Real Real Genuine

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 trust level thresholds (standard, trusted, premium) and the benefits of higher trust. However, it lacks details on error handling, rate limits, authentication needs, or what happens if the wallet address is invalid. The description does not 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 front-loaded with the core purpose in the first sentence, followed by trust levels and benefits. Every sentence adds value: the first defines the tool, the second explains trust thresholds, and the third describes outcomes. There is no wasted text, and it is appropriately sized for a single-parameter tool.

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 (checking on-chain reputation), no annotations, no output schema, and 100% schema coverage, the description is fairly complete. It covers purpose, trust levels, and benefits, but lacks details on return values (e.g., what specific data is returned) and error cases. For a read-only tool with simple inputs, this is adequate but not exhaustive.

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

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

The input schema has 100% description coverage, with the single parameter 'agent_wallet' well-documented in the schema. The description does not add parameter-specific details beyond the schema, but it implicitly clarifies that the wallet is used to check trust standing across brands. With high schema coverage and only one parameter, a baseline of 4 is appropriate as the description provides context without redundancy.

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 resource ('trust standing') and distinguishes itself from siblings by focusing on reputation rather than purchases, commissions, or other operations.

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

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

The description implies usage context by mentioning trust levels and benefits (e.g., 'unlocks better voucher offers and priority access'), suggesting it should be used to assess eligibility for perks. However, it does not explicitly state when to use this tool versus alternatives like 'get_offers' or 'redeem_voucher', nor does it provide exclusions or prerequisites.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes what the tool does (checking commission balance and history) and its scope (works for humans and AI agents), but lacks details on potential behavioral traits such as rate limits, authentication requirements, error conditions, or data freshness. It does not contradict any annotations, as none are given.

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 clearly stating the core purpose. Each subsequent sentence adds value: detailing what data is shown, how identification works, and the tool's applicability. There is no wasted text, and the structure efficiently conveys essential information in a few concise sentences.

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 (a read operation with one parameter), no annotations, and no output schema, the description is mostly complete. It covers the purpose, data returned, and parameter context well. However, it lacks details on output format (e.g., structure of commission history) and potential limitations (e.g., pagination for recent conversions), which would enhance completeness for an agent's 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 schema description coverage is 100%, with the single parameter 'wallet_address' well-documented in the schema. The description adds meaningful context by specifying that the wallet is for 'marketing agent' purposes and that commissions are 'identified by wallet', which clarifies the parameter's role beyond the schema's technical definition. With only one parameter, the baseline is high, and the description compensates adequately.

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

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

The description clearly states the 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 itself from siblings like 'log_referral', 'verify_credit_topup', or 'get_my_preferences' by focusing on commission tracking rather than logging, verification, or preference retrieval.

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: for checking commission-related data identified by a wallet address, applicable to both humans and AI agents. However, it does not explicitly state when not to use it or name specific alternatives among siblings (e.g., 'log_referral' for logging referrals instead of checking commissions), which prevents a perfect score.

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

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

With no annotations provided, the description fully discloses the side effects: verifies transfer, mints NFT, fires reputation signals, distributes revenue, returns download URL. It also explains the role of buyerAgentId and warns about matching sizes/colors.

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-organized with clear sections and front-loaded purpose. However, it could be slightly more concise by avoiding redundancy (e.g., repeating 'required for physical products'). Still, it's efficient and readable.

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, no output schema, and multi-step context, the description covers prerequisites, required fields for physical vs digital, and the tool's effects. It lacks details on error handling or output structure, but the download URL is mentioned. Almost complete.

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

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

Schema description coverage is 100%, and the description adds essential context beyond schema: e.g., buyerAgentId for reputation signals, selected_size/color MUST match, shipping_phone for delivery, buyerEmail for confirmation. This greatly aids correct invocation.

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 it confirms USDC payment and claims the listing, with a clear step-2 process after initiate_agent_purchase. It distinguishes itself from siblings like initiate_agent_purchase and confirm_purchase by describing the on-chain verification, minting, and signal firing.

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

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

The description provides explicit when-to-use instructions ('Call after sending USDC...') and mandatory conditions for physical products. It also explains the buyerAgentId purpose and clarifies that selected fields must match. No alternative is needed as it's the only step 2.

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

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

Without annotations, the description takes full burden. It discloses the on-chain minting (gasless), return of download link, and revenue split details. Missing details on potential costs or error handling, but overall 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 concise and well-structured. It starts with a summary, then lists requirements in a clear, scannable format without unnecessary verbosity.

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 main scenarios (physical vs digital), references the permit from initiate_purchase, and explains response contents. Could be more detailed on error cases but is generally 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%, but description adds value by explaining required fields for physical products, the purpose of shipping_phone and buyerEmail, and constraints on selected_size and selected_color matching the permit.

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 completes a purchase by submitting a permit, mints an NFT, and returns a download link. It distinguishes itself from siblings like initiate_purchase and 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?

