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

No annotations provided, so description bears full burden. It describes a read-only operation returning TVL, native token, and top 5 protocols, with no destructive side effects. Could be more transparent about limitations (e.g., 'only top 5 protocols, data may be delayed') but current disclosure is adequate for a simple query.

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, no filler. Front-loaded with purpose and default, then specific returns and supported chains. 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?

Given the tool's simplicity (one optional parameter, no output schema), the description is sufficiently complete: it explains what it does, what it returns, and which chains it supports. An agent can confidently select and invoke the tool based on this description.

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 100% with one parameter 'chain' having a description of casing and examples. Description adds explicit list of supported chains (Ethereum, Cardano, Solana, etc.) beyond schema examples, giving agents concrete options to use. This adds value over the schema alone.

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 clearly states the tool provides high-level DeFi stats for major chains, specifying return values: total TVL, native token, top 5 protocols. Distinguishes from sibling tools like get_protocol_tvl (protocol-level) or list_top_protocols (cross-chain) by focusing on chain-level aggregated data.

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 versus alternatives. Implies usage for major chains by listing supported ones, but does not state when not to use or suggest other tools. A statement like 'Use for chain overview; for specific protocol details, see get_protocol_tvl' would improve the score.

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 burden. It discloses return structure, the anchored=false scenario, and that off-chain signatures remain valid. No contradictions. Missing details on rate limits or authorization, but for a simple read tool, this is 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?

Three sentences with no wasted words. Purpose, verification rationale, and edge case are each addressed efficiently. Front-loaded with key information.

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 effectively explains return values and behavior despite the absence of an output schema. Covers the primary use case and exception case completely for a read tool with one optional parameter.

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 one optional parameter (protocol_slug) with schema description referencing list_signed_rwa_attestations. The tool description adds that it defaults to most recent, which is value beyond 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 clearly states the tool retrieves the on-chain anchor (Base tx hash, block, explorer URL) for a signed RWA attestation, distinguishing it from sibling tools that return the attestation 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?

Explanation includes why to use it (independent verification of content hash anchorage) and the edge case where anchored=false. Does not explicitly state when not to use or list alternatives, but sibling context fills that 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. It discloses the output includes TVL and time-based changes, but does not specify whether the TVL is current or historical, or detail any read-only nature. It adds some behavioral context but has 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 a single, front-loaded sentence that efficiently conveys the tool's purpose and optional parameter usage 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 low complexity (2 parameters, no output schema, no annotations), the description adequately covers the essential information: what the tool returns and how to filter. It slightly lacks detail on output format, but remains sufficient for 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?

Schema coverage is 100%, so the description is not required to add much. However, it explains that the optional chain filter narrows results to protocols deployed on that chain, adding meaningful context beyond the schema's description.

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 TVL plus 1d/7d/30d changes for any DefiLlama-listed protocol, with an optional chain filter. It uses specific verbs and resources, distinguishing it from sibling tools like list_top_protocols or get_chain_defi_status.

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 explains when to use the optional chain filter, implying context-based usage. While it doesn't explicitly name alternatives, the sibling tools are sufficiently different, so the guidance is clear enough for selecting this tool.

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 provided, so description carries full burden. It discloses what data is returned (TVL, sub-segments, issuers, chains) but not behavioral traits like data freshness, caching, or access permissions.

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 key output, no wasted words. Encourages scan for quick 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 no parameters or output schema, description is fairly complete. Could mention data source or update frequency, but not critical for this simple 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?

No parameters exist, so schema covers everything vacuously. Description adds value by explaining output fields, which is helpful for a tool with no 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 it provides an overview of RWA category including TVL, sub-segments, top issuers, and chain distribution. It distinguishes from siblings like get_rwa_protocol_detail by being high-level, but does not explicitly compare.

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 usage guidance or when-not-to-use. Implied for high-level overview, but lacks differentiation from list_top_rwa_protocols or score_protocol_positioning.

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 full burden. It discloses that the tool returns specific data fields and implies it is a read operation (consistent with get verb). However, it does not mention potential error conditions or required permissions.

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 efficiently conveys the purpose and content. No unnecessary 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?

For a single-parameter tool with no output schema, the description lists the key fields returned, providing sufficient completeness. It could mention that the output is an object, but the current level is 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 input schema has 100% coverage with a clear description and examples for protocol_name. The tool description does not need to add more, but the schema itself is informative. The baseline is 3, elevated due to good examples.

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 retrieves a detailed view of a specific RWA protocol, listing the information it provides (TVL, momentum, chain spread, segment classification, attestation availability). It is distinct from siblings like get_rwa_landscape and get_signed_rwa_attestation.

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 explicitly state when to use this tool versus alternatives. While the sibling list and context imply it is for single-protocol detail, there is no explicit guidance on usage context or when not to use it.

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 the return contents (ed25519 verification metadata) but does not mention read-only nature, idempotency, or other behavioral traits like caching or external calls.

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 purpose, no fluff. Every word serves a clear function.

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 partially describes the output (verification metadata) but does not fully characterize the 'summary view' or what is excluded compared to the full version. With no output schema, the description could be more 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 description coverage is 100% and the tool description only reaffirms the default behavior ('Defaults to most recent') without adding new meaning beyond what the schema already provides (e.g., examples).

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 'summary view' of a signed RWA trust attestation, with the verb 'get' and the resource identified. It distinguishes from sibling tools like 'get_signed_rwa_attestation_full' by specifying summary and listing the included verification 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 explains when to use it: for a specific protocol or the most recent if no slug is given. However, it does not explicitly guide when not to use it or compare with alternatives like the 'full' version or the listing tool.

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. It discloses the tool returns a full document with specific elements, implying a read operation. However, it lacks details on authentication, rate limits, or potential size of the response, which could affect agent 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?

