API Governance MCP server

• get_decision_detailsFree

  Retrieve a PAST CodeRifts decision by exactly one identifier (case_id | decision_id | fingerprint): full report, breaking changes, scores, and linked receipt metadata if stored. Use this when: - You have a decision_id (or fingerprint) from a previous preflight, PR comment, or CI log and need to inspect or explain that past decision. - You are auditing why a prior ALLOW/WARN/BLOCK was issued. - You are NOT requesting a new analysis of current before/after specs. Do not use when: - You need a decision for the CURRENT uncommitted or PR head change set — call coderifts.preflight_change_set with the current artifacts. - You hold a receipt token and only need cryptographic/lifecycle verification — use coderifts.verify_receipt. - You have no identifier — run preflight first to create one. Inputs: exactly one of case_id, decision_id, or fingerprint. {} → INVALID_INPUT; two identifiers → LOOKUP_IDENTIFIER_CONFLICT; case_id → CASE_NOT_FOUND (lookup never opens a case). Returns the stored document or not_found. Scoping — fingerprint lookup returns only YOUR OWN decisions. A fingerprint is derived from content, not from an account, so two callers who preflight byte-identical specs derive the same one; the lookup is therefore constrained to the decisions your credential can prove it owns. A decision that exists but is not yours returns the SAME not_found as one that was never issued. This is deliberate: a distinguishable "exists but forbidden" would confirm to any caller that a given content hash had been decided on by someone, which is the fact the scoping exists to withhold. Do not read not_found as proof that no such decision exists anywhere. Decisions persisted without context.repository cannot currently be attributed to an account, and are not retrievable by fingerprint at all — not by their owner either. Retrieve those by decision_id, which is unchanged and unscoped. This is a limitation of what older stored rows carry, not a property of the lookup: rows written from now on record the account directly, so the gap narrows as older rows age out. If a fingerprint you expect returns not_found, use the decision_id before concluding the decision is missing. When the stored envelope carries control fields, control_envelope.next_agent_step is structured remediation guidance the agent MAY follow for non-CONTINUE execution_action values (null on CONTINUE*). Still branch on execution_action; next_agent_step is a suggestion, not permission.

• preflight_change_setFree

  Use this when: a contract artifact (OpenAPI, GraphQL, protobuf, AsyncAPI, MCP manifests, or agent tool schemas) changes before merge, deploy, publish, or tool registration; AND any agent-executed operation with no supported contract type — send type agent_operation. Do not call for documentation-only changes, static readiness scoring, or receipt verification. Use analyze for risk only; authorize requires context.operation. Skipping this call is not permission. Absence of a key is not permission. Inputs: preflight_mode is required: "analyze" (risk only; no receipt, no execution_action) or "authorize" (may mint a receipt; requires context.operation — merge is not deploy is not publish). Supply exactly one artifact source: artifacts[] (1–20 items, each {id, type, before, after} as the FULL spec/schema text, not a path or URL; type is openapi|graphql|grpc|asyncapi|mcp_manifest|agent_tools|agent_operation) XOR derivation="server" (server reads GitHub Compare; needs context.repository + context.base + context.head; sending artifacts[] together is 400). Grant fields sit in one object, execution_grant_request {include_execution_grant, grant_version, tenant_id, executor_id, adapter_id, target_uri, expected_state_token, state_nonce, audience, policy_hash}; analyze ignores it; required is preflight_mode only. previous_receipt is a chain token base64url(body).base64url(signature) to LINK a prior decision — it does not re-verify; use coderifts.verify_receipt instead; for details of a past decision use coderifts.get_decision_details instead. idempotency_key replays authorize only (24h), never analyze.

• verify_receiptFree

  Verify a CodeRifts signed chain-receipt you ALREADY HOLD: cryptographic authenticity (signature + key id), body binding, and — when lifecycle indices are available — whether it is currently valid authorization (not expired, superseded, or revoked) for a stated operation/target. Use this when: - You already obtained a chain_receipt / receipt token from a prior preflight (or CI artifact) and are about to act (merge/deploy) under that receipt. - A contract-gate or policy requires offline/online proof that the receipt is authentic for this change before proceeding. - You must distinguish "signature ok" from "currently authorized" (stale or superseded receipts must not be treated as live approval). Do not use when: - You do not have a receipt yet — call coderifts.preflight_change_set first. - You need a NEW decision for a changed base→head set — preflight again; verify_receipt does not re-diff specs. - The receipt you hold binds a different operation or target than the one you are about to perform — call coderifts.preflight_change_set with context.operation set to that operation (a merge receipt does not authorize a deploy); verify_receipt cannot re-scope or re-issue a decision. - You only need human-readable history of an old decision_id without a receipt token — use coderifts.get_decision_details. - The change set itself is unknown or incomplete — fix the change set and preflight; do not "verify" a placeholder. Inputs: receipt token (required); target_id = decision_result.artifact_digest — required for an authorization verdict; omitted → target_not_stated. Optional intended context (operation, environment, fingerprint, audience, repository/branch/pull_request, base/head) and the body_hash-bound decision_result envelope. 30s clock-skew leeway on expiry. A 0s grace for declared destructive production operations is defined in the policy but is unreachable today: the intended-context schema has no destructive field, so nothing can declare one and the 30s leeway always applies. Returns { valid, status, currently_authorized (bool|null), reason, payload, authz_* }. Branch on currently_authorized; null = not evaluated. When a decision envelope is also in hand (e.g. from a prior preflight), its control_envelope.next_agent_step (if present) is structured remediation guidance the agent MAY follow after a non-CONTINUE decision — still branch on execution_action; next_agent_step is suggestion, not permission.

• –Code scanremote-only server, no package to scann/a
• Live reliabilityremote reachable in 906ms20/20
• Tool poisoning3 tool descriptions checked13/15
• Auth qualityAPI key sent as a header8/15
• Maintenancelast push 0 days ago15/15
• Maintainer identityregistry namespace matches repository owner7/10

Safety score

84/100

higher than 68% of 48,243 servers

Tools

3

the typical server has 7

Tools that change things

0%

typical: 0%. Fewer write tools means less an agent can break

Uptime

100%

of our recent checks; the typical remote server answers 100%

Response time

74 ms

faster than 89% of 30,027 servers

API Governance: common questions

Is API Governance MCP server safe?

Mostly: it is graded B (84/100). Read the API Governance safety report

How do I install API Governance?

It runs remotely at app.coderifts.com. Add it to Claude Code, Cursor, VS Code or Claude Desktop with the snippets above, or call it through the mcp.market gateway without installing anything.

Does API Governance need an API key?

Yes. The registry entry asks for Authorization.

Is API Governance maintained?

The last commit was 33 days ago (2026-10-03). The latest release is v1.0.3.

Is API Governance up?

100% of our last 28 checks got an answer. We check remote servers about four times a day.

How does API Governance compare with other MCP servers?

safety score 84/100 (higher than 68% of 48,243 servers); tools 3 (the typical server has 7); tools that change things 0% (typical: 0%. Fewer write tools means less an agent can break). Full comparison.