The description provides clear guidelines for when to include shipping and email parameters, especially for physical products. It implies the tool is used after initiate_purchase but lacks explicit when-not or alternative tool references.

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 explains that the agent acts on behalf and returns session details, but lacks details on prerequisites (e.g., wallet funds, credit consumption for Pro tier) and potential side effects. The description adds some value but is incomplete.

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 concise sentences that front-load the core purpose, describe the agent's role, and mention return type and management. No extraneous 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 the tool's complexity (11 parameters, two tiers, no output schema), the description covers the main functionality and return values adequately. It misses some details like LLM provider implications but is largely complete.

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

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

All 11 parameters have schema descriptions (100% coverage), so the description adds minimal extra value. It provides some high-level context about tiers but does not enhance parameter 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 verb 'Create' and the resource 'Personal Shopper' or 'Concierge agent' on RRG. It distinguishes between the two types and differentiates from sibling tools like 'check_agent_standing' and 'get_concierge_status'.

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

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

The description provides clear context for using the tool to create an agent, but it does not explicitly state when to avoid using it or mention alternatives. However, the purpose is well-defined.

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 discloses behavior: returns payment instructions, costs $0.10 USDC, gives credits and priority, limited to 500. Does not mention error states but covers core 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?

Front-loaded with purpose, bullet points for benefits, clear sequence. Slightly verbose but 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?

For a simple 1-parameter tool with no output schema, the description covers everything: what it does, input, return value (payment instructions), cost, benefits, limits, and follow-up action. 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?

Single parameter buyerWallet is fully described in schema with pattern and description. Tool description adds no new semantics beyond 'your wallet address on Base'. Schema coverage 100% meets baseline.

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 'Get your RRG Agent Pass, Phase 1 founding membership' with specific verb and resource. It distinguishes from sibling confirm_agent_purchase by describing the sequence.

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 steps: calls get_agent_pass to get payment instructions, then calls confirm_agent_purchase. States limits (500 passes, max 5 per wallet). Lacks explicit when-not scenarios.

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

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

No annotations are provided, so the description carries the full burden. It describes the tool as a read operation ('Get') and specifies the scope of returned details, but does not disclose behavioral traits like authentication needs, rate limits, or error handling. The description adds some context but lacks comprehensive 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?

The description is front-loaded with the core purpose in the first sentence and includes a concise usage note in the second sentence. Every sentence earns its place by providing essential information without redundancy, making it appropriately sized and efficient.

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

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

Given the tool's moderate complexity (single parameter, no output schema, no annotations), the description is adequate but has gaps. It covers the purpose and usage but lacks details on behavioral aspects like response format or error conditions, making it minimally viable but not fully complete for an unannotated tool.

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

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

Schema description coverage is 100%, so the schema already documents the single parameter 'brand_slug' with a description and example. The description adds minimal value by mentioning the parameter source ('from list_brands') but does not provide additional semantics beyond what the schema provides, aligning with the baseline for high 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 details are included ('profile, open briefs, and purchasable listings'). It distinguishes from siblings like 'list_brands' by focusing on a single brand's details rather than listing multiple brands.

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 ('Provide a brand_slug from list_brands'), implying it should be used after obtaining a slug from 'list_brands'. However, it does not explicitly state when not to use it or name alternatives for similar purposes, such as 'get_brand_mcp_endpoint'.

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 explains what the tool returns ('dedicated per-brand MCP endpoint URL') and its purpose ('for deeper product browsing, live stock checks, and sizing guides'), but doesn't cover potential limitations like rate limits, authentication requirements, or error conditions. It adds useful context but lacks comprehensive behavioral details.

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

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

The description is efficiently structured in two sentences with zero waste. The first sentence states the purpose and value, while the second provides clear usage guidance. Every element earns its place, and the [DISCOVER] prefix effectively signals the tool's nature.

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 reasonably complete. It explains what the tool does, when to use it, and distinguishes it from alternatives. However, without an output schema or annotations, it could benefit from more detail about the returned endpoint format or usage 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?

The input schema has 100% description coverage, with the single parameter 'brand_slug' well-documented in the schema. The description doesn't add any parameter-specific information beyond what's in the schema, so it meets the baseline of 3 where the schema does the heavy lifting.

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

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

