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, the description details the tool's operations: verifying transfer, minting NFT, firing reputation signals, distributing revenue, and returning a download URL. It also warns that size/color must match server-side verification. It does not cover idempotency or error states, but the main behaviors are well disclosed.

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 somewhat verbose but well-structured: it begins with the action and sequence, then lists the core effects, then specific parameter guidance. Every sentence adds information, though the physical product requirements could be more compact. Still, it balances detail with readability.

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 15 parameters and no output schema, the description covers the workflow and conditional requirements thoroughly. However, it omits details about the return format (beyond download URL) and does not mention potential errors or failure modes. It is adequate but not fully comprehensive.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value by grouping parameters under conditional requirements (e.g., physical products) and explaining why fields like buyerEmail and shipping_phone are needed. It also emphasizes that selected_size and selected_color must match the initiate step for verification.

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 identifies this as step 2 of a buy process, states the action ('confirm your USDC payment and claim the listing'), and specifies the sequence relative to initiate_agent_purchase. It also lists the exact on-chain and off-chain actions performed.

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 says 'Call after sending USDC to the address returned by initiate_agent_purchase.' It provides conditional requirements for physical products and explains the purpose of buyerAgentId. Though it does not contrast with sibling confirm_purchase, the step label and context make usage 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 full burden. It discloses that minting is gasless (platform covers gas), that a signed permit is required, and that the response includes revenue split details. It does not mention failure modes or idempotency, but key behaviors are covered.

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

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

The description is a single paragraph of about 5 sentences, front-loaded with purpose. It is concise and every sentence adds value, but could be more structured (e.g., bullet points for required fields). 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 15 parameters, 4 required, and no output schema, the description covers prerequisite (permit from initiate_purchase), behavior (minting, gasless, download link), conditional requirements (physical vs digital), and response content (revenue split). Minor gaps include error handling and mismatch behavior, but overall complete.

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

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

Schema coverage is 100%, baseline is 3. The description adds value by grouping shipping parameters as required for physical products, emphasizing that selected_size and selected_color must match initiate_purchase, and noting buyerEmail is necessary for order confirmation. This goes beyond the 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 'Complete the purchase by submitting the signed EIP-712 permit from initiate_purchase' and identifies it as Step 2, distinguishing it from the sibling tool 'initiate_purchase'. It specifies that it mints an ERC-1155 NFT, returns a download link, and includes revenue split details.

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

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

The description explains that the tool is the second step after initiate_purchase and lists required fields for physical products. However, it does not explicitly compare to other tools like 'confirm_agent_purchase' or state when not to use it. The context is clear but lacks exclusion criteria.

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

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

No annotations provided, so description must cover behavioral traits. It mentions the agent acts on behalf of owner and returns ID/session details, but does not disclose side effects (e.g., credit consumption for pro tier), authorization requirements, or irreversible actions. This leaves agents uninformed about important behavioral consequences.

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

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

Three carefully crafted sentences: first states purpose, second explains functionality, third covers output and management. Front-loaded with key information, no redundancy. Every sentence adds 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 11 parameters and no output schema, the description explains creation and general behavior but lacks details on prerequisites (e.g., wallet validation, balance checks) and return format. Adequate but not thorough for a complex creation 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% with descriptions for all parameters, so baseline is 3. The description does not add additional parameter-level meaning beyond the schema; it provides general context but no enrichment for individual 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?

The description starts with a clear verb 'Create' and specifies the resource 'Personal Shopper or Concierge on RRG'. It distinguishes between two types (free rule-based vs credit-based LLM-powered) and explains the agent's role. This provides unambiguous 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?

No guidance on when to use this tool vs alternatives. Sibling tools like 'initiate_agent_purchase' or 'get_concierge_status' are present but no mention of when to choose this one. The description lacks usage context or exclusions.

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

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

No annotations are provided, so the description bears full responsibility. It discloses the membership cost, benefits, limits, and that it 'Returns payment instructions.' While not exhaustive (e.g., no mention of idempotency), it gives a clear behavioral picture for a non-destructive membership initiation 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 a clear header, bullet points for benefits, and a concise closing instruction. Every sentence serves a purpose, but it could be slightly more concise (e.g., condensing the Phase 2 details). However, it remains reasonably efficient.

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

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

