Use OMG IQ from your AI agent

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:

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):

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):

Any MCP client

Tools

The write tools (create_finding, transition_finding, upload_evidence, add_comment, request_acceptance, 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.

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.

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.

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:

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:

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.

How agents read findings

Agents pull findings from OMG IQ the same way a person would in the UI — they search, fetch one, and read the evidence — but they do it through typed MCP tools instead of clicking. Every read is scoped to the agent's project, attributed to the API key, and counted in the audit trail.

Search by text

When the agent has a rough idea of what it's looking for, full-text search ranks across the project's findings — title, description, comments, evidence captions:

Filter by status and severity

For a tighter query, list findings in the project and filter on the fields the UI exposes — status, severity, type, priority, assignee:

Fetch one finding, end-to-end

A finding id (returned from the searches above) is enough to read its body, its evidence attachments (trace, video, screenshot, HAR), the comments, and any duplicate neighbours — a single read pass:

How agents create findings

When an agent spots a quality signal of its own — a flaky test, a runtime exception, a console error, a code smell — it files a Finding the same way a human QA engineer would. The create path takes a small, stable shape (type, severity, priority, description), and the agent then enriches it with evidence and comments. Every create goes through the same agent governance gate as every other write.

File a finding

Attach evidence

Evidence uploads bypass the API (no bytes through the server). The agent asks for a short-lived signed URL, PUTs the file straight to storage, then confirms the upload so the attachment moves to Processed with a thumbnail:

Discuss and link

Findings are a conversation, not just a record — agents (and humans) thread comments onto them, link the PR that ships the fix, and walk the status forward. Each step is its own typed tool with its own audit entry:

Example tools & use cases

A representative tool from each family, and a concrete scenario where it shines — these are the same calls the reading and creating sections above compose into a full agent loop.