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

With no annotations, the description must carry the behavioral burden. It discloses graceful partial failure, parallel execution, output composition (raw sections, honesty caveats, summary), and explicitly states no numeric scoring. It lacks details on error handling or permissions, but the key behaviors are well covered.

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

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

The description is concise and front-loaded, using three terse sentences. Each sentence delivers essential information: purpose/behavior, scoring expectation, and parameter effect. No redundant wording 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?

Given the absence of an output schema and annotations, the description sufficiently describes return components (raw sections, caveats, summary) and key behaviors. It could detail the report structure more, but the high-level description is adequate for an agent to invoke and interpret the tool.

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

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

Only the chain parameter has schema coverage; agentId and taskContext lack descriptions. The description adds meaning by explaining taskContext's role ('only shapes the summary text') and the tool's purpose for agentId, but it does not provide format details for agentId or chain defaults beyond the schema enum.

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 this tool produces a factual trust report for an ERC-8004 agent by running identity, registration, reputation, and validation lookups in parallel. This distinguishes it from sibling lookup tools like get_registration_file and get_reputation, which focus on individual data sources.

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 the tool is for comprehensive trust assessment, combining multiple lookups into one report. It notes that taskContext only shapes the summary, but it does not explicitly name alternatives or state when not to use this tool (e.g., when only reputation is needed).

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. It discloses important behavioral details: verification depends on URI scheme (ipfs verified, data inherently verified, https unverifiable). This is beyond a simple 'fetches file' statement. However, it doesn't mention output format, error behavior, or whether the tool performs network requests.

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, information-dense sentence that front-loads the action and provides key verification details. Every word earns its place; there is 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?

The core function and verification criteria are described, but with no output schema and no annotations, the description should explain what the tool returns and any prerequisites. It does not, leaving gaps in return format and parameter usage. It is adequate for a simple fetch tool but not fully 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?

Schema coverage is only 33% (chain has description, agentId and requireVerified do not). The description mentions 'via its tokenUri' but doesn't explain the parameters. agentId is inferable from the name, but requireVerified's behavior is not clarified. The description does not compensate for the low schema coverage.

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

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

The description clearly states the tool's action: 'Fetches and verifies an agent's registration file'. It specifies the resource and the verification behavior, distinguishing it from sibling tools like resolve_agent which likely resolves agent metadata, and trust assessment tools.

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

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

The description provides clear context for when to use this tool: when you need to fetch and verify a registration file. It also notes that https:// URIs are unverifiable in v1, which is a limitation but not an explicit alternative. It doesn't explicitly compare to sibling tools, but the purpose is unambiguous.

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 excels by disclosing that the tool always returns honesty caveats, explaining that feedback is self-reported and a weak signal, especially for low counts. This provides valuable behavioral context beyond a simple 'read' action.

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

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

The description is appropriately concise: two sentences that front-load the core function and add a critical caveat. Every sentence provides value without 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 description provides a solid overview for a read-only tool with no output schema. It covers the main capability and an important caveat. However, it omits details about pagination behavior (limit/offset) and the exact structure of the summary, which would be helpful given no output schema.

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

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

The input schema has only 20% coverage (only chain has a description). The description adds meaning for includeRaw ('raw feedback entries') and clarifies the context of agentId ('an agent's'). However, it does not discuss limit/offset pagination semantics, leaving some parameters underdefined.

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: reading an agent's Reputation Registry feedback summary, optionally including raw entries. It uses a specific verb ('Reads') and resource ('Reputation Registry feedback summary'), distinguishing it from siblings like get_validations and assess_trust.

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 the tool is used for reading reputation feedback but does not explicitly state when to use this tool over alternatives or mention any exclusions. It lacks direct guidance on choosing between this and related tools like get_validations or assess_trust.

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 transparency burden. It does disclose that the operation is a read and explains that an empty result is normal (a useful behavioral clarification). However, it omits details on pagination behavior (limit/offset), chain handling, and any potential side effects or errors, leaving significant 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?

The description is exceptionally concise: two sentences, front-loaded with the action and resource, and the second sentence adds a valuable clarification without any 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 tool has four parameters, no output schema, and no annotations, so the description must compensate. It provides a partial return-value description (entry fields) and the zero-validations clarification, but fails to cover pagination, chain switching, or how this differs from related trust/reputation tools. It is adequate but leaves clear 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?

Schema coverage is low (25%, only chain described). The description does not explain agentId, limit, offset, or chain semantics. It mentions the content of returned entries, which indirectly relates to what data is fetched, but it does not help an agent understand how to fill the parameters or what each parameter controls.

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 ('Reads') and resource ('Validation Registry entries'), and enumerates the entry content (validator, method classification, response, timestamp). This clearly distinguishes it from sibling tools like get_reputation or assess_trust, which focus on different aspects.

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 get_reputation or assess_trust. The note about zero validations being a normal result is a result-interpretation hint, not a usage-selection criterion, so it does not satisfy the 'when-to-use vs alternatives' requirement.

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?

Without annotations, the description carries the full burden of behavioral disclosure. It adds useful context about `isDefault` and `DEFAULT_CHAIN_ID` env resolution, but it does not mention potential errors, rate limits, or the exact structure of the returned list beyond slugs. For a read-only listing operation, this is acceptable but not fully comprehensive.

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 concise—two sentences—and front-loaded with the primary purpose. The second sentence adds crucial usage context without redundancy. Every word contributes to the tool's understanding.

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 params, no output schema), the description covers the essential aspects: what the tool lists, how to use the results, and what `isDefault` means. It could be more explicit about the return format (e.g., array of objects), but the description is sufficient for an agent to know when and how to invoke this tool.

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

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