Given the lack of an output schema, the description only vaguely states 'Returns payment instructions' without specifying format or content. It covers the membership details and flow adequately, but the missing output specifics leave an agent uncertain about what response to expect.

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

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

The sole parameter 'buyerWallet' is already fully described in the input schema (pattern, type, description including 'on Base'). The tool description adds no additional parameter semantics beyond what the schema provides. With 100% schema coverage, a baseline score of 3 is appropriate.

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

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

The description clearly states the tool's purpose: 'Get your RRG Agent Pass, Phase 1 founding membership.' It specifies the action (get), resource (Agent Pass), and distinguishes from siblings like 'initiate_agent_purchase' and 'confirm_agent_purchase' by detailing the sequential 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 usage context: it is for obtaining the pass, costs $0.10 USDC, limited to 500 passes (first-come), max 5 per wallet. It also outlines the next steps ('Send USDC, then call confirm_agent_purchase with your txHash'), giving clear guidance on when to use this tool versus the confirm tool. However, it does not explicitly state when not to use it.

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

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

No annotations are provided, so 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?

With no annotations, the description carries the burden. It discloses that it checks status and lists return fields, implying a read operation. No side effects or permissions mentioned, but the behavioral details are sufficient for safe invocation.

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?

Single sentence with a clear [CONCIERGE] prefix, efficient listing of return values, 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?

The description covers the main purpose and return fields. With no output schema, it provides adequate context. It could mention the dual lookup method (agent_id or wallet_address), but the schema handles that.

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

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

Schema coverage is 100%, so baseline is 3. The description does not add significant extra meaning beyond the schema; it implicitly references the lookup logic but doesn't elaborate on parameter usage.

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 the resource 'status of a Personal Shopper or Concierge', and lists specific aspects (credit balance, preferences, LLM provider, estimated operations). This distinguishes it from siblings like check_agent_standing or get_my_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?

The description implies usage for checking concierge status but does not explicitly state when to use it versus alternatives, or provide exclusions. Given siblings, it could be more explicit.

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

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

No annotations provided, so description carries full burden. It only states that the tool returns a brief ID; does not disclose read-only nature, authentication requirements, or behavior when no brief exists. Minimal behavioral disclosure.

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: first clearly states purpose, second adds usage context and parameter detail. No wasted words, front-loaded with key information.

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

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

Given no annotations and no output schema, the description covers the tool's purpose, return value (brief ID), and usage hint for submit_design. Could mention edge cases like missing brief, but overall adequate for a simple tool.

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

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

Schema coverage is 100% with one parameter described. Description adds 'Optionally filter by brand_slug', but this is already in the schema. No additional meaning beyond what schema provides.

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

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

Description clearly states it gets the current design brief, the active creative challenge. It distinguishes from siblings by specifying it returns a brief ID needed for submit_design and can be filtered by brand_slug, and suggests calling this or list_briefs 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?

Provides explicit context: 'Call this or list_briefs FIRST if you want to submit a design.' Also mentions optional filtering by brand_slug. No explicit when-not, but alternative (list_briefs) is implied.

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?

No annotations provided, so description must disclose behavioral traits. It mentions identity handling ('identity is just a Base wallet') and that the tool works identically for humans and agents. However, it does not discuss auth requirements, rate limits, or side effects, leaving 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?

Relatively concise with 4 lines, front-loading the main purpose. Some redundancy ('one programme, three names') but overall efficient. Every sentence provides useful 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?

Given no parameters or output schema, the description adequately explains what the tool returns (comprehensive guide with specific details) and mentions identity handling. Missing access requirements or whether the handbook is static, but still complete enough for a read-only 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?

There are 0 parameters, so schema coverage is 100% trivially. The description adds value by explaining the handbook's contents (strategies, talking points, commission structure, technical details), which informs the agent of what the response will contain.

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

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

