How the BugMojo MCP Server Works: Bugs Your AI Agent Can Actually Read

Plenty of bug trackers now ship an MCP server. That is no longer a differentiator. The interesting questions are narrower: what crosses the wire on a tool call, what the payload actually carries, and whether the AI on the other end is a guest with read access or a team member that can own work. This is an architecture deep dive into the BugMojo MCP server — the 14 tools, the thin-client-over-REST design, the polymorphic AGENT assignee, and a real JSON-RPC transcript. It assumes you already know what MCP is; if you don't, start with our developer's primer on MCP. And if you just want to wire it up, the connect-Claude-Code guide is the install walkthrough — this page is the why, not the how.

MCP tools are model-controlled: the LLM discovers them and decides when to call them, with no glue code from you. The spec also asks the client to keep a human in the loop — to surface a tool's inputs and request confirmation before the server is hit. BugMojo leans on that exactly. Write tools like create_bug and update_bug surface their JSON arguments in Claude Code before anything commits, so you approve the precise mutation, not a vague intent.

The server itself is deliberately boring. The entry file describes it as "a thin client that translates MCP tool calls into HTTP API calls to the BugMojo backend. All business logic lives on the backend, not here." That sentence is the whole design philosophy, and the rest of this article is the consequences of taking it seriously.

Every tool is registered with a Zod input schema, so the model receives a typed inputSchema in tools/list and knows the valid fields and enums before it ever calls. The 14 split cleanly into three families:

The split matters for safety. An agent doing read-only triage only needs the read tools; an agent that fixes and verifies needs the write tools. Because the family boundary is explicit, you can scope an API key to exactly the surface a given agent should touch — more on that in the security section.

This is the row no other issue-tracker MCP has. When Anthropic open-sourced MCP in November 2024, the reference servers covered Google Drive, Slack, GitHub, Git, Postgres, and Puppeteer. None of them — and none of the early adopters since — model an AI agent as a thing a task can be assigned to. They model the agent as a thing that calls the API. That distinction sounds academic until you watch a workflow run end to end.

In BugMojo, both create_bug and update_bug accept an assignee_type enum alongside the assignee_id. Set it to AGENT and the bug is owned by, say, a QA agent. The agent finds its work with get_agent_tasks, takes it with claim_agent_task (an atomic QUEUED → RUNNING transition so two agents can't grab the same task), and reports back with update_agent_task. The same add_comment a human uses is the channel the agent uses. There is no separate "bot API"; the polymorphism is the whole point.

Abstractions are easy to nod along to. Here is the actual wire. Three messages, in order: the discovery handshake, the call, and a self-correction round where the model fixes its own bad argument. This is the shape you'll see if you turn on MCP debug logging in Claude Code.

1. Discovery. The client asks what's available. The server answers with typed schemas (truncated here to one tool for space):

2. The call. The model decides to search for open high-priority checkout bugs and emits a tools/call. The server forwards it to GET /api/v1/bugs/search and returns the REST JSON inside content[].text — a string, because MCP tool results are content blocks, not raw objects:

3. Self-correction. Suppose the model first guessed a wrong enum (priority: "P1"). The Zod schema rejects it, the server returns a recoverable error with isError: true, the model reads the message, fixes the argument, and retries. The human never has to intervene:

The server holds zero business logic. Each tool builds a path, calls one of get/post/patch on a tiny HTTP client, and serializes the result. The client adds a Bearer header and maps status codes to readable errors — 401 becomes "Authentication failed... check your BUGMOJO_API_KEY," 403 becomes "Permission denied... your API key may lack the required permissions." That is the entire client:

Three things fall out of this choice, and they're the reason it's worth defending. One: the protocol and the product evolve independently. Permissions, rate limits, validation, and audit logging live on the backend, where they're tested once and apply to every caller — the web UI, the extension, and the MCP server all hit the same /api/v1. Two: the published npm package stays tiny and auditable. A reviewer can read the entire server in one sitting and confirm it only talks to your configured host. Three: it honors a core BugMojo principle — every entity is reachable through the same tRPC/REST API, so a human in the dashboard and an agent over MCP are operating on identical surfaces, never a forked "agent backend" that drifts out of sync.

The server connects over StdioServerTransport — it is a child process Claude Code spawns and talks to over stdin/stdout. Nothing listens on a port; nothing is exposed to the network beyond the outbound calls the tools make. Your bm_key_ key is read from the environment in the local config and used as a Bearer token against the base URL you set. There is no BugMojo-operated middle tier in the path.

One caveat worth stating plainly, because the Claude Code docs do: MCP servers can be a prompt-injection vector. A tool result is text the model reads, and a hostile bug title could in principle carry an instruction. BugMojo's mitigations are the human-in-the-loop confirmation on writes and API-key scoping on what an agent can reach — but you should still only connect MCP servers, and ingest bug data, from sources you trust.

Competitors already ship MCP servers, and some are more capable than BugMojo on their home turf. Sentry's MCP lets developers query production errors and issues straight from the IDE; Atlassian's Remote MCP Server lets Claude summarize work and create Jira issues inside permissioned boundaries. Both are legitimately good. The point of this table is not to claim BugMojo wins everywhere — it doesn't — but to isolate the one capability the issue-tracker MCP servers shipping today don't have.

Read that table both directions. If your problem is production exception monitoring at scale, Sentry is more mature and you should use it. If your problem is enterprise workflow governance, Jira's admin depth is unmatched and BugMojo isn't trying to replace it — it pushes captured bugs into Jira (see BugMojo vs Jira). The single row that flips is the last conceptual one: a bug an agent can own, carrying a replayable repro, is a capability with no equivalent in the issue-tracker MCP servers shipping in mid-2026.

Some context for why this is worth building against now and not in two years. MCP turned one year old on 25 November 2025. By that anniversary the official registry held close to 2,000 server entries — a 407% jump from the first batch onboarded in September 2025 — with more than 2,900 contributors on the MCP Discord. The bug-tracker category inside that registry is exactly where BugMojo's 14-tool server competes, and the protocol is now stable enough that the November 2025 spec is the version to target, not the 2024 launch docs.