Proof primitive for AI agents on MultiversX. Anchor file hashes on-chain as verifiable proofs.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
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.
Average 4.1/5 across 13 of 13 tools scored. Lowest: 3.3/5.
Most tools have clearly distinct purposes (file certification, decision certification, coherence anchoring, session audit, attestations, calibration, proof retrieval/verification). Minor overlap exists between get_proof and verify_proof, and between check_coherence and require_coherence_anchor, but descriptions clarify their different roles (retrieve vs verify, create vs check).
The vast majority follow a verb_noun pattern (audit_agent_session, certify_file, check_attestations, discover_services, get_calibration, get_proof, investigate_proof, register_trial, require_coherence_anchor, submit_outcome, verify_proof). One deviation: certify_with_confidence uses a verb_with_noun structure, but it's still readable and the pattern is otherwise consistent.
13 tools is well-scoped for a blockchain certification service covering discovery, trial, certification creation, verification, coherence anchoring, calibration, and investigation. Each tool addresses a specific workflow step without redundancy or bloat.
The core certification lifecycle (create, verify, retrieve) is fully covered, along with coherence anchors, calibration tracking, and investigation. A notable gap is the lack of a list or search tool to enumerate proofs for a wallet, but agents can work around it if proof IDs are known or provided by other flows.
audit_agent_sessionAInspectCertify an AI agent's work session on the MultiversX blockchain BEFORE executing any critical action (trade, deploy, data access). Returns a proof_id compliance certificate. The agent MUST call this tool before acting — certification failure blocks execution. Governance: set reversibility_class='irreversible' for actions that cannot be undone — a policy violation is flagged if confidence_level < 0.95 on irreversible decisions. Schema: https://xproof.app/.well-known/agent-audit-schema.json
| Name | Required | Description | Default |
|---|---|---|---|
| context | No | Optional additional context (model version, environment, tool chain, etc.) | |
| agent_id | Yes | Identifier of the agent making the decision | |
| decision | Yes | Agent's decision about whether to proceed | |
| timestamp | Yes | ISO 8601 timestamp of when the decision was made | |
| risk_level | Yes | Assessed risk level of the action | |
| session_id | Yes | Unique session identifier (UUID or timestamp-based) | |
| action_type | Yes | Category of the action being certified | |
| inputs_hash | Yes | SHA-256 of all inputs analyzed before making the decision | |
| risk_summary | No | Optional brief risk analysis justifying the decision | |
| action_description | Yes | Human-readable description of the specific action | |
| reversibility_class | No | Governance: how reversible is this action? 'reversible' = can be undone at low cost, 'costly' = reversible but expensive (fees, slippage, delay), 'irreversible' = cannot be undone (on-chain settlement, data deletion, email sent). When 'irreversible', a confidence_level >= 0.95 is required to be policy-compliant. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses important behavioral traits: the tool must be called before actions and certification failure blocks execution. It also adds governance context (reversibility_class and confidence_level threshold). This goes beyond basic descriptions, though it does not detail side effects or response structure beyond returning a certificate.
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 appropriately sized for a complex governance tool. It front-loads the primary purpose and usage, then adds governance specifics, and ends with a schema URL. Every sentence contributes useful information, though the schema URL and governance details add length. It is not overly verbose.
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 covers purpose, the mandatory usage context, behavioral outcomes (blocking execution), and governance rules. It also provides an external schema link for deeper reference. However, there is no output schema, and the description doesn't fully explain the return format beyond 'proof_id compliance certificate' or how failures are signaled (beyond blocking). Given the tool's criticality, a bit more detail on error/blocking behavior would improve completeness.
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 input schema provides exhaustive descriptions for all 11 parameters (100% coverage), so the baseline is 3. The description adds some context by explaining the governance meaning of reversibility_class and confidence_level, but it introduces confidence_level as if it were a parameter even though it is not in the schema, which could confuse. The schema already defines each parameter well.
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 specific action: 'Certify an AI agent's work session on the MultiversX blockchain BEFORE executing any critical action' and its output: 'Returns a proof_id compliance certificate.' It distinguishes itself from siblings like certify_file and certify_with_confidence by focusing on agent sessions and critical actions.
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 explicitly states when to use the tool: 'The agent MUST call this tool before acting' and 'BEFORE executing any critical action (trade, deploy, data access).' It also describes exclusion by saying 'certification failure blocks execution.' However, it does not explicitly mention when not to use it or name alternative tools, so it lacks full when-not/alternatives guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
certify_fileAInspectCreate a blockchain certification for a file. Records the SHA-256 hash on MultiversX blockchain as immutable proof of existence and ownership. Cost: $0.01 per certification, paid in EGLD.
| Name | Required | Description | Default |
|---|---|---|---|
| filename | Yes | Original filename with extension (max 255 chars) | |
| file_hash | Yes | SHA-256 hash of the file (64 hex characters) | |
| author_name | No | Name of the certifier (default: AI Agent, max 128 chars) | |
| webhook_url | No | Optional HTTPS URL for on-chain confirmation callback |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It transparently states the action (recording hash on blockchain), the nature (immutable proof), and the cost ($0.01 paid in EGLD). It does not detail failure modes or return values, but the key behavioral traits are covered.
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 consists of two concise, front-loaded sentences. The first immediately states the action, and the second adds critical cost and blockchain details without unnecessary verbosity.
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 has no output schema and no annotations, so the description must explain what the agent can expect from the call. While it covers purpose, hash, blockchain, and cost, it does not describe the return value (e.g., transaction hash, certificate ID) or potential delays for on-chain confirmation, leaving some contextual gaps.
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 input schema provides complete descriptions for all four parameters, so the baseline is 3. The tool description adds no extra parameter-level meaning beyond what the schema already states; it only reiterates the file_hash concept at a high level.
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 purpose with a specific verb ('Create') and resource ('blockchain certification for a file'), and specifies the mechanism (recording SHA-256 hash on MultiversX). This distinguishes it from sibling tools like verify_proof or check_attestations, which deal with verification rather than creation.
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 clear context for when to use the tool: to create a blockchain certification for a file. However, it does not explicitly mention alternatives or when-not-to-use scenarios, such as using certify_with_confidence for a different certification workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
certify_with_confidenceAInspectCreate a staged blockchain certification with a confidence score. Use this when your decision builds progressively — certify at 60% (initial assessment), 80% (pre-commitment), and 100% (final decision). Each stage shares the same decision_id, creating an on-chain audit trail of the decision process. Governance: set reversibility_class='irreversible' for actions that cannot be undone — xproof will flag a policy violation if confidence_level < 0.95. Cost: $0.01 per certification.
| Name | Required | Description | Default |
|---|---|---|---|
| who | No | Agent identity (wallet address, name, or agent ID) | |
| why | No | Reason or instruction hash driving this decision | |
| filename | Yes | Original filename with extension (e.g. decision.json, max 255 chars) | |
| file_hash | Yes | SHA-256 hash of the decision or output file (64 hex characters) | |
| author_name | No | Name of the certifying agent (default: AI Agent, max 128 chars) | |
| decision_id | Yes | Shared UUID linking all confidence stages for the same decision. Generate once and reuse across all stages. | |
| threshold_stage | Yes | Named stage of the decision: initial (first assessment), partial (gathering info), pre-commitment (almost certain), final (committed). | |
| confidence_level | Yes | Confidence score from 0.0 to 1.0. Typical values: 0.6 (initial), 0.8 (pre-commitment), 1.0 (final). | |
| reversibility_class | No | Governance: how reversible is this action? 'reversible' = can be undone, 'costly' = reversible but expensive, 'irreversible' = cannot be undone (on-chain settlement, data deletion, sent email). When 'irreversible', confidence_level must be >= 0.95 or xproof flags a policy violation. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well by disclosing the on-chain audit trail, the governance rule for irreversibility (confidence_level must be >= 0.95), and the cost of $0.01 per certification. This goes beyond basic functionality to warn about policy violations and financial implications.
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 sentences, each earning its place: purpose, usage scenario, and governance/cost. It is front-loaded with the core purpose and avoids unnecessary detail. This is exceptionally concise yet informative.
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 9-parameter tool with no annotations and no output schema, the description covers purpose, usage, governance, and cost. It does not describe the return value, but the absence of an output schema reduces that need. Overall, it provides sufficient context for an agent to invoke the tool 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 description coverage is 100%, so parameters are already well-documented. The description adds value beyond the schema by providing typical confidence values (0.6, 0.8, 1.0) and clarifying the governance condition for reversibility_class, making the parameter usage more concrete.
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: 'Create a staged blockchain certification with a confidence score.' The verb 'create' plus the resource 'staged blockchain certification' and the distinguishing 'confidence score' make the purpose specific. It also differentiates from sibling tools like certify_file by emphasizing the staged, confidence-scored 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 explicit when-to-use guidance: 'Use this when your decision builds progressively' and gives concrete examples of stages (60%, 80%, 100%). It lacks explicit alternatives or 'when not to use' statements, but the context is clear enough for an agent to decide appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
check_attestationsAInspectCheck domain-specific attestations for an AI agent wallet on xproof. Returns active attestations issued by third-party certifying bodies (healthcare, finance, legal, security, research). Each active attestation adds +50 to the agent's trust score (max +150 from 3 attestations). Use this to verify an agent's credentials before delegating a sensitive task.
| Name | Required | Description | Default |
|---|---|---|---|
| wallet | Yes | MultiversX wallet address (erd1...) of the agent to check |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral burden. It discloses that the tool returns active attestations and adds a domain rule: 'Each active attestation adds +50 to the agent's trust score (max +150 from 3 attestations).' This goes beyond basic semantics, though it does not explicitly state read-only behavior or error handling.
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?
Three sentences, each earning its place: the first states the function, the second explains the trust-score behavior, and the third gives usage recommendation. No filler or redundant repetition of schema details.
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 single-parameter read tool with no output schema, the description covers purpose, return value, trust-score impact, and use case. It omits return format and error conditions, but the simplicity of the tool makes this acceptable.
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 input schema already describes the wallet parameter as 'MultiversX wallet address (erd1...) of the agent to check' with 100% coverage. The description adds the context 'AI agent wallet' and 'xproof', but does not materially change parameter understanding. Baseline 3 is appropriate given full 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's function: 'Check domain-specific attestations for an AI agent wallet on xproof' and specifies what it returns: 'active attestations issued by third-party certifying bodies.' The verb 'check' and resource 'attestations' distinguish it from sibling tools like certify_file and certify_with_confidence, which create attestations.
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 final sentence provides explicit usage context: 'Use this to verify an agent's credentials before delegating a sensitive task.' While it does not mention when not to use it or alternatives, the context is clear enough for an agent to decide when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
check_coherenceAInspectAnchor your agent's reasoning as an immutable WHY proof BEFORE executing an action. Implements the Prove Before Act / Coherence Layer pattern. Pass intent (goal), context (facts considered), and decision (action about to execute). Receives: proof_id, coherence_anchor (SHA-256 of the payload), timestamp. Link the returned proof_id to your WHAT proof via certify_file metadata.why_proof_id to complete the full 4W audit trail. Cost: $0.01 per anchor (same as certify_file).
| Name | Required | Description | Default |
|---|---|---|---|
| who | No | Agent identifier — wallet address, agent name, or model id (default: derived from API key owner) | |
| intent | Yes | The agent's stated goal or objective for this action (e.g. 'Optimize portfolio allocation for Q3') | |
| context | Yes | Relevant facts, constraints, and inputs considered before the decision (e.g. 'BTC RSI=38, allocation 2.1%, policy v3.1') | |
| decision | Yes | The specific action the agent is about to execute (e.g. 'BUY 0.5 BTC at market') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the immutable proof creation, the response fields (proof_id, SHA-256 anchor, timestamp), and the cost ($0.01 per anchor), which are non-obvious behavior. It doesn't mention potential side effects beyond immutability, but overall it provides meaningful context.
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 and front-loaded with the core purpose. Each sentence contributes useful information: purpose, pattern, input, output, linking, and cost. It is slightly dense but not padded, earning a 4.
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 covers the tool's purpose, usage timing, return fields (since there is no output schema), cost, and integration with certify_file. This is sufficient for an agent to decide when and how to use it. It lacks error handling details but is adequate for the tool's simplicity.
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% with detailed descriptions and examples for all parameters. The description adds a conceptual mapping (intent=goal, context=facts, decision=action) but does not enrich parameter semantics significantly beyond what the schema already provides. 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 identifies the tool as an action that anchors reasoning as an immutable WHY proof before action execution. It uses specific verbs and resources ('Anchor', 'immutable WHY proof') and distinguishes itself from siblings by referencing the 4W audit trail and linking to certify_file as the WHAT proof.
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?
It explicitly states when to use the tool ('BEFORE executing an action') and describes the Prove Before Act pattern. It also mentions the integration with certify_file, giving workflow context. It does not explicitly name alternatives or exclusion scenarios, but the guidance is clear enough for an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
discover_servicesAInspectDiscover available xproof certification services, pricing, and capabilities. No authentication required.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that no authentication is required, which is useful, and 'Discover' implies a read-only operation. However, it does not explicitly state that there are no side effects, nor does it describe the return format or any potential limitations. It is adequate but not rich.
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 a single, front-loaded sentence that conveys purpose and a key usage note without any filler. Every word 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?
For a simple, parameterless discovery tool, the description covers the essential context: what it does, that it provides pricing and capabilities, and that no auth is needed. It lacks an explicit statement about the return type, but given the nature of discovery, this is low risk. The description is complete enough for the tool's simplicity.
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 tool has zero parameters, so the baseline is 4. The description does not need to add parameter semantics since none exist, and the schema confirms this with 100% coverage (vacuously).
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 the specific verb 'Discover' with the resource 'xproof certification services, pricing, and capabilities,' clearly distinguishing this from sibling tools that certify, verify, or audit. It conveys the tool's scope (listing available services) without ambiguity.
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 states 'No authentication required,' which is a usage condition, and implies the tool is for discovering services before using other tools. However, it does not explicitly mention alternatives or when not to use it, so usage guidance remains implicit rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_calibrationAInspectQuery an agent's calibration quality over time: mean confidence gap, variance, bias label (overconfident / underconfident / calibrated), and per-decision time series. Fully public — use this to evaluate another agent before trusting it. agentId accepts a MultiversX wallet address (erd1...) or internal user id.
| Name | Required | Description | Default |
|---|---|---|---|
| n | No | Number of recent outcomes to include (default 50, max 200) | |
| agent_id | Yes | Agent wallet address (erd1...) or internal user id |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden. It discloses the tool is 'fully public' (no auth needed), a key behavioral trait, and outlines the returned data. It doesn't mention potential side effects, but as a read-only query this is adequate.
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 compact sentences with no filler. It front-loads the purpose and provides essential usage and parameter context efficiently.
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 query tool with no output schema, the description explains the return contents well. It covers purpose, usage, and access. It lacks details on the time series structure or pagination, but overall gives sufficient context for an agent to correctly invoke the 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?
Schema description coverage is 100%, so baseline is 3. The description restates what the schema already says about agent_id formats but adds no new parameter semantics beyond the schema. No extra context for the 'n' parameter is provided in the description.
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 queries an agent's calibration quality over time, listing specific outputs (mean confidence gap, variance, bias label, per-decision time series). It distinguishes this from sibling tools focused on auditing sessions or verifying proofs.
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 says 'use this to evaluate another agent before trusting it', giving a clear when-to-use context. It does not mention alternatives or exclusions, but the public-access note clarifies it's a safe evaluation step.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_proofAInspectRetrieve a proof in structured JSON or Markdown format. Use JSON for machine processing, Markdown for LLM consumption.
| Name | Required | Description | Default |
|---|---|---|---|
| format | No | Output format: json or md | json |
| proof_id | Yes | UUID of the certification |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of transparency. The verb 'retrieve' implies a read-only operation, and the description adds specific behavioral detail about the two output formats. However, it does not explicitly confirm non-destructiveness or describe error behavior, which would strengthen 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 a single, front-loaded sentence that directly communicates purpose and format selection. Every word earns its place, with no redundancy or fluff.
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 simplicity of the tool (2 params, no output schema), the description is mostly adequate. It explains the core function and format choice. However, it could be more complete by mentioning that proof_id is a certification UUID (already in schema) or by clarifying relationships to sibling tools, but these are not critical gaps for a straightforward retrieval 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 input schema already provides descriptions for both parameters (100% coverage), so the baseline is 3. The description adds meaningful semantic guidance for the 'format' parameter, explaining when to choose JSON vs Markdown ('machine processing' vs 'LLM consumption'), which goes beyond the schema's enum values.
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 action ('Retrieve a proof') and the specific resource ('proof'), while also identifying the two output formats (JSON/Markdown). However, it does not differentiate this tool from sibling tools like verify_proof or investigate_proof, which could be ambiguous in a broader context.
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 guidance on format selection ('Use JSON for machine processing, Markdown for LLM consumption') but gives no indication of when to use this tool as opposed to siblings (e.g., verify_proof, investigate_proof). There are no explicit usage conditions or alternatives mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
investigate_proofAInspectReconstruct the full 4W audit trail for a contested agent action. Returns WHO (agent identity + SIGIL), WHAT (SHA-256 hash on-chain), WHEN (MultiversX block timestamp), WHY (decision chain anchored before acting). Includes verification summary with intent_preceded_execution flag, chronological timeline of WHY/WHAT proofs, and session heartbeat anchor. Requires x402 payment ($0.01 USDC on Base via X-PAYMENT header) or API key authentication. Without payment, returns payment requirements with USDC address and amount.
| Name | Required | Description | Default |
|---|---|---|---|
| wallet | Yes | Agent wallet address (erd1...) that owns the proof | |
| proof_id | Yes | UUID of any proof in the action pair — WHY (reasoning), WHAT (action), or heartbeat session proof |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the payment/authentication requirement (x402 or API key), the fallback behavior when unpaid, and the contents of the returned audit trail. It does not state side effects, but the read-oriented verb 'Reconstruct' implies a non-destructive operation, and no contradictions exist.
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?
Four sentences, each earning its place: the core purpose, the return value breakdown, and the authentication/payment gate. No filler or redundancy. Front-loaded with the main action.
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?
No output schema exists, so the description must explain return values. It lists the key components (WHO, WHAT, WHEN, WHY, verification summary, intent_preceded_execution flag, timeline, heartbeat anchor) and also covers the payment fallback. For a tool of this complexity, this is a complete and self-sufficient 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?
Schema description coverage is 100%, with both parameters (wallet, proof_id) thoroughly documented in the schema itself. The description adds no new parameter-level meaning beyond what the schema already provides, so the baseline 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 opens with a specific verb ('Reconstruct') and a precise resource ('full 4W audit trail for a contested agent action'). It clearly distinguishes this tool from siblings like verify_proof and get_proof by emphasizing the comprehensive, contested-action scope.
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 phrase 'for a contested agent action' provides clear context for when to use the tool. It does not explicitly name alternatives or exclusions, but the context is strong enough to guide selection among the sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
register_trialAInspectSTART HERE if you have no API key. Get 10 free on-chain certifications instantly — no wallet, no credit card, no account required. Call this once with any agent_name, receive a pm_ key, then use certify_file or audit_agent_session immediately. Takes under 1 second.
| Name | Required | Description | Default |
|---|---|---|---|
| agent_name | Yes | A short identifier for your agent (e.g. 'trading-bot', 'my-langchain-agent'). Must be unique across the platform. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses meaningful behavioral traits: no wallet/credit card/account required, takes under 1 second, and 'Call this once' implies one-time usage. It doesn't mention consequences of repeated calls, but for a registration tool this is adequate.
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 sentences, front-loaded with the critical 'START HERE' signal. Each sentence earns its place: condition, benefit, usage, performance, and next steps. No wasted words.
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 simple tool (1 param, no output schema, no annotations), the description covers the essential context: when to use, what it does, what you receive, and immediate next actions. It 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% with a detailed description for agent_name (unique identifier, maxLength). The description's 'any agent_name' adds no meaningful semantics beyond the schema, so 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 explicitly states the tool's purpose: 'START HERE if you have no API key' and 'Get 10 free on-chain certifications instantly' and 'receive a pm_ key'. This clearly differentiates it from sibling tools by positioning it as the entry-point registration 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?
Provides explicit when-to-use guidance: 'START HERE if you have no API key' and instructs to 'Call this once' and then 'use certify_file or audit_agent_session immediately'. This gives clear context and next steps, outranking sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
require_coherence_anchorAInspectPolicy gate: verify a valid, unexpired coherence anchor (WHY proof) exists for a given intent BEFORE allowing an action to execute. Call this from an orchestrator before delegating a sub-action. Pass either the exact intent_hash (the coherence_anchor returned by check_coherence) or the same intent + context + decision payload (the anchor hash is recomputed deterministically). Returns { allowed, anchor_id, expires_at }. If allowed=false, block execution and call check_coherence first. Free — no credit consumed.
| Name | Required | Description | Default |
|---|---|---|---|
| who | No | Agent identifier — must match the value used in check_coherence (default: derived from API key owner) | |
| intent | No | The stated goal — must be byte-identical to the check_coherence call (used with context + decision to recompute the anchor hash) | |
| context | No | The facts considered — must be byte-identical to the check_coherence call | |
| decision | No | The action to execute — must be byte-identical to the check_coherence call | |
| intent_hash | No | The coherence_anchor hash returned by check_coherence (64 hex chars). Fastest path — pass this if you have it. | |
| max_age_minutes | No | Anchor validity window in minutes (default 120 = 2h). Anchors older than this are considered expired/divergent. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It reveals the return shape, deterministic recomputation of the anchor hash, expiration semantics, the blocking fallback behavior, and that it is free with no credit consumed. These are substantive details 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the purpose. Every sentence contributes operational value: when to call, how to pass parameters, what the response contains, what to do on failure, and cost implications. No filler or redundancy.
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?
Despite having 6 parameters, no annotations, and no output schema, the description is complete. It covers the tool's purpose, invocation patterns, return value shape, fallback behavior, and cost, making it fully sufficient for an agent to select and invoke the tool 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 the baseline is 3. The description adds value by explaining the two invocation paths (passing intent_hash vs. intent+context+decision) and that the hash is deterministically recomputed, clarifying how the parameters interrelate.
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 'Policy gate: verify a valid, unexpired coherence anchor ... BEFORE allowing an action to execute,' clearly stating the verb, resource, and purpose. It explicitly references check_coherence and the orchestrator use case, distinguishing it from sibling tools.
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 states 'Call this from an orchestrator before delegating a sub-action' and instructs to 'block execution and call check_coherence first' when allowed=false. This provides explicit when-to-use guidance and a fallback path, clearly differentiating it from the related sibling check_coherence.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
submit_outcomeAInspectSubmit the actual outcome for a decision previously anchored with metadata.confidence_level. Computes the confidence gap (anchored − actual) and stores it for calibration tracking. Operator-only — you must own the proof. Each proof can only have one outcome.
| Name | Required | Description | Default |
|---|---|---|---|
| proof_id | Yes | UUID of the certification that was anchored with metadata.confidence_level | |
| visibility | No | Whether this outcome is publicly visible (default: public) | public |
| outcome_score | Yes | Actual outcome quality (0.0 = complete failure, 1.0 = fully successful) |
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 reveals the side effect of computing and storing the confidence gap, the operator-only permission requirement, and the uniqueness constraint on outcomes. However, it does not specify what happens on duplicate submission or the exact return behavior, which would add further 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: the first states the primary action, the second explains the computation and purpose, and the third lists key constraints. Every sentence adds value and is front-loaded with the core purpose, achieving excellent conciseness.
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 has no annotations and no output schema, the description covers the essential behavioral aspects: purpose, side effects, permission requirements, and uniqueness. It does not explicitly describe error handling or the return value, but the description is sufficiently complete for an action-oriented tool with a well-defined input schema.
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 input schema already provides 100% coverage, describing proof_id as a UUID of the anchored certification and outcome_score as a quality score between 0 and 1. The description adds context about the confidence gap computation but does not meaningfully enhance parameter understanding 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 clearly states the specific action: 'Submit the actual outcome for a decision previously anchored with metadata.confidence_level.' It further explains the computed confidence gap and calibration tracking, which distinguishes it from siblings like certify_with_confidence (which anchors) and get_calibration (which reads).
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: after a decision has been anchored with confidence_level and you need to record the actual outcome. It includes important constraints (operator-only, must own the proof, one outcome per proof) but does not explicitly name alternatives or state when not to use it, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
verify_proofBInspectVerify an existing xproof certification. Returns proof details including file hash, timestamp, blockchain transaction, and verification status.
| Name | Required | Description | Default |
|---|---|---|---|
| proof_id | Yes | UUID of the certification to verify |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the return content (file hash, timestamp, blockchain transaction, verification status), adding value, but does not state whether the operation is read-only, the behavior for invalid/unknown proof IDs, or any required permissions.
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 a single, well-structured sentence that leads with the action and then lists return details. It is concise with 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?
Given the simple one-parameter tool with no output schema or annotations, the description covers the core functionality and return content. However, it omits usage context and potential error behavior, and does not guide selection among sibling tools, leaving it somewhat incomplete.
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 is 3. The description adds minimal semantic context by referring to 'existing' certifications, which implies proof_id must reference a valid proof, but it does not elaborate further beyond what the schema already conveys.
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 an existing xproof certification and mentions specific return details. It uses a specific verb+resource structure, but does not explicitly distinguish from sibling tools like get_proof or investigate_proof.
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 tool versus alternative verification or lookup tools. It lacks any when/when-not or alternative references.
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.
No comments yet. Be the first to start the discussion!
Sign in to create a connector for this server.