Tamper-proof audit trail for AI decisions. 6 tools to record, verify, and export cryptographic proof chains. SHA-256 hash chain, JSON-LD v2 export, public verification.
Verifies the entire SHA-256 hash chain integrity for a domain. Performs O(n) sequential verification of all Decision Proof Units and reports the first broken index if tampering is detected.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | The domain to verify (e.g. rehab_care, market, edu) | |
| toIndex | No | End verification at this chain index | |
| batchSize | No | Number of DPUs to process per batch | |
| fromIndex | No | Start verification from this chain index |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral burden. It discloses algorithmic behavior (O(n) sequential verification) and output behavior (reports first broken index). However, it does not explicitly state whether the operation is read-only, whether it requires special permissions, or how failures like a nonexistent domain are handled.
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 two focused sentences with no filler. It front-loads the core function and adds the most important behavioral nuance (O(n) complexity and broken-index reporting) in a compact way.
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?
The description explains the main verification behavior and one key output behavior, but no output schema is provided. It does not describe the full success return shape, what happens when no tampering is detected, or how the optional fromIndex, toIndex, and batchSize parameters affect verification. The core workflow is understandable, but details remain unclear for an agent.
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?
The schema has 100% parameter coverage, so each of the four parameters already has descriptive text. The description adds little about parameters, only implicitly tying 'domain' to the verification target. This meets the baseline for well-documented schemas but provides no additional semantic value beyond the schema.
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 clearly states the tool performs SHA-256 hash chain integrity verification for a specific domain, with an explicit scope of 'entire chain' and 'all Decision Proof Units.' This goes beyond a generic 'verify' and distinguishes the tool from sibling tools like proof_get or proof_report.
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 clearly conveys when to use the tool: when full-chain hash integrity verification is needed. It provides concrete details like O(n) sequential verification. However, it does not explicitly mention alternatives or when not to use the tool, leaving no exclusions or sibling comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Exports a Decision Proof Unit as a JSON-LD v2.0 proof document conforming to Cronozen Evidence Ontology. Includes compliance status, 6W extraction (Who/What/Where/When/How/Why), hash chain info, and policy snapshot.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The DPU ID to export as JSON-LD |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden. It mentions the output includes compliance status, 6W extraction, hash chain info, and policy snapshot, giving some transparency about the result. However, it does not disclose side effects, error conditions, or whether the operation is read-only or mutating.
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 concise, containing a single sentence that packs essential information without fluff. It is front-loaded with the main purpose and immediately followed by relevant output details, maintaining good structure and clarity.
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?
While the description covers the core function and output contents, it lacks contextual completeness for a tool with siblings. It does not explain when to use this export tool compared to other proof-related operations, and it omits any prerequisites or preconditions. This is a gap given the existence of sibling tools.
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?
The schema already describes the single parameter 'id' as 'The DPU ID to export as JSON-LD', which is clear. The description adds no extra meaning about the parameter, such as format, constraints, or examples. With 100% schema coverage, the baseline is met but not exceeded.
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 clearly states the tool's function: exporting a Decision Proof Unit as a JSON-LD v2.0 proof document conforming to the Cronozen Evidence Ontology. It distinguishes this from siblings by specifying the export action and format.
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 does not provide any guidance on when to use this tool versus the sibling tools (e.g., proof_get, proof_verify). It lacks context about typical scenarios or conditions that would make this the appropriate choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieves a Decision Proof Unit by ID with full details including hash chain position, AI involvement, human control, evidence level, and compliance information.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The DPU ID to retrieve |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It correctly indicates a retrieval operation and lists the content fields, but it does not disclose behavior around missing IDs, permissions, side effects, or response format. It is acceptable but not thorough.
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?
One concise, front-loaded sentence uses a single specific verb and a compact list of relevant detail categories. There is zero wasted text and the structure is easy to scan.
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?
The tool is low-complexity: a single required string parameter and no output schema. The description adequately communicates the purpose and the nature of the returned data. Omitting error handling or output container details is a minor gap, but the description is sufficient for a simple lookup tool.
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?
The only parameter id already has a schema description ('The DPU ID to retrieve'), and the tool description adds no additional format, source, or constraint details. Since schema description coverage is 100%, baseline of 3 applies.
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 states a specific verb ('Retrieves') and resource ('Decision Proof Unit by ID'), and enumerates exactly what kind of details are returned. This clearly distinguishes it from siblings like proof_verify or proof_chain_verify, which focus on verification and chain checks rather than plain retrieval.
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?
No guidance is provided on when to use this rather than a sibling such as proof_verify, proof_public_verify, or proof_report. The broad use case (retrieve a DPU by ID) is clear, but there are no exclusions or explicit alternative references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Publicly verifies a DPU's cryptographic integrity without authentication. Checks SHA-256 hash validity, previous/next chain link integrity, and returns verification status. Anyone can verify — no credentials required.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The DPU ID to publicly verify |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It transparently explains the verification steps (SHA-256 hash, chain link integrity) and the output (verification status), but does not discuss potential errors or side effects. Overall, it gives a solid picture of the tool's behavior.
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 concise, consisting of two clear sentences. It avoids redundancy and provides only essential information, making it easy to parse and understand.
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?
The tool is simple with a single input and no output schema. The description fully explains what the tool does, what input it requires, and what it returns (verification status). No additional context is needed.
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?
The parameter 'id' is described in the schema with the same text as in the tool description ('The DPU ID to publicly verify'), so the description adds no additional semantic value beyond the schema. Schema coverage is 100%, resulting in a baseline score of 3.
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 clearly states the tool's function: publicly verifying a DPU's cryptographic integrity without authentication. It specifies the resource (DPU) and the action (verify), and distinguishes it from sibling tools by emphasizing the public and credential-free nature.
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 clear context for when to use this tool—when public verification is needed without authentication—but does not explicitly mention alternatives or when not to use it. The context is sufficient for most use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Records an AI execution as a Decision Proof Unit (DPU). Creates a cryptographically chained proof record with SHA-256 hash chain. Returns the created DPU with decision_id and chain hash.
| Name | Required | Description | Default |
|---|---|---|---|
| tags | No | Tags for categorization | |
| domain | Yes | Business domain (e.g. rehab_care, market, edu, mentor, welfare) | |
| purpose | Yes | Purpose/reason for the decision | |
| approved | No | Whether the decision was approved | |
| reviewed_by | No | Human reviewer identifier | |
| final_action | Yes | The action that was taken (e.g. CREATE, UPDATE, APPROVE) | |
| reference_id | No | ID of referenced entity | |
| reviewer_role | No | Role of the reviewer (e.g. operator, admin) | |
| evidence_level | No | Evidence level. Default: AUDIT_READY | |
| reference_type | No | Type of referenced entity |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that the record is cryptographically chained with SHA-256 and returns decision_id and chain hash, but does not mention permissions, failure behavior, or immutability beyond the implied hash chain. This is moderate transparency.
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 three concise sentences, front-loaded with the action ('Records an AI execution...'), and contains no redundant or vague phrasing. Every sentence adds meaningful context about the creation and its output.
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 creation tool with 10 parameters and no output schema, the description adequately covers the essential return fields (decision_id, chain hash) and the cryptographic nature. It lacks details on error conditions or prerequisites, but given the simplicity of the operation, it is sufficiently complete.
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 description coverage is 100% (all 10 parameters have descriptions). The tool description adds no extra semantics about the parameters themselves, only mentions return fields (decision_id, chain hash). Since the schema fully documents parameters, baseline 3 is appropriate.
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 clearly states the tool records an AI execution as a DPU, using specific verbs and resource names. It distinguishes itself from siblings (proof_verify, proof_get, proof_report, etc.) which are for verification, retrieval, or export, while this is the creation tool.
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 implies use for recording proofs, and the sibling context makes it obvious this is the write operation. However, it does not explicitly state when not to use it or mention alternatives, so it stops short of explicit exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generates a structured decision report for a DPU. Returns a formatted document with decision details, hash chain verification, and download links (PDF, JSON-LD). Use this after proof_record to provide a downloadable evidence report.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The DPU ID to generate a report for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It does reveal return format, document contents, hash chain verification, and download links. However, it does not explicitly state whether the operation is read-only or persists anything, nor how it behaves for missing/invalid DPU IDs.
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?
Two concise sentences front-load the tool's purpose and add a practical workflow directive. There is no filler or redundant explanation; every sentence earns its place.
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 low complexity—one parameter, no output schema—the description adequately covers what the tool returns, what the document contains, what download formats are available, and when it should be used. Missing error/auth details are not critical for this simple report generator.
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% for the single id parameter, which already describes it as 'The DPU ID to generate a report for.' The tool description does not add meaningful parameter guidance beyond the schema, so the baseline score of 3 is appropriate.
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 uses a specific verb ('Generates') and resource ('DPU'), then enumerates concrete output contents: decision details, hash chain verification, and PDF/JSON-LD download links. It distinguishes itself from sibling verification/export tools by positioning itself as the post-proof_record evidence report.
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?
Explicitly states when to use it: 'Use this after proof_record to provide a downloadable evidence report.' This gives clear sequential context, though it does not name alternatives or exclusion cases compared to siblings like proof_export_jsonld or proof_verify.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verifies a specific proof record's cryptographic integrity. Checks hash consistency and returns verification status.
| Name | Required | Description | Default |
|---|---|---|---|
| data | No | Optional original data for re-verification of hash | |
| proofId | Yes | The proof ID to verify |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the core behavioral trait—checking hash consistency and returning verification status—which is useful. However, with no annotations provided, it should also convey whether the operation is read-only, requires special permissions, or fails on mismatch; this information is absent.
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 two concise sentences that immediately state the primary action and outcome, with no redundant or filler content. It is well front-loaded and every word contributes value.
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 relative simplicity (2 params, no output schema), the description is adequate for understanding core functionality. However, with no annotations and no usage guidance, the overall context is incomplete for an agent deciding between this and sibling verify tools.
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?
Both parameters are fully described in the input schema, so the schema already covers their meaning. The description adds no additional parameter context beyond what the schema provides, keeping this at the baseline for high schema coverage.
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 clearly states the tool verifies a specific proof record's cryptographic integrity and checks hash consistency, providing a specific verb and resource. It implies differentiation from siblings like proof_public_verify and proof_chain_verify through 'specific proof record', but does not explicitly name alternatives or contrast with them.
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 gives no guidance on when to use this tool versus proof_public_verify, proof_chain_verify, or other siblings. It does not state prerequisites, exclusions, or typical scenarios, leaving the agent to infer usage solely from the name and purpose.
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!
Add one secure layer between your agents and this server.
Most tools are clearly distinct (record, get, export, report, chain verify), but proof_verify and proof_public_verify both verify cryptographic integrity with overlapping semantics. The descriptions clarify the auth and chain-link differences, but an agent could still confuse them.
All tools follow a strict 'proof_' prefix with a verb action (get, record, verify, export, report, chain_verify, public_verify). The pattern is consistent, snake_case throughout, and predictable.
With 7 tools covering proof recording, retrieval, verification, export, and reporting, the server is well-scoped for its purpose. No redundancy or bloat, and each tool serves a clear function.
The tool surface covers the full lifecycle of proof management: record (create), get (read), verify (check integrity), export (format), and report (human-readable output). A list operation is missing, but it's not critical for the domain's core workflows.