The description clearly states the tool's purpose with specific verbs ('Get a brand's dedicated per-brand MCP endpoint URL') and resources ('brand'), and explicitly distinguishes it from its sibling tool get_brand by contrasting 'deeper product browsing, live stock checks, and sizing guides' with 'full profile with briefs and listings'. This provides precise differentiation.

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 ('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'). This provides clear guidance on tool selection.

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 lists what the tool checks but does not disclose behavioral traits such as authentication requirements, rate limits, or side effects. With no annotations to supplement, the description fails to convey the safety profile or idempotency of the operation.

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

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

The description is a single sentence that efficiently lists the tool's outputs. However, the leading '[CONCIERGE]' tag adds little value and the sentence could be slightly more structured for 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?

Despite no output schema, the description lists key return values (credit balance, preferences, etc.), providing sufficient context for a status-check tool. It could mention the behavior when both parameters are omitted, but overall it is adequately 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% and the parameter descriptions already detail the lookup behavior (agent_id vs wallet_address). The tool description adds no additional meaning beyond what the schema provides, so the baseline score 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 checks the status of a Personal Shopper or Concierge, including specific aspects like credit balance and preferences. It differentiates from sibling tools such as 'check_agent_standing' and 'get_agent_pass' which focus on 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?

No explicit guidance is provided on when to use this tool versus alternatives. It does not mention prerequisites, suitability, or when not to use it, leaving the agent to infer usage context from the tool name and description alone.

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 states it returns a brief ID needed for submit_design, but does not disclose other behavioral traits like side effects or rate limits. Adequate but could be better.

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

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

Two sentences, front-loaded with purpose and usage context. 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?

For a simple read tool with one optional parameter, the description is fairly complete. Mentions return of brief ID and usage context. Could detail the output structure more, but 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 coverage is 100% and the parameter description in the schema is already clear. The tool description adds 'Optionally filter by brand_slug' which is redundant but confirms optionality. No additional 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 gets the current design brief, the active creative challenge. It distinguishes from siblings by advising to call this or list_briefs first for submitting a design.

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 to call this or list_briefs first when wanting to submit a design, providing clear context. No explicit when-not-to-use, but the guidance is strong.

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

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

No annotations are provided, so the description carries the full burden. It discloses that the tool retrieves 'signed download URLs' (implying authentication/security) and is for 'previously purchased' items (implying read-only access to existing data), but lacks details on rate limits, error conditions, or response format. The description adds some behavioral context but doesn't fully compensate for the absence of annotations.

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

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

The description is two sentences with zero waste: the first states the purpose and condition, the second provides usage guidance. It is front-loaded with key information and efficiently structured 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 (retrieving URLs post-purchase), no annotations, no output schema, and 100% schema coverage, the description is mostly complete. It covers purpose, usage context, and references siblings, but lacks details on output format or error handling, which would be helpful for an agent.

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

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

Schema description coverage is 100%, so the schema already documents both parameters (tokenId and buyerWallet) with their types and constraints. The description adds no additional parameter semantics beyond implying these identify a specific purchase, which is already clear from the schema. Baseline 3 is appropriate when schema does the heavy lifting.

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

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

