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

With no annotations, the description carries the burden of behavioral disclosure. It adds useful context about the 1-hour expiry and the requirement to sign and submit via trust_verify. However, it does not clarify whether the operation is read-only or state-changing, nor what the challenge response contains.

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 zero wasted words. It conveys the core purpose and essential usage in 20 words, making it highly 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?

For a simple tool with only 2 parameters and no output schema, the description is largely complete. It explains the purpose, the next step (trust_verify), and the time constraint. However, it does not describe the return value structure, which could be helpful for an agent to know what to expect.

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 covers 100% of parameters, so baseline is 3. The description adds no extra meaning beyond the schema, only referencing 'a specific chain' without elaborating on the chain parameter. This meets the baseline but does not improve understanding.

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: 'Get a verification challenge for a specific chain.' It uses a specific verb ('Get') and resource ('verification challenge'), and distinguishes itself from its sibling trust_verify by explaining the challenge must be submitted via trust_verify.

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 usage context by stating 'The challenge must be signed and submitted via trust_verify within 1 hour.' This implies the tool is the first step in a verification flow and names the sibling tool to use next, though it does not explicitly contrast with other sibling 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?

No annotations are provided, so the description carries the full burden. It discloses a key behavioral trait (creates negative evidence affecting trust score) and a rate limit (3 per reporter per day), but omits reversibility, authentication requirements, and what happens after the dispute is filed.

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 primary action, and no filler. 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?

The description provides essential context (negative evidence, rate limit) but, with no output schema, does not state what the caller receives (e.g., dispute ID or status). For a 5-parameter mutation tool, this is adequate but not comprehensive.

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%, so the schema already documents all five parameters. The description adds no parameter-level detail, which is acceptable given the baseline of 3 when schema coverage is high.

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 ('File a dispute against an agent') and clearly names the resource and effect ('Creates negative evidence affecting their trust score'). This distinguishes it from sibling tools like trust_challenge or trust_review by specifying the negative-evidence outcome.

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 when you want to file a dispute against an agent, but it does not explicitly state when to prefer this over alternatives like trust_challenge or trust_review. No exclusions or alternative paths are mentioned, so guidance is only implicit.

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 discloses two behavioral constraints (must be registered, self-endorsements rejected) but does not mention side effects, success/failure return values, or any other system behavior. The description adds some value but leaves significant behavioral aspects undisclosed.

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 concise, front-loaded sentences with no wasted words. It immediately states the core action and then adds key constraints, making it highly scannable 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?

