paybond-mcp-Python
Server Quality Checklist
Latest release: v0.12.17
- Disambiguation5/5
Each tool has a meticulously crafted description that clearly states its purpose and explicitly lists what NOT to use it for, eliminating ambiguity even across similar-looking tools like paybond_create_intent vs paybond_create_spend_intent.
Naming Consistency5/5All tools follow a consistent 'paybond_verb_noun' pattern (e.g., get, verify, submit, list, create) with optional version suffixes, making the naming predictable and systematic.
Tool Count2/5With 31 tools, the server is far beyond the typical 3-15 range. While the domain is complex, the large surface area can overwhelm agents and increase selection difficulty.
Completeness4/5The tool set covers a broad range of fintech operations: identity, intents, capabilities, evidence, fraud, reputation, A2A, receipts, and mandates. Minor gaps like refunds or dispute resolution might exist, but core workflows are well-supported.
Average 4.1/5 across 31 of 31 tools scored. Lowest: 2.8/5.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 1 community issues answered or closed in the last 6 months
- 42 commits in the last 12 weeks
- Last stable release on
- 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 already declare readOnlyHint=true, so the description's mention of 'verify' is consistent but adds minimal value. No additional behavioral traits (e.g., side effects, authorization needs) are disclosed 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.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no redundancy, but it is overly terse and sacrifices clarity. A more informative description would better serve the agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite a single parameter and output schema existence, the description does not explain the return value or the verification outcome (e.g., boolean, details). Annotations provide minimal context, leaving the agent underinformed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description provides no details on the structure or expected fields of the 'signed_mandate' parameter. The mention of 'AgentMandateV1 envelope' is vague and insufficient for parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (verify) and the specific resource (signed AgentMandateV1 envelope), distinguishing it from sibling verification tools like verify_capability and verify_protocol_receipt_v1. However, the jargon ('gateway v2 protocol surface') may obscure meaning.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, nor any prerequisites or exclusions. The description merely restates the tool's purpose without application context.
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 description's mention of 'Fetch' aligns and adds that the receipt is 'signed protocol-v2'. However, it does not disclose what the signed receipt contains or its permanence. This adds marginal value 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.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (11 words) and front-loaded, but it is too brief. It sacrifices necessary detail for brevity, making it only adequate. Additional context would improve without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (1 param, output schema exists), the description should at least explain the parameter and usage context. It fails to do so, leaving the agent without enough information to use the tool correctly. The purpose is clear but incomplete for execution.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'receipt_id' is a required string with 0% schema description coverage. The description does not explain what a receipt_id is, how it is generated, or how to obtain it. This leaves the agent guessing about valid input values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Fetch' and the resource 'signed protocol-v2 settlement receipt for one Harbor intent'. It is specific and distinguishes itself from sibling tools like paybond_get_intent or paybond_get_reputation_receipt by focusing on a particular receipt type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool versus alternatives. It implies it is for fetching a specific receipt but offers no context on prerequisites, such as having an intent ID or where to obtain a receipt_id. Given many sibling tools, this lack of guidance is a gap.
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 description's 'Fetch' is consistent. It adds context about tenant-scoping and the gateway operator view, but does not disclose any additional behavioral traits such as error handling, permissions, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single concise sentence that front-loads the purpose with the verb and resource. No extraneous words; every part is informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the single parameter and existence of an output schema, the description covers scope and view context. However, it omits any description of the parameter and does not clarify what an 'intent' is, which is a gap for new users.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not explain the only parameter 'intent_id' beyond what the schema provides (a string). With 0% schema description coverage, the description should compensate but fails to add meaning or format guidelines.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific verb 'Fetch' and resource 'Harbor intent detail', with scoping ('one tenant-scoped') and access view ('through the gateway operator view'). This distinguishes it from sibling tools like paybond_list_intents (list) and paybond_create_intent (create).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for fetching a single intent but does not explicitly state when to use this tool versus alternatives like list_intents or create_intent. No exclusions or context for when not to use 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?
The description adds value beyond annotations by noting that the proof is 'replay-safe' and that verification is against expected purpose and request envelope. Annotations already indicate readOnlyHint=true, so the tool is safe. No contradiction observed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences, front-loading the core action. No unnecessary words or repetition. Slightly more detail on parameters could be added without harming conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although an output schema exists (not shown), the description does not mention return values or error conditions. For a verification tool with three required object parameters, more contextual information is needed to ensure correct invocation, such as what constitutes a valid proof or expected request format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate for parameter meaning, but it only mentions 'expected purpose' and 'request envelope' without explaining the 'proof' object or the structure of 'expected_request'. The term 'request envelope' is vague and does not clarify the parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Verify a replay-safe AgentRecognitionProofV1 against an expected purpose and request envelope.' It specifies the verb (Verify) and the resource (AgentRecognitionProofV1), and it differentiates from similar siblings like verify_agent_mandate_v1 and 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 Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some context by stating that verifier context is derived from the authenticated session, but it does not explicitly advise when to use this tool versus alternatives like verify_agent_mandate_v1 or verify_protocol_receipt_v1. No when-not-to-use or prerequisite guidance 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 indicates a read-only fetch operation, which aligns with the readOnlyHint annotation. However, it does not add behavioral details beyond what annotations already provide, such as error handling or authorization needs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that conveys the purpose efficiently with no redundant words or sections.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists (though not shown in detail) and the tool is a simple fetch, the description is reasonably complete. It lacks mention of error states or what 'published' implies, but overall sufficient for an experienced agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description should compensate by explaining the 'contract_id' parameter's format or constraints, but it only mentions 'by identifier' without further details. The schema itself lacks descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does 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 as a 'published Paybond A2A task contract', distinguishing it from sibling tools like 'paybond_list_a2a_task_contracts' which lists multiple.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for fetching a single contract by ID, but does not explicitly state when to use this tool versus alternatives, nor does it provide 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.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide basic behavioral hints (readOnlyHint=false, openWorldHint=true), and description adds context about simulator settlement/predicate checks. However, it does not explain idempotency, side effects, or what happens on resubmission 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences that immediately state purpose and usage boundaries. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite 8 parameters and low schema coverage, the description omits critical details for correct invocation, such as how to structure evidence or what each parameter does. Output schema exists but description doesn't leverage it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not explain any of the 8 parameters (e.g., payload, metadata, artifacts). No parameter-level guidance provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states verb 'submit evidence' and resource 'sandbox guardrail intent'. Differentiates from sibling 'paybond_submit_spend_evidence' by specifying sandbox vs live Harbor spend.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use (sandbox guardrail intent needs evidence) and when not to use (live Harbor spend evidence) with a named alternative tool.
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, indicating a safe read operation. The description adds context about the tenant scope and gateway operator view, which are useful behavioral constraints. 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single, concise sentence of 11 words that clearly conveys the core functionality with no unnecessary verbiage. Front-loaded with the action verb.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the purpose is clear and annotations provide read-only info, the description lacks parameter explanation. An output schema exists but does not excuse the missing parameter semantics. For a 2-parameter tool, this is insufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. However, it does not explain the meaning of job_id or issue_download. The phrase 'job detail' only hints at job_id, and issue_download is not mentioned at all.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does 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', the scope 'tenant-scoped', and the viewpoint 'gateway operator view'. This uniquely identifies the tool and differentiates it from siblings like paybond_list_audit_exports.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for a single audit export job detail and mentions the operator view, but it does not explicitly state when to use this tool versus alternatives (e.g., paybond_list_audit_exports) nor provide 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 already indicate readOnlyHint=true, so the read-only nature is clear. The description adds value by specifying the scope ('tenant-scoped') and access context ('gateway operator view'), which is beyond what annotations convey. However, it does not mention pagination behavior or other traits like rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, no redundant words, and front-loads the core purpose. Every sentence adds value: the first states the main action, the second lists optional filters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 optional parameters and no parameter descriptions, the description is minimal. It does not cover parameter constraints or output details, though an output schema exists. The agent may struggle with proper parameter formatting without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the burden. It lists the parameter names (status, operator DID, limit, cursor) but provides no details on their semantics, formats, valid values, or required constraints. This leaves the agent with insufficient guidance for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('list'), the resource ('Harbor intents'), and the scope ('tenant-scoped through the gateway operator view'). It is specific and distinguishes from sibling tools like paybond_create_intent or 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 Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing intents but does not explicitly state when to use this tool versus alternatives like paybond_get_intent for a single intent or when not to use it. No exclusions or context for selection 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 already indicate a write operation (readOnlyHint=false) and non-idempotence. The description adds value by specifying the 'replay-safe recognition proof' mechanism and the 'gateway v2 protocol surface', providing behavioral context beyond annotations. However, it does not explain failure modes or authorization requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence that is front-loaded with the primary action. It uses precise terminology without excess verbiage. Every part of the sentence contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (4 parameters, nested objects, binding process) and the presence of an output schema, the description is adequate but lacks details on side effects, success/failure outcomes, or idempotency implications. It provides the core purpose but not a complete picture.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 explains signed_mandate, intent_id, and recognition_proof by linking them to the domain terms 'signed AgentMandateV1', 'Harbor intent', and 'replay-safe recognition proof'. The transport_binding parameter is not mentioned, but the three required parameters are well explained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb 'import', the resource 'AgentMandateV1', and the binding to a 'Harbor intent' using a 'replay-safe recognition proof'. It distinguishes from sibling tools like verify_agent_mandate_v1 which focus on verification rather than import and binding.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. It does not mention prerequisites (e.g., intent must exist), exclusion criteria, or when not to use it. The description is purely functional without contextual usage advice.
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 read-only nature is clear. The description adds that the tool is tenant-scoped and accessed via the operator view, which provides useful context 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-formed sentence that efficiently conveys the tool's purpose without extraneous words. Every part contributes value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (not needed to describe return values), the description is mostly complete. However, it misses mentioning pagination behavior implied by the parameters (limit/cursor), which would aid agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning no parameter descriptions exist in the schema. The tool description does not add any meaning for the 'limit' or 'cursor' parameters (e.g., pagination hints). It fails to compensate for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists tenant-scoped compliance audit export jobs via the gateway operator view. It uses a specific verb and resource ('list audit exports'), and the scope is clarified, distinguishing it from sibling tool 'paybond_get_audit_export' which retrieves a single 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used through the 'gateway operator view' but does not explicitly state when to use it versus alternatives like 'paybond_get_audit_export'. No exclusions or context cues for selection are provided.
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-destructive. Description adds context about audit-record usage but does not discuss idempotency or side effects beyond that. 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no redundant information, front-loaded with core purpose and exclusions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters (3 required), nested objects, and an output schema, the description is too brief. It does not explain the structure of body or recognition_proof, nor the output. More details on evidence format and prerequisites are needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any parameters. It mentions 'signed evidence' but does not map to parameters like intent_id, body, recognition_proof. The description fails to compensate for missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool's purpose: submitting signed evidence for a Paybond spend intent. It distinguishes from creating/funding intents and sandbox guardrail evidence, aligning with sibling tools like paybond_create_spend_intent and paybond_submit_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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (when a spend intent needs signed evidence) and when not to use (not for creating/funding intents, not for sandbox guardrail evidence). Provides clear exclusions.
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, idempotentHint=false. Description adds that it creates a 'tenant-bound spend gate' and is used before side-effecting tools, but does not detail side effects or failure modes. 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no redundant information. Efficiently conveys purpose and usage boundaries.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema exists. Description covers when to use and alternatives, but lacks detail on return values, error handling, or behavior of parameters. Adequate but could be more complete given tool complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%; description does not explain any of the 4 parameters (token, intent_id, operation, requested_spend_cents). Parameter names give some hint, but no details on format, defaults, or semantics beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool authorizes a spend gate when an agent has an intent_id and capability_token, before calling side-effecting tools. It distinguishes from sibling tools by specifying not to use for creating/funding 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (when agent has intent_id and capability_token, before side-effecting calls) and when not to (for creating/funding intents), and names alternatives (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=false and destructiveHint=false, but the description adds behavioral context: it is sandbox-only with no live settlement rails. This goes beyond annotations by specifying environmental 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with usage context, no redundant words. Every sentence earns its place by defining 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.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains purpose and usage boundaries, and an output schema exists so return values are covered. However, with 6 parameters and no parameter guidance, the description is incomplete for helping an agent correctly populate arguments.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no information about the 6 parameters (operation, requested_spend_cents, currency, metadata, evidence_schema, idempotency_key). The description fails to compensate for the lack of parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a sandbox-only guardrail intent for building/testing first paid-tool integrations, specifying 'no live settlement rails'. It distinguishes from production use and already-created Harbor intents, aligning with the tool's name and title.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use (building/testing first integration needing sandbox guardrail) and when not to use (production live money movement, already-created Harbor intents). While it doesn't name sibling tools as alternatives, the exclusions provide clear context.
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. Description adds context (published catalog, delegated Harbor workflows) but lacks details like return format or pagination. 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, 12 words, front-loaded with verb and resource. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and existing output schema, the description adequately explains what the tool does and its context. It could mention the output schema or note that the catalog contains all contracts, but overall complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so schema coverage is 100%. Description does not need to add parameter info. Baseline 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'Fetch' and resource 'published catalog of Paybond A2A task contracts' with context 'for delegated Harbor workflows'. Clearly 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives. While the tool itself is straightforward (read-only, no parameters), the description misses an opportunity to clarify that this is for listing versus getting a single contract, which is relevant given siblings.
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 indicate readOnlyHint=false, but the description describes a verification operation that likely does not mutate state. However, it does not explicitly confirm idempotency or lack of side effects. No contradiction, but behavioral details are minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the primary purpose and usage boundaries. No redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 4 parameters and 0% schema coverage, the description should provide more parameter context. While output schema exists (so return format is covered), the description omits guidance on token format, operation values, or spend semantics. It is adequate but incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description only mentions 'one tenant-bound Harbor intent' but does not explain the meaning of individual parameters (intent_id, operation, token, requested_spend_cents). The agent needs more context to select values correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description explicitly states the tool performs 'raw capability-token verification for one tenant-bound Harbor intent', using a specific verb and resource. It distinguishes from paybond_authorize_agent_spend by noting it as 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear guidance: 'Use this when you need raw capability-token verification' and explicitly states when not to use it: 'Do not use this to create, fund, or modify intents; use paybond_authorize_agent_spend as the clearer gate'. This includes an alternative tool.
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 it's a write (readOnlyHint=false) and non-destructive. The description adds 'replay-safe recognition proof' context but does not elaborate on idempotency or other side effects 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is two sentences, front-loaded with purpose, and each sentence adds essential value without redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given 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 sibling tools, the description covers the core use case adequately, though it could explicitly mention the low-level nature and prerequisites more comprehensively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description only partially explains two parameters ('body' and 'recognition_proof') in context but omits details on structure or constraints for the third parameter 'idempotency_key'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does 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, distinguishes it from the sibling paybond_create_spend_intent, and specifies the prerequisite of a fully signed request body and proof.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says when to use (having signed intent body and proof) and when not to use (preferring the higher-level alternative), providing clear context for agent decision-making.
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 description's 'Fetch' is consistent. No additional behavioral traits (e.g., caching, idempotency) are disclosed 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that is front-loaded with the action and resource. Every word is meaningful, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no parameters, has annotations providing safety hints, and an output schema presumably describes return values. The description is sufficient for an agent to understand its purpose and when to call it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters and schema coverage is 100%, so the description has no need to add parameter details. Baseline for 0 parameters is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches the published Paybond A2A discovery card for protocol-trust delegation. This verb+resource combination is specific and distinct from sibling tools which handle fraud, contracts, verification, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use or when not to use; however, the tool is straightforward with no parameters and a clear purpose, so the context is implied. Missing exclusionary or alternative usage notes keep it at a mid score.
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 and openWorldHint=false. The description adds behavioral context: pre-validation against schemas and forbidden fields, and that it is not authoritative (Harbor is authoritative at submit time). This provides useful transparency beyond the annotations, though it could detail the validation result 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose in the first sentence. Every word adds value: the first sentence defines the action and scope, the second gives usage condition and caveat. No redundant or irrelevant content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (though not provided in the input), the description need not detail return values. It adequately covers the tool's purpose, prerequisite, and non-authoritative nature. However, it could mention what 'catalog JSON Schemas' refers to or hint at the validation outcome format, making it slightly less complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not explain any of the 6 parameters beyond mentioning 'vendor and canonical completion evidence', which loosely maps to vendor_payload and canonical_payload. The frozen_* parameters and preset_id are not described at all. Since schema description coverage is 0%, the description should compensate but fails to add meaningful parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: pre-validating vendor and canonical completion evidence against JSON schemas and forbidden fields. It distinguishes itself from sibling submit tools (e.g., paybond_submit_evidence) by explicitly stating it's a pre-validation step, and notes that Harbor is authoritative at submit time, clarifying its role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when this tool is required: before evidence submit tools when PAYBOND_MCP_EVIDENCE_POLICY=strict. While it provides clear context for use, it does not explicitly mention when not to use it or name alternative tools for other scenarios, which prevents a score of 5.
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's mention of 'read-only' is consistent but not additive. The description adds behavioral context by explaining the type of explanation (allow/approve/deny), which is useful but not required given 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first states purpose, second provides usage warning and alternative. Every sentence earns its place; no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (11 parameters) and existing annotations, the description is adequate for purpose and usage but incomplete on parameter semantics. With output schema present, return values are covered, but the lack of parameter guidance creates a gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description should compensate but does not. It mentions 'proposed spend' but never maps to any of the 11 parameters (e.g., requested_spend_cents, currency, vendor_id). The agent receives no guidance on how to fill parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('explain') and resource ('spend policy'), and clearly states the outcomes (allow, require approval, deny). It distinguishes from sibling tool paybond_authorize_agent_spend, which is for persisting decisions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when not to use this tool ('do not use to authorize spend or create approval requests') and provides a clear alternative ('call 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 indicate readOnlyHint=true, which aligns with the description calling it a 'read-only dry-run'. The description adds context about its use in a workflow (before authorization) and implies no side effects. 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (two sentences), front-loads the purpose, and includes essential usage guidance without extraneous details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the high parameter count (11) and zero schema descriptions, the description lacks completeness on parameter usage. However, the presence of an output schema covers return values, and the core use case is well-defined. The description is adequate but does not fully compensate for missing parameter details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not explain any of the 11 parameters beyond the vague mention of 'tenant-bound intent'. With 0% schema description coverage, the agent must infer parameter meanings from names alone, missing guidance on optional parameters like currency, tool_name, etc.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: a read-only dry-run to check remaining spend budget for a tenant-bound intent before authorizing a paid tool. It uses a specific verb ('get') and resource ('remaining spend budget'), and distinguishes itself from sibling tools by mentioning when not to use.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use it ('before authorizing a paid tool') and when not to use it ('do not use to authorize spend or create decisions'), directing the agent to the 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 indicate mutability (readOnlyHint=false). The description adds that it is a low-level Harbor API call, implying direct database writes and side effects beyond what annotations convey. This contextualizes the behavioral impact.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no excess words, front-loaded with usage guidance. Every sentence serves a clear purpose: specifying when to use and when to avoid.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is complex (5 params, nested objects) with an output schema. The description covers purpose and alternatives but lacks parameter details and behavioral specifics beyond the route. Given annotations and output schema, some gaps remain, particularly around parameter semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description mentions 'body' and 'recognition proof' but does not explain intent_id, idempotency_key, or completion_preset_id. The agent must infer their meanings from names, which is insufficient for a 5-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it submits Harbor evidence using a specific route, with a specific verb and resource. It distinguishes from the sibling tool paybond_submit_spend_evidence by specifying the API route and low-level nature.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (when you have Harbor evidence body and recognition proof) and when not to use (high-level spend-control path), recommending the alternative 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 it's not read-only, not destructive, and not idempotent. The description adds behavioral context beyond annotations by detailing that the intent includes bounded budget, allowed operations, evidence requirements, and settlement review. 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. It front-loads the usage instruction and immediately states the alternative, making it efficient and scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters, one nested object, and an output schema, the description covers the high-level purpose and provides alternative usage. However, it lacks detail on the recognition_proof parameter and does not expand on the body structure beyond high-level features. An output schema exists to cover return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description does not explicitly describe the parameters. It mentions high-level intent features (bounded budget, etc.) which likely map to the body, but does not address idempotency_key or recognition_proof. This leaves the agent with little guidance on parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (create) and the resource (Paybond spend intent) with specific attributes (bounded budget, allowed operations, evidence requirements, settlement review). It also distinguishes from the sibling tool paybond_authorize_agent_spend by contrasting use cases.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly specifies when to use this tool (for creating a new spend intent) and when not to (for checking an already funded capability token), and provides the alternative tool (paybond_authorize_agent_spend). This gives clear context and prevents misuse.
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?
Description adds context beyond annotations: confirms read-only and side-effect free, specifies tenant-bound Gateway GET, and clarifies scope boundaries for validity tiers.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose and usage, but the last sentence on validity tiers is somewhat extraneous for a tool description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given one parameter with no schema docs and an output schema exists, description adequately covers the return type and use case, with clear boundaries.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description explains that receipt_id is a SHA-256 action id or intent-terminal UUID, providing crucial format context absent from schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool retrieves a signed agent receipt JSON for a given receipt_id, with specific identifier types. Distinguishes from sibling tool for 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (need signed agent receipt for one receipt_id), when not to (settlement receipts), and provides alternative resource for agent-to-agent handoff.
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 incremental value by stating 'Idempotent read' and 'returns null when no assessment exists'. This goes beyond annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact (three sentences) and well-structured: purpose, example, exclusions, behavioral note. No wasted words; each sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of both input and output schemas, the description covers purpose, parameters, exclusions, and behavioral details. Nothing is missing for effective tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description adds meaningful context: operator_did must belong to authenticated tenant, and score_version is optional with default. Examples reinforce usage. This provides extra clarity beyond the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it retrieves a read-only fraud assessment for a known operator DID, distinguishing it from sibling tools like paybond_get_fraud_metrics and paybond_get_intent. The verb 'get' and resource 'fraud assessment' are specific and 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use context (before deciding on a spend workflow) and when-not-to-use (for tenant-wide metrics or intent escrow details), including direct references to alternative tools. Also includes an example invocation.
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?
Describes idempotent read with no side effects and null return for missing receipts. Annotations already indicate readOnlyHint, but description adds idempotency and null behavior, enhancing transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Concise and well-structured. The main purpose is in the first sentence, followed by clear exclusions and behavioral details. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given simple tool with 2 parameters, full schema coverage, and existing output schema, the description covers purpose, constraints, alternatives, and edge case (null return). Fully adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 context about the operator DID belonging to the authenticated tenant and provides examples, going beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Explicitly states the tool retrieves a signed Signal reputation receipt for a single tenant-scoped operator DID, with clear verb and resource. Distinguishes from three sibling tools by specifying what not to use it for.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use, when-not-to-use, and names alternative tools for other use cases (portfolio summary, signed portfolio artifact, fraud assessment). Also mentions required API key and read access.
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?
The description states 'Read-only and side-effect free', aligning with readOnlyHint annotation. It details success conditions (valid=true with fields) and failure modes (HTTP 400 for errors), adding 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with purpose and usage, then behavioral details. Every sentence adds value, but it is slightly lengthy; however, the complexity justifies the length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the single object parameter and presence of output schema, the description fully covers purpose, usage, behavior, and parameter structure, leaving no gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds significant meaning by discriminating between two receipt kinds (authorization vs settlement) with detailed required fields, beyond the schema's description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool verifies a signed protocol-v2 receipt using Ed25519, with specific verb 'verify' and resource 'protocol receipt'. It distinguishes from siblings by explicitly naming alternatives for AgentMandateV1 and Harbor capability tokens.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use (already have signed receipt JSON) and when-not-to-use (not for AgentMandateV1 or Harbor capability). It also instructs to call paybond_get_settlement_receipt_v1 first if needed.
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?
Annotations already set readOnlyHint=true; description adds concrete details: 'read-only external GET', 'idempotent identity lookup with no side effects', and clarifies error behavior. Fully consistent with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is somewhat lengthy but each sentence adds value. It is front-loaded with purpose and structured with clear usage guidance. Could be slightly more concise but still effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has zero parameters and an output schema (present), the description fully covers purpose, usage context, behavioral traits, and comparisons to siblings. No gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so schema coverage is 100% vacuously. The description does not need to add parameter info; baseline 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verb 'confirm' and resource 'tenant-bound service-account principal', and clearly lists returned fields (tenant_id, subject, roles). It explicitly distinguishes from sibling tools by naming them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when to use (prerequisite before Harbor escrow, Signal reads when tenant identity unknown), when not to use (once tenant_id known, not for intent escrow or A2A discovery), and suggests alternatives (paybond_get_intent, paybond_get_a2a_agent_card).
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: idempotent read with no side effects, auth requirements (PAYBOND_API_KEY with Signal analytics read access and private-dashboards feature), and error behavior for invalid windows (HTTP 400).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences front-load the purpose, then provide exclusions/requirements, then behavioral details. No redundant or superfluous text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, usage boundaries, auth, default behavior, error cases, and return value coverage via output schema. Complete for a read tool with two optional parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds default behavior for window (24h) and clarifies that unsupported windows fail. For score_version, it restates optionality and default. Slightly above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool retrieves tenant-wide fraud backtesting and monitoring metrics, specifies the verb 'get' and resource 'fraud metrics', and distinguishes from sibling tools like paybond_get_fraud_assessment 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly indicates when to use (for tenant-wide metrics) and when not to use (not for one operator or Harbor intent), and provides alternative tool names.
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 error handling (auth/RBAC/gateway failures surface as errors), adding context beyond 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Concise single paragraph front-loading purpose, followed by usage guidelines and behavioral details; every sentence contributes meaningfully.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, usage, behavioral transparency, parameter default, and tenant scope; output schema exists so return info not needed; fully adequate for agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Single optional parameter with schema coverage 100%; description adds value by explaining omission defaults to current model (1.0), though mostly aligns with schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool retrieves a signed portfolio artifact for offline/partner sharing, distinguishes from public leaderboard and 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (portable signed snapshot) and when not to (for aggregates, receipts, fraud assessment), and names alternative tools for each case.
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?
Discloses read-only, idempotent behavior with no side effects, aligns with readOnlyHint annotation. Describes required auth, feature flag, and possible error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences with clear front-loading: purpose, constraints, exclusions, and safety. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, usage boundaries, behavior, auth, error modes, and parameter semantics. Output schema exists, so return values need not be detailed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers the parameter fully with description and examples. Description adds context about default behavior, complementing without redundancy.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it returns a tenant-scoped portfolio aggregate with specific fields. Explicitly distinguishes from sibling tools by naming alternatives for different use cases.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use (read-only portfolio aggregate) and when-not-to-use (signed operator list or receipt), referencing sibling tools by name.
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?
Annotations already state readOnlyHint=true and openWorldHint=false. The description adds behavioral details: side-effect free, success returns valid=true with specific fields (kind, receipt_id, tenant_id, normalized receipt), failures raise clear verification error. It also explains the optional validity_tier effect. 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, each purposeful. First sentence states purpose and usage. Second adds optional tier. Third clarifies exclusion. Fourth summarizes return behavior. No fluff, efficiently front-loaded with key info.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (nested object, optional validity tiers, multiple verification facets), the description is complete. It covers inputs, sources, exclusions, and outputs (success/failure). The presence of an output schema is noted but not shown; description still provides sufficient detail for agent selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for both parameters. The description adds significant meaning: for 'receipt', it clarifies it must be a complete signed object (not just ID) and lists valid sources; for 'validity_tier', it explains default 'operational' and that higher tiers are auditor-oriented, not needed for MCP handoff. This goes well beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool verifies a signed paybond.agent_receipt_v1 JSON object via offline Ed25519 signature check. It distinguishes itself from the sibling 'paybond_verify_protocol_receipt_v1' by specifying 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use: 'when you already have a signed paybond.agent_receipt_v1 JSON object and need an offline Ed25519 signature check'. Also explicitly tells what not to use it for: 'Do not use this for protocol authorization/settlement receipts—call paybond_verify_protocol_receipt_v1', giving a clear alternative.
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:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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-python'
If you have feedback or need assistance with the MCP directory API, please join our Discord server