HODLXXI Read-Only

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the burden for behavioral disclosure. It reveals the signed nature of the document and the main return fields, and 'Return' implies a read-only operation, but it does not discuss authentication, caching, or any other behavioral traits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence with no filler. Every clause adds meaningful information about what the tool returns.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter tool with an output schema, the description covers the key return aspects: signed document, endpoint links, trust surfaces, timestamp, and agent signature. It lacks explicit sibling differentiation and read-only declaration, but the low complexity keeps it largely complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters and an empty input schema, so the baseline is 4. The description adds useful context about the returned content even though parameter semantics are essentially not applicable.

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?

Description uses specific verb 'Return', names the resource 'signed Agent Protocol discovery document', and enumerates its contents ('public endpoint links, trust surfaces, timestamp, agent signature'). This clearly distinguishes it from sibling getters like get_agent_identity or get_attestations.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage context is implied by the resource name and description, but no explicit when-to-use or alternatives/exclusions are stated. An agent can infer it is for retrieving the discovery document, but not why it should be chosen over related sibling tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the burden; 'Return' indicates a read-only operation and 'public' implies no special authentication, while 'canonical' and 'trust-model declarations' give context about the document's authority. It does not discuss caching, rate limits, or failure modes, but for a zero-parameter public getter this is largely sufficient.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

One sentence, front-loaded with the primary action and resource, and every clause earns its place by enumerating relevant document sections. No redundancy or filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter public read-only getter with an output schema available, the description is complete enough. It identifies the resource, the scope of contents, and the public/canonical nature without needing to describe return values that the output schema already covers.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has zero parameters, so the baseline is 4; there is no parameter information needed. The description focuses on the content of the returned document rather than parameters, which is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states that the tool returns the canonical public agent identity document and enumerates its contents (capabilities, pricing, endpoints, skills, messaging metadata, trust-model declarations). It is specific about verb and resource, but it does not explicitly differentiate from sibling getters such as get_capabilities or get_skills, which are also listed as contents.

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 intended use is implied by 'canonical public agent identity document'—use it when you need the full identity document—but there is no explicit when-to-use or when-not-to-use guidance, nor any mention of alternatives among the many sibling tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are present, so the description must carry the behavioral burden. It implies a read-only operation and lists output fields (skill names, descriptions, URLs, types, SHA-256 digests), which is useful. However, it does not disclose potential side effects, authentication needs, or performance characteristics, though the tool's simple read-only nature may make such disclosure less critical.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence that wastes no words. It efficiently conveys the action and the nature of the returned data.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter tool with an output schema, the description covers the essential behavior and what is returned. It could mention whether this includes all skills or is filtered, but the presence of an output schema reduces the need for further detail. Overall, it is complete for the tool's low complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema is empty, so there are no parameters to explain. According to the rubric, a baseline of 4 applies for zero-parameter tools, and no additional description is warranted.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb+resource ('Return the Agent Skills discovery index') and enumerates fields, making the purpose clear. It does not explicitly contrast with siblings like hodlxxi_get_skills, but the phrase 'discovery index' and field list help disambiguate.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is given on when to use this tool versus alternatives such as hodlxxi_get_skills or hodlxxi_get_agent_discovery. There is no when-to-use, prerequisites, or exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the disclosure burden. It adds useful context by saying the catalog is 'public' and describes the contents, but it does not explicitly state that the operation is read-only or side-effect free, nor does it mention response format or operational details.

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?

