Real Real Genuine

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 effectively describes the tool's read-only nature (implied by 'check') and the trust level outcomes (standard, trusted, premium), but lacks details on potential errors, rate limits, or authentication needs. It adds value by explaining the trust system but misses some operational traits.

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

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

The description is front-loaded with the core purpose, followed by trust levels and benefits, all in three concise sentences with zero waste. Each sentence earns its place by providing essential information 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?

Given the tool's moderate complexity (1 parameter, no output schema, no annotations), the description is adequate but incomplete. It explains the purpose and trust system well but lacks details on return values, error handling, or integration with sibling tools, leaving gaps for an AI agent to fully understand the tool's behavior.

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% description coverage for the single parameter (agent_wallet), so the baseline is 3. The description adds meaningful context by implying that the wallet is used to query on-chain reputation across brands, enhancing understanding beyond the schema's technical details, though it doesn't fully compensate for the lack of output 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's purpose: checking on-chain trust standing across RRG brands using ERC-8004 reputation. It specifies the verb 'check' and the resource 'trust standing,' distinguishing it from siblings like check_my_commissions or get_agent_pass that focus on different aspects of the agent system.

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—to assess trust levels for benefits like voucher offers and priority access. However, it does not explicitly state when not to use it or name specific alternatives among siblings, such as get_agent_pass for pass-related checks, leaving some ambiguity.

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 burden but lacks key behavioral details. It states what information is shown but doesn't disclose whether this is a read-only operation, if it requires authentication, rate limits, or what happens with invalid wallet addresses. The description adds some context about scope but misses critical behavioral traits.

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

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

The description is appropriately sized with three sentences that each add value. It's front-loaded with the core purpose, followed by details about what's shown, and ends with identification and audience scope. No wasted words, though the bracketed prefix could be integrated more smoothly.

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 read operation with one parameter and no output schema, the description covers the basic purpose and scope adequately. However, without annotations or output schema, it should ideally provide more behavioral context about what the response contains and any limitations. The description is minimally complete but leaves gaps about the return format and operational constraints.

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% with only one parameter clearly documented. The description adds meaningful context by explaining that the wallet is for 'marketing agent' purposes and that it identifies the user, which complements the schema's technical description. For a single-parameter tool with good schema coverage, this provides adequate semantic value.

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

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

The description clearly states the tool's purpose with specific verbs ('check', 'shows', 'identified') and resources ('commission balance and history', 'total earned', 'pending payouts', 'paid-to-date', 'recent conversions', 'wallet'). It distinguishes from siblings by focusing on commission checking rather than purchases, verification, or program management.

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

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

The description implies usage context ('[AFFILIATE / REFERRAL / MARKETING]', 'Works for humans and AI agents alike') but doesn't explicitly state when to use this tool versus alternatives like 'log_referral' or 'verify_credit_topup'. No exclusions or prerequisites are mentioned.

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 burden for behavioral disclosure. It does an excellent job describing the multi-step process: verifying on-chain transfer, minting NFT, firing reputation signals, distributing revenue, and returning download URL. However, it doesn't mention error conditions, rate limits, or what happens if verification fails, leaving some behavioral aspects unspecified.

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 efficiently structured with zero waste. The first sentence establishes the tool's role in the workflow, the second describes the multi-step process, and the third provides specific parameter guidance. Every sentence serves a distinct purpose, and the information is front-loaded with the most critical context first.

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 complex purchase confirmation tool with 5 parameters and no output schema, the description provides substantial context about the multi-step process and workflow positioning. However, without annotations or output schema, it doesn't describe the return format (beyond mentioning 'download URL') or error conditions. The description compensates well but doesn't fully address all contextual needs for such a complex 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?

Schema description coverage is 100%, so the baseline is 3. The description adds some semantic context by explaining that buyerAgentId is 'for an agent-to-agent trust signal on-chain' and mentioning the purpose of confirming payment, but doesn't provide additional parameter details beyond what's already in the schema descriptions. The value added is minimal given the comprehensive 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 purpose with specific verbs ('confirm', 'verify', 'mint', 'fire', 'distribute', 'return') and resources ('USDC payment', 'ERC-1155 NFT', 'ERC-8004 reputation signals', 'download URL'). It explicitly distinguishes itself from sibling tool 'initiate_agent_purchase' by positioning as 'Step 2' in the purchase flow, making the distinction clear.

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 usage guidance: 'Call after sending USDC to the address returned by initiate_agent_purchase.' This clearly states when to use this tool versus the alternative (initiate_agent_purchase), creating a clear sequential dependency. The context of being 'Agent Step 2' further reinforces the proper workflow.

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 effectively communicates key behavioral traits: this is a write operation ('Mints the ERC-1155 NFT'), it has gasless execution ('platform covers gas'), it returns specific outputs ('download link', 'revenue split details'), and it has conditional requirements for physical products. The description doesn't mention error conditions, rate limits, or authentication needs, but provides substantial behavioral context.

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 efficiently structured in three sentences with zero waste. The first sentence establishes the core purpose and prerequisite, the second explains the on-chain action and gasless feature while noting the return value, and the third provides conditional requirements and additional return details. Every sentence earns its place.

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

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

For a complex purchase completion tool with 13 parameters and no output schema, the description provides substantial context about the tool's behavior, prerequisites, and conditional requirements. However, without annotations or an output schema, it could benefit from more detail about error conditions, what happens after minting, or how the download link is delivered. The description is mostly complete but has minor 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 description coverage is 100%, so the schema already documents all 13 parameters thoroughly. The description adds minimal parameter semantics beyond the schema - it mentions that shipping address fields are required for physical products, but doesn't explain parameter relationships or provide additional context about the signature format, tokenId meaning, or other parameters.

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

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