The description clearly states the tool retrieves the RRG Referral/Marketing/Affiliate Programme handbook, using specific verb 'Get' and resource 'marketing handbook'. It distinguishes from siblings like join_marketing_program and check_my_commissions by specifying it's a guide to earning commissions.

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

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

Implies usage for obtaining the handbook, but does not explicitly state when to use this tool versus alternatives like join_marketing_program or check_my_commissions. The note about working identically for humans and AI agents provides some context but no exclusions.

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

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

The description implies a read-only operation ('view', 'transparent') and confirms the agent wallet parameter, but does not disclose additional behavioral traits such as idempotency, side effects, or authentication requirements beyond the wallet. Without annotations, the burden is partially met.

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 3 sentences, front-loaded with the main purpose. It is concise with no fluff, though the '[PROFILE]' prefix is slightly distracting. Overall 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 simplicity (2 params, no output schema), the description adequately explains the tool's purpose and return data. It adds the transparency note for context. It could mention output format or error cases, but it's complete enough for typical 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?

The input schema covers 100% of parameters with clear descriptions, so the description adds limited value for parameter semantics. It mentions the wallet address in context but does not enhance schema-level detail. Baseline 3 is appropriate.

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

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

The description clearly states the verb 'View' and the resource 'personalised agent profile', listing specific data items returned (interaction history, purchase records, etc.). It distinguishes the tool from siblings like get_offers or get_brand, which target different 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 explains what the tool does but does not provide explicit guidance on when to use it versus alternatives or when not to use it. No exclusions or context for sibling differentiation is given, so it scores a baseline of 3.

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?

No annotations provided, so the description carries full burden. It discloses the tool's role as payment instruction generator and the required follow-up action. However, it does not describe what the response looks like, error handling, idempotency, or authentication requirements. The behavior is adequately implied but lacks explicit 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 sentences with a short second paragraph for post-call instructions. Every sentence adds value: the first defines the tool and its target audience, the second explains the exact workflow. No wasted words, perfectly 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 simplicity (4 parameters, no output schema, no annotations), the description covers the main flow adequately. It tells what to do with the result. Minor gaps: does not explain error scenarios or what if parameters are invalid, but overall sufficient for an AI agent to use correctly.

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

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

Schema coverage is 100% so baseline is 3. The description adds meaningful context beyond the schema: explains that tokenId identifies the drop, buyerWallet is on Base, and provides guidance on selected_size and selected_color from get_drop_details. This helps the agent correctly fill in parameters for sized/colored products.

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: getting payment instructions for a direct USDC transfer purchase for AI agents that cannot sign EIP-712 permits. It distinguishes itself from the sibling tool 'initiate_purchase' (likely for humans) and sets context as step 1 of a two-step process leading to 'confirm_agent_purchase'.

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: 'Use this if you are an AI agent that cannot sign EIP-712 permits.' It also provides clear follow-up steps: send USDC to the address and call confirm_agent_purchase. This effectively tells when to use and what to do after, contrasting with alternative 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?

The description discloses that the tool returns a permit payload requiring signTypedData, which is critical behavioral info beyond the tool's basic action. However, it could elaborate on subsequent steps (e.g., how to use the permit) and any side effects.

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

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

The description is three sentences long, all essential, and front-loaded with the core purpose. No 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?

Despite no output schema, the description explains the return type (permit payload) and provides usage context. The tool is simple and the description adequately covers 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 coverage is 100% with detailed parameter descriptions. The tool description does not add extra parameter insight beyond what the schema already provides, so baseline score of 3 is appropriate.

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

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

The description explicitly states the tool returns an EIP-712 permit payload for human wallets, clearly distinguishing it from the sibling tool 'initiate_agent_purchase' designed for 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 includes an explicit warning: 'AI AGENTS: do NOT use this tool. Use initiate_agent_purchase instead.' This provides clear when-to-use and when-not-to-use 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, the description carries the full burden. It details commission structure (10%), identity handling (Base wallet), and outcome (assigned partner ID). It does not mention side effects or reversibility, but for a registration tool, this is adequate.

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 focused paragraph of 6 sentences, front-loaded with purpose. It is well-structured but could be slightly more concise (e.g., merging the 'one programme' phrase).

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

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