A single, front-loaded sentence with no filler. It states the artifact and its key components efficiently.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter, read-only catalog fetch with an output schema, the description covers the resource and content areas well. It could mention the catalog's relationship to other discovery endpoints, but that is not necessary for simple selection and invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has zero parameters, making parameter semantics N/A. Per the baseline for zero-parameter tools, this is a 4; the description does not need to add parameter detail because there are none.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb and resource: 'Return the public RFC-style API linkset catalog with service descriptions, documentation links, and status links.' This clearly identifies the tool's function and distinguishes it from sibling tools like get_agent_identity, get_capabilities, and get_openid_configuration.

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 context is implied—use this when you need the API catalog or linkset—but there is no explicit when-to-use vs. alternatives or exclusions. It does not name sibling tools that might overlap or specify when not to use this one.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description must carry behavioral context. It does disclose pagination behavior and parameter range constraints, which is useful. However, it does not explicitly state that this is a read-only operation or describe potential errors or authentication needs, leaving gaps.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences, each earning its place. The first states the purpose, the second provides critical parameter constraints. No fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple paginated read tool with an output schema present, the description covers the core invocation details: what it returns (attestations), pagination controls, and parameter validation. It lacks usage context but is otherwise sufficient for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must compensate. It effectively explains both parameters: 'limit must be 1-100' and 'offset must be non-negative', adding constraints not present in the schema. It also indicates the role of pagination, giving meaningful context beyond the raw type/default fields.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description explicitly states the action ('Return') and the resource ('signed receipt attestations'), and adds the 'paginated' scope. This clearly distinguishes it from siblings like get_receipt or verify_receipt, which target different resources.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives. The description only mentions operational constraints (limit/offset) and does not explain scenarios such as retrieving a single receipt vs listing attestations.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden. It discloses the 'signed' nature of the document, which is a meaningful behavioral trait, but does not mention side effects, authentication needs, or response verification. The simple read-only nature is only implicit in the 'Return' verb.

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?

A single, front-loaded sentence that states the action and lists the document contents with no wasted words. Every phrase earns its place by clarifying what the capabilities document contains.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a no-parameter retrieval tool with an output schema, the description is adequately complete: it names the document and its major sections, and the output schema can handle return-value details. The 'signed' qualifier adds an important integrity trait.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, so the baseline is 4. The description correctly adds no parameter-specific detail because the input schema is empty.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Return') and names a distinct resource ('signed capabilities document'), then enumerates its key contents. This clearly differentiates it from sibling tools like get_capabilities_schema and get_api_catalog.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit when-to-use or alternative guidance is provided, but the description implies this tool is the one to call when the full signed capabilities document is needed. It does not mention exclusions or relationship to similar sibling tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

There are no annotations, so the description carries the burden. It states the tool returns a JSON Schema, which is a read operation and implies no side effects, but it does not disclose other behavioral aspects such as whether the schema is static or dynamically generated, or any authentication requirements. For a simple read tool, this is adequate but not rich.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence, front-loaded with the action and resource. There is no wasted words. It clearly states what is returned and for what document.

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 is simple (no parameters, no nested structures) and has an output schema, the description is complete enough for an agent to understand its purpose ascending from siblings. It does not need to explain return values since an output schema exists. It adequately differentiates by specifying 'schema' vs the document itself.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, so the description does not need to explain parameter semantics. With no parameters, the description's job is mainly to clarify the return value, and it does that. However, it does not describe the schema's contents or its typical use, which could be helpful but is not required.

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 that the tool returns a JSON Schema for a specific signed document, using the verb 'Return' and the resource 'JSON Schema... for the signed HODLXXI capabilities document'. It distinguishes from sibling tools by focusing on the schema of the capabilities document, whereas siblings like hodlxxi_get_capabilities likely return the document itself.

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 context (getting the schema for the capabilities document) but does not explicitly state when to use this versus siblings. For example, it does not say 'use this to understand the structure of the capabilities document' or contrast with hodlxxi_get_capabilities. Given the sibling set, some inference is possible but not explicit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description implies a read-only operation via 'Return', but does not explicitly state side effects or permissions; no annotations to rely on.

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?

Single, concise sentence with no fluff; clearly structured.

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?

Covers all key return items and the 'when available' caveat; sufficient for a simple getter with no parameters.

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?

