paybond-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.12.17
Disambiguation5/5
Each tool has a clearly distinct purpose with detailed descriptions that prevent ambiguity. For example, paybond_get_fraud_assessment vs paybond_get_fraud_metrics vs paybond_get_reputation_receipt vs paybond_get_signed_portfolio_artifact are all well-differentiated. Overlaps are explicitly warned against in descriptions.
Naming Consistency5/5
All tools follow the consistent pattern 'paybond_verb_noun' in snake_case, with clear verb-object pairings (e.g., create_intent, get_fraud_assessment, verify_capability). Minor variations like 'a2a_agent_card' are still interpretable and follow the same convention.
Tool Count4/5
The 29 tools cover a complex domain (spend intents, Harbor escrow, fraud analytics, portfolio, evidence, verification, A2A). While on the high side, each tool has a specific role and is justified by the detailed descriptions. A few could possibly be merged, but the count is reasonable for the scope.
Completeness4/5
The tool set covers core workflows: create/authorize/submit/verify for spend intents, fraud assessment, portfolio, and evidence. Minor gaps exist, such as no update or delete operations for intents, but the primary lifecycle (create, authorize, submit evidence, verify) is well-covered.
Average 4.2/5 across 29 of 29 tools scored. Lowest: 3.5/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 42 commits in the last 12 weeks
- Last stable release on August 2, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under Apache 2.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
This server has been verified by its author.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=true, which matches the verification nature. The description adds 'replay-safe' and context derivation, but overall behavioral detail beyond annotations is minimal. No contradictions 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two brief sentences that front-load the core action and key constraints. Every word contributes information with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema and complex parameters, the description is sparse. It does not explain return values, proof structure, or edge cases, leaving gaps for an AI 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.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'expected purpose and request envelope' linking to two parameters, but provides no details on the 'proof' parameter, which is a complex object. The description adds limited meaning beyond 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 clearly states the verb 'Verify' and the resource 'AgentRecognitionProofV1', specifying the action and the object. It distinguishes the tool from siblings by naming a specific proof type and including 'expected purpose and request envelope', which is unique among the sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context (authenticated MCP session) but does not explicitly state when to use or avoid this tool. No alternatives or exclusions are mentioned, leaving the agent to infer usage from the sibling tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the safe read nature is clear. The description adds the term 'signed protocol-v2' which gives some specificity, but no additional behavioral context (e.g., permission requirements, response size, or error conditions) is provided beyond the annotations.
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 a single sentence of 11 words, front-loaded with the verb 'Fetch'. No wasted words; every token contributes to meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter and an existing output schema, the description covers the basic purpose. However, it lacks contextual completeness by not referencing related tools or explaining when this receipt differs from others. It is minimally adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one required parameter 'receipt_id' (string) with 0% description coverage. The description does not elaborate on what the receipt ID is or its format. Although the name is self-explanatory, the description should at least restate the parameter's role to aid an AI agent.
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 clearly states the verb 'Fetch', the resource 'signed protocol-v2 settlement receipt', and the scope 'for one Harbor intent'. This distinguishes it from sibling tools like paybond_get_reputation_receipt or paybond_verify_protocol_receipt_v1.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly indicates use for fetching a settlement receipt but provides no explicit guidance on when to use it versus alternatives like paybond_get_reputation_receipt or paybond_verify_protocol_receipt_v1. Context signals show many sibling tools, so this gap is notable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate non-read-only and non-idempotent behavior; the description adds context about the protocol and replay-safety but does not disclose side effects like overwrite behavior or failure modes.
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?
A single, front-loaded sentence of 23 words with no redundancy; every word contributes to the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (4 parameters, nested objects) and presence of an output schema, the description is adequate but omits key context like prerequisites, error conditions, or what happens on duplicate calls.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description only names three required parameters without any detail on format, constraints, or the optional transport_binding, leaving agents to infer semantics from names.
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 clearly specifies the action 'import' and resource 'signed AgentMandateV1', and distinguishes this from sibling verification tools like paybond_verify_agent_mandate_v1 by noting the gateway protocol and binding to an intent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied (after obtaining a signed mandate and recognition proof, bind to an intent), but there is no explicit guidance on when to use versus alternatives (e.g., verify first), nor any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=true and openWorldHint=false, indicating a safe read operation. The description adds context about the gateway v2 protocol surface, which gives behavioral insight beyond the annotations. No contradictions.
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 a single, concise sentence that efficiently conveys the tool's purpose without unnecessary words. It is well-structured and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the description covers the basic purpose and protocol, it lacks completeness by not explaining what 'verify' entails (e.g., signature validation, authority checks) or how this tool relates to other verify tools. The presence of an output schema reduces the need for return value details, but more context on the verification process would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage for the single parameter 'signed_mandate'. The description does not elaborate on its structure or requirements beyond the name, failing to compensate for the low coverage. Expected details about the envelope format are absent.
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 clearly states the tool verifies a signed AgentMandateV1 envelope, specifying the protocol surface (gateway v2). This provides a specific verb-resource pair and distinguishes it from siblings like import_agent_mandate_v1 and other verify tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide guidance on when to use this tool versus alternatives, such as when to verify a mandate versus importing or other verification operations. No exclusions or contextual advice is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description is consistent with the annotation 'readOnlyHint: true' by using 'fetch'. However, it does not disclose additional behavioral traits such as error handling (e.g., what happens if the contract is not found) or any constraints beyond the identifier.
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 a single sentence that is front-loaded with the action and resource. Every word is necessary, with no superfluous content or structure issues.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and has an output schema (presumably covering return values). The description adequately describes the core functionality, though it could be more complete by mentioning the meaning of 'published' or typical use cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema coverage at 0%, the description adds minimal value: it mentions 'by identifier' but does not specify format, length, or examples for the 'contract_id' parameter. A simple type string with no description in the schema leaves the agent without guidance on valid values.
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 clearly states the action ('fetch'), the specific resource ('published Paybond A2A task contract'), and the method ('by identifier'). It effectively distinguishes from the sibling tool 'paybond_list_a2a_task_contracts' which implies listing all contracts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this vs alternatives. The description implies fetching a single contract by ID, but does not provide exclusions or context for when to choose this over the list or other sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true. The description adds context about tenant-scoping and operator view, but does not disclose additional behaviors like pagination, rate limits, or what happens when no exports exist.
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?
Single sentence, no unnecessary words. Front-loaded with key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and presence of an output schema, the description covers the core purpose and scope. Minor gaps in parameter guidance and usage context prevent a perfect score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does not explain the 'limit' or 'cursor' parameters, leaving their purpose and usage unclear despite schema constraints (1-200, string).
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 clearly specifies the verb 'List', the resource 'compliance audit export jobs', and the scope 'tenant-scoped through the gateway operator view'. This distinguishes it from siblings like paybond_get_audit_export.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for listing exports but does not provide explicit guidance on when to use this vs. alternatives like paybond_get_audit_export for single exports. No when-not or exclusion criteria are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so safety is clear. The description adds context about scope ('tenant-scoped') and perspective ('gateway operator view'), but these are minor additions. No behavioral traits beyond annotations are disclosed.
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 a single, front-loaded sentence with no redundant words. Every word serves a purpose: verb, resource, scope, and view.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (single required parameter, output schema exists), the description is adequate. It could explain what 'tenant-scoped' and 'gateway operator view' entail in terms of permissions, but for a read operation, it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter intent_id, and its description ('Canonical Harbor intent UUID') is already provided in the schema. The description adds no further semantic detail beyond 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 clearly states the action ('Fetch') and the resource ('one tenant-scoped Harbor intent detail'), distinguishing it from sibling tools like list_intents (list multiple) and create_intent (create). The specific verb and resource make the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for fetching a single intent by ID, but does not explicitly state when to use this tool versus alternatives like paybond_list_intents. No guidance on prerequisites or when not to use it is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false (write operation) and destructiveHint=false. Description adds that the intent involves bounded budget, allowed operations, evidence, and settlement review, which provides further behavioral context without contradiction.
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?
Two sentences efficiently convey purpose and usage boundaries. No extraneous information; every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (3 parameters, 2 required, nested objects, output schema exists), the description lacks parameter details, making it insufficient for an agent to use the tool correctly. The high-level purpose is clear, but parameter semantics are absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the schema lacks property descriptions. The tool description does not mention or explain any of the three parameters (body, idempotency_key, recognition_proof), leaving the agent with no guidance on how to construct them. This is a critical gap.
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 clearly states the tool creates a Paybond spend intent with specific constraints (bounded budget, allowed operations, evidence requirements, settlement review). It also distinguishes from the sibling paybond_authorize_agent_spend, making the purpose unambiguous.
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?
Explicitly tells when to use (agent workflow needs new spend intent with bounded budget, etc.) and when not to use (checking funded capability token, redirects to paybond_authorize_agent_spend). Provides clear guidance on context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the safe read-only nature is clear. The description adds value by specifying the 'gateway operator view' and 'tenant-scoped' context, which informs the agent about the data scope and perspective. No contradictions 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently communicates the core purpose without any redundancy. Every word contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The output schema exists, covering return values. The description covers the basic operation, scoping, and filtering, but omits pagination details (though cursor and limit are in schema). It is mostly complete for a list tool, but could hint at pagination behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% with no parameter descriptions. The description only mentions 'optional filters' without elaborating on the meaning of limit, cursor, status, or operator_did. This fails to add sufficient meaning beyond the parameter names.
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 specific verb 'List' and resource 'Harbor intents', mentions scoping (tenant-scoped) and view (gateway operator), clearly distinguishing from siblings like create_intent or get_intent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
While the description implies usage for listing intents with filters, it does not explicitly state when to use this tool versus alternatives like get_intent for a single intent or create_intent for creation. No exclusions or alternative recommendations are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide basic traits (readOnlyHint=false, openWorldHint=true). Description adds context of simulator usage but no additional behavioral info beyond annotations.
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?
Two sentences, front-loaded with purpose and exclusion, no extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 8 parameters, low schema coverage, and minimal description, the tool definition is incomplete for correct invocation despite output schema existence.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is low (38%) and description does not explain any parameter beyond the general 'evidence' concept, failing to add meaning.
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?
Clear verb 'submit' and resource 'evidence' for sandbox guardrail intents, distinguishing from sibling paybond_submit_spend_evidence.
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?
Explicitly states when to use (sandbox guardrail) and when not (live Harbor spend), naming alternative tool paybond_submit_spend_evidence.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate non-read-only and non-destructive, and the description adds useful behavioral context: the evidence is signed and used for release, refund, review, and receipt generation, implying an audit trail. No contradictions 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two concise sentences. The first sentence efficiently states the tool's purpose and context, and the second provides clear exclusions. No superfluous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the tool has 0% schema description coverage for its 5 parameters, including nested objects. The description does not explain what the parameters represent or how they relate to the audit-ready record, leaving significant gaps 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.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no explanation of parameters (e.g., intent_id, body, recognition_proof). It fails to add meaning beyond the JSON schema, leaving the agent uninformed about parameter semantics.
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 clearly states the tool's purpose: submitting signed evidence for a Paybond spend intent to ensure audit-ready records for release, refund, review, and receipt generation. It distinguishes from sibling tools like paybond_submit_evidence and paybond_submit_sandbox_guardrail_evidence by specifying 'spend evidence' and excluding sandbox guardrail evidence.
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?
The description explicitly says when to use ('when a Paybond spend intent needs signed evidence') and when not to use ('Do not use this to create or fund intents, and do not use it for sandbox guardrail evidence'), directly addressing usage context and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the safety profile is clear. The description adds context about fetching a 'published' card and its use for 'protocol-trust delegation,' which provides some behavioral context beyond the annotation but does not disclose potential failure modes or return behavior.
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 a single concise sentence with no wasted words. It is front-loaded with the main action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless, read-only tool with an output schema, the description is adequate. It could be slightly more complete by hinting at the content of the card, but the output schema provides the structure. Overall well-suited to the tool's simplicity.
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?
There are zero parameters, so baseline 4 applies. The schema coverage is 100% trivially, and the description does not need to add parameter meaning. No improvement needed.
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 'Fetch' and clearly identifies the resource 'Paybond A2A discovery card' with a purpose 'for protocol-trust delegation.' It distinguishes the tool from siblings like paybond_create_intent or paybond_authorize_agent_spend.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states what the tool does (fetch a discovery card) but does not explicitly tell when to use it versus alternatives or when not to use it. While sibling tool names imply different purposes, no direct guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true for safe read operation. The description adds context about tenant scope and gateway operator view, and is consistent with annotations, no contradiction.
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?
Single sentence that is concise, front-loaded with the action verb, and contains no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains what is fetched and the scope, and an output schema exists. It does not mention error handling or prerequisites, but for a get-by-id tool, this is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for both parameters (job_id, issue_download). The description does not add extra meaning beyond the schema; baseline score applies.
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 clearly states the verb 'Fetch', the resource 'compliance audit export job detail', and the scope 'tenant-scoped' and context 'gateway operator view'. It distinguishes from sibling tools like paybond_list_audit_exports which lists multiple jobs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for fetching a single job detail, but does not explicitly state when not to use it or mention alternatives like paybond_list_audit_exports. The usage is implied by context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description implies a read-only verification, but annotations have readOnlyHint=false, creating a contradiction. No additional behavioral traits are disclosed beyond the schema/annotations.
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?
Two concise sentences that convey purpose, usage guidelines, and exclusions without any fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists and the tool is relatively simple (4 params, no enums), the description covers the key aspects. However, the behavioral contradiction and lack of return value explanation slightly reduce completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (all parameters have descriptions). The tool description adds no extra parameter meaning beyond 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 clearly states the tool is for 'raw capability-token verification for one tenant-bound Harbor intent', distinguishing it from siblings like paybond_authorize_agent_spend which is a 'clearer gate before side-effecting agent tools'.
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?
Explicitly tells when to use (capability-token verification) and when not to use (creating, funding, modifying intents), and points to an alternative tool (paybond_authorize_agent_spend).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true. Description adds workflow context: pre-validation, strict policy requirement, and that Harbor is authoritative at submit time. No contradictions 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, no waste. First sentence defines purpose, second adds condition, third clarifies authority. Efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters and output schema, description explains the tool's role clearly. Does not detail parameters or output, but output schema exists. Could mention parameter purpose briefly, but overall sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. Description does not explain any parameter meaning or usage. Parameter names like preset_id and payloads are somewhat self-explanatory, but the description fails to add value beyond 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 clearly states it pre-validates evidence against JSON schemas and forbidden fields, distinguishing it from sibling submit tools. The verb 'pre-validates' and resource 'completion evidence' are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
States it is required before evidence submit tools when PAYBOND_MCP_EVIDENCE_POLICY=strict, giving clear usage context. Notes that Harbor is authoritative at submit time, implying preliminary nature, but no explicit exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=false, destructiveHint=false, openWorldHint=true. The description adds that it's sandbox-only and has no live settlement rails, which aligns. However, no additional behavioral traits are disclosed (e.g., what side effects occur, if any). It neither contradicts nor substantially enriches beyond annotations.
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?
Two sentences, front-loaded with purpose and usage. No wasted words. Every sentence contributes essential information about when to use and when not to use.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's 6 parameters, 2 required, and existing output schema, the description is relatively short but covers the core purpose and constraints. It is complete enough for a sandbox guardrail tool, though more detail on parameter relationships could help. Output schema reduces need for return value explanation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50% (3/6 parameters described). The description does not add meaning beyond what the schema already provides for those parameters. No extra examples or constraints are given. Baseline 3 is appropriate as description doesn't compensate for missing schema 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 clearly states it's for building/testing a first paid-tool integration in a sandbox, with no live settlement rails. This distinguishes it from sibling tools like paybond_create_intent or paybond_authorize_agent_spend, which are for production or different intents.
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?
The description explicitly says when to use (building/testing first integration with sandbox) and when not to use (production live money movement or already-created Harbor intents). This provides clear context and implies usage of other sibling tools for those cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a write operation (readOnlyHint=false) and not destructive (destructiveHint=false). The description adds context about the specific route and that it's a low-level API call, which helps set expectations about behavior without contradicting annotations.
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?
Two sentences with no wasted words. Front-loads the use case and immediately provides a negative case with alternative. Efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers when to use and the alternative, but given the complexity (5 parameters, nested objects, output schema exists), it lacks detailed guidance on the structure of body and recognition_proof. The output schema mitigates some completeness concerns, but parameter-level gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate, but it only mentions 'body' and 'recognition_proof' generically without detailing the other three parameters (intent_id, idempotency_key, completion_preset_id). Meaningful parameter semantics are largely missing, leaving agents to guess the purpose of nested objects.
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 clearly states the tool submits Harbor evidence to a specific API route. It identifies the required inputs (request body and recognition proof) and distinguishes it from the sibling paybond_submit_spend_evidence by naming the low-level vs high-level context.
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?
Explicitly tells when to use (when you have the evidence body and proof for the specific route) and when not to use (for high-level spend-control path). Directly names the alternative tool (paybond_submit_spend_evidence), providing clear guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description adds value by specifying the scope ('delegated Harbor workflows') and confirming the operation is a fetch. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no extraneous information. Perfectly concise and front-loaded with the essential action.
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?
Given no parameters, strong annotations, and an output schema, the description is complete for an agent to understand the tool's purpose and safe invocation.
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?
The tool has zero parameters, and schema coverage is 100% trivially. Baseline is 4 per rule. Description adds no parameter info but provides context on what the tool lists.
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 'Fetch the published catalog of Paybond A2A task contracts for delegated Harbor workflows', which clearly states the verb (Fetch), resource (catalog), and context. It distinguishes from sibling 'paybond_get_a2a_task_contract' which retrieves a single contract.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
While the description implies usage for listing contracts, it lacks explicit guidance on when to use this tool vs alternatives like 'paybond_get_a2a_task_contract'. No when-not or context exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate the tool is not read-only and not destructive, with openWorldHint true. The description adds context about being a 'spend gate' for authorization but does not detail side effects (e.g., holds, budget deductions). It gives adequate workflow context but lacks full behavioral disclosure.
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 two sentences, front-loaded with the primary use case, and no unnecessary words. It efficiently conveys when to use and when not to use.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given an output schema exists and annotations are present, the description adequately covers the tool's role in the workflow (post-create_intent, pre-side-effect). It does not address error scenarios or failure modes, but is sufficient for agent selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The description provides overall context (e.g., 'tenant-bound spend gate') but does not add new meaning beyond the schema for individual parameters. Baseline of 3 is appropriate.
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 clearly states the tool's purpose: authorizing agent spend before side-effecting actions. It specifies the required context (intent_id, capability_token) and the action (tenant-bound spend gate). It distinguishes itself from siblings like paybond_create_spend_intent.
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?
The description provides explicit when-to-use and when-not-to-use guidance. It states 'Use this when an agent has an intent_id and capability_token' and 'Do not use this for creating, funding, or changing intents' with references to alternative tools (paybond_create_spend_intent, paybond_fund_intent).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true; description adds that it's a dry-run and not authorizing spend, reinforcing the read-only nature and policy-evaluation context.
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?
Two sentences, front-loaded with purpose and usage guidance, no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists and the tool has 11 parameters (only 1 required), the description covers the core purpose and usage well, though it doesn't detail output structure (covered by output schema).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description does not add parameter-specific meaning beyond schema, but the parameters are self-explanatory given the dry-run context.
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 clearly states the tool performs a 'read-only dry-run of remaining spend budget' for a specific resource (tenant-bound intent) and distinguishes it from authorization tools.
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?
Explicitly states when to use ('before authorizing a paid tool') and when not to use, directing to the sibling tool paybond_authorize_agent_spend.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true; description adds context: the read is idempotent, has no side effects, and errors (auth, RBAC, feature, gateway) surface as tool errors. This goes beyond the annotation.
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 concise, front-loading purpose and guidelines. It is a single sentence with some density, but every part is necessary. Could be slightly more structured but still effective.
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?
Despite having an output schema (not shown), the description fully covers purpose, usage, requirements, behavioral traits, and parameter details. Sibling tools are numerous but key differentiators are addressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a single optional parameter. The description mentions the parameter but does not add significant meaning beyond the schema's examples and description. Baseline 3 is appropriate.
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 clearly states the tool retrieves a 'tenant-scoped Signal portfolio aggregate' and lists specific fields. It distinguishes from sibling tools by explicitly naming when to use alternative tools (paybond_get_signed_portfolio_artifact, paybond_get_reputation_receipt).
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?
The description provides explicit when-to-use and when-not-to-use guidance, naming specific alternative tools. It also states prerequisite requirements (PAYBOND_API_KEY, Signal analytics read access, private-dashboards feature).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=true. The description adds minimal behavioral context beyond noting 'replay-safe recognition proof', which is more about input validation. No contradictions.
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?
Two dense sentences efficiently convey usage conditions and alternatives with no extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description adequately covers prerequisites, route, and differentiation from sibling. It doesn't detail return value or error scenarios, but the output schema likely handles that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema coverage, the description explains the meaning of 'body' as a fully signed Harbor intent request body and 'recognition_proof' as replay-safe proof, providing essential semantic context for both required parameters.
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 clearly states the tool creates a Harbor intent using a signed request body and recognition proof. It distinguishes itself from the sibling paybond_create_spend_intent by specifying when not to use it.
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?
Explicitly states when to use (when you have a fully signed intent and proof) and when not to use (prefer paybond_create_spend_intent for normal agent spend-control).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds value by specifying the nature of evaluation (proposed spend) and the possible outcomes (allow, require approval, deny), which goes beyond the annotations. However, it does not disclose other behavioral aspects like rate limits or error states, but given the annotations cover the key trait, the additional context earns a 4.
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 two sentences, front-loads the purpose, and uses no unnecessary words. Every sentence adds value, including the exclusion of alternative use.
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, the description does not need to explain return values. It covers the core functionality completely for a simple query tool, including the decision outcomes and the advisory against authorization.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does not elaborate on individual parameters beyond the overall purpose, which is acceptable since the schema already fully describes each parameter.
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 clearly states the verb 'explain' and the resource 'spend policy', specifying three outcomes: allow, require approval, or deny. It distinguishes itself from the sibling tool 'paybond_authorize_agent_spend' by explicitly saying not to use it for authorization.
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?
The description explicitly provides when to use ('when you need a read-only explanation') and when not to use ('do not use this to authorize spend or create approval requests'), and names the alternative tool 'paybond_authorize_agent_spend'. This is exemplary guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true. The description adds value by stating idempotency and null returns when no assessment exists, providing behavioral context beyond annotations.
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 concise (3 sentences), front-loaded with purpose, includes an example, and clearly lists exclusions. No redundant information.
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?
Given the presence of an output schema, the description adequately covers all necessary context: purpose, usage, exclusions, and a key behavioral note about null returns. Complete for a simple read operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 reinforces parameter usage with an example but does not add new semantic meaning beyond the schema's built-in 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 clearly states the specific verb 'get' and resource 'fraud assessment for one tenant-scoped operator DID'. It distinguishes from siblings by explicitly naming alternatives paybond_get_fraud_metrics and paybond_get_intent.
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?
The description provides explicit when to use ('before deciding whether to continue a spend workflow') and when not to use, with direct references to appropriate sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, but the description adds that the tool is 'Idempotent read with no side effects' and details error behavior for unsupported windows (HTTP 400). This adds useful context beyond the annotations.
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?
Three sentences, each earning its place: purpose and metrics, exclusions and alternatives, behavioral details (idempotent, defaults, error handling). Front-loaded with essential info, no fluff.
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 2 optional parameters, an output schema, and no nested objects, the description covers purpose, usage, auth, error conditions, and defaults comprehensively. It is complete given the complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already documents both parameters with descriptions and examples. The description adds only minor clarifications (default 24h for window, optionality of score_version). With full schema coverage, a score of 3 is appropriate.
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 clearly states the tool retrieves tenant-wide Signal fraud backtesting and monitoring metrics over a rolling window, listing specific metrics (flagged operators, severity counts, etc.). It distinguishes from siblings like paybond_get_fraud_assessment (single operator) and paybond_get_intent (Harbor intent escrow).
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?
Explicitly states when to use ('when you need tenant-wide Signal fraud backtesting and monitoring metrics') and when not to use, with direct references to alternative tools. Also mentions required authentication (PAYBOND_API_KEY with Signal analytics read access and private-dashboards feature).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, and description adds 'Read-only and side-effect free'. It also specifies tenant-bound Gateway GET and signed JSON. No contradiction.
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?
Description is slightly long but each sentence adds value. Front-loaded with core use. Could be slightly more concise but effective.
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?
Given output schema exists, description covers purpose, usage, exclusions, and alternatives. Complete for a read tool with good annotations.
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%, but description adds context: ID formats (SHA-256 hex or UUID), tenant binding, and warning about inventing identifiers. Adds meaning beyond 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?
Description clearly states the tool retrieves a signed JSON receipt for a given receipt_id, specifies the ID formats, and distinguishes from settlement receipts. It also mentions the alternative MCP resource.
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?
Explicitly says when to use (need signed receipt) and when not (protocol settlement receipts, refer to sibling). Also mentions preferring MCP resource for agent-to-agent handoff and excludes validity tiers.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds context beyond annotations: declares the operation idempotent with no side effects, explains error handling (auth/RBAC/failure surfaced as errors), and confirms read-only nature aligning with readOnlyHint. No contradiction.
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 informative and front-loaded with core purpose, but slightly verbose. Each sentence earns its place, though minor tightening possible without losing clarity.
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?
Fully covers all aspects for a simple one-parameter tool: use case, prerequisites, parameter behavior, error semantics, and sibling differentiation. Output schema exists, so return details are not needed in description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description only restates the parameter's default behavior already in the schema ('Omit to use gateway default current model'). No additional parameter meaning or constraints beyond 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?
Description specifies a precise verb-resource combination ('get signed portfolio artifact'), details the content (operator list + Ed25519 signing material), and clearly distinguishes from sibling tools like paybond_get_portfolio_summary and paybond_get_reputation_receipt.
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?
Explicitly states when to use (portable signed snapshot for offline checks), when not to use (not for public leaderboard), provides alternatives for related tasks, and lists required credentials (PAYBOND_API_KEY with read access).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds idempotency, read-only external GET, no side effects, and error handling beyond annotations' readOnlyHint, providing full transparency for an identity lookup.
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?
Well-structured and front-loaded, but slightly verbose with multiple sentences. Still concise enough to be effective without redundancy.
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?
Complete coverage: explains purpose, usage, side effects, and returned fields (tenant_id, subject, roles). Output schema exists, so detail on return structure is sufficient.
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?
No parameters in schema (100% coverage by default); description mentions use of PAYBOND_API_KEY (config), which is not a parameter but acceptable context. Score baseline 4 for zero-parameter tool.
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 clearly states the tool confirms the tenant-bound service-account principal (tenant_id, subject, roles) and distinguishes it from sibling tools like paybond_get_intent and paybond_get_a2a_agent_card.
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 guidance on when to call (prerequisite before tenant-scoped tools when identity unknown), when not needed (once tenant_id known), and alternatives (use paybond_get_intent for intent detail, paybond_get_a2a_agent_card for A2A).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes idempotent read with no side effects, and the return behavior when no receipt exists (returns null). Adds context beyond readOnlyHint annotation, such as tenant-scoping constraints.
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?
Single paragraph with no wasted words. Front-loads purpose, then provides alternatives, requirements, and behavior. Every sentence adds value.
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?
Covers all key aspects: purpose, scope, alternatives, permissions, behavior, and parameter constraints. Output schema exists but description sufficiently complements it.
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 has 100% coverage with descriptions and examples. Description adds extra constraint ('Must belong to the authenticated tenant; do not invent tenant identifiers') not in schema, improving semantics.
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 clearly states the tool retrieves a signed Signal reputation receipt for one operator DID, including specific content (score, metrics, reason codes, signing material). It also distinguishes from sibling tools by naming them explicitly.
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?
Explicitly states when to use ('Use this when you need the signed Signal reputation receipt for one known tenant-scoped operator DID'), when not to use (e.g., for tenant-wide aggregates), and provides alternative tool names. Also specifies required API key permission.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool is read-only and side-effect free, and details what success returns (valid=true with kind, receipt_id, tenant_id, normalized receipt) and failure behavior (clear verification error). This goes beyond the annotations which only indicate readOnlyHint=true.
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 and efficient, front-loading the core use case, providing clear exclusions, and then adding behavioral details. Every sentence adds necessary information without redundancy.
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?
Given the presence of an output schema and the complexity of the input (nested object), the description sufficiently covers the tool's behavior: it explains what the tool does, when to use it, and what to expect from success and failure. No gaps remain.
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?
Although schema coverage is 100%, the description adds value by specifying that the receipt parameter must be a complete signed object (not a string) and how to obtain it. The validity_tier parameter's description clarifies the context for each tier (operational, primary, attested) and advises that MCP handoff only requires operational.
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 clearly states the tool's purpose: verifying a signed paybond.agent_receipt_v1 JSON object via an offline Ed25519 signature check. It distinguishes itself from the sibling tool paybond_verify_protocol_receipt_v1 by explicitly stating not to use it for protocol authorization/settlement receipts.
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?
The description provides explicit guidance on when to use this tool (when you have a signed agent receipt) and when not to (for protocol receipts, directing to paybond_verify_protocol_receipt_v1). It also mentions that other audit surfaces are covered elsewhere.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes side-effect-free read-only behavior, success output fields (valid=true, kind, receipt_id, etc.), and failure modes (unsupported kind, malformed JSON, digest mismatch, signature failure -> HTTP 400). Consistent with readOnlyHint annotation.
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?
Concise, front-loaded with purpose and usage. Each sentence adds necessary information without redundancy. No wasted words.
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?
Given the complexity (1 nested parameter, output schema exists), the description covers usage, behavior, failure modes, and sourcing of inputs. Complete for an agent to decide on invocation.
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 already provides detailed descriptions for the receipt parameter, including required fields for each kind. The description adds value by explaining where receipts come from and warning not to invent digests/signatures.
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?
Clearly states the tool verifies a signed protocol-v2 authorization or settlement receipt (offline Ed25519 verification). Distinguishes from siblings like paybond_verify_agent_mandate_v1 and paybond_verify_capability.
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?
Explicitly tells when to use (already have signed receipt) and when not to (identifies alternative tools for other verification tasks). Also provides a workflow hint about calling paybond_get_settlement_receipt_v1 first.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![paybond-kit MCP server](https://glama.ai/mcp/servers/nonameuserd/paybond-kit/badges/card.svg)](https://glama.ai/mcp/servers/nonameuserd/paybond-kit)

Score Badge

Copy to your README.md:

[![paybond-kit MCP server](https://glama.ai/mcp/servers/nonameuserd/paybond-kit/badges/score.svg)](https://glama.ai/mcp/servers/nonameuserd/paybond-kit)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/nonameuserd/paybond-kit'

If you have feedback or need assistance with the MCP directory API, please join our Discord server