Given no output schema, the description covers the return value (partner ID), commission rate, and requirements. It is complete for a registration tool, though it could mention error handling or confirmation 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?

Schema description coverage is 100%, so the baseline is 3. The description adds value by explaining the wallet_address is for payouts, name is the agent name, and erc8004_id is optional, enriching understanding beyond the schema.

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

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

The description clearly states the tool's purpose: 'Register as an RRG referral partner / marketing partner / affiliate.' It uses specific verbs ('Register') and identifies the resource (marketing program), distinguishing it from sibling tools like 'log_referral' and 'check_my_commissions'.

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 program), prerequisites (Base wallet and optional ERC-8004 ID), and post-join action (use 'log_referral' to refer). However, it lacks explicit instructions on when not to use it or alternatives, though none exist.

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?

Discloses that only active brands are listed, return field names, and chronological order. No annotations exist, so description carries full burden, and it sufficiently covers behavioral traits without 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?

Concise single paragraph, front-loaded with purpose. Every sentence provides useful 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 no output schema and zero parameters, description fully explains return values, ordering, and usage hints. No gaps in 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?

No parameters exist, so schema coverage is 100%. Description adds value by listing return fields and ordering details, exceeding the baseline of 3 for zero-parameter tools.

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

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

Clearly states 'List all active brands on the platform.' with a specific verb and resource. Distinguishes from sibling tools like 'get_brand' and 'list_briefs' by mentioning use of 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?

Provides explicit guidance on when to use this tool (browsing brands) and references sibling tools ('list_drops', 'list_briefs') for filtering. Also explains chronological ordering for sorting, though no explicit 'when not to use' is stated.

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

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

No annotations provided, so description carries full burden. Clearly labels the tool with '[BROWSE]' to indicate read-only nature, describes return fields, and explicitly states it does not return products for sale. Provides sufficient behavioral detail for a safe, non-destructive list 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?

Four sentences, no wasted words. Main purpose is front-loaded, followed by usage guidance, return information, and differentiation from sibling. Highly efficient.

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

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

Given the tool's simplicity (one optional param, no output schema), the description covers all essential aspects: what it does, when to use, what it returns, and how to use results with another tool. No gaps.

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

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

Schema coverage is 100% and the only parameter 'brand_slug' is adequately documented in the schema. The description does not add additional semantics beyond the schema's description, so baseline 3 is appropriate.

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

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

Specifies the verb 'list' and the resource 'design briefs, creative challenges, and collaboration requests'. Clearly differentiates from sibling 'list_drops' by stating these are not products for sale.

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

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

Provides explicit when-to-call conditions: 'when asked about briefs, collaborations, creative challenges, or what brands are looking for'. Also gives an exclusion: 'To see products for sale, use list_drops instead', and a follow-up action: 'Use a brief ID with submit_design to respond'.

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

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

No annotations provided, so description carries full burden. It discloses pagination behavior, return fields (limit, offset, total_count, has_more, next_offset, listings), and notes that on-chain minted count is elsewhere. No contradictions.

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?

Single paragraph, front-loaded with purpose and usage. Every sentence adds value, no wasted words. Efficiently packs all needed 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?

No output schema, yet description explains return format and fields. Provides next steps (get_drop_details + initiate_agent_purchase). Complete for a paginated listing tool with good sibling differentiation.

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%, baseline 3. Description adds context: explains limit default/max, offset default, and brand_slug filter. Also notes catalogue size to justify pagination, adding value beyond 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 it lists active RRG listings with pagination and optional brand filter. It distinguishes itself from the sibling tool search_products by specifying when to use each.

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

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