Two concise sentences front-load the purpose and usage. No wasted words; every sentence is informative.

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 no output schema, the description hints at the return value by listing components. It also references a sibling for parameter details. For a simple tool with one optional parameter, this is adequately complete, though a note about output format would be helpful.

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 100% and the description adds value by explaining the default behavior and referencing a sibling for available slugs. This goes beyond the schema's description, making parameter usage clear.

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 it gets the full signed RWA attestation document with every proof_element, agent_signature, and orchestrator_signature. It distinguishes from the sibling 'get_signed_rwa_attestation' by specifying 'full' and enumerating all components.

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?

Explicitly says 'Use this when you want to independently verify the chain cryptographically,' providing a clear use case. It does not explicitly mention when not to use or alternatives, but the guidance is sufficient for an agent to select it for full verification.

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 burden. It describes the output but does not disclose edge cases (e.g., empty list), rate limits, or authentication needs. It is adequate but not thorough.

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 efficiently conveys purpose, examples, and return fields without 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 no parameters and no output schema, the description is largely self-sufficient. It covers the key information but could mention ordering or empty result handling.

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; baseline is 4. The description adds value by explaining what the tool returns, fulfilling the need for parameter semantics.

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: listing every RWA protocol with signed trust attestations. It includes specific examples and enumerates the return fields, making it distinct from sibling tools that retrieve single 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 implies use for getting an overview but does not explicitly contrast with sibling tools (e.g., get_signed_rwa_attestation) or state when not to use it.

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 description carries full burden. It confirms a read-only listing but does not disclose any potential limitations, rate limits, or exact sorting behavior (e.g., descending by TVL). Additional behavioral traits like pagination or result format are omitted.

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 with no unnecessary words. First sentence states the core function, second provides a concrete usage guideline. Front-loaded 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?

Tool is low complexity with two optional parameters and no output schema. The description covers basic intent and usage hint, but lacks specification of output structure (e.g., whether protocols include TVL values) and ordering. Adequate but leaves minor ambiguity.

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 covers 50% of parameters with descriptions (chain has description, limit does not). Description adds default values (Ethereum, top 10) but does not explain limit semantics beyond default. Baseline 3 is appropriate given partial schema coverage and minor additive 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?

Clearly states 'Top DeFi protocols by TVL on a given chain' with default Ethereum top 10. Verb 'list' is implied by tool name and description, resource is well-defined, and distinguishes from sibling 'list_top_rwa_protocols' by specifying DeFi versus RWA.

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?

Explicitly advises 'Use this for discovery before calling get_protocol_tvl', providing a clear usage context. Does not enumerate when-not to use, but the specific recommendation compensates.

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 provided, so description must disclose behavior. It mentions returning annotations and gives examples, but does not state data freshness, ordering (descending TVL?), error handling, or pagination for limit parameter. Partial disclosure only.

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, clear and direct. Last sentence listing examples is slightly redundant but not harmful. Could be more concise by removing examples or integrating them. Overall 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?

No output schema; description mentions return includes annotations but does not specify the return structure (e.g., list of objects with fields). Also lacks details on ranking order. Incomplete for a tool with 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?

Input schema has one parameter (limit) with 0% description coverage. Description does not mention limit or its effect. Agent must infer from schema alone. Missed opportunity to clarify that limit controls number of protocols returned.

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 clearly states purpose: list top RWA protocols by TVL, ranked across all chains, with annotations for segment and primary chain. Examples given. Distinguishes from siblings like list_top_protocols (likely general) and list_signed_rwa_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?

Implies usage for getting ranked list of top RWA protocols by TVL. No explicit when-to-use or when-not-to-use compared to siblings like get_rwa_protocol_detail or score_protocol_positioning. Contextual 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?

No annotations are provided, so the description bears full burden. It discloses that this is a free (read-only) teardown and returns a scorecard with next action. However, it does not specify authentication needs, behavior on invalid input, or whether it is purely observational. The 'free' label hints at non-destructive action but lacks explicit safety guarantees.

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 with no wasted words. It front-loads key information ('FREE positioning teardown') and succinctly covers what the tool does and what it returns, including the upsell note.

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 (1 required param, no output schema), the description adequately covers purpose, output structure (scorecard + next action), and free tier limitation. It lacks explicit mention of the five dimensions but is still mostly complete for an agent to use 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 single parameter 'protocol_name' is already described in the schema as 'DefiLlama protocol name.' The description adds that it scores a DeFi protocol on 5 dimensions, but no additional parameter-level detail (e.g., format, case-sensitivity, or domain) beyond what the schema provides. With 100% schema description coverage, baseline 3 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 the tool performs a 'FREE positioning teardown' that 'scores a DeFi protocol on 5 dimensions' and returns a 'structured scorecard + recommended next action.' The verb 'scores' and resource 'DeFi protocol' are specific, and the tool is distinct from siblings like get_protocol_tvl or list_top_protocols.

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 for scoring protocol positioning but does not explicitly state when to use or not use this tool versus siblings. It mentions 'free tier' and an upsell CTA, but no direct guidance on exclusion criteria or when a different tool is appropriate.

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