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, the description carries the full burden. It discloses one important behavior: reviews with proof-of-payment are marked as verified. However, it does not mention side effects (e.g., permanence, editability, authentication requirements) or what happens on submission, so transparency is partial.

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, compact sentence that front-loads the purpose and adds a key behavioral detail. No wasted words or redundant 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 tool is a write operation with no annotations and no output schema. The description does not mention return values, prerequisites (e.g., whether the agent must be registered with trust_register), or how the review is linked to a specific transaction. This leaves significant gaps for an agent deciding whether and how to invoke 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?

Schema coverage is 100%, and notable parameter descriptions already explain the verification effect of proof_of_payment. The description adds no new parameter semantics beyond restating that proof-of-payment affects verification status, which the schema already covers.

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 ('Submit') and resource ('a review for an agent'), along with a clear context ('after a transaction'). This distinguishes it from siblings like trust_lookup, trust_register, and trust_list, which are not write/review operations.

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

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

Provides a clear usage context: 'after a transaction'. This tells the agent when to invoke the tool. It does not explicitly mention alternatives or exclusions, but the sibling names suggest when other tools might be appropriate, so the guidance is adequate though not exhaustive.

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