Explicitly says when to use this tool (exploring catalogue without a specific item) and when not to (if product name, SKU, brand, or keyword known, use search_products first because it's far cheaper). Provides clear alternative.

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

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

With no annotations, the description carries the full burden. It explains the business outcome (earning 10% of platform share) and implies a write operation ('log a referral, register an agent'). It does not detail side effects or error states, but the core behavior is transparent.

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

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

The description is three tight sentences plus a category tag, front-loaded with the action. Every sentence adds value: purpose, incentive, prerequisite. No redundant or verbose content.

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?

Despite no output schema, the description explains the tool's purpose, business logic, and prerequisite. It does not describe return values, but the tool's simplicity and the schema's completeness mitigate this gap. Overall, sufficiently complete for an agent to use correctly.

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

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

Schema description coverage is 100%, so the schema already documents each parameter. The tool description adds no further explanation of parameters, which is acceptable given the high coverage. Baseline score of 3 is appropriate.

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

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

The description clearly states the action ('Log a referral, register an agent') and the resource (referral/recruitment to RRG). It distinguishes from sibling tools by being the only one that logs referrals; prerequisites and related tools are mentioned separately.

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 a prerequisite ('You must be a registered partner - use join_marketing_program first'), giving clear context for when to use the tool. It does not list alternatives or exclusions, but the single-purpose nature makes this unnecessary.

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?

No annotations provided, so description carries full burden. It discloses output (voucher details and redemption URL) and the one-time use constraint, but lacks details on authentication, side effects, 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?

Two sentences, front-loaded with context and action. No redundant information, every word earns its place.

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

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

For a simple tool with no output schema, it covers the essential workflow, but could mention error handling (e.g., invalid or already redeemed codes).

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

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

Schema coverage is 100% with both parameters described. The description adds minimal extra beyond the schema, only reinforcing the code format.

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 'redeem', the resource 'voucher code', and the context 'after buying a drop'. It distinguishes from sibling tools like initiate_purchase by specifying this is for post-purchase redemption.

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?

It provides context with '[AFTER PURCHASE]' and states each voucher can only be redeemed once, but does not explicitly exclude other scenarios or point to alternatives.

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

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

With no annotations, the description carries full burden. It discloses that brand status starts as 'pending' with admin approval within 24 hours, automatic USDC payouts, and a limit of 10 product listings. This adds valuable context beyond the input schema, though it omits potential failure reasons (e.g., rejected acceptance).

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 well-structured, with bullet points for benefits and a clear 'Requires:' line. Every sentence adds value, and the front-loaded [BUILD] tag aids quick scanning.

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?

Despite no output schema, the description explains post-registration outcome (status, approval timeline, storefront, briefs, listings, payouts). It covers the lifecycle well, though it could briefly mention the response format or error cases. Overall, adequate for a create 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 coverage is 100%, so baseline is 3. The description lists required parameters and adds minimal context (e.g., wallet_address for USDC revenue), but largely repeats schema descriptions. No significant additional semantic value beyond what the schema already provides.

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

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

The description clearly states the verb 'register' and the resource 'brand', explaining that it launches a fashion or lifestyle brand. It distinguishes from sibling tools (e.g., list_brands, get_brand) which are read-only, so no ambiguity.

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 says 'This is how AI agents launch their own fashion or lifestyle brand,' clearly indicating when to use. It also highlights required parameters like accept_terms must be true. However, it does not explicitly state when not to use or mention alternatives, though none exist 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 behavioral disclosure burden. It explains matching logic (multi-token independently matched, SKU-exact outranks body-copy), return fields (tokenId, priceRangeUsdc, authenticationStatus, etc.), per-size pricing behavior when size parameter is used, and handling of zero results (suggests broader tokens or falling back to list_drops). Also discloses rejection status for generic queries. However, it does not mention rate limits or authentication requirements, which are common behavioral aspects. Overall, very transparent but not exhaustive.

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, query patterns, parameter usage, next steps, zero-match handling). It is front-loaded with the most important usage instruction ('START HERE when you know what you want'). While it is lengthy, every sentence adds value. Some redundancy (size parameter advice appears twice), but overall it balances detail with structure. Slightly verbose but not wasteful.

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 has 4 parameters, no output schema, and is complex, the description is impressively complete. It explains all common use cases, specific return fields, per-size pricing, next-step tool invocations (initiate_agent_purchase with selected_size/selected_color), and zero-result remediation. The agent can use this tool effectively without needing additional documentation.

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 baseline is 3. The description adds significant extra meaning: explains that size parameter returns sizeAvailable, sizePriceUsdc, and sizeStock; that query supports multi-token with min 2-char tokens; that brand_slug is to be obtained from list_brands; and that limit defaults to 10. This goes beyond basic parameter descriptions and helps the agent use parameters effectively. Score 4 because it's rich but not exceptional.

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 is for free-text search across active RRG listings, and specifies it answers defined intent, not open browse. It distinguishes from sibling tool list_drops, which is for browsing without intent. The verb 'search' and resource 'products' are explicit, and the opening instruction 'START HERE when you know what you want' immediately clarifies its 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?