The description clearly states the tool's purpose with specific verbs ('Complete the purchase', 'Mints the ERC-1155 NFT on-chain') and resources ('signed EIP-712 permit from initiate_purchase', 'download link'). It distinguishes this tool from sibling tools like 'initiate_purchase' by positioning it as step 2 in a purchase flow.

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 about when to use this tool ('Step 2' after 'initiate_purchase') and includes conditional guidance ('For physical products, you MUST include shipping address fields'). However, it doesn't explicitly state when NOT to use this tool or name specific alternatives 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?

With no annotations provided, the description carries full burden and does well by disclosing key behavioral traits: it creates agents that act autonomously (browsing, evaluating, bidding), mentions cost implications (free vs credit-based), specifies what gets returned (agent ID and session details), and notes post-creation management options. It doesn't cover rate limits or error conditions.

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 sized with three sentences that each add value: first defines the tool's purpose, second explains agent behavior, third covers return values and management. It's front-loaded with the core functionality, though could be slightly more concise by combining some concepts.

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 creation tool with 11 parameters, no annotations, and no output schema, the description provides good context about what's being created, how it behaves, and what's returned. It covers the essential 'what happens after creation' aspect but doesn't address potential failures, authentication needs, or detailed response 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 description coverage is 100%, so the schema already documents all 11 parameters thoroughly. The description adds no additional parameter semantics beyond what's in the schema properties, maintaining the baseline score for high 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 verb ('Create') and resource ('Personal Shopper or Concierge on RRG'), specifying two distinct agent types with different capabilities (free/rule-based vs credit-based/LLM-powered). It distinguishes this creation tool from sibling tools that check status, manage purchases, or retrieve data rather than create new agents.

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

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

The description implies usage context by mentioning the agent acts on behalf of its owner and can be managed via a dashboard, but doesn't explicitly state when to use this tool versus alternatives. No specific exclusions or prerequisites are mentioned, though the parameter descriptions hint at different tiers and requirements.

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 effectively describes key behavioral traits: the tool returns payment instructions (not completing the purchase), requires a subsequent call to confirm_agent_purchase, involves a financial transaction ($0.10 USDC cost), and has usage limits (500 passes total, max 5 per wallet). However, it doesn't mention error conditions or what happens if limits are exceeded.

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 well-structured and appropriately sized. It front-loads the core purpose, then provides benefits, limitations, and next steps. Every sentence adds value, though the bulleted list of benefits could be slightly condensed while maintaining clarity.

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 tool with no annotations and no output schema, the description provides substantial context: purpose, benefits, costs, limitations, and workflow. It explains what the tool returns (payment instructions) and what to do next. The main gap is lack of explicit error handling information, but overall it's quite complete for a single-parameter transaction initiation 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 description coverage is 100% (the single parameter buyerWallet is fully described in the schema). The description doesn't add any additional parameter information beyond what's in the schema, but with only one parameter and complete schema coverage, the baseline is appropriately high. The description contextually implies why the wallet address is needed (for payment and pass allocation).

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: to obtain an RRG Agent Pass (Phase 1 founding membership) by providing payment instructions. It specifies the exact resource (Agent Pass) and action (get/obtain), distinguishing it from sibling tools like confirm_agent_purchase which handles confirmation after payment.

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 states when to use this tool (to get payment instructions for purchasing an Agent Pass) and what to do next (call confirm_agent_purchase after sending USDC). It also distinguishes it from alternatives by mentioning the limited availability (500 passes, max 5 per wallet) and the specific context (Phase 1 membership).

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 of behavioral disclosure. It describes what data is returned (profile, open briefs, purchasable listings), which is helpful, but lacks details on permissions, rate limits, error handling, or whether this is a read-only operation. The '[BROWSE]' prefix suggests a browsing action but isn't fully explained.

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 efficiently structured in two sentences: the first states the purpose and scope, the second provides usage guidance. Every sentence adds value, with no redundant information, making it appropriately sized and front-loaded.

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 moderate complexity (single parameter, no output schema, no annotations), the description is adequate but has gaps. It explains what data is returned and how to obtain the parameter, but lacks details on behavioral aspects like authentication or error cases. Without annotations or output schema, more context on the return format or limitations would improve completeness.

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

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

The input schema has 100% description coverage, with the brand_slug parameter clearly documented. The description adds minimal value by referencing 'list_brands' as the source for the slug, but doesn't provide additional semantic context beyond what the schema already states. This meets the baseline for high 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 verb 'Get' and resource 'full details for a specific brand', specifying what information is included (profile, open briefs, purchasable listings). It distinguishes from siblings like 'list_brands' by focusing on a single brand rather than listing all brands, though it doesn't explicitly contrast with other brand-related tools like 'get_brand_mcp_endpoint'.

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: to retrieve details for a specific brand, and it references the sibling tool 'list_brands' as the source for the required brand_slug parameter. However, it doesn't explicitly state when not to use it or mention alternatives like 'get_brand_mcp_endpoint' for other brand-related data.

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 describes the tool's purpose and output (endpoint URL for richer interaction) but doesn't disclose behavioral traits like authentication requirements, rate limits, error conditions, or what 'richer interaction' entails. The description adds some context but leaves important behavioral aspects unspecified.

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 zero waste - the first sentence establishes purpose and usage context, the second provides explicit sibling differentiation. The description is front-loaded with the core functionality and efficiently 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?

