MCP Guide

Use OMG IQ from your AI agent

OMG IQ runs a Model Context Protocol server, so an AI coding agent — Claude Code, Cursor, Codex, or anything MCP-compatible — can search, read, create, and move findings — and plan and run the backlog (epics, stories, sprints) — without leaving its context. The agent works the same data your team does, with the same permissions.

What is MCP?

Model Context Protocol is an open standard for connecting AI agents to external tools. Instead of pasting logs into a chat, the agent calls typed tools directly. OMG IQ exposes its quality workflow as MCP tools so an agent can, for example, "find the open Safari checkout regression, read its trace, and re-open it" in one turn.

1-step install

The MCP endpoint is:

https://api.omgiq.com/mcp

First, generate an API key under Account → API keys. Keys are project-scoped by default (least privilege): the agent can only see and act on the one project you pick — it cannot read or touch findings in any other project, enforced on the server. Grant it only the scopes it needs (a read-only key can search and read but never mutate); “entire workspace” is a deliberate, broader choice. Then paste one of the configs below and replace the token.

Claude Code

Add the server with a single command (or drop the JSON into ~/.claude.json). Use --scope user to make it available in every repo on your machine, or --scope project to register it only for the current repo (writes a .mcp.json in that repo — handy when each repo maps to a different workspace):

claude mcp add --scope user --transport http omgqa https://api.omgiq.com/mcp \ --header "Authorization: Bearer omg_live_•••••••••"

The API key already binds to one workspace, so no other header is needed — in particular you do not send X-Org-Slug (that is only for interactive user logins).

Cursor

