A
license-
qualityC
maintenanceEnables AI agents to map cross-repository dependencies, detect breaking changes in API contracts, and assess impact across services.
MIT
api-governance
Server Details
API governance for AI agents. Detects breaking changes, scores blast radius, blocks unsafe calls.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- coderifts/self-hosted
- GitHub Stars
- 0
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
MCP client
Glama
MCP server
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
100% free. Your data is private.
Tool Definition Quality
A4.9/5.0
Tool DescriptionsA
Average 4.8/5 across 3 of 3 tools scored.
Server CoherenceA
Disambiguation5/5
Each tool has a clearly distinct role in the decision lifecycle: preflight_change_set creates a new decision, get_decision_details retrieves past decision details, and verify_receipt validates an already-held receipt. The descriptions explicitly cross-reference when to use which, eliminating ambiguity even though two tools deal with past decisions.
Naming Consistency5/5
All three tool names follow the same verb_noun pattern with snake_case: get_decision_details, preflight_change_set, verify_receipt. The verbs (get, preflight, verify) clearly indicate the action, and the nouns (decision_details, change_set, receipt) indicate the object. Perfectly consistent.
Tool Count5/5
Three tools is an appropriate size for this narrow governance domain. They cover the essential operations: analyzing/authorizing a change, retrieving historical decisions, and verifying receipt validity. Each tool carries significant functionality, so there is no sense of bloat or thinness.
Completeness5/5
The tool surface covers the full decision lifecycle: preflight_change_set creates a decision (with analyze/authorize modes), get_decision_details retrieves it, and verify_receipt validates the outcome. Since governance decisions are immutable, update/delete tools are not needed. The only optional tool mentioned (agent_readiness_score) is explicitly out of scope for the default set, so no critical gap exists.
Available Tools
3 toolsget_decision_detailsARead-onlyInspect
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.
ParametersJSON Schema
| 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). |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| meta | Yes | |
| decision | No | |
| patterns | No | |
| risk_score | No | |
| safe_for_agent | No | |
| decision_result | Yes | decision-result.v1 envelope (present when a chain receipt is available). Full schema: https://coderifts.com/schemas/decision-result.v1.consumer.json |
| breaking_changes | No | |
| control_envelope | No | Control envelope (control/1.0) derived from the stored decision_result. |
| execution_action | No | |
| verdict_fingerprint | No | |
| required_action_core | No | Branchable required-action core { type, reason_code, recheck_required } when present on the envelope. |
Tool Definition Quality
A4.7/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description adds useful behavioral details: empty {} is rejected as INVALID_INPUT, and the result is the stored decision document or not_found. It also notes 'linked receipt metadata if stored,' which is context beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections, no fluff. Each sentence adds necessary information about purpose, usage boundaries, and input requirements.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present and clear annotations, the description still covers input requirements, exclusions, and return behavior. It is fully complete for a read-only lookup tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and each parameter has a good description. The description adds clarity that at least one of the two is required despite no required fields in schema, and emphasizes decision_id as preferred. It also mentions the empty-object rejection, which is not in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Retrieve') and names the resource ('PAST CodeRifts decision') and key fields (decision_id or fingerprint). It clearly distinguishes this from sibling tools by stating it retrieves past decisions, not new analyses.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
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' sections name the exact conditions and alternatives (preflight_change_set for current changes, verify_receipt for receipt verification). This provides unambiguous decision criteria for the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
preflight_change_setARead-onlyInspect
Preflight a COMPLETE base→head change set of contract artifacts and return risk score and breaking-change analysis — plus, on the AUTHORIZE path only, a governance decision (ALLOW / WARN / REQUIRE_APPROVAL / BLOCK) and a signed chain-receipt when applicable. ANALYZE returns informational risk only: analysis_outcome, may_execute:false, no decision, no receipt.
Requires a pending base→head (before/after) contract change you are about to act on (merge, deploy, publish, or register tools). No pending change set → do not call this tool.
Use this when:
You are about to merge, push, deploy, publish, or register/expose agent tools, AND the change includes ≥1 contract artifact (OpenAPI/Swagger, GraphQL SDL, gRPC/protobuf, AsyncAPI, MCP manifest, or agent tool schemas: type=agent_tools, including before re-registering tools with a runtime).
You have (or can assemble) FULL base and head for every changed contract artifact in this set — not a single-file subset when other contract files also change.
You need a NEW decision for the CURRENT change; you do not already hold a currently-valid receipt for this exact target/operation.
You hold a receipt for a different operation or target than the act you will perform (e.g. ALLOW for merge, now deploying) — re-call with the intended operation; a differently-scoped receipt is not reusable authorization.
Do not use when:
The change is documentation-only (README, guides, comments) with no contract artifact content change — do not call any CodeRifts tool.
You already hold a signed receipt and only need to check it is authentic and currently valid — use coderifts.verify_receipt instead.
You need details of a PREVIOUS decision by decision_id — use coderifts.get_decision_details instead.
You want a static 0–100 "agent readiness" score for one OpenAPI/MCP file and there is no pending base→head mutate — use coderifts.agent_readiness_score (advanced / opt-in; not one of the three default tools). If that tool is not in your available list, call none of the CodeRifts tools; do not substitute preflight_change_set.
You cannot supply both before and after (or base and head) for the artifacts that change — fix the change set first; do not invent empty before specs.
Inputs: list of artifacts, each with type, before, after (or equivalent), plus optional operation (merge|deploy|tool_call|publish), environment/stakes, and context. Returns decision, execution_action, risk fields, and chain_receipt when issued.
Mode (required): pass preflight_mode. Use "analyze" for informational risk only (returns analysis_outcome with may_execute:false, no decision/execution_action/ safe_for_agent, no receipt). Use "authorize" for the operation-bound path that can mint a receipt (requires context.operation: merge|deploy|publish|tool_call). Under Decision Spec 2.0 the mode is mandatory; omission is an error unless a legacy decision_spec_version "1.0" pin is set.
ParametersJSON Schema
| 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. | |
| artifacts | Yes | Contract artifacts to analyze together (max 20). Each is { id, type, before, after }. | |
| 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 | |
| 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. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
A4.8/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description details analyze vs authorize modes, receipt minting conditions, idempotency replay behavior, operation-bound authorization, and the necessity of preflight_mode under Decision Spec 2.0. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but well-structured with clear sections (Use this when, Do not use when, Inputs, Mode). It is front-loaded with the core purpose. Some redundancy with the schema exists (e.g., mode details), but the length is justified by the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with two modes, multiple artifact types, and operation-binding subtleties, the description covers all relevant context: prerequisites, mode semantics, return concepts (decision, execution_action, chain_receipt), legacy version pin, and alternative tools. It is complete despite the output schema existing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema descriptions are already detailed. The description adds extra meaning by emphasizing 'COMPLETE' change set, requiring full base/head for all changed artifacts, and clarifying that context.operation is required in authorize mode. This goes beyond the schema's static descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and object: 'Preflight a COMPLETE base→head change set of contract artifacts and return risk score and breaking-change analysis.' It clearly distinguishes from siblings by naming alternatives like verify_receipt and get_decision_details in the 'Do not use when' section.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Extensive 'Use this when' and 'Do not use when' sections provide explicit criteria, including prerequisites (pending change set, FULL base/head) and exclusions (docs-only changes, existing valid receipt). It names alternative tools for each non-use case, making decision boundaries very clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
verify_receiptARead-onlyInspect
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 for that operation; 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 expected target_id, operation, and now-skew policy hooks. Returns { valid, status, currently_authorized (bool|null), reason, payload, authz_* }. Branch on currently_authorized; null = not evaluated.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| token | Yes | The chain receipt token (base64url(body).base64url(signature)) | |
| 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 | |
| environment | No | Intended environment (e.g. production) — must match the receipt | |
| fingerprint | No | Intended change fingerprint — must equal the receipt fp | |
| 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. |
Output Schema
ParametersJSON Schema
| 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 / …) |
| 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. |
Tool Definition Quality
A4.8/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description explains that verify_receipt does not re-diff specs, cannot re-scope a decision, and fails closed when authorization context is missing (currently_authorized false). It also clarifies that null means 'not evaluated'. These are exactly the behavioral traits an agent needs to avoid misusing the tool, and no contradiction with annotations exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long, but the complexity of the tool justifies it. It is front-loaded with the core purpose and structured with clear labels ('Use this when', 'Do not use when', 'Inputs'). Minor redundancy exists between the second and third 'Do not use' bullets (both mention preflight and re-scoping), but overall it is efficient for the content it covers.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description fully covers purpose, alternatives, behavior, input parameters, and return shape ({ valid, status, currently_authorized, reason, payload, authz_* }). It addresses edge cases like stale/superseded receipts and fail-closed authorization. Given the tool's complexity and the presence of an output schema, this is complete and self-contained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds value by summarizing the required token and how optional intended-context parameters plus the decision_result envelope switch between signature-only and authorization evaluation. It also explains the fail-closed result when context is supplied without the envelope, which goes beyond the schema's property descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb ('Verify') and a precise resource ('CodeRifts signed chain-receipt'), and clearly states the two flavors of verification (authenticity and authorization). It distinguishes itself from siblings by explicitly naming preflight_change_set and get_decision_details as alternatives for different needs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Includes explicit 'Use this when' and 'Do not use when' sections. It names sibling tools and gives concrete conditions for when to use each, such as 'call coderifts.preflight_change_set first' when you don't have a receipt, and 'use coderifts.get_decision_details' for human-readable history. This is model guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
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
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.
Discussions
No comments yet. Be the first to start the discussion!
Related MCP Servers
- AlicenseAqualityBmaintenanceA read-only API change deploy gate for AI coding agents that analyzes OpenAPI specs to determine if changes are safe to deploy. It provides tools for comparing specs, explaining breaking changes, and generating migration guides.534MIT
- AlicenseAqualityDmaintenanceEnables testing and validation of APIs for AI agent compatibility, providing scores, grades, and actionable recommendations.3MIT
coderadiusofficial
Alicense-qualityAmaintenanceEnables AI agents to query architecture context, data contracts, and blast radius to prevent cross-repo architectural breakage before merging.30Apache 2.0