MCP Guide

Use OMG QA from your AI agent

OMG QA 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 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 QA 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.omgqa.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.omgqa.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.omgqa.com/mcp", "headers": { "Authorization": "Bearer omg_live_•••••••••" } } } }

Any MCP client

{ "mcpServers": { "omgqa": { "type": "http", "url": "https://api.omgqa.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.

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

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 QA and it lands as test runs and findings (failures dedupe into findings automatically). One endpoint, one adapter per source:

POST https://api.omgqa.com/api/v1/ingest/{source}?projectId={id}
SourceAdapterPayload
genericFullOMG QA 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 QA, 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 QA — Capture Every Finding. Fix Faster.

Documentation · API Reference · MCP Guide · Home