No parameters exist, so the description adequately covers them by omission; baseline for 0 params is 4.

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 purpose: return chain health data, specifying the exact items returned.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus the many sibling get tools; lacks explicit when/when-not or alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Since no annotations exist, the description must disclose behavior, but it only mentions 'validated covenant identifier' and lists output fields. It does not state whether the operation is read-only, require authentication, or explain possible side effects, even though these are typical expectations for a getter.

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?

A single, information-dense sentence with no redundancy or filler, perfectly matching the tool's simple scope.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description adequately covers the tool's main input and output concepts, and the existence of an output schema fills in return-type details. However, the term 'non-claims' is unexplained and could confuse agents, and common use-case clarifications are omitted, leaving a middling level of completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description clarifies that the parameter is a 'validated covenant identifier', which maps to covenant_id, but provides minimal detail about format or the default value. As schema coverage is 0%, the description partially compensates by naming the identifier's purpose, but more specificity is needed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb 'Return' and identifies the resource as a 'declared covenant artifact', enumerating key fields (descriptor, policy, funding status, public keys, non-claims) which clearly distinguishes it from mere verbosity. It does not explicitly compare to sibling tools like get_covenant_countdown, so it misses a point for explicit differentiation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives no guidance on when to use this tool versus alternatives; it only implies the need for a covenant identifier. No exclusions or comparison to siblings such as get_trust_events or get_receipt are provided, so usage context is absent.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the behavioral transparency burden. It makes clear this is a read-oriented, informational call and names the kinds of results returned, but it does not address auth expectations, data freshness, or the exact meaning of 'conservative trust interpretation.'

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence with no wasted words. Every phrase contributes meaning: the format, the resource, and the key output dimensions.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter informational getter with an output schema, this description is largely complete. It lists the main content categories and the machine-readable nature of the result, though clarifying the 'conservative trust interpretation' would strengthen it further.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters and 100% schema description coverage, so the parameter baseline of 4 is appropriate. There are no parameter semantics to explain; the description instead focuses on what the response will convey.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Return') with a clearly scoped resource ('covenant countdown') and enumerates the exact data dimensions it contains: chain height, spend paths, estimated unlocks, funding status, and conservative trust interpretation. This clearly distinguishes it from sibling tools like get_covenant and get_trust_events.

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 when to use the tool: whenever a machine-readable covenant countdown with these fields is needed. However, it does not explicitly explain when to prefer this tool over related getters or when it should not be used.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the transparency burden. It discloses that the key set is public and explicitly states 'No private JWK fields are exposed', which is a useful safety guarantee. It doesn't describe pagination or errors, but for a simple key retrieval tool this is adequate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences long, front-loads the action and resource, and provides a meaningful security caveat without any waste. Every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a no-parameter tool with an output schema and low complexity, the description is complete. It identifies what is returned, its purpose, and the absence of private fields. No additional context is necessary.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, so the baseline is 4. There are no parameter semantics to clarify, and the description appropriately focuses on the return value and security property rather than input details.

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 returns a public RSA JSON Web Key Set and specifies its purpose: verifying HODLXXI-issued JWT signatures. This is a specific verb-resource-purpose combination that distinguishes it from sibling get_* tools, which target other discovery or identity resources.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly mentions the tool is 'used to verify HODLXXI-issued JWT signatures', giving a clear context for when to use it. It does not compare with alternatives, but the resource is unique among siblings and no-parameter nature makes alternatives less relevant.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full responsibility for behavioral disclosure. It only lists the content fields and mentions 'normalized' but does not state that it is a read-only operation, potential side effects, data volume, or auth requirements. For a get tool, assuming read-only is reasonable but not explicit, so transparency is lacking.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence that enumerates the key components of the listing. It contains no redundant or filler content, making it concise and well-structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has no parameters, an output schema exists (so return format is covered), and the description lists the main content areas, it provides sufficient context for basic understanding. However, it could be slightly richer by explaining what 'normalized' means in this context or the intended use case, but overall it is adequate for a simple, parameterless getter.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, so schema coverage is 100% and there is nothing for the description to add about parameter semantics. Baseline for zero parameters is 4, and the description appropriately focuses on output rather than inputs.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly identifies the tool as returning a normalized marketplace listing with specific components (discovery links, job types, pricing, skills, reputation snapshot, chain health, trust model). It uses a specific verb 'Return' and specifies the resource, distinguishing it from sibling tools like get_agent_discovery or get_chain_health.

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 its use for retrieving marketplace listing data but does not explicitly state when to prefer it over alternatives like get_agent_discovery or get_reputation. No exclusions or alternative tool recommendations are provided, though its scope is inferable from the name and content.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations, so description carries full burden. It discloses the read-only nature via the 'separate read-only sidecar' and the routing detail, which is useful behavioral context. Does not cover auth or rate limits, but for a simple retrieval tool this is adequate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with the action, no fluff. The routing detail is included efficiently without detracting from the main purpose.

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?