The description clearly states the specific action ('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 focused on purchases, brands, or submissions. It explicitly mentions the condition 'AFTER PURCHASE' and references a sibling tool for context.

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 names an alternative tool (confirm_purchase) for comparison. It clearly sets boundaries for usage relative to sibling tools in the purchase 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. It discloses key behavioral traits: it's a read operation (implied by 'Get'), returns detailed metadata (e.g., 'physical product details, signed image URLs'), and clarifies it's part of a purchase flow for AI agents. However, it doesn't mention potential errors, rate limits, or authentication needs, leaving some gaps.

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

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

The description is front-loaded with the core purpose, followed by usage context and next steps. Every sentence earns its place: the first defines the tool, the second explains returns, and the third provides workflow guidance. It's efficient with zero waste.

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

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

Given the tool's moderate complexity (single parameter, no output schema, no annotations), the description is largely complete. It covers purpose, usage, returns, and workflow integration. However, without annotations or output schema, it could benefit from more detail on error handling or response structure, leaving minor gaps.

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

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

Schema description coverage is 100%, so the schema already documents the tokenId parameter fully. The description adds minimal value beyond the schema by mentioning 'tokenId' in context but doesn't provide additional semantics like format examples or constraints. Baseline 3 is appropriate when the schema does the heavy lifting.

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

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

The description clearly states the specific action ('Get full details for a specific listing by tokenId') and resource ('listing'), distinguishing it from siblings like list_drops (which lists multiple items) and purchase tools. The purpose is precise and actionable.

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

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

It explicitly states when to use this tool ('Call this after list_drops to see what you are buying') and provides clear next steps ('Next step: call initiate_agent_purchase to buy this listing'), including a warning about alternatives ('AI agents must use this flow, not initiate_purchase'). This offers comprehensive 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?

No annotations provided, so description carries full burden. It doesn't explicitly state read-only nature, authorization needs, or side effects. Mentions identity handling but lacks complete 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?

Four sentences, front-loaded with purpose, then identity context, then content summary. Every sentence adds value; 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 zero parameters and no output schema, the description adequately covers what the tool returns. Could mention output format briefly, but not essential. Sufficient for an agent to understand.

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 (0 params) and schema coverage is 100%, so the description adds no param info but also doesn't need to. Baseline 4 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?

Description clearly states it gets a specific handbook (RRG Referral/Marketing/Affiliate Programme), with a specific verb 'get' and resource. It distinguishes from sibling tools that perform actions like joining or checking 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 when needing the handbook, but no explicit when-to-use or when-not-to-use, and no alternatives mentioned. Context signals suggest non-action retrieval, but guidance is minimal.

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 states 'View' and 'Returns', implying a read-only operation, but does not disclose other behavioral traits like authentication requirements, rate limits, or whether the data is cached. The statement 'This is transparent' is a value claim rather than a 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?

The description is concise (three short sentences) and front-loaded with the purpose. Every sentence adds information, though the third sentence ('This is transparent...') is slightly redundant but not detrimental.

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 2 parameters, no output schema, and no annotations, the description adequately explains what data it returns (history, purchases, submissions, preferences) and implies the read-only nature. It is sufficient for selection but could mention response format or pagination.

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 already describes both parameters with 100% coverage. The description adds 'Optional: specific aspect to search for' for 'query' and 'Your wallet address' for 'agent_wallet', which exactly match the schema descriptions, providing no additional semantic value beyond the structured field.

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

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

The description clearly states the tool returns the user's personalized agent profile, listing specific data categories (interaction history, purchases, submissions, etc.). It distinguishes from siblings like 'check_agent_standing' or 'get_offers' by focusing on personal profile data.

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

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

The description implies usage for viewing profile data but does not explicitly state when to use this tool versus alternatives (e.g., 'use this to see what RRG remembers about you'). No exclusions or context are provided.

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 clarifies that this is a browsing/list operation ('[BROWSE]'), implies it's read-only (no mention of mutation), and provides workflow context about voucher codes and redemption. However, it doesn't disclose rate limits, pagination behavior, 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 efficiently structured with three sentences: the core purpose, workflow context about voucher redemption, and parameter guidance. Every sentence earns its place by providing essential information without redundancy. The '[BROWSE]' tag upfront signals the operation type immediately.

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 list/browse tool with one optional parameter and no output schema, the description provides adequate context about what's being listed, how it relates to the workflow, and basic parameter guidance. However, without annotations or output schema, it could benefit from more detail about response format or behavioral constraints like pagination.

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

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

Schema description coverage is 100%, so the schema already fully documents the single optional parameter. The description adds minimal value beyond the schema by mentioning 'Optionally filter by brand_slug' but doesn't provide additional semantic context about what brand slugs are or how filtering works. The baseline of 3 is appropriate when the schema does the heavy lifting.

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

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

The description clearly states the specific action ('List active voucher offers') and resource ('voucher offers (perks) from brands'), distinguishing it from sibling tools like 'list_brands' or 'list_drops'. It also clarifies that vouchers are 'bonus perks bundled with purchases', providing context about what these offers represent.

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 browse active voucher offers, with optional filtering by brand. It mentions 'redeem_voucher' as a related tool for redemption, but doesn't explicitly state when NOT to use this tool or compare it to alternatives like 'list_brands' or 'list_drops' for broader listing purposes.

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

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

No annotations are provided, so the description carries the full burden. It discloses that the tool returns status, title, and rejection reason, which adds behavioral context beyond the input schema. However, it lacks details on error handling, permissions, or rate limits, leaving some behavioral aspects unclear.

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 and usage, followed by return details, all in two efficient sentences. Every sentence adds value without redundancy, making it appropriately sized and well-structured for quick understanding.

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

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

Given the tool's low complexity (1 parameter, no output schema, no annotations), the description is mostly complete. It covers purpose, usage, and return values adequately. However, it could improve by mentioning error cases or authentication needs, slightly reducing completeness for a tool with no 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 documents the 'submission_id' parameter as a UUID from 'submit_design'. The description adds minimal value by reiterating this in the usage context ('submissionId returned by submit_design'), but doesn't provide additional semantics beyond what the schema offers, meeting the baseline for high 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 ('Check') and resource ('status of a design submission'), specifying what the tool does. It distinguishes from siblings by mentioning the specific relationship with 'submit_design', which is a sibling tool, making the purpose specific and well-differentiated.

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'). It distinguishes from alternatives by tying it directly to the submission process, offering clear guidance on usage timing.

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 this is step 1 of a multi-step purchase process, returns payment instructions, and requires subsequent actions. It lacks details on side effects, authentication, or rate limits, but provides sufficient workflow context for an agent.

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

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

Two sentences, front-loaded with purpose and usage. Zero wasted words. The structure is efficient and clear.

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

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

For a tool with 4 parameters and no output schema, the description does not specify the return format (e.g., amount, payTo address). It implies the response but lacks explicit fields. It also omits error handling or prerequisites, making it incomplete for complex scenarios.

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 workflow context (e.g., calling get_drop first for sizes/colors) but does not significantly add meaning beyond the existing schema parameter 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 explicitly states the tool is for getting payment instructions for a direct USDC transfer purchase, specifically for AI agents that cannot sign EIP-712 permits. It clearly distinguishes from siblings like initiate_purchase (likely for EIP-712) and confirm_agent_purchase (next step).

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 says 'Use this if you are an AI agent that cannot sign EIP-712 permits,' providing clear guidance on when to use. It also instructs the agent to send USDC and then call confirm_agent_purchase. However, it does not explicitly name alternative tools or state when not to use.

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

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

With no annotations, the description carries the full burden. It discloses that the tool returns a permit payload that must be signed via signTypedData, implying no immediate mutation. However, it does not mention authentication requirements or side effects if the permit is not signed, but overall 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?

Three sentences with zero waste. The first sentence front-loads the purpose and audience, the second gives direct instruction to AI agents, and the third contextualizes the tool. 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?

Given the complexity (4 params, no output schema), the description is mostly complete. It mentions the return type (EIP-712 permit) and references companion tools for parameter guidance. Missing explicit mention of post-signing steps, but the purpose is clear enough for an agent to decide if this tool is appropriate.

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 for 'selected_size' (required when sizes have different prices) and references 'get_drop' for variants. This adds marginal value 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 returns an EIP-712 permit payload, explicitly distinguishes from the sibling tool 'initiate_agent_purchase', and specifies it is for human wallets only. The verb 'returns' and resource 'permit payload' are specific.

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 tells AI agents not to use this tool and directs them to 'initiate_agent_purchase' instead. It also states the context for human wallets, providing 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 full burden. It explains that this is a registration (mutation) that creates a partner ID, is non-destructive, works for humans and AI agents, and discloses the commission rate (10%). It doesn't mention any side effects or permissions needed.

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 informative but slightly verbose. It front-loads the multiple names and includes necessary details. Every sentence adds value; could be more terse but not padded.

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 what the tool does, what you get (partner ID), requirements, and the next step (`log_referral`). Without an output schema, it reasonably describes the outcome. No critical gaps.

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

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

Schema description coverage is 100%, so baseline is 3. The description adds minor context (wallet for commissions, erc8004_id is optional) but does not significantly enhance 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 uses specific verbs ('register', 'join') and clearly identifies the resource ('RRG referral partner / marketing partner / affiliate'). It distinguishes from siblings by calling it 'THE single programme' for commission and mentions a related tool (`log_referral`).

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 (to earn commissions by referring agents) and lists requirements (Base wallet address, optional agent ID). It mentions that after joining, you can immediately use `log_referral`. However, it doesn't explicitly state when not to use this tool.

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

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

No annotations are provided, so the description carries the full burden. It discloses that the tool provides an invite link and directory, implying a read-only, non-destructive action. However, it doesn't detail behavioral traits like authentication needs, rate limits, or what happens upon invocation (e.g., if it returns a one-time link or persistent access). The description adds some context but misses key operational details.

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

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

The description is appropriately sized and front-loaded: the first sentence directly states the tool's purpose, and the second adds useful context without redundancy. Every sentence earns its place by clarifying the tool's function and value, with no wasted words or unnecessary elaboration.

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

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

Given the tool's low complexity (0 parameters, no output schema, no annotations), the description is somewhat complete but has gaps. It explains what the tool does and its purpose, but without annotations or output schema, it doesn't fully cover behavioral aspects like return format or invocation effects. For a simple tool, it's adequate but could be more thorough in disclosing operational details.

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

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

The input schema has 0 parameters with 100% coverage, so no parameters need documentation. The description doesn't add parameter semantics, but this is acceptable as there are no parameters to explain. A baseline of 4 is appropriate since the schema fully covers the absence of parameters, and the description doesn't need to compensate.

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 explicitly differentiate from sibling tools like 'join_marketing_program' or 'get_download_links', which might also involve access to resources, though the Discord-specific focus is implied.

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

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

The description implies usage context by stating 'The Discord is the hub for agent networking, listing notifications, and commerce alerts,' suggesting it should be used for connecting to community and updates. However, it lacks explicit guidance on when to use this tool versus alternatives (e.g., no mention of when to choose this over other communication or networking tools in the sibling list), and no exclusions or prerequisites are provided.

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 explicitly states that the tool is for browsing (non-destructive) and specifies the return fields, date format (ISO 8601), and ordering (chronological). Since no annotations are provided, the description adequately conveys the safe read-only nature of the operation.

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

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

The description is concise, front-loading the purpose, then providing field details, ordering, and usage notes in a logical flow. Every sentence adds value without unnecessary words.

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

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

Given the simplicity of the tool (no params, no output schema), the description is complete. It explains the return fields, ordering, and hints at integration with sibling tools, providing enough context for an AI agent to use it 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?

There are no parameters, and the schema coverage is 100% trivially. The baseline for zero parameters is 4, and the description does not need to add parameter-level details.

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: 'List all active brands on the platform.' It specifies the exact fields returned and the ordering. While it doesn't explicitly distinguish from siblings like 'get_brand', the use of 'list' and mention of 'browse' implicitly differentiates it from single-brand retrieval.

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 guidance on when to use this tool (to list brands) and hints at using it with other tools ('Use a brand slug with list_drops or list_briefs to filter by brand'). However, it does not explicitly state when not to use it or contrast with alternatives like 'get_brand'.

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 signals read-only nature with '[BROWSE]' prefix, clarifies the content is not for sale, and specifies return fields (title, brand name, description, brief ID). This is sufficient for an agent to understand behavior.

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

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

Two tightly written sentences. The first delivers purpose, the second adds usage guidance and return info. No wasted words; critical information is front-loaded.

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

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

Given the tool's simplicity (one optional param, no output schema), the description fully covers purpose, usage, return schema, and relation to siblings. An agent has all needed context to invoke 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% with one optional parameter 'brand_slug' already having a description. The tool description adds no further meaning to the parameter beyond what the schema 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?

Description clearly states it lists open design briefs, creative challenges, and collaboration requests. It distinguishes from sibling tool list_drops by noting these are NOT products for sale and directs to list_drops for products.

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 the tool (asked about briefs, collaborations, creative challenges, or what brands are looking for) and when not to (for products, use list_drops). Also explains that brief IDs returned should be used with submit_design.

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, but the description fully covers behavioral traits: it returns a page object with pagination details, each listing's fields, and notes that on-chain minted count is not included here. It implies read-only, no 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 a single paragraph but efficiently structured: core function, usage guidance, return format, limitations, and next steps. 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?

For a paginated listing tool with no output schema, the description completely covers purpose, usage, return structure, what is excluded, and follow-up actions. No gaps remain.

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%, but the description adds valuable context beyond parameter descriptions, such as default limit values, pagination usage with next_offset, and the purpose of brand_slug. This goes above the baseline 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 tool lists active RRG listings with pagination and optional brand slug filtering. It distinguishes itself from siblings like search_products and get_drop_details by naming them directly.

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

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

Explicitly advises using this tool when exploring without a specific item, and recommends calling search_products first if a specific product is known, citing cost savings. It also suggests next steps after narrowing down.

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

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

No annotations are provided, so the description carries the full burden. It discloses the behavioral consequence (earning 10% of platform's share on the referred party's first action) and the prerequisite (must be a registered partner). It does not mention idempotency, confirmation, or potential side effects, but the core business logic is clear. Given the lack of annotations, this is a solid 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?

The description is extremely concise: two sentences (plus an incentive sentence) with no fluff. It front-loads the category and verb, and every sentence adds value by explaining prerequisite, action, and outcome.

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 5 parameters (2 required), no output schema, and no annotations, the description adequately covers the purpose, prerequisite, and business consequence. It does not detail the return value or behavior on duplicate referrals, but for a logging tool, the provided context is sufficient for an agent to decide when to use it. Minor gap: no description of what happens if referral already exists.

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% (all 5 parameters have descriptions). The description adds context about why these parameters are used (e.g., to log a referral and track commission), but does not add new meaning beyond the schema. The baseline of 3 is appropriate as the schema already handles parameter documentation.

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 'log a referral' and the resource 'an agent you have recruited to RRG'. It distinguishes from sibling tools like join_marketing_program by mentioning it as a prerequisite, and the category marker '[AFFILIATE / REFERRAL / MARKETING]' further clarifies the domain.

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: after recruiting someone, and notes that you must be a registered partner first (referencing join_marketing_program). It explains the incentive (10% commission). However, it does not explicitly state when not to use the tool, which would strengthen guidance.

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

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

With no annotations provided, the description fully discloses auth method (EIP-191 signature), replay window (5 min), channel options, and automatic RRG signoff. It implies a broadcast action but does not mention destructive side effects; overall 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 highly concise: 3 sentences cover purpose, auth, and call format. Every sentence is essential and front-loaded with key information. 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 has 5 parameters, no output schema, and no annotations, the description adequately covers purpose, auth, parameters, and a simple error condition (timestamp rejection). It lacks return value details but is sufficient for correct invocation.

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

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

Schema description coverage is 100% (all parameters documented). The description adds value beyond the schema by clarifying content max length, timestamp format, signature method, default channels, and optional image URL. It compensates for the lack of higher-level context.

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

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

The description clearly states the tool broadcasts marketing posts to RRG channels (Telegram, BlueSky, Discord) using the autopost path. It specifies the target audience (PRISCILLA ONLY) and function, distinguishing it from unrelated sibling 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 explicitly marks the tool as PRISCILLA ONLY, indicating it is for a specific agent wallet. It includes auth instructions (EIP-191 signature) and a replay window (5 min), but does not explicitly state when to use vs. alternatives; however, given the unique context, this is sufficient.

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?

Since no annotations are provided, the description carries the full burden. It discloses that each voucher can only be redeemed once, which is a critical behavioral trait. It also mentions the return value. However, it does not explicitly state side effects, auth requirements, or idempotency.

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

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

The description is concise, with no wasted words. Two sentences effectively communicate the purpose and constraints.

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 redemption tool with no output schema, the description provides sufficient context: when to use it, input format, and key constraint (single use). It is complete enough for an AI agent to select and invoke 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 the baseline is 3. The description does not add meaning beyond what the schema already provides for the two parameters. Both are well-described in 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 it redeems a voucher code after purchase, specifying the code format and that it returns voucher details and URL. However, it does not differentiate from sibling tools like confirm_purchase or initiate_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?

The description hints at the context ('AFTER PURCHASE') but provides no explicit guidance on when not to use it or how it relates to sibling tools. Given the large sibling set, more direction would be helpful.

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 carry burden. Describes pending status and approval timeline, lists outcomes. Does not disclose potential failure modes (e.g., rejection reasons) or auth requirements. Adequate but not comprehensive.

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?

Well-structured with bullet points and a requirements summary. Slightly lengthy but front-loaded with purpose. Could be more concise but earns its space.

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

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

Tool has 8 params, no output schema, but description covers process, benefits, approval status, and prerequisites. Missing error scenarios but sufficient for a registration 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 100%, description adds value by grouping required params and explaining purpose (e.g., wallet_address for USDC revenue). Provides context beyond schema fields.

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

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

Clear verb+resource: "Register your own brand on RRG." Differentiates from siblings like list_brands (listing) and get_brand (retrieve). States specific purpose with benefits.

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?

Explicit when-to-use: "This is how AI agents launch their own fashion or lifestyle brand." No explicit when-not or alternatives, but usage is inferred as first-time registration, not modification.

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 fully carries the burden. It discloses that generic queries are rejected with status 'needs_more_detail', explains ranking (SKU-exact hits outrank body-copy), and details return fields including variantSummary per-size pricing. It also covers next steps and edge cases like zero matches.

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 long but well-organized with clear sections and bullet points. Every sentence adds value, though a slightly more condensed version could improve conciseness. It remains highly readable and informative.

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

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

Despite no output schema, the description fully explains return fields and variantSummary format. It covers error handling (rejection with needs_more_detail) and recovery suggestions for zero matches. It also provides next-step guidance for purchase and optional detail retrieval, making the context 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%, but the description adds substantial meaning beyond the schema. For size, it explains the behavior (sizeAvailable, sizePriceUsdc, sizeStock). For query, it lists valid patterns and notes that multi-token queries are matched independently. It also references list_brands for brand_slug and notes default limit.

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 is a free-text search tool for active RRG listings, with explicit instructions to start here when you know what you want. It distinguishes from the sibling tool list_drops for browsing without intent, making the purpose unambiguous.

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

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

The description provides explicit guidance on when to use this tool (when you know what you want) and when to use alternatives (list_drops for browsing). It also details valid query patterns, including multi-token matching and size parameter usage, ensuring the agent can select correctly.

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

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

No annotations are provided, so the description must carry the behavioral burden. It discloses that this is a CREATE operation, the design becomes an NFT if approved, and the creator earns 35% of sales. It also explains the image URL constraint and the need for prior upload. However, it does not describe error responses or what happens on failure.

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

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

The description is well-structured with a clear lead sentence, then prerequisites, fallback, and parameter guidance. It is somewhat long but each sentence adds value. It is front-loaded with the essential purpose and step.

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 covers the overall workflow (prerequisites, submission process, fallback, required vs recommended fields). It explains the consequences of approval (NFT listing, revenue share). Missing details about error responses or post-submission status, but overall it provides a complete picture.

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 significant meaning beyond the schema: it explains that image_url must be a publicly accessible JPEG/PNG (max 5MB) and recommends using upload_image first, it clarifies that accept_terms must be true and provides a link, and it explains that creator_wallet receives revenue. This goes well beyond bare 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 explicitly states 'Submit an original artwork for review' with a specific verb and resource. It also notes this is step 2, distinguishing from sibling tools like list_briefs (step 1) and upload_image (image hosting).

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 prerequisites: 'Call list_briefs or get_current_brief FIRST to get a brief_id'. It also includes a fallback email method if MCP token limits prevent image delivery, and separates required from recommended parameters with explicit instructions.

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, but description fully discloses input forms (base64, URL, chunks), server-side concatenation of chunks, maximum URL size (5 MB), and return object fields (image_id, image_url, format, size_bytes). This is comprehensive.

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?

Well-structured with bullet points and clear sections. Slightly lengthy but all sentences add value. Front-loaded with core purpose.

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, but description explicitly lists return fields. Covers input formats, constraints, and alternative methods. Highly complete given tool complexity (3 optional parameters, no required).

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%, but description adds significant value by explaining usage scenarios for each parameter (e.g., image_chunks for large base64), how they relate, and that chunks are concatenated server-side. Goes 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?

Description clearly states verb 'Upload', resource 'JPEG or PNG image', and outcome 'get back a hosted URL you can use with submit_design'. It distinguishes from siblings by linking to submit_design, which is a separate tool.

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: 'when your agent framework produces images as artifacts and you need to upload them before submitting a design.' Also gives alternatives (email methods) for when base64 truncation occurs, covering 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 carries full burden. It discloses key behavioral traits: it's a write operation (credit creation), requires a prior transaction, and specifies the exchange rate (1 USDC = $1.00). However, it doesn't mention error handling, permissions needed, or what happens on failure, leaving gaps for a mutation 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 appropriately sized and front-loaded, with the core instruction in the first sentence and essential details (wallet address, exchange rate) efficiently included. Every sentence earns its place 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?

For a mutation tool with no annotations and no output schema, the description is moderately complete. It covers the purpose, usage context, and key parameters, but lacks details on return values, error cases, or side effects, which are important for a financial transaction tool.

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

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

Schema description coverage is 100%, providing baseline documentation for both parameters. The description adds context by explaining that tx_hash corresponds to a USDC transfer on Base and agent_id comes from create_concierge, but doesn't provide additional semantic details beyond what the schema already 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 tool's purpose with specific verbs ('verify a USDC transfer' and 'credit the equivalent USD amount') and identifies the resource ('to a Concierge'). It distinguishes from siblings by focusing on credit top-up verification rather than other concierge or agent operations like create_concierge or get_concierge_status.

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

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

The description explicitly states when to use this tool: after sending USDC to a specific wallet address on Base, then calling it with the transaction hash. It implies when not to use it (e.g., for other concierge operations) and provides a clear prerequisite action, though it doesn't name specific 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?

Describes the action (on-chain check) and outcome (badge visible on listings). No annotations exist, so the description carries full burden. Does not disclose potential costs or errors, but is sufficient for a verification 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?

Concise, front-loaded with '[TRUST]' signal, and provides all necessary information in a few clear sentences 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?

Completes the picture by explaining the optional nature, the badge visibility, and provides a registration URL. No output schema needed as the description covers the outcome.

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?

Single parameter with 100% schema coverage. The description adds context that the wallet must be registered on AgentBook and that the check occurs on Base mainnet, which complements the schema's description.

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

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

Clearly states it verifies an agent is backed by a real human via World AgentKit, checks on-chain registry, and awards a trust badge. Distinct from sibling tools which handle other functions.

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

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

Explicitly states the tool is optional and unverified agents can still use the platform, providing clear context for when not to use. Lacks explicit comparison to sibling tools but the purpose is distinct enough.

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