Explicitly states when to use (when you know what you want) and when not to use (generic browse words like 'what do you have' will be rejected). Provides alternative tool (list_drops) for browsing. Gives detailed query patterns (product name, SKU, brand, collaborator, attributes) and specific guidance on passing size parameter explicitly. Also outlines next steps after search, making usage 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 full burden. It discloses that the submission may become an NFT on Base and the creator earns 35% of sales. It does not mention rate limits or authentication, but it covers the main side effects. The description could be more explicit about synchronous/asynchronous behavior or potential failures.

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: step indicator, bolded Required/Recommended, and a contingency plan. It is informative but slightly verbose with the email subject/body details. Overall, it earns its length with practical 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 9 parameters and no output schema, the description lacks information about what the tool returns (e.g., submission ID, status). It explains the workflow leading to submission but not the response or next steps after submission. This is a gap for an AI agent needing to confirm success.

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 value by explaining the image_url parameter must be a publicly accessible URL and instructs to use upload_image if needed. It also clarifies accept_terms requires acceptance of specific terms and creator_wallet is for revenue on Base. These details go beyond the 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 the tool submits an original artwork for review, specifies the step in the workflow (Step 2 after getting a brief), and explains the outcome if approved (NFT listing on Base with revenue share). It distinguishes itself from siblings like upload_image by explicitly calling out the prerequisite.

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

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

Provides explicit when-to-use guidance: call list_briefs or get_current_brief first for brief_id, and use upload_image if image is local. It also offers an alternative workflow via email if MCP cannot deliver images. This clearly separates when to use this tool vs. upload_image or email.

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?

Discloses return fields (image_id, image_url, format, size_bytes) and max 5 MB for image_url. Lacks error/format handling details but no annotations to contradict.

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?

Front-loaded with purpose, well-paragraphed. Slightly verbose but each section 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?

Covers upload trigger, all parameters, return object, and alternative email methods. Missing file size for base64 but otherwise 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?

Adds value beyond 100% schema coverage by explaining three input options and when to use each, including data URI prefix handling.

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 uploads a JPEG/PNG image and returns a hosted URL, explicitly distinguishing it from sibling submit_design which consumes the URL.

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

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

Provides explicit when-to-use context (agent artifact upload), alternative methods (email) for large base64 truncation, and guidance on choosing between image_base64, image_url, and image_chunks.

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?

No annotations are provided, so the description must disclose behavioral traits. It states the tool performs a check and grants a badge, but does not clarify if it is read-only or has side effects (e.g., writing to state). The action of 'receiving a badge' could imply mutation, but it's ambiguous. More explicit disclosure would improve 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?

The description is efficient at two sentences plus a note and link. It is front-loaded with the main purpose and outcome. Minor improvement could be integrating the registration note more succinctly, but overall it is 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 (one parameter, no output schema), the description fully covers what the tool does, its optional nature, and what it returns (a trust badge). It provides sufficient context for an agent to decide whether to invoke it.

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 'agent_wallet' parameter has a description and pattern. The tool's description does not add any additional semantic information beyond what the schema already provides. Baseline score of 3 is appropriate.

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

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

The description clearly states the tool verifies that an agent is backed by a real human via World AgentKit, checks the on-chain registry, and awards a trust badge. It distinguishes itself from siblings like 'check_agent_standing' by being specifically about 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 notes that verification is optional and unverified agents can still use the platform, providing context for when to use. It also directs agents to register first if not already human-backed. However, it does not explicitly mention when not to use or name alternative tools.

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