Simple tool with no parameters and an output schema. Description covers what it returns, the specific endpoint, and an implementation detail (routing to sidecar). No obvious missing information.

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?

Tool has zero parameters, so the baseline is 4. The description doesn't add parameter semantics because none exist; schema coverage is trivially 100% for an empty schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Clear verb+resource: 'Return the live MCP discovery server card' plus the specific URL. This distinguishes it from sibling tools that return other artifacts (e.g., API catalog, trust events).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides clear context (returns the live server card for a given URL) but does not explicitly mention when to prefer this over alternatives or provide exclusions. The specificity of the URL effectively implies the use case.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the transparency burden. It discloses that the tool returns 'signed' announcement data and explicitly mentions 'non-goals', which is somewhat transparent. However, it does not clarify what 'signed' means operationally (e.g., requires verification, network fetch) or whether any side effects occur. It is a reasonable description of a read-only getter but could be more explicit about 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 a single, well-structured sentence that front-loads the action verb 'Return' and enumerates exactly what content is delivered. Every word adds value, and it avoids redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (no parameters) and the existence of an output schema, the description covers the essential aspects of what the tool returns. It could be considered complete, though it might briefly note the purpose of the announcement (e.g., discovery via NIP-89/90) or the audience. Overall, sufficient for a no-argument getter.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, so the baseline is 4. The description focuses on the output, which is appropriate since there are no parameters to document. It does not waste space on parameter details.

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 returns a 'signed Nostr announcement template' with specific content types (NIP-89/NIP-90 kinds, discovery links, non-goals). This specific verb+resource combination distinguishes it from sibling get_* tools, which likely return other metadata.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this tool versus alternatives. The presence of many sibling get_* tools (e.g., get_agent_discovery, get_capabilities) makes it unclear which agent queries should target this announcement endpoint versus another. The description implies it's for Nugget announcements, but does not state exclusions or selection criteria.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden. It discloses the operation is a public metadata read ('Return public...') and enumerates the content categories, giving a clear picture of what the tool offers without claiming any side effects.

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?

A single, well-structured sentence that front-loads the purpose and packs the key metadata categories into a compact list. No filler words or redundant content.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter tool with an output schema, the description is complete: it states the resource, the public nature, and the included metadata fields. Nothing additional is needed for an agent to invoke the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, so there is no parameter semantics to convey. The description correctly avoids mentioning any parameters, matching the empty schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Return') and identifies a precise resource ('public NIP-17/NIP-59 messaging policy metadata') with listed fields (intake status, custody limitations, accepted kind, size ceiling). This clearly distinguishes it from sibling tools like get_agent_identity or get_capabilities.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides clear context: it is for retrieving public DM policy metadata for NIP-17/NIP-59. It doesn't explicitly state when to use alternatives, but the specification of the policy type provides enough context for a zero-parameter getter.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the burden. It indicates a read-only 'Return' operation, which is transparent enough, but it does not disclose whether authentication is required, potential errors, or any other behavioral nuances. The additional details about the discovery block and disabled registration endpoints are content-specific, not behavioral.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence that front-loads the main action ('Return OAuth authorization-server metadata') and then adds specific relevant details. It is concise and well-structured, with no wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simplicity of the tool (no parameters, output schema present), the description is nearly complete. It specifies the key content returned. However, it could have briefly mentioned that this is a read-only metadata endpoint or provided a hint about typical use cases, though the output schema covers return-value specifics.

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?