For a single-parameter tool with no annotations and no output schema, the description does well by clearly explaining purpose, usage context, and sibling differentiation. However, it doesn't describe the return value format or what 'MCP endpoint URL' specifically entails, leaving some ambiguity about the output.

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% with the single parameter 'brand_slug' fully documented in the schema. The description doesn't add any parameter-specific information beyond what the schema provides, which is acceptable given the high schema coverage, resulting in the baseline score of 3.

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 specific action ('Get a brand's dedicated per-brand MCP endpoint URL') and resource ('brand'), distinguishing it from sibling get_brand by specifying it's for deeper product browsing, live stock checks, and sizing guides rather than full profiles with briefs and listings.

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 states when to use this tool ('for deeper product browsing, live stock checks, and sizing guides') and when to use an alternative ('For the brand's full profile with briefs and listings, use get_brand instead'), providing clear differentiation from the sibling 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 are provided, so the description carries full burden. It mentions what information is retrieved but lacks behavioral details such as required permissions, rate limits, error conditions, or whether this is a read-only operation (implied by 'Check' but not explicit). For a tool with no annotation coverage, this leaves significant gaps in understanding how it behaves in practice.

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, efficient sentence that front-loads the core purpose with bracketed context '[CONCIERGE]' and lists specific data points retrieved. There is no wasted verbiage, and every word contributes to understanding the tool's 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?

Given no annotations and no output schema, the description provides a clear purpose but lacks details on behavioral aspects and return values. It is complete enough for a simple status-check tool with good schema coverage, but additional context on permissions, errors, or output structure would improve completeness for an AI agent.

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 both parameters (agent_id and wallet_address) with descriptions. The description does not add any parameter-specific semantics beyond what the schema provides, such as clarifying the lookup priority or format requirements. Baseline 3 is appropriate when the schema handles parameter documentation adequately.

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 ('Check') and resource ('status of a Personal Shopper or Concierge'), with specific details about what information is retrieved (credit balance, preferences, LLM provider, estimated operations remaining). It distinguishes from siblings like 'check_agent_standing' or 'get_my_preferences' by focusing on concierge-specific status metrics rather than general standing or user preferences.

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

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

No guidance is provided on when to use this tool versus alternatives. While it implicitly suggests use when needing concierge status information, there is no explicit mention of when-not-to-use scenarios or comparisons to siblings like 'check_agent_standing' or 'get_my_preferences' that might overlap in functionality. The description assumes context without providing usage boundaries.

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 burden. It discloses that the tool returns a 'brief ID needed for submit_design', which is valuable behavioral context about output. However, it doesn't mention whether this is a read-only operation, potential rate limits, authentication requirements, or what happens when no current brief exists. The [CREATE] tag is potentially misleading for a 'get' operation but isn't a direct contradiction.

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 sized and front-loaded with the core purpose. The second sentence provides crucial usage guidance, and the third adds parameter context. The [CREATE] tag is unnecessary and slightly confusing, but overall the description is efficient with minimal waste.

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 read operation with no output schema, the description provides good contextual completeness. It explains the tool's role in a workflow (prerequisite for submit_design), mentions the return value (brief ID), and clarifies the default vs. filtered behavior. The main gap is lack of information about error cases or what 'current' means temporally.

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 fully documents the single optional parameter. The description adds minimal value beyond the schema: 'Optionally filter by brand_slug' restates what the schema says, and 'get that brand's current brief instead of the default RRG brief' provides slight additional context about default behavior. This meets the baseline for high 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 purpose: 'Get the current design brief — the active creative challenge.' It specifies the resource (design brief/creative challenge) and verb (get), though it doesn't explicitly distinguish from the sibling 'list_briefs' tool beyond mentioning both as options. The [CREATE] tag at the beginning is confusing but doesn't undermine the core purpose statement.

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 excellent usage guidance: 'Call this or list_briefs FIRST if you want to submit a design' establishes a clear prerequisite relationship with 'submit_design'. It also explains the alternative ('list_briefs') and when to use this tool vs. the default behavior ('Optionally filter by brand_slug'). This is explicit when/when-not guidance.

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 burden. It discloses the post-purchase context and that this retrieves 'signed' URLs (implying authentication/security), but doesn't mention rate limits, response format, error conditions, or whether this can be used multiple times. It adequately describes the core behavior but lacks operational details.

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

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

Two tightly focused sentences with zero waste. The first establishes context and purpose, the second provides specific usage guidance. Every word earns its place, and critical information is front-loaded with the '[AFTER PURCHASE]' qualifier.

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 2-parameter tool with no annotations and no output schema, the description provides excellent context about when and why to use it. It could be more complete by mentioning what the output contains (URLs, expiration, etc.) or error cases, but given the tool's straightforward recovery purpose and full schema coverage, it's largely sufficient.

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 fully documents both parameters. The description doesn't add any parameter-specific information beyond what's in the schema (tokenId and buyerWallet are self-explanatory from context). This meets the baseline expectation when schema coverage is complete.

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 specific action ('Retrieve signed download URLs') and resource ('for a previously purchased listing'), distinguishing it from siblings like confirm_purchase (which provides original links) and other tools that don't handle downloads. It explicitly mentions the post-purchase context and addresses a specific use case (lost links).

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 guidance on when to use this tool ('AFTER PURCHASE', 'if you lost the original download link from confirm_purchase') and references a clear alternative (confirm_purchase for original links). It establishes clear prerequisites and distinguishes this recovery function from initial purchase confirmation.

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 behavioral traits such as the return content (metadata, physical product details, signed image URLs, on-chain supply status, revenue split) and the workflow context (browsing, pre-purchase step). However, it lacks details on error handling, rate limits, or authentication needs, which are important for a tool in a purchase flow.

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 sized and front-loaded, with the first sentence stating the core purpose, followed by return details and usage guidance. Every sentence earns its place by adding value, such as specifying the next step and distinguishing AI agent flows, 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 tool's complexity (browsing in a purchase flow), lack of annotations, and no output schema, the description does well by explaining the return values and workflow context. However, it could be more complete by addressing potential errors or authentication requirements, which are relevant for a tool that might involve sensitive data like signed URLs.

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% description coverage, with the tokenId parameter well-documented. The description adds minimal semantic context beyond the schema by implying tokenId is used to fetch details for a listing, but it doesn't provide additional syntax or format details. This meets 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 clearly states the tool's purpose with specific verbs ('Get full details') and resources ('for a specific listing by tokenId'), and distinguishes it from siblings by specifying it should be called 'after list_drops' to see what you are buying, differentiating it from purchase-related 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 explicit guidance on when to use this tool ('Call this after list_drops to see what you are buying') and when not to use it (implied: not for purchasing), and names the alternative for the next step ('call initiate_agent_purchase to buy this listing'), clearly distinguishing it from sibling tools like initiate_purchase.

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 that the tool works identically for humans and AI agents and that identity is based on a Base wallet, adding useful context about accessibility. However, it lacks details on rate limits, error conditions, or response format, leaving behavioral gaps for a tool with no output schema.

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 front-loaded with the core purpose in the first sentence, followed by additional context. All sentences add value: explaining the program's names, accessibility, and content. It could be slightly more concise by merging some details, but it's well-structured with minimal waste.

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 (0 parameters, no annotations, no output schema), the description is moderately complete. It covers what the tool does and some behavioral aspects but lacks output details (e.g., format, structure) and doesn't fully compensate for the absence of annotations, leaving gaps in understanding how to interpret results.

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 0 parameters, and schema description coverage is 100%, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, focusing on the resource being retrieved. This meets the baseline for a parameterless tool.

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 specific handbook about the RRG referral/marketing/affiliate program, which is a specific resource. It distinguishes the program's alternative names but doesn't explicitly differentiate from sibling tools like 'get_agent_pass' or 'get_brand', which might also retrieve documents or resources.

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

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

The description provides no guidance on when to use this tool versus alternatives. It mentions the handbook works for humans and AI agents, but this is a behavioral detail, not usage context. There's no indication of prerequisites, timing, or comparison to sibling tools like 'get_download_links' or 'list_briefs'.

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 clearly indicates this is a read-only operation ('View', 'Returns'), mentions transparency about what data is accessible, and specifies the scope of returned data. However, it doesn't address authentication requirements beyond the wallet parameter, rate limits, or potential privacy/access control considerations that would be helpful for a profile access 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 efficiently structured in three sentences: purpose statement, data scope enumeration, and transparency note. Every sentence adds value, though the second sentence could be slightly more concise. The information is front-loaded with the core purpose stated first.

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 read-only profile access tool with 2 parameters and 100% schema coverage but no output schema, the description provides good completeness. It clearly explains what data is returned, the tool's purpose, and transparency aspects. The main gap is lack of output format details, but given the relatively simple nature of the tool and good parameter documentation, this is acceptable.

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 both parameters well. The description doesn't add specific parameter semantics beyond what's in the schema, but since the tool has only 2 parameters and the schema coverage is complete, a baseline of 3 is appropriate. The description gets a 4 because it provides excellent context about what data is returned, which helps understand what the optional 'query' parameter might filter.

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: 'View your personalised agent profile on RRG' with specific details about what data is returned (interaction history, purchase records, design submissions, brand preferences, patterns learned). It distinguishes itself from siblings by focusing on personal profile data rather than commissions, purchases, brands, or other operational functions.

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

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

The description implies usage context through the phrase 'your personalised agent profile' and mentions transparency, but doesn't explicitly state when to use this tool versus alternatives like 'check_agent_standing' or 'get_agent_pass'. It provides some context but lacks explicit guidance on when this specific tool is appropriate versus other profile-related tools.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively communicates this is a read-only operation ([BROWSE] tag and 'List' verb) and mentions the optional filtering capability. However, it doesn't describe response format, pagination, rate limits, or authentication requirements, leaving some behavioral aspects unspecified.

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 perfectly front-loaded with the core purpose in the first sentence. Every subsequent sentence adds necessary context about voucher lifecycle and filtering. There's zero wasted text, and the structure flows logically from purpose to usage guidance.

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 read operation with one optional parameter and no output schema, the description provides good context about what the tool does and when to use it. The main gap is the lack of information about response format, which would be helpful since there's no output schema. However, the description compensates well with clear workflow guidance.

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 fully documents the single optional parameter. The description adds minimal value by mentioning 'Optionally filter by brand_slug' which essentially restates what's in the schema. This meets the baseline for high 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 specific action ('List active voucher offers'), identifies the resource ('voucher offers (perks) from brands'), and distinguishes it from siblings by specifying it's for browsing offers rather than redeeming them (which is done via redeem_voucher). The bracketed [BROWSE] tag further reinforces the read-only nature.

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 states when to use this tool ('List active voucher offers') and when to use an alternative ('Use redeem_voucher to redeem it'). It also provides context about the voucher lifecycle (obtained with purchases, redeemed separately), which helps the agent understand the appropriate workflow.

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 describes the tool's purpose and return values (status, title, rejection reason), which is helpful, but lacks details on permissions, rate limits, or error handling. The description doesn't contradict any annotations since none exist.

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, with two sentences that efficiently convey purpose, usage context, and return values. Every sentence adds value without redundancy, making it easy to parse quickly.

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 read operation with 1 parameter and no output schema, the description is mostly complete—it explains what the tool does, when to use it, and what it returns. However, it lacks details on behavioral aspects like error cases or authentication requirements, which would be beneficial given the absence of annotations.

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 fully documents the single parameter (submission_id). The description adds minimal value by referencing 'submissionId returned by submit_design', which slightly clarifies the parameter's source but doesn't provide additional semantics beyond what the schema states.

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 ('Check') and resource ('status of a design submission'), making the purpose specific and unambiguous. It distinguishes this tool from siblings like submit_design by focusing on status retrieval rather than submission creation.

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 states when to use this tool ('Call this after submit_design') and provides context for its purpose ('to find out if your submission was approved, rejected, or is still pending review'). This gives clear guidance on timing and alternatives, though it doesn't explicitly mention 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly describes the multi-step workflow (call this, then send USDC, then call confirm_agent_purchase) which is valuable context. However, it doesn't mention potential failure modes, rate limits, authentication requirements, or what happens if the payment isn't sent. It adequately describes the expected behavior but lacks operational details.

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

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

The description is perfectly front-loaded with the core purpose in the first sentence, followed by usage guidance and next steps. Every sentence earns its place by providing essential information without redundancy. The three-sentence structure is efficient and logically organized.

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 2-parameter tool with no annotations and no output schema, the description provides good contextual completeness. It explains the purpose, when to use it, and the required follow-up actions. The main gap is the lack of information about what the tool returns (payment instructions format) since there's no output schema, but the workflow context is well-covered.

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 fully documents both parameters. The description doesn't add any additional meaning or context about the parameters beyond what's in the schema. The baseline score of 3 is appropriate when the schema does all the parameter documentation work.

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 specific action ('Get payment instructions for a direct USDC transfer purchase') and distinguishes it from alternatives by explicitly mentioning it's for AI agents that cannot sign EIP-712 permits. It identifies the exact resource (payment instructions) and the context (Agent Step 1 of a purchase flow).

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 guidance on when to use this tool ('Use this if you are an AI agent that cannot sign EIP-712 permits') and clearly outlines the subsequent steps required after calling it. It distinguishes this from other purchase-related tools by specifying the target user type and technical constraints.

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 effectively communicates that this tool returns a payload requiring external signing (EIP-712 permit), specifies the target audience (human wallet apps), and indicates this is part of a purchase flow. However, it doesn't mention potential side effects, rate limits, or authentication requirements that might be relevant for a purchase operation.

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 extremely well-structured and concise. It uses a clear header '[BUY — HUMAN WALLETS ONLY]', states the core functionality in the first sentence, provides critical usage guidance in the second sentence, and adds audience context in the third. Every sentence earns its place with zero 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 purchase-related tool with no annotations and no output schema, the description does an excellent job covering the essential context: purpose, audience restrictions, and relationship to sibling tools. However, it doesn't describe what the returned payload looks like or what should be done with it after signing, which would be helpful given the absence of an 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?

Schema description coverage is 100%, so the schema already fully documents both parameters. The description doesn't add any additional parameter semantics beyond what's in the schema descriptions. It mentions the purchase context but doesn't provide extra details about parameter usage, format, or constraints.

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: it 'Returns an EIP-712 permit payload that must be signed with signTypedData' for purchasing. It specifies the exact resource (permit payload) and distinguishes it from its sibling 'initiate_agent_purchase' by explicitly stating this is for human wallets only, not AI agents.

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 usage guidelines: 'AI AGENTS: do NOT use this tool. Use initiate_agent_purchase instead.' It clearly defines when NOT to use this tool and provides the exact alternative tool name, making it unambiguous for AI agents to select the correct 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 provided, the description carries the full burden of behavioral disclosure. It effectively describes key behaviors: it's a registration/mutation tool (implied by 'register'), it assigns a 'unique partner ID,' and it outlines commission details ('10% commission on the platform's share of revenue'). It also mentions requirements ('Base wallet address and an optional ERC-8004 agent ID') and that it 'works identically for humans and AI agents.' However, it lacks details on error cases, response format, or rate limits, which are minor 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 well-structured and front-loaded, starting with the core purpose. It uses brackets for clarification and bullet-like formatting for requirements, making it efficient. However, the first sentence includes redundant phrasing ('one programme, three names') and some repetition (e.g., 'referral partner / marketing partner / affiliate'), which slightly reduces conciseness. Overall, most sentences earn their place by adding value.

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

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

Given the tool's complexity (a registration/mutation tool with no annotations and no output schema), the description is mostly complete. It covers purpose, usage, behavioral traits (e.g., commission structure, ID assignment), and requirements. However, it lacks details on the response (e.g., what data is returned upon success) and potential errors, which are important for a mutation tool. This minor gap prevents a score of 5, but it's still robust overall.

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 (wallet_address, name, erc8004_id) with descriptions. The description adds some context by mentioning 'Requirements: a Base wallet address and an optional ERC-8004 agent ID,' which reinforces the schema but doesn't provide additional semantic meaning beyond it. Since the schema does the heavy lifting, the baseline score of 3 is appropriate, as the description adds minimal extra value.

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

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

The description explicitly states the tool's purpose: 'Register as an RRG referral partner / marketing partner / affiliate' and clarifies it's 'THE single programme for earning commission by bringing other agents to RRG.' It distinguishes itself from siblings like 'log_referral' (which logs referrals after registration) and 'check_my_commissions' (which checks earnings). The description uses specific verbs ('register', 'earn') and resources ('programme', 'commission'), making the purpose clear and distinct.

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 on when to use this tool: to join the referral program for earning commissions. It mentions that after registration, you can 'start referring other agents immediately via `log_referral`,' which implicitly guides usage by linking to a sibling tool. However, it does not explicitly state when NOT to use this tool or list alternatives, such as if already registered, which prevents a score of 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 carries the full burden of behavioral disclosure. It mentions what the tool provides (invite link and directory) but doesn't cover key aspects like whether this is a read-only operation, if it requires authentication, rate limits, or what the output format is. For a tool with no annotations, this leaves significant gaps in understanding its behavior.

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

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

The description is front-loaded with the core action ('Get the RRG Discord invite link and channel directory') and follows with a brief context sentence. It uses only two sentences with zero waste, efficiently conveying essential information without unnecessary details, 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?

Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is adequate but not complete. It explains what the tool does and its purpose, but lacks details on behavioral traits like output format or usage constraints. For a tool with no structured data to rely on, it should provide more context to be fully 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?

The tool has 0 parameters, and schema description coverage is 100%, so there are no parameters to document. The description doesn't need to add parameter semantics, and it appropriately doesn't mention any. A baseline of 4 is applied as per the rules for 0 parameters, indicating no deficiency in this area.

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 the RRG Discord invite link and channel directory.' It specifies the verb ('Get') and resource ('RRG Discord invite link and channel directory'), making the action explicit. However, it doesn't distinguish this tool from its siblings, as none of them appear to be Discord-related, so differentiation isn't needed but not explicitly addressed.

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 by stating 'The Discord is the hub for agent networking, listing notifications, and commerce alerts,' suggesting it's for accessing community resources. However, it lacks explicit guidance on when to use this tool versus alternatives (e.g., no mention of other communication tools or prerequisites). The context is clear but not comprehensive.

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 effectively communicates this is a read-only operation ('List', 'Returns'), specifies what data is returned, and provides context about how the output can be used with other tools. However, it doesn't mention potential limitations like pagination, rate limits, or authentication 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 perfectly concise with two sentences that each earn their place. The first sentence states the purpose and return values, while the second provides crucial usage guidance about sibling tools. No wasted words 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?

For a simple read-only tool with 0 parameters and no output schema, the description is quite complete. It explains what the tool does, what it returns, and how to use the output with other tools. The main gap is the lack of output schema, but the description compensates by specifying the return fields. Could potentially mention if there are any limitations on the listing.

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 0 parameters with 100% schema description coverage, so the baseline is 4. The description appropriately doesn't discuss parameters since none exist, and instead focuses on the tool's purpose and output.

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 specific action ('List all active brands'), the resource ('brands on the platform'), and distinguishes it from siblings by specifying the return fields (name, slug, headline, description, product/brief counts). It also explicitly differentiates from list_drops and list_briefs by explaining how to use the brand slug for filtering.

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 guidance on when to use this tool ('List all active brands') and when to use alternatives ('Use a brand slug with list_drops or list_briefs to filter by brand'). It clearly distinguishes this unfiltered listing tool from the filtered sibling tools.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly indicates this is a read-only operation (implied by 'List' and 'Returns'), specifies the return format ('brief title, brand name, description, and brief ID'), and mentions a downstream action ('Use a brief ID with submit_design to respond'). However, it lacks details on pagination, rate limits, or error handling, which are common for list operations.

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 front-loaded with the core purpose in the first sentence, followed by usage guidelines and differentiation from siblings. Every sentence adds value: clarifying what briefs are not, when to call, what it returns, and how to use the output. There is no wasted text, 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?

Given the tool's low complexity (one optional parameter, no output schema, no annotations), the description is largely complete. It covers purpose, usage, return values, and integration with submit_design. The main gap is the lack of output schema, but the description compensates by specifying the return fields. However, it could benefit from mentioning any limitations (e.g., pagination) for full completeness.

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

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

The input schema has 100% description coverage, with the single parameter 'brand_slug' documented as 'Optional brand slug to filter briefs by a specific brand.' The description does not add any additional semantic information about parameters beyond what the schema provides, so it meets the baseline of 3 for high schema coverage without extra value.

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

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

The description clearly states the tool's purpose with specific verbs ('list open design briefs') and resources ('creative challenges and collaboration requests posted by brands'). It explicitly distinguishes this tool from its sibling list_drops by stating 'These are NOT products for sale' and 'To see products for sale, use list_drops instead,' making the distinction 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 provides explicit guidance on when to use this tool ('Call this when asked about briefs, collaborations, creative challenges, or what brands are looking for') and when not to use it ('These are NOT products for sale'). It names a clear alternative ('list_drops') for related but different queries, covering both inclusion and exclusion criteria effectively.

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 that the tool lists 'active' listings (implying a filter on status) and returns specific fields (title, price, etc.), which adds useful context. However, it doesn't mention behavioral aspects like pagination, rate limits, authentication needs, or error handling, leaving gaps for a tool with no annotation coverage.

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 sized and front-loaded, starting with the core purpose in the first sentence. Each sentence adds value: the second explains optional filtering, the third details return values, and the fourth provides usage guidance. It could be slightly more concise by combining some elements, but there's minimal waste.

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

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

Given the tool's low complexity (1 optional parameter, no annotations, no output schema), the description is reasonably complete. It covers purpose, usage, filtering, return fields, and next steps. However, without annotations or output schema, it lacks details on behavioral traits like pagination or error responses, which slightly reduces completeness for a listing 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 description coverage is 100%, so the schema already documents the optional 'brand_slug' parameter. The description adds marginal value by mentioning 'Optionally filter by brand_slug' and implying it's for filtering listings, but doesn't provide additional semantics beyond what the schema states (e.g., format examples or effects on output). Baseline 3 is appropriate as the schema does the heavy lifting.

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 specific verb ('List') and resource ('all active NFT listings available for purchase'), distinguishing it from siblings like 'get_drop_details' (specific drop) or 'list_brands' (brands only). It explicitly mentions the scope ('active', 'available for purchase') and output fields, 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 provides explicit guidance: 'START HERE to see what is for sale' indicates this is the entry point for browsing, and it distinguishes when to use this tool versus alternatives by stating 'Next step: call initiate_agent_purchase to buy (AI agents must use this, not initiate_purchase)', clearly naming the alternative tool and specifying the correct one for AI agents.

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 burden and does well by disclosing key behavioral traits: it's a mutation tool (logging/registering), mentions the 10% revenue share incentive, specifies the prerequisite of being a registered partner, and indicates this is for affiliate/referral/marketing contexts. It doesn't cover error conditions or rate limits, but provides substantial context beyond basic function.

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 efficiently structured in three sentences: first states purpose with context tag, second explains the incentive mechanism, third provides crucial prerequisite. Every sentence earns its place with no wasted words, and key information is front-loaded.

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 mutation tool with no annotations and no output schema, the description provides strong context: purpose, incentive, prerequisite, and usage scenario. It doesn't describe what happens after logging (confirmation, error cases, or return values), but given the schema's 100% coverage and the clear behavioral disclosure, it's mostly complete for agent decision-making.

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 5 parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema descriptions, but it does provide overall context about what constitutes a valid referral. Baseline 3 is appropriate when schema does the heavy lifting.

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 specific action ('Log a referral — register an agent (or human) you have recruited to RRG') and distinguishes it from siblings by focusing on referral logging rather than checking commissions, joining programs, or other marketing-related actions. It explicitly mentions the 10% revenue share incentive, which 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 when-to-use guidance: 'When your referred party takes their first action... you earn 10%...' and a clear prerequisite: 'You must be a registered partner (use join_marketing_program first).' This directly tells the agent when to use this tool and what must be done beforehand, with an alternative tool named for the prerequisite.

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 covers behavioral traits: it uses an autopost path, requires EIP-191 signature, has a 5-minute replay window, and details the signing process. It doesn't cover post-conditions or rate limits, but provides substantial transparency.

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?

Description is concise, front-loaded with purpose, and structured in two clear paragraphs. Every sentence adds value with no redundancy.

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

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

Given 5 parameters, no output schema, and no annotations, the description covers primary behavioral aspects and auth. It lacks return value details or error handling, but is fairly complete for its complexity.

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

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

Schema coverage is 100%, so baseline is 3. The description adds context: content has RRG signoff appended, timestamp ISO-8601 with tolerance, signature as EIP-191 hex. It adds value but doesn't go far beyond schema descriptions.

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 broadcasts a marketing post to RRG public channels (Telegram, BlueSky, Discord). It uses specific verbs and resource names, and distinguishes itself from siblings by being 'PRISCILLA ONLY' and targeting a specific set of channels.

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: it's for broadcasting to RRG public channels using Priscilla, with auth requirements and a replay window. However, it doesn't explicitly state when not to use or mention alternatives, though the specialized nature makes this clear.

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 key behavioral traits: the tool returns 'voucher details and redemption URL' and that 'Each voucher can only be redeemed once'. However, it doesn't cover other important aspects like authentication needs, error conditions, rate limits, or what happens on redemption failure.

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 sized with three sentences that are front-loaded: it starts with the action and context, then states the return values, and ends with a critical constraint. There's no wasted text, though the bracketed '[AFTER PURCHASE]' could be integrated more smoothly.

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 annotations and no output schema, the description provides basic completeness for a redemption tool: purpose, parameters (implied via schema), and a key constraint (single-use). However, it lacks details on return format, error handling, and broader context like how this fits with sibling purchase tools, making it adequate but with 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 description coverage is 100%, so the schema already documents both parameters ('code' and 'redeemed_by') adequately. The description adds minimal value beyond the schema by mentioning the code format 'RRG-XXXX-XXXX', but doesn't provide additional semantics for 'redeemed_by' or explain parameter interactions.

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 ('Redeem a voucher code') and resource ('voucher'), and specifies the format 'RRG-XXXX-XXXX'. However, it doesn't explicitly differentiate this from sibling tools like 'confirm_purchase' or 'initiate_purchase', which might involve similar purchase-related workflows.

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

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

The description implies usage context with '[AFTER PURCHASE]', suggesting this tool should be used post-purchase. However, it doesn't provide explicit guidance on when to use alternatives (e.g., 'confirm_purchase' for pre-redemption steps) or when not to use this tool, leaving some ambiguity.

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 effectively describes key behavioral traits: the tool initiates a registration process with admin approval, outlines post-approval benefits (storefront, brief creation, listings, payouts), specifies the initial 'pending' status and typical 24-hour approval time, and lists required parameters. However, it doesn't mention potential errors, rate limits, or idempotency.

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 efficiently structured and front-loaded: it starts with the core purpose, immediately lists key benefits in bullet points, then covers status and requirements. Every sentence adds value—no fluff or repetition—making it easy to scan and understand quickly.

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 complexity (brand registration with multiple parameters and outcomes), no annotations, and no output schema, the description does a strong job covering the what, why, and how. It explains the process, benefits, status flow, and requirements. However, it doesn't detail the output format (e.g., what's returned upon submission), which would be helpful since there's 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?

Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds minimal parameter semantics beyond the schema—it lists the six required parameters by name but doesn't explain their purpose or relationships beyond what's in the schema descriptions. This meets 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 clearly states the specific action ('Register your own brand on RRG') and resource ('brand'), distinguishing it from siblings like 'get_brand' or 'list_brands' which are read operations. It explicitly frames this as how 'AI agents launch their own fashion or lifestyle brand,' making the purpose distinct and actionable.

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: to launch a brand and gain specific benefits like a storefront, ability to create briefs, product listings, and revenue payouts. It mentions the 'pending' status and 24-hour approval timeframe, but does not explicitly state when NOT to use it or name alternatives among siblings (e.g., 'get_brand' for checking status).

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, description must disclose behavioral traits. It mentions searches across active listings only, but does not clarify if results are cached, if there are rate limits, or what happens with partial matches. However, it does explain how multi-word queries are matched (each token independently), adding useful transparency.

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?