Add to ~/.cursor/mcp.json (or the project's .cursor/mcp.json):

{ "mcpServers": { "omgqa": { "url": "https://api.omgiq.com/mcp", "headers": { "Authorization": "Bearer omg_live_•••••••••" } } } }

Any MCP client

{ "mcpServers": { "omgqa": { "type": "http", "url": "https://api.omgiq.com/mcp", "headers": { "Authorization": "Bearer omg_live_•••••••••" } } } }
MCP directories can discover the server from its machine-readable manifest at /.well-known/mcp (also at /mcp/manifest) — it lists the server name, description, every tool and how to authenticate.
Which workspace, and which project? The API key is the boundary — and by default it is scoped to a single project, so an agent's reach is exactly one project.
  • Workspace is fixed by the key — each key belongs to one workspace, so the agent never chooses one and no header selects it.
  • Project — with a project-scoped key (the default) the agent is locked to that project: list_projects returns only it, and any search_findings / create_finding / finding lookup for another project is rejected on the server (not found / forbidden). A workspace-scoped key (the broader, opt-in choice) instead lets the agent pick a project per call via list_projects + projectId.
Running Claude across several projects on one machine? Give each repo its own project-scoped key, so the agent in one repo physically cannot see another project's findings:
  • Register one server per repo with --scope project (each repo's .mcp.json carries its own project key), or give each a distinct name — omgqa-acme, omgqa-globex.
  • This holds even for two projects in the same workspace: two project-scoped keys keep them isolated. Only reach for a workspace-scoped key when one agent genuinely needs several projects at once (e.g. a cross-project report).

Tools

ToolWhat it does
list_projectsList the projects in the current organization.
search_findingsList/filter findings in a project by status, paged.
search_findings_textFull-text search findings across the org.
find_similar_findingsSemantic neighbours of a finding (duplicate detection).
get_finding_detailsGet the full details of a finding by id.
get_finding_evidenceList a finding's evidence attachments (metadata).
download_evidenceShort-lived download URL for an attachment's bytes (screenshots, traces, logs).
list_test_runsList recent automated test runs for a project (read).
get_project_analyticsRelease-readiness rollup for a project (read).
create_findingFile a new finding (type, severity, priority, description).
transition_findingMove a finding through its workflow (e.g. triage → in progress → resolved).
upload_evidenceAttach evidence to a finding (returns an upload URL).
complete_evidenceConfirm an evidence upload finished (after PUTting the bytes).
add_commentAdd a comment (or internal note) to a finding.
request_retestMove a finding to ReadyForRetest after a fix ships.
link_prLink a pull request / commit / issue to a finding.
link_finding_commitLink a git commit to a finding by SHA (repository is enough — OMGQA builds the commit URL), so record_deployment can resolve it.

The write tools (create_finding, transition_finding, upload_evidence, add_comment, request_retest, link_pr, link_finding_commit) all run through the same agent governance gate: the per-agent policy (read-only / approval / autonomous), the tool allow-list and the hourly cap are enforced, and every decision is audited.

Plan & backlog tools

OMG IQ isn't only findings. The same MCP server — same key, same governance gate — also exposes the epics & stories layer, so an agent can read your roadmap, author and triage work, move it through the workflow, and wire up the whole structure: modules, cross-module contracts, roadmap decisions and sprints. Each story body is materialized as a BMad .md, so nothing is lost.

ToolWhat it does
list_modules / list_epics / list_storiesRead the module catalog, epics, and stories (filter by epic / state / module / assignee).
get_story_detailsGet a full story — body, state, priority, labels, links, and its comment thread inline (the human context behind the work).
list_story_commentsPull just a story's comments (the discussion thread) for context.
add_story_commentAdd a comment to a story's thread — write context (repro, root cause, decision) back for humans and other agents.
create_epicCreate an epic; its key prefixes the stories under it.
create_storyCreate or upsert a story in one call — module, labels, priority, initial state, and your own external key.
classify_story / prioritize_story / move_stateSet module & labels, set priority & sprint, step it through the workflow.
assign_story / develop_story / publish_storyAssign to a user, start development, publish a ready story.
link_related / reference_documentLink related stories (Blocks / BlockedBy / …) and attach supporting documents.
submit_triage / create_story_from_requestCapture intent in the triage inbox, then convert it into a story.
create_module / set_module_metadata / create_contract / create_decision / create_cycle / create_documentAuthor the project structure: module catalog, cross-module contracts, roadmap decisions, sprints, and documents.
get_story_by_external_keyResolve a story by your own key — for idempotent checks and resuming a migration.

Migrate a whole backlog in one call

import_structure pushes an entire project — modules, epics, stories, their links and documents — in a single governed call instead of hundreds of round-trips. It's idempotent and resumable: modules are upserted by name, epics by key, and stories by your own externalKey, so re-running after an interruption updates in place instead of duplicating. In approval mode the whole import is one approval, replayed once.

import_structure(structureJson = { "projectId": "…", "modules": [{ "name": "Checkout", "phase": "LIVE" }], "epics": [{ "key": "CDP", "title": "Customer Data Platform" }], "stories": [{ "externalKey": "CDP-E1-S1", "epicKey": "CDP", "title": "Lock down CORS", "state": "Done", "priority": "high", "labels": ["security"], "related": [{ "relatedExternalKey": "CDP-E1-S2", "relation": "BlockedBy" }] }] })

Every write here runs through the same agent governance gate as the finding tools — per-key mode, allow-list, hourly cap, and a full audit trail.

Coordination, review & the acceptance gate

When a whole fleet of agents works the backlog at once, they coordinate through OMG IQ rather than colliding: they register by role, atomically claim the next ready item, funnel every change through one serialized merge lane, and stop at the human acceptance gate.

ToolWhat it does
register_worker / heartbeat_worker / deregister_worker / list_workersJoin the fleet under a role, keep a live heartbeat, and see who's active.
claim_next / claim_next_findingAtomically claim the next ready story (or finding) for your role — no two agents take the same work.
get_work_queue / set_work_queue_scope / order_queue / list_claimable_findingsRead and shape the shared work queue.
submit_for_merge / list_merge_queue / merge_status / resolve_mergeHand a change to the single serialized merge lane and track it through.
submit_review / record_review_outcome / record_gate_outcomeRecord review and quality-gate results on the work.
request_retest / accept_storyMove work to the gate — accept_story (human-only) is what crosses it to Done.
set_acceptance_criteria / mark_acceptance_criterionDefine a story's acceptance criteria and tick them off.
raise_decision_request / answer_decision_request / list_decision_requestsEscalate a call to a human's decisions inbox, and read the answer.
record_deployment / get_last_deployment / link_commitRecord what shipped and wire deployments to the stories and findings in them.
get_roadmap / get_workflow_funnel / get_eventsRead the roadmap, the delivery funnel, and the live coordination event stream.
The gate holds here too. Agents reach Ready for Acceptance / Ready for Retest; only a human calls accept_story or resolves a finding. Every tool runs under the same per-agent governance — mode, allow-list, hourly cap, audit.

Guardrails for agent writes

Giving an agent write access shouldn't mean giving up control. Every agent (API key) acts under an explicit, per-key governance policy rather than ambient trust — directly addressing OWASP "excessive agency". The policy has four independent dials:

Mode

Read-only blocks all mutating tools. Approval (the safe default) queues each write for an admin to approve in the app, then runs it. Autonomous lets writes apply immediately — still inside the key's scopes and allow-list.

Tool allow-list

Restrict a key to a named subset of tools (e.g. let it create_finding and add_comment but never transition_finding). An empty list means "all tools the key's scopes already permit".

Hourly rate cap

An optional per-agent ceiling on write actions per hour bounds the blast radius of a runaway or compromised agent.

Org override & full audit

An org-wide policy can tighten every agent at once, and each gate decision — allowed, queued, denied, or rate-limited — is written to the tamper-evident audit log.

This sits on top of the project-scoped key boundary above: by default a key can only see and act on a single project (see scoping), and the governance policy then bounds what it may do within that project. Defense in depth — the scope limits reach, the policy limits authority.

Ingest from agentic QA tools

Already running an agentic test tool? Post its output straight to OMG IQ and it lands as test runs and findings (failures dedupe into findings automatically). One endpoint, one adapter per source:

POST https://api.omgiq.com/api/v1/ingest/{source}?projectId={id}
SourceAdapterPayload
genericFullOMG IQ normalized JSON: { run, results[], findings[] }.
playwright-mcpFullPlaywright JSON report (suites → specs → tests → results).
momenticDocumented{ run, results[] } — name, status, durationMs, error.
mablDocumented{ metadata, testResults[] } — name, status, failureReason.
qawolfDocumented{ runs[] } — name, status, url, error.

The generic adapter lets any tool integrate today by emitting the normalized shape; the named adapters map a vendor payload onto it. Either way, ingestion reuses the same create paths as the rest of OMG IQ, so de-duplication applies.

What an agent run looks like

A coding agent fixing a regression might chain:

# 1. find the regression search_findings_text(query="safari checkout") # 2. read it + its evidence (the failing trace) get_finding_details(findingId="…") get_finding_evidence(findingId="…") # 3. check it isn't a duplicate find_similar_findings(findingId="…", limit=5) # 4. after shipping the fix PR, move it forward transition_finding(findingId="…", status="In Review")
Prefer plain HTTP? Every tool maps to a REST endpoint — see the API Reference.

OMG IQ — Capture Every Finding. Fix Faster.

Documentation · API Reference · MCP Guide · Home