With zero parameters and an empty schema, the baseline is 4. The description adds no parameter details because none are needed. It correctly focuses on what the tool returns rather than inputs.

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 returns OAuth authorization-server metadata, with a specific verb 'Return' and a precise resource. It distinguishes from sibling tools like get_openid_configuration by naming the HODLXXI agent_auth discovery block and disabled registration endpoint references.

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 usage context is implied by the name and description—this is for OAuth authorization server metadata—but there is no explicit guidance on when to use this over alternatives like get_openid_configuration or get_jwks. No when-not or alternative references are given.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations to rely on, the description clearly discloses the returned metadata fields and implies read-only behavior. However, it does not mention potential error conditions, authentication requirements, or side effects, though none are expected for a metadata endpoint.

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?

A single, front-loaded sentence that immediately conveys the action and object, with every word contributing to understanding. No fluff or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The presence of an output schema means return values are documented elsewhere, so the description only needs to convey purpose and content. For a parameterless metadata retrieval, this is complete and leaves no obvious gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, so the schema fully covers parameter semantics. The description appropriately adds no parameter details, and the baseline of 4 is justified since there is nothing to describe.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses the specific verb 'Return' and clearly identifies the resource as 'OAuth protected-resource metadata,' listing concrete attributes (issuer, authorization servers, JWKS URI, scopes, bearer method). This differentiates it from sibling tools like get_oauth_authorization_server and get_jwks by naming the protected-resource context.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies when to use the tool (to fetch protected-resource metadata) but provides no explicit guidance on when to choose it over alternatives. No exclusions or alternative tool names are mentioned, leaving usage context to be inferred.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden for behavior disclosure. It clearly lists the output contents, which implies a read-only metadata operation, but it does not explicitly state that this is a safe GET with no side effects, nor does it mention any authentication requirements or failure modes. For a simple metadata fetch, the description is adequate but not fully transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence of 17 words, front-loaded with the action and resource, followed by a compact list of specific metadata elements. There is no redundant wording, and the structure is clear and efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The output schema exists, so return values are already structured. The description enumerates the standard OpenID Connect discovery fields (issuer, endpoints, JWKS URI, grants, scopes, PKCE, signing algorithms), which is complete for a zero-parameter read-only tool. No additional contextual information is needed for this straightforward operation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has zero parameters, so there is no parameter semantics to explain. The baseline score for zero-param tools is 4, and the description adds no parameter-related meaning because none is needed. The focus on the returned metadata is appropriate and does not conflict with the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses the specific verb 'Return' and clearly identifies the resource as 'OpenID Connect discovery metadata', followed by an explicit enumeration of the included fields (issuer, authorization and token endpoints, JWKS URI, grants, scopes, PKCE, signing algorithms). This distinguishes it from siblings like hodlxxi_get_jwks, which returns actual JWKS values, and hodlxxi_get_oauth_authorization_server, which covers OAuth-specific metadata.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description does not provide explicit guidance on when to use this tool versus alternatives. Usage is implied by the tool's name and description, but it does not mention that hodlxxi_get_jwks provides the actual key material or that other sibling tools may overlap in scope. No exclusions or alternative recommendations are given.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the transparency burden. It states the tool returns 'public' data, implying a safe, read-only operation. However, it does not disclose potential error conditions, rate limits, or any special behavior beyond the simple retrieval. The word 'public' is the only transparency signal.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, well-structured sentence that immediately states the core purpose and the full list of included components. No filler words or redundant elaboration. It front-loads the verb and resource, making it easy to scan.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a parameterless, read-only getter with an output schema, the description is complete. It enumerates all the entities returned (statement, keys, status, policy, references) and does not need to explain return format since the output schema handles that. No side effects or complex behaviors require further context.

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?