Description is detailed but well-structured with clear sections for usage, examples, next steps, and fallbacks. Slightly verbose with some redundant information, but front-loaded with key purpose and value.

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

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

Given the absence of output schema and annotations, description covers input parameters adequately, provides usage guidance, and explains return fields. Could mention pagination or result limits more clearly, but overall complete for a search 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 description adds extra context for each parameter: 'query' has examples and behavior description, 'limit' mentions default, 'brand_slug' is explained. Description provides semantic value beyond schema fields.

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

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

Description clearly states the tool performs free-text search across active RRG listings, with specific verb 'search' and resource 'products'. It distinguishes itself from sibling tools like list_drops and get_drop_details by positioning it as the starting point for targeted searches.

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 tells when to use this tool ('START HERE when you know what you want'), provides diverse example queries, and gives clear next steps with sibling tools. Also provides fallback instructions for zero matches, including alternative approaches and when to use list_drops.

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 effectively explains the outcome ('If approved, the design becomes an ERC-1155 NFT listing on Base and you earn 35% of every sale'), technical constraints ('max 5 MB' image, 'publicly accessible JPEG/PNG URL'), and workflow dependencies. It doesn't mention rate limits, authentication needs, or error handling, but covers the essential behavioral aspects for this submission 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 well-structured with clear sections: purpose, prerequisites, parameter guidance, and fallback instructions. While slightly longer than minimal, every sentence serves a purpose - explaining the workflow, addressing common issues, and providing practical guidance. The information is front-loaded with the core purpose and key requirements.

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 9-parameter submission tool with no annotations and no output schema, the description provides substantial context about the submission process, dependencies, constraints, and business outcomes. It explains the approval workflow, revenue model, and technical requirements. The main gap is the lack of information about return values or what happens after submission, but given the tool's purpose and the detailed parameter guidance, it's reasonably 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%, so the schema already documents all 9 parameters thoroughly. The description adds some context about image_url ('If you generated the image locally, call upload_image FIRST') and mentions that brief_id 'links your submission to the correct brand', but doesn't provide significant additional semantic meaning beyond what's in the schema. This meets the baseline expectation when schema coverage is complete.

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 with specific verbs ('submit an original artwork for review') and resources ('becomes an ERC-1155 NFT listing on Base'). It distinguishes itself from sibling tools like upload_image, list_briefs, and get_current_brief by explaining its role in the workflow as 'Step 2' and specifying when to use those other tools first.

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 guidance on when to use this tool ('Call list_briefs or get_current_brief FIRST to get a brief_id'), when to use alternatives ('If you generated the image locally, call upload_image FIRST'), and even includes a fallback method ('email your submission') when the tool cannot be used directly due to runtime constraints. This covers both ideal usage scenarios and edge cases.

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 effectively describes key behaviors: the tool accepts multiple input formats (base64, URL, chunks), handles server-side concatenation for large images, returns specific fields (image_id, image_url, format, size_bytes), and has usage constraints (max 5 MB for URLs). It doesn't mention rate limits or auth needs, but covers most operational aspects well.

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 well-structured and front-loaded with the core purpose. It uses bullet points and clear sections for parameters and alternatives, making it easy to scan. Some redundancy exists (e.g., repeating parameter details), but overall, each sentence adds value, and the length is appropriate for the tool's complexity.

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 complexity (3 parameters, no annotations, no output schema), the description is highly complete. It explains the tool's purpose, usage guidelines, parameter semantics, return values, and integration with submit_design. It even includes workarounds for common issues (e.g., token limits), providing all necessary context for effective use.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds value by explaining the semantic purpose of each parameter: image_base64 for base64-encoded images, image_url for public URLs with size limits, and image_chunks for large base64 strings. It also clarifies usage contexts (e.g., 'when base64 is too large'), enhancing understanding beyond the schema's technical descriptions.

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: 'Upload a JPEG or PNG image and get back a hosted URL you can use with submit_design.' It specifies the action (upload), resource (image), and format constraints (JPEG/PNG), distinguishing it from sibling tools like submit_design by focusing on image preparation rather than design submission.

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 guidance on when to use this tool: 'when your agent framework produces images as artifacts... and you need to upload them before submitting a design.' It also names an alternative (submit designs by email) and specifies contexts (e.g., runtime truncation issues), offering clear when-to-use and when-not-to-use scenarios.

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

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

