The usual options for pushing bugs from a QA tool into a tracker are: a CSV export, a webhook, a one-off REST integration per tracker, or an email template. We tried the first three. The fourth is too sad to discuss.
For NSPEC we dropped all of them in favour of Model Context Protocol (MCP). This is what changed.
Why MCP instead of custom REST clients
A tracker integration has three parts you can’t avoid:
- Authorization to act on the user’s behalf.
- A schema of what fields the tracker understands.
- A mapping from your domain objects to that schema.
Every tracker asks for parts 1 and 2 slightly differently. Jira Cloud wants OAuth2 with a specific scopes payload and an Atlassian-hosted callback. Linear wants a scoped API key or OAuth2 with their own dance. GitHub Issues wants a GitHub App installation on a specific org and repo. Notion wants an integration token bound to a workspace.
Before MCP, that meant three or four custom clients, each with its own auth state, its own rate-limit story, its own retry semantics, and its own SDK version bump every quarter. The code was mostly plumbing.
MCP turns the tracker into a named server with a known tool surface. NSPEC connects to jira.mcp.atlassian.com (or a local MCP shim, for self-hosted Jira / Linear / GitHub) and asks what tools it exposes: create_issue, update_issue, add_comment, list_projects. The shape of the call is standardized. The auth lives at the MCP session layer. Our code doesn’t ship a Jira SDK any more.
That’s the primary reason. There’s a secondary one: MCP is where agents are going anyway. If a customer’s internal agent network speaks MCP, they can plug NSPEC’s findings directly into their own workflows without building a bespoke connector.
The ticket body
Every verified NSPEC bug maps to the same ticket shape, regardless of which tracker it lands in:
- Title · one sentence, benefit-for-user framing. Example: Impossible RTP values displayed on game detail page.
- Repro · numbered steps, executable.
- Acceptance criteria · testable and binary.
- Severity · P1/P2/P3 with a short rationale.
- Suggested owner · inferred from git-file ownership (opt-in).
- Evidence attachments· the full bundle, uploaded via the tracker’s native attachment API so they live with the ticket forever.
- Link back to the run report for audit.
Severity → priority mapping
No two trackers agree on priority levels. Jira has P1–P5 defaults. Linear has Urgent / High / Medium / Low / None. GitHub Issues doesn’t have priority at all, just labels.
NSPEC’s internal severity vocabulary is the small one — P1/P2/P3 — and the tracker integration holds a configurable mapping per workspace. The default maps P1 to the highest priority the tracker offers, P2 to the second, and P3 to the third. For GitHub Issues we create labels (nspec/p1, nspec/p2, nspec/p3) scoped under a prefix you can rename.
Idempotency and why it stops mattering
With webhooks, you spend half the integration time worrying about duplicate tickets when a webhook fires twice. With MCP, the client holds session state and uses a stable bug_id as an idempotency key on create_issue. If the agent retries, the tracker either returns the existing ticket or updates it in place. No duplicates in seven weeks of internal runs.
Owner inference (opt-in only)
If you opt in to git-diff based prioritization, NSPEC also reads CODEOWNERSand the git blame for the file that contains the offending element (where we can map DOM to file). The inferred owner goes on the ticket as a suggested assignee, never as a hard assignee — we don’t want to surprise people with auto-assignments.
What we still can’t do (yet)
- Notion pages (on the roadmap; MCP server for Notion exists and works, we just need to do the field-mapping UI).
- Asana (on the roadmap).
- Azure DevOps (on the roadmap; lower priority based on beta signal).
- Two-way sync (a ticket’s comments flowing back into the NSPEC run view). Not hard, not shipped.
Why this matters on the buyer side
Most QA tools file a PDF or a CSV and call it “integration.” NSPEC files a ticket. The difference between “a report landed in my inbox” and “a ticket exists in our backlog with the right owner, the right priority, and the evidence attached” is the difference between QA-as-receipt and QA-as-work.
Get early access. First cohort plugs into Jira, Linear, and GitHub at launch.