There are zero parameters, so the schema already covers everything. The baseline for 0 params is 4, and the description does not need to add any parameter-level detail. It correctly focuses on what is returned rather than parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action (return) and the resource (operator-continuity statement, keys, status, policy, references). It is specific enough to distinguish from a generic getter, but it doesn't explicitly differentiate from sibling tools like get_agent_identity or get_covenant, leaving some ambiguity about when exactly to use it.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance on when to use this tool versus the many sibling tools. No context is provided about typical scenarios, prerequisites, or exclusions. Since there are ~20 sibling tools, the lack of explicit alternatives is a notable gap.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description bears full responsibility for disclosing behavior. It adds context that the report is public and machine-readable, and that the SHA-256 field is only included when present. However, it does not mention error handling, whether the operation is purely read-only, or any rate limits or side effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence that front-loads the core purpose: returning a public report by identifier. The qualifying clause about the SHA-256 field is relevant and not redundant. It is appropriately sized.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simple input (one parameter) and the presence of an output schema, the description is mostly sufficient. However, it is vague about what constitutes a 'trust or readiness report' and does not clarify the relationship to sibling tools like get_receipt or get_trust_summary, leaving some contextual gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has one parameter (report_id) with no description, and coverage is 0%. The description only adds 'validated' to the identifier, which is a minor semantic hint. It does not explain the format or provenance of the identifier, nor how to obtain one.

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 returns a report by identifier, with a specific mention of the SHA-256 field. It distinguishes itself from siblings like get_receipt and get_trust_summary by focusing on 'trust or readiness report' and the canonical hash, though it does not explicitly name alternatives.

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 validated report identifier, but it does not explain when to choose this over similar tools like get_receipt or get_trust_summary. No exclusions or alternative conditions are provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must convey behavioral traits. 'Return' implies a read-only operation)Skip, and 'public' hints that no special access may be needed. However, it does not explicitly state side effects, authentication requirements, rate limits, or whether data is cached. The description is adequate but not rich for an unannotated tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence that front-loads the action ('Return') and lists the key data elements. It is fairly concise, though the list is somewhat long. No fluff or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has no parameters and an output schema exists, the description covers the main content areas (job counts, attestations, trust metrics, trend). It doesn't explain usage context, but for a simple read operation with zero parameters, it is sufficiently complete for an agent to know what it returns.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parametersLESS_THAN, so there is no need to explain parameter semantics. The schema is empty and trivially 100% covered. The description adds no parameter info, but that is acceptable since there are none.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Return') and clearly identifies the resource (aggregate public operating history, evidenced job counts, attestation count, trust/confidence averages, pattern distribution, rolling trust trend). This distinctively differentiates it from sibling tools like get_trust_summary or get_attestations by naming unique metrics.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus the many similar sibling tools (e.g., get_trust_summary, get_attestations). It lacks any explicit scenarios, prerequisites, or exclusions that would help an agent choose this over alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description must carry the transparency burden. It adds useful context by calling the catalog "checked-in" and "public," which implies a read-only, accessible operation, but it does not explicitly disclose staleness, failure behavior, or whether any side effects could occur.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence with no filler. Every element—"checked-in," "public," "metadata," "repository paths," and "installation URLs"—adds specific value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's low complexity, zero parameters, and existing output schema, this description is complete enough. It names the resource and the key contents returned; no additional return-value explanation is required because an output schema is present.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, so the schema is vacuously covered at 100%. Per the rubric, zero-parameter tools receive a baseline of 4, and there is no parameter semantics burden for the description to carry.

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 a specific action and resource: "Return the checked-in public skill catalog with metadata, repository paths, and installation URLs." This distinguishes it from likely siblings like hodlxxi_get_agent_skills_index by emphasizing the full catalog plus metadata and URLs.

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?

