API governance for AI agents. Detects breaking changes, scores blast radius, blocks unsafe calls.
Retrieve a PAST CodeRifts decision by decision_id (or fingerprint): full report payload, breaking changes list, 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 decision_id/fingerprint — run preflight first to create one.
Inputs: at least one of decision_id (preferred) or fingerprint is required (empty {} is rejected by the server as INVALID_INPUT). Returns the stored decision 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.
| Name | Required | Description | Default |
|---|---|---|---|
| decision_id | No | The decision_id from a prior decision_result envelope. Provide this and/or fingerprint (at least one non-empty string required). | |
| fingerprint | No | A verdict fingerprint (sha256:...); returns the latest matching decision. Provide this and/or decision_id (at least one non-empty string required). |
| Name | Required | Description |
|---|---|---|
| meta | Yes | |
| decision | No | |
| evidence | No | |
| patterns | No | |
| operation | No | |
| timestamp | No | |
| risk_score | No | |
| receipt_kind | No | |
| chain_receipt | No | |
| preflight_mode | No | |
| safe_for_agent | No | |
| decision_result | Yes | decision-result.v1 envelope (control enums closed). Additive fields may appear and are not permission. Full schema: https://coderifts.com/schemas/decision-result.v1.consumer.json (producer: https://coderifts.com/schemas/decision-result.v1.producer.json). |
| pattern_sources | No | |
| breaking_changes | No | |
| control_envelope | No | Control envelope (control/1.0) derived from the stored decision_result. Includes next_agent_step (structured remediation SUGGESTION for non-CONTINUE execution_action; null on CONTINUE*; not permission — still branch on execution_action). |
| evidence_quality | No | |
| execution_action | No | |
| coderifts_version | No | |
| requires_migration | No | |
| verdict_fingerprint | No | |
| required_action_core | No | Branchable required-action core { type, reason_code, recheck_required } when present on the envelope. |
| decision_spec_version | No | |
| decision_semantic_hash | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, but the description adds substantial non-obvious behavior: fingerprint scoping to own decisions, deliberate identical not_found for forbidden lookups, legacy rows not retrievable by fingerprint, and the meaning of control_envelope.next_agent_step. This goes well beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections and front-loaded purpose, but it is quite lengthy and includes some details that slightly overlap with the schema (e.g., empty {} rejection) and an extended legacy-row explanation that could be tightened. Still, nearly every sentence carries useful behavioral information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (scoped lookups, legacy limitations, not_found semantics, control_envelope hints), the description covers all critical aspects an agent needs to call it correctly. The presence of an output schema means return-value details do not need to be in the description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although the input schema has 100% parameter coverage, the description adds meaningful semantics beyond it: decision_id is preferred, fingerprint is content-derived and scoped to the caller's own decisions, decision_id is unscoped, and a fallback strategy is provided when fingerprint returns not_found. This enhances the agent's ability to choose and combine the parameters correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('Retrieve'), a clear resource ('a PAST CodeRifts decision'), and the key identifiers (decision_id or fingerprint). It explicitly enumerates what the payload contains (report, breaking changes, scores, receipt metadata) and distinguishes itself from sibling tools by focusing on past decisions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit 'Use this when' and 'Do not use when' sections, naming the exact alternatives (preflight_change_set, verify_receipt) and the conditions that trigger them. This is the clearest possible routing guidance for an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when: a change set of contract artifacts modifies OpenAPI, GraphQL, protobuf, AsyncAPI, MCP manifests, or agent tool schemas before merge, deploy, publish, or tool registration. Do not call for documentation-only changes, static readiness scoring, or receipt verification. Use analyze for risk only; authorize requires context.operation for permission. For receipt verification use coderifts.verify_receipt instead; for details of a past decision use coderifts.get_decision_details instead.
| Name | Required | Description | Default |
|---|---|---|---|
| context | No | Optional apply-site context folded into the bundle fingerprint. operation distinguishes merge vs deploy vs publish (and other labels); the server accepts any string for operation (change-set.js) — conventional values below. | |
| audience | No | Requester identity for the decision envelope. Accepted here; the server-derived audience wins when both are present. | |
| artifacts | No | Contract artifacts to analyze together (max 20). Each is { id, type, before, after }. | |
| tenant_id | No | Tenant the grant is issued under (cr.exec.v2). Defaults to "default" when absent. | |
| adapter_id | No | Adapter the executor will apply the change with, e.g. fs, postgres, git (cr.exec.v2). | |
| derivation | No | Opt-in (ID637 6b). "server" = the server derives artifacts[] from GitHub Compare via the App installation. Allowed only when the tenant has a proven binding for context.repository and context.base + context.head are present. Omit artifacts[] (caller-supplied artifacts[] with this flag is 400 — one source of truth). Default absent = today's caller-artifacts path (byte-identical). | |
| target_uri | No | Target the grant is bound to (cr.exec.v2). Falls back to context.target_uri, then to a repository/head-derived value. | |
| executor_id | No | Identity of the executor the grant is bound to (cr.exec.v2). | |
| policy_hash | No | Policy identity the grant is issued under (cr.exec.v2). Bound into the signed grant when supplied. | |
| state_nonce | No | Optional ATOMIC-profile nonce. When include_execution_grant is true, copied into the signed grant as state_nonce (a separate signed field — NOT folded into scope_hash). Absent → BEARER grant (today's default). See docs/cr-exec-v1.md. | |
| grant_version | No | Grant envelope to mint when include_execution_grant is true. MIGRATION: omitting this yields cr.exec.v1 until 2026-09-18 and cr.exec.v2 on and after it; the response carries grant_version_deprecation while the old default is still in effect. An explicit value always wins, before and after the cutoff — pin "v1" to keep the current behaviour with no code change on the date. | v2 |
| preflight_mode | Yes | REQUIRED. "analyze" = informational risk only (no decision/execution_action/safe_for_agent; analysis_outcome + may_execute:false). "authorize" = operation-bound path; may mint a receipt (requires context.operation). Decision Spec 2.0: omission is an error unless decision_spec_version is '1.0' (30-day legacy pin with soft-default analyze). | |
| idempotency_key | No | Optional client key; in authorize mode, a repeat with the same key + body replays the original decision (24h). Analyze responses are not replayed. | |
| previous_receipt | No | Optional prior chain receipt token to link | |
| expected_state_token | No | State token the executor expects to observe at apply time (cr.exec.v2). Signed as a separate field; empty string when absent. | |
| decision_spec_version | No | Optional pin. '1.0' = legacy contract (soft-default mode + analyze still carries decision/execution_action) until the sunset date. Omit or '2.0' = current contract. | |
| include_execution_grant | No | Opt-in (authorize only). When true on allow-class authorize, the response includes a signed execution_grant (cr.exec.v1) alongside chain_receipt, or HTTP 503 SIGNER_UNAVAILABLE — never unsigned. Default false. Analyze ignores this flag. See docs/cr-exec-v1.md. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only indicate non-read-only and non-open-world. The description adds substantial behavioral context: analyze is informational (no decision/execution_action, may_execute:false), authorize may mint a receipt and require context.operation, include_execution_grant can return a signed execution_grant or 503, idempotency_key replays decisions for 24h, and grant_version migration behavior. It does not fully disclose all side effects (e.g., what happens on rejection) but covers the main behavioral modes well.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but every sentence serves a purpose. It front-loads the primary usage condition and exclusions, then routes to alternatives. The prose is dense but not padded; it efficiently covers multiple modes and edge cases. Slightly verbose but justified given the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 17 parameters, 100% schema coverage, an output schema, and nested objects, the description covers the key decision points: when to use, mode distinctions, authorization requirements, receipt/grant behavior, and alternatives. It does not explain every edge case (e.g., exact response structure is left to output schema) but is sufficiently complete for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline 3. The description adds meaningful semantics beyond schema: explains preflight_mode's analyze vs authorize difference, notes operation accepts any string but conventional values (merge, deploy, tool_call, publish), clarifies context.operation is required for authorize, and describes derivation flag's server-side artifact derivation with constraints. This enriches parameter understanding without redundancy.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (preflight) and resource (change set of contract artifacts) with clear scope (OpenAPI, GraphQL, protobuf, AsyncAPI, MCP manifests, or agent tool schemas before merge, deploy, publish, or tool registration). Explicitly distinguishes from siblings by naming verify_receipt and get_decision_details as alternatives, making it unambiguous what this tool is for.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use conditions (modifying contract artifacts before merge/deploy/publish/registration) and when-not-to (documentation-only, static readiness, receipt verification). Names the alternatives (coderifts.verify_receipt, coderifts.get_decision_details) and the mode-specific guidance (analyze vs authorize). Nothing is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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); optional intended context (operation, environment, fingerprint, target_id, 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.
| Name | Required | Description | Default |
|---|---|---|---|
| base | No | Intended base commit/ref SHA the receipt must match (signed-wins vs envelope.base) | |
| head | No | Intended head commit/ref SHA the receipt must match (signed-wins vs envelope.head) | |
| token | Yes | The chain receipt token (base64url(body).base64url(signature)) | |
| branch | No | Intended branch the receipt must bind (place binding; optional) | |
| audience | No | Intended audience — must match the receipt | |
| operation | No | Intended operation the receipt must authorize (conventional: merge|deploy|tool_call|publish). Triggers authorization evaluation when non-empty; supply decision_result for full scope binding. | |
| target_id | No | Intended apply-site target the receipt must bind | |
| repository | No | Intended repository the receipt must bind (place binding; optional) | |
| environment | No | Intended environment (e.g. production) — must match the receipt | |
| fingerprint | No | Intended change fingerprint — must equal the receipt fp | |
| pull_request | No | Intended pull-request id the receipt must bind (place binding; optional) | |
| decision_result | No | The body_hash-bound decision envelope (carries operation/target/decision). Required for a meaningful AUTHORIZATION evaluation of scope; without it, intended context alone fails closed on authorization (currently_authorized false) while signature status remains independent. Full schema: https://coderifts.com/schemas/decision-result.v1.consumer.json. |
| Name | Required | Description |
|---|---|---|
| valid | Yes | true iff status is VERIFIED_CURRENT or RETIRED_KEY_VALID_AT_ISSUE |
| reason | No | |
| status | Yes | |
| payload | No | |
| authz_note | No | Present when no intended context supplied: status reflects signature+expiry only |
| authz_state | No | Lifecycle state from isCurrentlyAuthorized when authorization is evaluated (optional; omitted when currently_authorized is null) |
| authz_reason | No | When currently_authorized=false: the deny reason (operation_mismatch, decision_not_allow, superseded, expired, target_mismatch, environment_mismatch, …) |
| authz_status | No | Authorization-level status (VERIFIED_WRONG_ENVIRONMENT / VERIFIED_SUPERSEDED / VERIFIED_SCOPE_MISMATCH / …) |
| caller_value | No | Caller claim that differed from the signed envelope |
| signed_value | No | Signed envelope slot when signed-wins fail-closed (source_binding_mismatch) |
| binding_level | No | place_and_content | content_only — forensic, not a second verdict |
| correlation_id | No | Route-owned trace id (ID828); always a non-empty string on 200 |
| currently_authorized | Yes | Whether the receipt currently authorizes the intended operation/target/fp (§106). null means authorization could not be evaluated (e.g. no intended context) — not unauthorized and not authorized. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond readOnlyHint=true, the description discloses the 30s clock-skew leeway, the unreachable 0s destructive-production grace, fail-closed authorization when the envelope is omitted, return semantics with currently_authorized null, and next_agent_step being advisory. No annotation contradiction; this goes well beyond what annotations and schema already state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description front-loads the core purpose, then uses scannable bullets for when/do-not-use, then compactly adds operational details and return guidance. It is dense, but every sentence carries a distinct fact relevant to invoking or interpreting the tool; there is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex 12-parameter verification tool with nested objects and an output schema, it covers prerequisites, mode selection, edge cases, return branching, and sibling routing. The existing output schema makes detailed return documentation unnecessary, and the description still gives the essential branching pointer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema coverage is 100%, the description adds meaning that the schema alone does not: two evaluation modes, token-only acceptance, fail-closed behavior when intended context is present but the decision envelope is omitted, and the need for decision_result for full scope binding. This materially helps an agent construct correct calls.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific action and resource: verify a chain-receipt you ALREADY HOLD, covering signature authenticity, body binding, and authorization status. It also differentiates itself from preflight_change_set and get_decision_details in the Do-not-use section, so an agent can distinguish it from siblings without inspecting schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit 'Use this when' and 'Do not use when' blocks specify the exact conditions: holding an existing receipt, about to act, needing proof, and needing to distinguish signature-ok from authorized. It names sibling tools and states when to call them instead, such as preflight for new decisions and get_decision_details for history without a receipt token.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user or an account that owns the GitHub organization, then choose Claim with GitHub.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
Deterministic runtime safety for AI agents: scan PII, gate tool actions, verify LLM output.
Zero-trust gateway for AI agents: score tool calls, verify agent cards, enforce policy, audit.
Pre-execution governance for AI agents. Deterministic PASS/FAIL/REVIEW verdicts, replayable proof.
The WAF for agents. Pattern-based + heuristic firewall scans prompts, RAG documents, tool argume...
Add one secure layer between your agents and this server.
The three tools have clearly distinct purposes: preflight_change_set creates new decisions, get_decision_details retrieves past decisions, and verify_receipt checks receipt validity. Some semantic overlap exists between get_decision_details and verify_receipt (both inspect prior outcomes), but the detailed usage guidance disambiguates them effectively.
Tool names follow a consistent verb_noun pattern (get_decision_details, preflight_change_set, verify_receipt). Minor inconsistency: preflight_change_set uses a compound noun while the others use verb_object, but all are snake_case with clear verbs.
Three tools is a reasonable, minimal surface for an API governance decision workflow: analyze/decide, retrieve past decisions, and verify receipts. The count feels slightly thin for a governance server (e.g., no tool for listing decisions or managing rules), but it is well-scoped for its stated purpose.
The core lifecycle is covered: preflight creates the decision, get_decision_details retrieves it, verify_receipt validates authorization. Minor gaps include no explicit analyze-only or authorize-only split (mentioned in the preflight description but not exposed as separate tools) and no listing/cancellation capability.
