Return a previously issued signed receipt by job identifier. Optional requester-proof fields depend on the historical receipt.
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes |
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral disclosure. It notes that 'Optional requester-proof fields depend on the historical receipt,' which hints at conditional output, but it does not explicitly state whether the operation is read-only, requires authentication, or has any side effects. The term 'signed receipt' implies cryptographic integrity but not operational behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two sentences, front-loads the primary action, and contains no filler. It is appropriately concise and well-structured for a simple retrieval tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which covers return values) and only one parameter, the description does not need to explain return shape. It covers the essential context: what the tool does, the identifier used, and a caveat about conditional fields. It lacks any mention of error conditions or prerequisites, but for a low-complexity getter with output schema, this is acceptable completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain parameters. It does so by clearly stating the receipt is retrieved 'by job identifier,' mapping directly to the sole required parameter job_id. This adds meaning beyond the bare type definition. It also mentions 'optional requester-proof fields,' which may relate to output but not directly to parameters. Overall, it sufficiently clarifies the one parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Return a previously issued signed receipt by job identifier.' It uses a specific verb (return) and a specific resource (signed receipt) with a clear identifier (job_id). This distinguishes it from sibling tools like 'verify_receipt' (which verifies rather than retrieves) and other getters focused on different domains.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you have a job_id and want the associated previous receipt, but it does not provide explicit when-to-use or when-not-to-use guidance, nor does it mention alternatives like verify_receipt. It is clear enough for basic selection but lacks exclusionary context or scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Most tools are clearly distinct, targeting specific documents or endpoints (e.g., identity, capabilities, JWKS, receipts). However, some overlap exists among discovery-related tools (e.g., get_agent_discovery, get_agent_identity, get_capabilities, get_marketplace_listing) that could cause confusion about which to use for a given purpose.
All tool names follow a consistent pattern: 'hodlxxi_get_' or 'hodlxxi_verify_' followed by a descriptive noun phrase. The verbs are consistent (get/verify) and the nouns are specific, making the naming predictable and uniform.
With 26 tools, the count is slightly above the typical well-scoped range (3-15) but still reasonable for a read-only server that exposes a wide array of public documents and metadata. Each tool serves a distinct purpose, so the count is justified, though it borders on heavy.
The server covers a comprehensive set of read-only operations for its domain: identity, capabilities, skills, receipts, trust events, OAuth/OIDC metadata, and verification. Minor gaps exist, such as no tool for listing all covenants or reports (only get by identifier), but the core surface is well-covered.