There is no guidance about when to prefer this tool over sibling tools such as hodlxxi_get_agent_skills_index or hodlxxi_get_capabilities. The description implies a simple retrieval, but it does not state exclusions, alternatives, or preconditions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description must carry the behavioral transparency burden. It discloses that the tool is public and paginated, but it does not explain pagination behavior (e.g., max limit, offset semantics), ordering, error handling, or if the operation is read-only (though implied by 'Return'). The mention of 'public' is useful, but more detail on constraints would be needed for a higher score.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, concise sentence that immediately states the action and the core content. No filler words or redundancy. It is well-structured and front-loaded with the key purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simple parameter set (2 integers with defaults) and the presence of an output schema, the description doesn't need to detail return values. It does state the types of data included (hashes, receipts, timestamps, etc.), which is sufficient for a low-complexity tool. However, it could mention any limitations or ordering to be more complete, but it's adequate.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema description coverage is 0%, so the description must compensate for explaining limit and offset. It only says 'paginated' which implies the parameters are for pagination, but it does not define their meaning, range, or effect. The baseline for low coverage is that the description should provide explicit parameter guidance, which it fails to do.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function: returning a paginated chain of trust events with specific data fields (hashes, receipt linkage, timestamps, public key, signatures). This specific verb+resource phrasing distinguishes it from sibling tools like get_trust_summary or get_attestations.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no context on when to use this tool versus alternatives. It doesn't mention any exclusions, prerequisites, or relationships to sibling tools. The user is left without guidance on whether to choose this over get_trust_summary or other related tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full transparency burden, but it only mentions 'compact' and 'validated'. It does not disclose what 'validated' means, what happens for invalid identifiers, whether authentication is needed, or how the summary is derived.

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?

A single 12-word sentence that is front-loaded with the action and object. Every word earns its place, and there is no repetition of schema details or filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is simple (one optional parameter, output schema present), so the bare description is minimally viable. However, it omits important context about the 'validated' requirement and how this summary relates to the broader trust/reputation toolset.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema provides only a string type and a default, with 0% description coverage. The description adds the key semantic that agent_id is a 'validated public agent identifier', but it does not explain identifier format, how validation occurs, or relationships to the default value.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Return') and a specific resource ('compact trust summary'), scoped to a 'validated public agent identifier'. This clearly differentiates it from siblings like hodlxxi_get_trust_events or hodlxxi_get_reputation, which cover related but distinct resources.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to choose this tool over alternatives such as hodlxxi_get_trust_events, hodlxxi_get_attestations, or hodlxxi_get_reputation. The phrase 'validated public agent identifier' implies a prerequisite, but there is no explicit when-to-use or when-not-to-use direction.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It discloses two specific non-behaviors ('does not poll /agent/jobs' and 'cannot mint a receipt'), which is useful. However, it does not mention any side effects, errors for invalid job_id, or security/auth requirements. It is a read operation by inference, but that is not stated explicitly.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, front-loaded with the purpose, and every sentence adds value. The first sentence states the action and return items; the second clarifies exclusions. No redundant or vague wording.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is simple (1 parameter) and the description covers its function and exclusions. An output schema exists (indicated), which likely details return values. The description adequately scopes the tool's role within a larger ecosystem of get_* tools, making it complete enough for an agent to use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has no description for job_id, and the description only repeats 'by job identifier', which adds minimal meaning beyond the parameter name. It does not specify format, origin, or validation. With 0% schema coverage, the description should compensate but only partially does so.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool verifies a previously issued receipt by job identifier, with a specific verb ('Verify'), a resource ('receipt'), and a qualification ('by job identifier'). It also distinguishes from siblings by noting it does not poll /agent/jobs and cannot mint a receipt, aligning with the get_* tools but focusing on verification.

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 when to use it: after a receipt is issued and needs verification, providing the job_id. It explicitly states what it does not do (does not poll, cannot mint), which helps avoid misuse. However, it does not name alternative tools like hodlxxi_get_receipt, though the differentiation is implicit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.