Given the tool's simplicity, the description covers the main purpose and constraints, but with no output schema and no annotations, it does not explain what happens on success or failure. While it is adequate for a basic operation, it could be more complete by mentioning the expected result or postconditions.

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 already provides complete descriptions for all 3 parameters (100% coverage), so the baseline is 3. The description adds marginal context by clarifying that the endorser must be a registered agent, which slightly elaborates on the endorser_id field, but does not fundamentally enhance parameter understanding.

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 ('Endorse an agent') and the purpose ('to boost their social trust score'), using a specific verb and resource. This distinguishes it from sibling tools like trust_lookup or trust_review, which focus on reading or reviewing rather than endorsing.

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 (endorsing an agent) and provides concrete prerequisites (endorser must be registered, self-endorsements rejected). However, it does not explicitly mention when to use this tool over alternatives or provide any exclusions, leaving some ambiguity in selection among the trust-related siblings.

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 discloses a key behavioral trait: "Unverified evidence is weighted at 50%." This adds meaningful context beyond the schema. However, it does not mention other behavioral aspects like acceptance criteria, timing of score updates, or reversibility, so it is only partially 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 two sentences, front-loaded with the action and purpose. The second sentence lists evidence types and adds a key weighting fact. Every sentence earns its place with no redundant 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 a simple write operation with no output schema. The description explains the purpose and types but does not mention possible responses, errors, or success indicators. While the weighting note is helpful, an agent might need to know what happens after submission, so completeness is adequate but not exceptional.

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 covers all four parameters with descriptions, including the enum values for 'type' and nested 'data' object. The description repeats the enum types but does not add new semantics beyond what the schema already provides. Thus, 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's function: "Submit self-reported evidence to improve trust score." It gives a specific verb (submit), a resource (evidence), and its purpose (improve trust score), which distinguishes it from sibling tools like trust_verify or trust_challenge.

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: when you have self-reported evidence to improve a trust score. However, it does not explicitly mention alternatives or when not to use it, such as comparing with trust_verify or trust_challenge. Usage context is present but not fully elaborated.

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 carries the full burden. It does disclose that this is a read operation ('View') and indicates the nature of the output (trajectory). However, it lacks details such as return format, pagination behavior, or any permissions required. 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 two concise sentences, front-loaded with the core purpose. The second sentence adds useful detail about the trajectory classification. There is no redundancy or wasted content, making it highly 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 tool has minimal complexity with only two parameters, but it has no output schema and no annotations. The description explains the high-level behavior but does not specify the returned data structure (e.g., timestamps, ordering) or handle edge cases. It is complete enough for basic understanding but leaves room for improvement regarding expected response details.

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% for the two parameters (agent_id and limit). The description does not add any extra meaning beyond referring to 'agent' and does not mention the limit parameter. It relies on the schema, which is complete, so a baseline score of 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 states a specific verb ('View') and resource ('agent's trust score history'), and adds the trajectory aspect (improving/stable/declining), clearly distinguishing it from siblings like trust_lookup (current score) or trust_review (detailed review). This makes the tool's purpose unambiguous.

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 one needs historical score data or trend analysis, but it does not explicitly mention alternatives or state when not to use it. No exclusions or comparisons with sibling tools are provided, so the guidance is only implicit.

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 a read-only behavior ('List') and adds 'Supports pagination', which is useful. However, it omits details about return format, sorting, or error behavior, which would be helpful for a complete behavioral picture.

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 concise sentences, front-loaded with the key action and scope, with no filler or 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?

For a simple paginated listing tool with two well-documented parameters and no output schema, this description is fairly complete. It covers the action, scope, content, and pagination, though it could benefit from mentioning sorting or default return format.

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% for both parameters (page, limit), so the baseline is 3. The description only reiterates pagination without adding new meaning beyond what the schema already provides.

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 'List' with a clear resource ('all registered agents') and content ('their trust scores'). The phrase 'all registered agents' clearly distinguishes this from siblings like trust_lookup (likely single-agent lookup) and trust_search (filtered search), making the purpose unambiguous.

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 listing all registered agents, but it does not explicitly state when to choose it over alternatives like trust_search or trust_lookup, nor does it provide any exclusions or context.

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 disclosing behavior. It clearly states the return structure (score 0-100, tier, verification details), which is useful. However, it does not explicitly state that the operation is read-only, nor does it mention any failure modes, permissions, or side effects beyond the implied lookup 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 two concise sentences that front-load the action and purpose. The first sentence states what the tool does and when to use it; the second lists the key return fields. There is no redundancy or unnecessary detail, and every word contributes to the overall 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?

For a simple lookup tool with one parameter and no output schema, the description covers the essential aspects: the action, the timing, and the return values. It is missing some detail about what 'verification details' includes, and there is no mention of error scenarios (e.g., agent not found), but for the tool's complexity, it is 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?

Schema description coverage is 100% for the single parameter (agent_id) with a clear description ('Agent UUID or name to look up'). The tool description does not add any extra parameter information, but since the schema already fully documents the parameter, the baseline of 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 states a specific action ('Look up an agent's trust score') and the resource (agent's trust). It adds context ('before transacting') and specifies return values (score, tier, verification details). However, it does not explicitly differentiate from sibling tools like trust_verify or trust_search, which could also be used for trust-related lookups.

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 phrase 'before transacting' provides a clear context for when this tool should be used, implying a pre-transaction trust check. It does not mention when not to use it or suggest alternatives, such as using trust_verify for verification requests or trust_history for past scores.

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 full burden. It discloses that registration is free and yields an instant trust score, but it does not mention important behavioral aspects such as permanence, public visibility, or whether prior registration is required. This leaves significant gaps for a registration 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 two short, front-loaded sentences that deliver the purpose and key benefits without any fluff. Every word earns its place, adhering to conciseness standards.

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, so the description should hint at expected outcomes. 'Instant trust score' provides some indication, but other details like response format or any follow-up steps are omitted. For a simple registration tool, it is minimally sufficient but not comprehensive.

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 descriptions for all three parameters (name, contact, description), so schema coverage is 100%. The tool description does not add any additional parameter semantics beyond what the schema already offers, which is acceptable at baseline score.

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 'Register yourself in the trust registry' with a specific verb and resource. It distinguishes itself from sibling tools like trust_lookup, trust_review, and trust_verify by focusing on self-registration.

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 registering yourself and mentions 'Free registration, instant trust score,' which conveys some context. However, it does not explicitly compare with alternatives or state when not to use it, so usage guidance is present but not fully 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 carries the full burden of behavioral disclosure. It does disclose the verification effect of proof-of-payment, but it does not mention whether the review is public, editable, or any side effects beyond submitting. 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 that front-loads the primary action and adds the most critical behavioral nuance. Every word earns its place, with 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?

Given the tool's simplicity and full schema coverage, the description provides enough context for correct invocation. It explains the core purpose and the verification mechanism. However, it lacks explicit mention of optional parameters like reviewer_pubkey, though the schema covers that.

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 100%, so all parameters are already documented. The description adds minimal value beyond the schema—it only reiterates the verification behavior tied to proof_of_payment. 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 action ('Submit a review') and the specific context ('after a transaction'). It also adds the distinctive behavior that proof-of-payment results in a 'verified' status, which differentiates it from sibling tools like trust_endorse or trust_dispute.

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 phrase 'after a transaction' provides clear usage context, indicating this tool is intended for post-transaction reviews. It does not explicitly exclude alternatives or list when-not-to-use scenarios, but the context is sufficient for correct selection among siblings.

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 carry the full burden of behavioral disclosure. It only lists filter criteria and does not mention whether the operation is read-only, how results are ordered, whether pagination exists, or what the return format is. This is a significant gap for a search 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, front-loaded sentence that names the verb and resource immediately. Every word contributes meaning, with no fluff or repetition, making it highly 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?

With six parameters, no annotations, and no output schema, the description is too sparse to be complete. It does not explain what the search returns, how multiple filters combine, or any behavioral context such as pagination or default limit. The sentence leaves the agent without enough context 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?

The schema already documents all six parameters with descriptions, so the baseline is 3. The description mentions name, capability, minimum score, and verification status, which map to q, capability, min_score, and verified, but it does not add any semantics beyond what the schema already provides.

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 searches agents by name, capability, minimum score, or verification status, providing a specific verb and resource. However, it does not explicitly differentiate from sibling tools like trust_lookup or trust_list, so it is clear but not fully distinguishing.

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 does not specify that trust_search is for filtered queries while trust_lookup might be for exact ID lookups, leaving the usage context entirely implicit.

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 burden of disclosing side effects. It mentions adding economic evidence, recalculating the score, and deduplicating by payment_hash, which implies idempotency. It does not cover permissions, response format, or error handling, but the disclosed behaviors are substantial.

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 three short sentences, each delivering distinct value: purpose, effects, and dedup behavior. No fluff or repetition, making it highly efficient 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?

The description gives a clear overview of purpose and side effects, and the schema covers all parameters. However, with no output schema, it does not describe the return value or error behavior for duplicate payment_hash submissions, leaving minor gaps in 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 100%, so the schema already documents all parameters. The description does not add significant parameter-level meaning beyond what the schema provides; the dedup reference is already present in the schema for payment_hash. 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 a specific verb ('Record') and resource ('completed transaction'), with a clear scope ('for trust scoring') and additional actions ('adds economic evidence', 'recalculates score', 'deduplicates by payment_hash'). It distinguishes itself from sibling tools like trust_lookup or trust_evidence by focusing on transaction recording.

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 clear context for when to use the tool: when a transaction is completed and needs to be recorded for trust scoring. However, it does not explicitly name sibling alternatives or state when not to use it, so it falls short of a 5.

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 carry the full burden. It does add behavioral context by naming supported chains and explaining the challenge-signature prerequisite. However, it does not disclose whether the operation is a write/mutation, what happens upon success, or any side effects, which is important for an identity verification 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 two sentences long and front-loaded with the purpose. It immediately states what the tool does, lists supported chains, and provides the critical workflow note. No superfluous 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?

The tool has 11 parameters and no output schema. The description covers the prerequisite challenge flow and supported chains, but does not explain how to choose the relevant parameters for a specific chain (e.g., that only parameters for the selected chain should be provided). The schema covers individual parameters but not the overall selection logic, leaving a gap for this complex 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 schema has 100% coverage with detailed per-parameter descriptions, so the baseline is 3. The description adds value by connecting the signature parameter to the trust_challenge flow, which is not explicitly in the schema descriptions. It also lists supported chains, but this duplicates the 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 the verb 'Verify' and the resource 'your identity on a blockchain or platform', and lists the supported chains. This distinguishes it from sibling tools like trust_lookup (which likely reads verifications) and trust_challenge (which provides challenges).

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 instructs that for chains requiring a signature, one must first use trust_challenge to get a challenge, sign it, then call this tool with the signature. This provides clear context for when to use this tool and a prerequisite workflow, though it does not explicitly mention alternative tools for other use cases like trust_lookup.

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