The tool has zero parameters, so the baseline is 4. The description adds meaning beyond the empty schema by explaining that the returned `chain` slugs are used as arguments in other tools and that `isDefault` indicates the fallback chain. This enriches the conceptual understanding of how the tool's output is consumed.

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 'lists the chains this server is configured for', using a specific verb and resource. It distinguishes this tool from siblings (ping, resolve_agent, etc.) by focusing on chain configuration. The added detail about `isDefault` and the relationship to other tools' `chain` argument further clarifies its unique purpose.

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

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

The description provides explicit context that this tool must be used to obtain valid `chain` slugs for other tools, stating 'Every other tool's `chain` argument must be one of the `chain` slugs returned here'. It implies the appropriate time to use this tool (before using other tools with chain arguments), though it does not explicitly mention when not to use it or name 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 provided, the description carries the full burden of behavioral disclosure. It discloses the return value (pong and server version) and implies a non-destructive read-only operation, but it does not explicitly discuss side effects, error behavior, 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.

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

The description is a single, front-loaded sentence that wastes no words. It states the action ('liveness check') and the expected result ('returns pong and server version') 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 simple zero-parameter tool, the description covers the essential context: what it does and what it returns. However, it omits details about failure modes or response formatting, which would be nice but are not critical for such a basic 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 tool has zero parameters, and the schema coverage is trivially 100%. No parameter documentation is needed in the description, so the baseline score of 4 applies.

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

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

The description clearly states the tool's purpose as a liveness check and specifies that it returns pong and the server version. This distinctively separates it from sibling tools which deal with agent resolution, chains, and reputation.

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 is implied by the nature of a ping (checking if the server is alive), but there is no explicit guidance on when to use it versus alternatives, nor any exclusions or prerequisites. The description is adequate 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?

With no annotations provided, the description must cover behavioral traits. It discloses that parsing is 'best-effort' and that exactly one selector is required, which is useful. However, it does not indicate whether the operation is read-only, whether it makes network calls, or what error behavior to expect, leaving a transparency gap.

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, dense sentence that front-loads the core purpose and includes a critical usage constraint. Every word contributes value with no redundancy or irrelevant details.

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

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

The tool has no output schema and no annotations, so the description must cover return values and behavioral context. It mentions identity fields plus endpoints/capabilities, but does not specify the structure or any potential error cases. While the core is covered, the lack of detail on the return format and edge cases leaves it incomplete.

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

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

The schema documents only the chain parameter (33% coverage), leaving agentId and ownerAddress undescribed. The description compensates by explaining that one of these two selectors must be provided, adding meaning beyond the bare schema. It does not detail output fields, but the selector constraint is well covered.

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 resolves an ERC-8004 agent by a specific selector (agentId or ownerAddress) and returns parsed identity fields plus endpoints/capabilities. This is a specific verb+resource with scope, and the mention of 'parsed from its registration file' distinguishes it from a simple file fetcher.

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 includes the important usage constraint 'exactly one selector', which guides parameter selection. However, it does not explicitly state when to use this tool over siblings like get_registration_file or search_agents, nor does it mention alternatives 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?

With no annotations, the description fully discloses the tool's stub status and the guaranteed INDEX_UNAVAILABLE response. It also notes that input validation still runs, which is a valuable behavioral detail beyond what the schema reveals.

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: the first states the core purpose, and the second delivers the critical caveat. Every word earns its place, and it is appropriately front-loaded with the search intent.

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 that the tool always returns a fixed error code, the description fully captures what an agent needs to know: the search capability, the stub status, and the guarantee of INDEX_UNAVAILABLE. No output schema is needed because the outcome is fully specified.

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 adds meaning to the query parameter by specifying it searches name/capability/description, which is not in the schema. However, it does not explain the chain or limit parameters beyond what the schema already provides, and schema coverage is only 33%.

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 states a specific action ('Searches for ERC-8004 agents') and identifies search criteria ('by name/capability/description'). It clearly differentiates from sibling tools like resolve_agent by indicating a broad search rather than targeted resolution.

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

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

The description provides clear context that this is an MVP stub and will always return INDEX_UNAVAILABLE, telling the agent not to rely on it for actual results. It does not explicitly name an alternative tool, which prevents a 5, but the warning is unambiguous.

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