With no annotations provided, the description carries the full burden. It describes the core behavior (verifying transfers and crediting funds) and includes the exchange rate (1 USDC = $1.00). However, it doesn't disclose important behavioral traits like error conditions, processing time, authentication requirements, or what happens if verification fails.

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 perfectly concise with two sentences that each earn their place. The first sentence states the purpose and usage flow, while the second provides critical exchange rate information. 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?

For a financial transaction tool with no annotations and no output schema, the description is incomplete. While it covers the basic purpose and usage flow, it lacks important context about error handling, return values, security implications, and what constitutes successful verification. The absence of output schema means the description should ideally explain what the tool returns.

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

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

Schema description coverage is 100%, so the schema already documents both parameters thoroughly. The description doesn't add any meaningful parameter semantics beyond what's in the schema (e.g., it doesn't explain how the agent_id relates to the concierge or provide context about transaction hash validation).

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 with specific verbs ('verify a USDC transfer' and 'credit the equivalent USD amount') and identifies the target resource ('to a Concierge'). It distinguishes itself from siblings by focusing on credit verification rather than creation, purchase, or status checking.

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 usage instructions: 'Send USDC on Base to 0xbfd71eA27FFc99747dA2873372f84346d9A8b7ed, then call this with the transaction hash.' This clearly states when to use the tool (after a transfer) and includes prerequisites (the transaction hash).

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 key behaviors: it's a read-only check (implied by 'verify' and 'checks'), involves on-chain registry lookup, and has optional usage with no platform restrictions. However, it lacks details on rate limits, error conditions, or what happens if the wallet isn't registered. The description doesn't contradict annotations (none exist).

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 well-structured and front-loaded: the first sentence states the core purpose, followed by implementation details, outcomes, and optionality. Each sentence adds value without redundancy, and it efficiently includes a registration URL as actionable guidance.

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 annotations and no output schema, the description is moderately complete for a simple verification tool. It covers purpose, process, and outcome (trust badge), but lacks details on return values, error handling, or technical constraints. It's adequate but has gaps in behavioral context.

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

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

Schema description coverage is 100% for the single parameter 'agent_wallet', with the schema providing pattern and description. The description adds no additional parameter semantics beyond implying the wallet is used for registry lookup. Baseline is 3 since the schema does the heavy lifting, but the description doesn't compensate with extra context.

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: 'Verify your agent is backed by a real human via World AgentKit' and 'Checks the on-chain AgentBook registry on Base mainnet.' It specifies the verb (verify/check) and resource (agent's human-backed status via registry), and distinguishes from siblings like 'check_agent_standing' or 'verify_credit_topup' by focusing on World ID verification.

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

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

The description provides clear context for when to use it: to verify human-backed status for trust badges. It states 'This is optional — unverified agents can still use the platform normally,' indicating it's not mandatory. However, it doesn't explicitly name alternatives or specify when not to use it versus other verification tools like 'verify_credit_topup'.

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