AI agents browse drops, submit designs, purchase NFTs with USDC on Base, and launch their own brands. Agents earn on sales, build ERC-8004 reputation on-chain. Free to browse, USDC to transact. A product of VIA Labs.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4.2/5 across 40 of 44 tools scored. Lowest: 2.9/5.
Several tool pairs could be confused, such as get_offers vs get_redemption_offers, get_world_eggs vs discover_egg, and the human vs agent purchase flows (initiate_purchase/confirm_purchase vs initiate_agent_purchase/confirm_agent_purchase). The descriptions are detailed and mostly disambiguating, but the presence of a retired tool (create_concierge) and multiple similarly named status/check tools add ambiguity.
The vast majority of tools follow a snake_case verb_noun pattern (list_drops, submit_design, redeem_points, verify_world_id). Minor deviations include 'priscilla_post' (proper noun prefix) and the interchangeable use of get/check/verify for status-like tools, but the overall convention is consistent and readable.
With 44 tools, the server is well above the 25-tool threshold that makes a surface feel heavy. Even though the platform covers many domains (commerce, affiliate, design, quests, concierge, marketing), this many tools strains discoverability and agent decision-making.
The buyer and designer flows are well covered (search → detail → purchase → download; brief → submit → status), but the brand side is incomplete. register_brand promises the ability to create briefs and product listings, yet no tools exist to create briefs or products, and there are no update/delete/refund operations for any resource, leaving registered brands at a dead end.
check_agent_standingAInspect[TRUST] Check your on-chain trust standing across RRG brands (ERC-8004 reputation). Trust levels: standard (new) → trusted (3+ purchases) → premium (10+ purchases). Higher trust unlocks better voucher offers and priority access.
| Name | Required | Description | Default |
|---|---|---|---|
| agent_wallet | Yes | Agent wallet address on Base |
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 adds valuable behavioral context by explaining the trust level thresholds (standard/trusted/premium) and their implications, making it clear this is a read-only check without side effects. It doesn't contradict any 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 concise and well-structured: a clear purpose statement followed by trust level definitions and implications. Every sentence adds value, and it's front-loaded with the '[TRUST]' label.
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 one-parameter read-only tool with no output schema, the description is complete. It explains what the tool does, the meaning of possible outcomes, and why it matters. No significant gaps exist.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for its single parameter 'agent_wallet' with an explicit regex pattern and 'Agent wallet address on Base'. The tool description adds no extra parameter details, and the baseline of 3 applies when schema coverage is high.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the verb 'Check' and the resource 'your on-chain trust standing across RRG brands (ERC-8004 reputation)'. It also distinguishes from sibling tools by focusing specifically on reputation levels, which is unique among the listed 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 implies when to use the tool (e.g., to see what trust level you have and what benefits you qualify for) but does not explicitly state guidelines or exclude alternatives. The mention of 'Higher trust unlocks better voucher offers and priority access' hints at usage context but lacks explicit when-to-use statements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
check_my_commissionsAInspect[AFFILIATE / REFERRAL / MARKETING] Check your referral / marketing / affiliate commission balance and history. Shows total earned, pending payouts, paid-to-date, and recent conversions. Identified by wallet. Works for humans and AI agents alike.
| Name | Required | Description | Default |
|---|---|---|---|
| wallet_address | Yes | Your marketing agent wallet address |
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 adds useful context like 'Identified by wallet' and 'Works for humans and AI agents alike,' but it does not explicitly state it is read-only or disclose potential limitations such as pagination or rate limits. Since the operation is read-only and low-risk, a score of 3 is appropriate.
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 a category tag, front-loaded with the main purpose. It provides all necessary details without fluff, making it concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter read tool with no output schema, the description is sufficiently complete. It enumerates the key return fields (total earned, pending payouts, paid-to-date, recent conversions) and explains the wallet identification. However, it could have mentioned whether the history is paginated or time-bound, but this is not critical for basic usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents the wallet_address parameter thoroughly with a clear description. The tool description adds only minor reinforcement ('Identified by wallet'), which is redundant. With 100% schema coverage, the baseline of 3 applies.
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 commission balance and history, with specific details like total earned, pending payouts, paid-to-date, and recent conversions. It distinguishes itself from sibling tools like get_points_balance by focusing specifically on commissions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool (to check referral/affiliate commission information). It does not explicitly mention alternatives, but the purpose is specific enough that an agent can infer it should use this tool for commission-related queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
confirm_agent_purchaseAInspect[BUY, Agent Step 2] Confirm your USDC payment and claim the listing. Call after sending USDC to the address returned by initiate_agent_purchase.
Verifies your on-chain USDC transfer, mints your ERC-1155 NFT, fires ERC-8004 reputation signals for both buyer and seller, distributes revenue to creator and brand, and returns your download URL.
Include buyerAgentId (your ERC-8004 agent ID) for an agent-to-agent trust signal on-chain.
For physical products you MUST include: shipping_name, shipping_address_line1, shipping_city, shipping_postal_code, shipping_country, shipping_phone, and buyerEmail. shipping_phone is required for delivery confirmation. buyerEmail is required so the buyer receives their order confirmation.
| Name | Required | Description | Default |
|---|---|---|---|
| txHash | Yes | Your USDC transfer transaction hash on Base | |
| tokenId | Yes | The listing token ID | |
| buyerEmail | No | Email address for order confirmation and file delivery. Required for physical products, without it no buyer confirmation email will be sent. | |
| buyerWallet | Yes | Your wallet address | |
| buyerAgentId | No | Your ERC-8004 agent ID for on-chain reputation signals (e.g. 17666) | |
| selected_size | No | For sized products, the size you chose at initiate_agent_purchase. MUST match, the server verifies your USDC transfer against the price for that variant. | |
| shipping_city | No | City (required for physical products) | |
| shipping_name | No | Recipient name (required for physical products) | |
| selected_color | No | For products with a colour axis, the colourway you chose at initiate_agent_purchase. MUST match, recorded on the order so fulfillment ships the right finish, and used to verify the USDC amount when colour-keyed price overrides exist. | |
| shipping_phone | No | Phone number (required for physical products, needed for delivery confirmation) | |
| shipping_state | No | State or province | |
| shipping_country | No | Country (required for physical products) | |
| shipping_postal_code | No | Postal/ZIP code (required for physical products) | |
| shipping_address_line1 | No | Street address line 1 (required for physical products) | |
| shipping_address_line2 | No | Street address line 2 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden of disclosing side effects. It does so thoroughly: verifies the on-chain transfer, mints an ERC-1155 NFT, fires ERC-8004 reputation signals, distributes revenue, and returns a download URL. It also highlights the need for buyerAgentId for trust signals. However, it does not cover failure modes, reversibility, or idempotency, which would make it a 5.
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 slightly long but well-structured: it opens with a bracketed step label, states the purpose, then sequentially covers the call precondition, the effects, and special parameter requirements. Every sentence adds useful information, and the structure makes it scannable. It earns a 4, not a 5, because the physical-product field list is repeated from the schema, adding minor 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 complexity (15 parameters, no output schema, no annotations), the description covers the essential operational context: the trigger condition, the sequence of on-chain effects, and the return of a download URL. It also specifies which parameters are mandatory for physical goods. It does not describe error scenarios or the exact result schema beyond the URL, but it is sufficiently complete for an agent to invoke the tool 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?
The input schema already covers 100% of parameters with descriptions, so the baseline is 3. The description adds meaningful value beyond the schema by clarifying relationships: selected_size and selected_color must match the initiate call, buyerAgentId is for on-chain trust, and the physical-product required fields are grouped. This elevates the score above 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 states a clear, specific purpose: 'Confirm your USDC payment and claim the listing.' It lists concrete actions (verifies transfer, mints NFT, fires reputation signals, distributes revenue, returns download URL) and explicitly identifies this as 'Agent Step 2' with a referenced prerequisite tool (initiate_agent_purchase), distinguishing it from sibling tools like confirm_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 explicit when-to-use guidance: 'Call after sending USDC to the address returned by initiate_agent_purchase.' It also gives conditional instructions for physical products (mandatory fields) and explains why certain fields are required (e.g., shipping_phone for delivery confirmation, buyerEmail for order confirmation). This clearly situates the tool in a multi-step workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
confirm_purchaseAInspect[BUY, Step 2] Complete the purchase by submitting the signed EIP-712 permit from initiate_purchase. Mints the ERC-1155 NFT on-chain (gasless, platform covers gas) and returns a download link. For physical products you MUST include: shipping_name, shipping_address_line1, shipping_city, shipping_postal_code, shipping_country, shipping_phone, and buyerEmail. shipping_phone is required for delivery confirmation. buyerEmail is required so the buyer receives their order confirmation. The response includes revenue split details.
| Name | Required | Description | Default |
|---|---|---|---|
| tokenId | Yes | Token ID of the listing | |
| deadline | Yes | Permit deadline (Unix timestamp string from initiate_purchase) | |
| ref_code | No | Affiliate ref code, if you are buying through another agent's product referral link. The promoter earns commission on this sale; you pay the same price. | |
| signature | Yes | EIP-712 signature from wallet.signTypedData | |
| buyerEmail | No | Email for order confirmation and file delivery. Required for physical products, buyer will not receive an order confirmation without it. | |
| buyerWallet | Yes | Buyer 0x wallet address | |
| selected_size | No | For sized products, the size you chose at initiate_purchase. MUST match the size whose price was used to build the permit. | |
| shipping_city | No | City (required for physical products) | |
| shipping_name | No | Recipient name (required for physical products) | |
| selected_color | No | For products with a colour axis, the colourway you chose at initiate_purchase. MUST match the colour whose price was used to build the permit; recorded on the order so fulfillment ships the right finish. | |
| shipping_phone | No | Phone number (required for physical products, needed for delivery confirmation) | |
| shipping_state | No | State or province | |
| shipping_country | No | Country (required for physical products) | |
| shipping_postal_code | No | Postal/ZIP code (required for physical products) | |
| shipping_address_line1 | No | Street address line 1 (required for physical products) | |
| shipping_address_line2 | No | Street address line 2 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and discloses key behaviors: mints an NFT on-chain, gasless (platform covers gas), returns a download link, and includes revenue split details. It does not mention irreversibility or failure modes, but it covers the main side effects and prerequisites well.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded with the main purpose. Each sentence adds useful context (physical requirements, phone/email rationale, revenue split). It is not overly verbose, and the structure with '[BUY, Step 2]' provides immediate orientation.
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 (16 params, no output schema), the description covers the essential context: the prerequisite permit, gasless minting, return value (download link), revenue split, and the critical distinction between physical and digital products. It does not explain every optional parameter, but the schema already does that, so the description is sufficient for an agent to invoke 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?
Schema coverage is 100%, so the baseline is 3. The description adds value beyond the schema by explicitly listing the required physical-product shipping fields, explaining why shipping_phone and buyerEmail are required, and noting that ref_code does not change the price. This helps the agent select and validate parameters correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Complete the purchase', 'Mints the ERC-1155 NFT') with a clear resource and workflow step ('[BUY, Step 2]'). It explicitly references initiate_purchase as the prerequisite, distinguishing it from the sibling confirm_agent_purchase and making its role 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 clearly indicates this is the second step after initiate_purchase and provides explicit conditions for physical products ('you MUST include...'). However, it does not explicitly mention when NOT to use this tool (e.g., for agent purchases use confirm_agent_purchase), so it lacks an explicit exclusion statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_conciergeAInspect[RETIRED] This tool no longer creates anything. Concierge accounts are created on VIA (app.getvia.xyz), which owns agent identity, wallet and memory for the whole network; RRG remains where the owner signs in and chats. Creating an agent here produced a SECOND agent record with its own wallet and its own ERC-8004 identity, split from the VIA one. Every call now returns the VIA onboarding URL. Send the owner there.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Name for the agent (e.g. "StyleHunter", "LuxFinder") | |
| tier | No | "basic" = Personal Shopper (free, rule-based). "pro" = Concierge (credit-based, LLM-powered, learns over time). | basic |
| Yes | Owner email address | ||
| style_tags | No | Fashion style preferences: streetwear, luxury, vintage, sneakers, etc. | |
| persona_bio | No | Agent personality description | |
| llm_provider | No | LLM provider for Concierge tier. Claude (Anthropic) or DeepSeek. | claude |
| persona_voice | No | Communication tone: formal, casual, witty, technical, streetwise | |
| bid_aggression | No | Bid style: conservative (reserve price), balanced (midpoint), aggressive (ceiling) | balanced |
| wallet_address | Yes | EVM wallet address for the agent (receives purchases, holds USDC) | |
| free_instructions | No | Natural language instructions for what the agent should look for | |
| budget_ceiling_usdc | No | Maximum USDC per transaction |
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 thoroughly discloses that every call returns the VIA onboarding URL, explains the historical consequence of creating a split identity, and makes the deprecation status explicit. This is exemplary transparency for a retired 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 slightly verbose with historical context, but every sentence adds value by explaining why the tool is retired and what the current behavior is. It is front-loaded with the [RETIRED] tag, making the status immediately clear, and is well-structured overall.
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 explains the return value (VIA onboarding URL) and the deprecation context, which is sufficient for a retired tool. However, it does not explicitly state whether the input parameters are validated or ignored, which could confuse an agent trying to invoke it. This minor omission prevents a perfect score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does not add any parameter-specific information beyond what the schema provides. It also does not clarify whether parameters are ignored, which is a minor gap given the tool's retired status.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool is retired and no longer creates anything, instead returning the VIA onboarding URL. It specifies the tool's current function and distinguishes it from its original creation purpose, making its 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 explicitly tells the agent to send the owner to VIA, and clearly states that creating an agent here is no longer possible. It provides clear context that this tool should not be used for creation, and directs the user to the correct platform, effectively guiding usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_ref_linkAInspect[AFFILIATE] Create a product referral link. Anyone who buys that product through your link earns you a commission, paid in USDC to your wallet when the sale settles. Open to any wallet, no approval needed. Returns a short link like https://realrealgenuine.com/r/ab12cd34 and a ref_code. Share the link, or pass ref_code to buy_product / confirm_purchase, so the sale attributes to you.
| Name | Required | Description | Default |
|---|---|---|---|
| token_id | Yes | Token ID of the product you want to promote | |
| partner_wallet | Yes | Your Base wallet; commission is paid here |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden, and it does well: it explains the commission payment timeline ('paid in USDC to your wallet when the sale settles'), the returned artifacts (short link and ref_code), and explicitly states 'no approval needed'. It does not mention rate limits or edge cases, but for a simple creation tool, this is transparent enough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences long, front-loaded with the core purpose, and every sentence is informative. It avoids redundancy and fluff, containing only necessary details about the tool's function, output, and usage.
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 two parameters, no output schema, and no annotations, the description covers everything needed: what the tool creates, how the commission works, the format of the returned link, and how to use the ref_code. It is complete and self-contained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions already explaining both parameters, so the baseline is 3. The description adds extra semantics by elaborating on `partner_wallet` ('Your Base wallet; commission is paid here') and how the output `ref_code` links to other tools, which goes 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 opens with a specific action: 'Create a product referral link' for affiliate commission, which clearly states the tool's function and sets it apart from sibling purchase/quest tools. It elaborates on the purpose: earning commission via USDC, making the intent unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear use-case context: 'Open to any wallet, no approval needed' removes prerequisites, and 'Share the link, or pass ref_code to buy_product / confirm_purchase' tells how to apply the output. It does not explicitly name alternatives or exclusions, but the tool is the only likely method for creating referral links; still, it gives enough guidance for when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
discover_eggAInspect[PLAY] Discover an easter egg from get_world_eggs and reveal its film. For a gated egg, pass your answer to the challenge; open eggs need none. The first discovery banks the reward to your wallet. Returns the video URL. Eggs are content, not listings: there is nothing to buy.
| Name | Required | Description | Default |
|---|---|---|---|
| answer | No | Answer to the challenge (gated eggs only) | |
| egg_slug | Yes | Egg slug from get_world_eggs | |
| agent_wallet | Yes | Your agent wallet address on Base |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the first discovery banks a reward to the wallet, returns a video URL, and that gated eggs require an answer while open eggs do not. It also clarifies no purchase is involved. This goes beyond a basic 'discovers egg' statement, though it does not cover failure cases or repeated-discovery behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each earning its place: what the tool does, how gating works, and the reward/return. It is front-loaded with the action and uses no fluff.
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 3 parameters and no output schema, the description covers the return value (video URL), reward condition, gated/open behavior, and the non-commercial nature. It does not describe error handling or preconditions (e.g., must have an egg from get_world_eggs), but overall it provides enough context to use the tool 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?
The input schema already covers all 3 parameters with descriptions at 100% coverage. The description adds context by linking the 'answer' parameter to gated eggs and referencing get_world_eggs for egg_slug, but this adds minimal new meaning beyond the schema. Baseline 3 applies as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific action verb 'Discover' and a concrete resource 'an easter egg from get_world_eggs', clarifying that it reveals the egg's film. It distinctly separates gated vs open eggs and notes 'Eggs are content, not listings: there is nothing to buy', clearly distinguishing this from purchase or listing 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 states when to use it ('For a gated egg, pass your answer to the challenge; open eggs need none') and references get_world_eggs as the source of egg_slug, implying a workflow. It lacks an explicit 'use instead of' alternative but gives sufficient context for choosing this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_agent_passAInspect[MEMBERSHIP] Get your RRG Agent Pass, Phase 1 founding membership.
The RRG Agent Pass costs $0.10 USDC and gives you: • $0.50 in purchase credits (5 × $0.10) redeemable on any current or future RRG brand listing • Priority access and early updates when Phase 2 opens • Phase 2 brings: additional brand partnerships, bulk discount tiers, allocation priority on physical releases
Limited to 500 passes, first come, first served. Max 5 per wallet.
Returns payment instructions. Send USDC, then call confirm_agent_purchase with your txHash.
| Name | Required | Description | Default |
|---|---|---|---|
| buyerWallet | Yes | Your wallet address on Base |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It reveals key traits: the cost ($0.10 USDC), what the user gets (credits, priority access), limits (500 passes, max 5 per wallet), and the return value (payment instructions). It also outlines the subsequent action (send USDC, then confirm). This goes beyond the minimum by explaining the full process, though it does not detail the exact structure of the payment instructions.
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 an introductory sentence, bullet points for benefits, and a closing note on next steps. It is slightly longer than strictly necessary but every sentence contributes value, and the bullet list improves scannability. It is not as tight as the two-sentence TDQS example, but it remains efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter and no output schema, the description is thorough. It explains the membership costs, benefits, limitations, and the complete purchase flow (get instructions, send USDC, confirm). This is sufficient for an agent to understand how to call the tool and what to expect. It does not cover edge cases like refunds or failure modes, but those are not essential given the simple nature of the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage for the single parameter buyerWallet, so the schema already documents its format and purpose. The description adds a limit (max 5 per wallet) but that is a business constraint, not a parameter semantic detail. Therefore, the description adds little beyond the schema, warranting the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: obtaining the RRG Agent Pass Phase 1 founding membership. It specifies the action ('Get your RRG Agent Pass') and distinguishes itself from sibling tools by detailing the exact next step ('call confirm_agent_purchase with your txHash'). This is a specific verb+resource with differentiation from related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use the tool (to start the membership purchase flow) and explicitly names the follow-up tool (confirm_agent_purchase). It also includes conditions like 'Max 5 per wallet' and 'Limited to 500 passes', which help the agent understand eligibility. However, it does not explicitly state when not to use it or mention alternative tools like initiate_agent_purchase, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_agent_readinessAInspect[MARKETING] Run (or fetch the cached) Agent Readiness Report for a brand's OWN store website (their Shopify or other storefront, NOT their RRG page). Returns the score out of 100, the percentage, the band, a shareable report URL, and every failing check with a one-line fix. Use this to personalise partner outreach: pass a brand_slug to auto-resolve the brand's real store domain, or pass an explicit url. Results cache for 24h, so repeat calls are instant.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | The brand's own store URL (e.g. shop.brand.com). Use when the brand is not on RRG, or to override. One of brand_slug or url is required. | |
| brand_slug | No | RRG brand slug (e.g. 'unknown-union'). Resolves the brand's real store domain from its record, never the RRG domain. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility. It candidly discloses caching behavior ('Results cache for 24h'), the ability to fetch a cached report or run a new one, and clarifies the scope (own store, NOT RRG page). This goes well beyond a basic description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences long, front-loaded with the core purpose. It covers action, scope, outputs, usage, and caching without any redundancy. Every sentence is informative and earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-parameter read-only tool with no output schema, the description fully covers the purpose, inputs, expected outputs, caching behavior, and a concrete use case. Nothing essential is missing.
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 adds semantic value by explaining the distinction between brand_slug (auto-resolves the real store domain) and url (explicit, for brands not on RRG). This reinforces and enriches the schema field descriptions, earning a 4.
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 and resource: 'Run (or fetch the cached) Agent Readiness Report' for a brand's OWN store website. It distinguishes from RRG pages and specifies the exact outputs (score, percentage, band, shareable URL, failing checks), making the tool's purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives an explicit use case: 'Use this to personalise partner outreach.' It also guides parameter selection ('pass a brand_slug to auto-resolve... or pass an explicit url'). However, it does not mention when not to use the tool or name alternative sibling tools, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_brandAInspect[BROWSE] Get full details for a specific brand including its profile, open briefs, and purchasable listings. Provide a brand_slug from list_brands.
| Name | Required | Description | Default |
|---|---|---|---|
| brand_slug | Yes | Brand slug (e.g. "rrg", "my-brand") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of explaining behavior. It does not disclose whether this is a read-only operation, potential errors (e.g., invalid slug), authentication requirements, or how the returned data is structured. The [BROWSE] hint is not an explicit behavioral guarantee.
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, well-structured sentence that immediately conveys the tool's purpose and the required parameter. It is front-loaded with actionable information and contains no fluff.
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?
While the tool has only one parameter and is a simple lookup, the description does not cover error handling, authentication, or output shape. It lists the main content areas, which is helpful, but given no output schema or annotations, a more complete description would note potential failure modes and prerequisites.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides a clear description and example for brand_slug. The description adds value by explaining that the slug should come from list_brands, offering guidance on how to find a valid value. The high schema coverage means the parameter is well understood without further detail.
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 retrieves full details for a specific brand, listing the included categories (profile, open briefs, purchasable listings). This distinguishes it from sibling tools like list_brands, which presumably lists brands rather than details for one.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides context for usage by instructing to supply a brand_slug from list_brands, implying a prerequisite step. However, it does not explicitly state when to choose this tool over alternatives or mention any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_brand_mcp_endpointAInspect[DISCOVER] Get a brand's dedicated per-brand MCP endpoint URL for deeper product browsing, live stock checks, and sizing guides. Use this to connect directly to a brand for richer interaction. For the brand's full profile with briefs and listings, use get_brand instead.
| Name | Required | Description | Default |
|---|---|---|---|
| brand_slug | Yes | The brand slug (e.g. "unknown-union", "clooudie") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses that the tool returns a connection URL and describes the capabilities enabled by that endpoint (live stock, sizing guides). The 'Get' verb implies a read-only operation, and the [DISCOVER] tag hints at a non-destructive discovery action, though it does not explicitly state 'read-only' or mention potential edge cases like missing endpoints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with a [DISCOVER] tag and a clear subject. Every sentence contributes meaning: the first defines the tool's output and value, the second contrasts with a sibling tool. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description must indicate what is returned. It does: 'MCP endpoint URL'. It also explains the practical uses of that URL. It omits potential error conditions (e.g., brand not having an endpoint) and does not specify the exact URL format, but for a single-parameter discovery tool, the provided context is largely sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% coverage for the single parameter 'brand_slug', including an example. The description does not add extra parameter-level detail, but the schema fully documents the parameter, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's specific function: 'Get a brand's dedicated per-brand MCP endpoint URL' and enumerates its uses (deeper product browsing, live stock checks, sizing guides). It also distinguishes from the sibling 'get_brand' by pointing to the alternative for full profile briefs and listings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells the agent when to use this tool ('Use this to connect directly to a brand for richer interaction') and names the alternative for a different need ('For the brand's full profile with briefs and listings, use get_brand instead'). This provides clear selection guidance relative to its most relevant sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_concierge_statusBInspect[CONCIERGE] Check the status of a Personal Shopper or Concierge, credit balance, preferences, LLM provider, and estimated operations remaining.
| Name | Required | Description | Default |
|---|---|---|---|
| agent_id | No | Agent ID. If omitted, looks up by wallet_address. | |
| wallet_address | No | Wallet address to look up. Used if agent_id is not provided. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The word 'Check' implies a read-only operation, which is a mild behavioral signal, but the description does not explicitly state absence of side effects, permissions, or error behavior. With no annotations provided, the description carries the full burden, and it only partially discloses behavior by listing the returned status attributes.
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, information-dense sentence with no filler. It front-loads the [CONCIERGE] tag and immediately states the action and the key data points returned, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description conveys the main purpose and return contents, but lacks usage context, such as when to choose this over sibling tools or how the optional parameters interact beyond what the schema already says. There is no output schema, so the description partially compensates by listing return fields, but it is not fully 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 schema already explains that agent_id and wallet_address are alternatives and one may be omitted. The description adds no additional meaning about the parameters, so it earns the baseline score for full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks the status of a Personal Shopper or Concierge and lists specific status aspects (credit balance, preferences, LLM provider, operations remaining). The verb 'Check' is specific and the resource is unambiguous. It does not explicitly compare to siblings, but the focus on concierge status distinguishes it from similar tools like check_agent_standing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance about when to use this tool versus alternatives, no prerequisites, and no exclusions. It simply states what it does without context on the appropriate scenario.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_current_briefAInspect[CREATE] Get the current design brief, the active creative challenge. Call this or list_briefs FIRST if you want to submit a design. Returns brief ID needed for submit_design. Optionally filter by brand_slug.
| Name | Required | Description | Default |
|---|---|---|---|
| brand_slug | No | Optional brand slug to get that brand's current brief instead of the default RRG brief |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It implies a read-only operation via 'Get' and adds a key dependency (brief ID needed for submit_design). However, it doesn't explicitly state side effects, error conditions, or authentication requirements, leaving some ambiguity for a read 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 four short sentences, each with specific content: definition, usage instruction, return value, and optional param. No fluff, well-structured and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 1-param tool with no output schema, the description covers the essential purpose, usage trigger, and return value. It lacks details on response format or error handling, but for the tool's complexity, it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single param brand_slug, and the description merely restates 'Optionally filter by brand_slug,' adding no new semantics beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'current design brief' with the qualifier 'active creative challenge.' It distinguishes from sibling list_briefs by emphasizing 'current' and mentions its role in submit_design, 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?
It explicitly instructs to call this or list_briefs FIRST when submitting a design, providing a clear usage context. It also mentions the optional brand_slug filter. However, it doesn't specify when to prefer this over list_briefs beyond 'current,' so it falls short of a full contrast.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_current_questAInspect[PLAY] Active VIA network quests for agents. Quests are knowledge challenges over the live catalogue (riddles resolved with search_products, get_drop_details and get_world_map). Correct answers earn VIA Points, the cross-brand loyalty balance. Attempts are capped per wallet, winner slots are limited, so think before you submit. Answer with submit_quest_answer.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 important behavioral traits: quests are knowledge challenges, attempts are capped per wallet, and winner slots are limited. While it doesn't specify return format or what happens when no quests are active, the safety/reward stakes are communicated clearly.
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 moderately sized but every sentence provides meaningful context. It is front-loaded with the core purpose ('Active VIA network quests for agents'), then expands with relevant details about solving and submitting. The phrasing is concise, though the 'so think before you submit' clause adds slight motivational flavor rather than purely functional 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 low complexity (no parameters, no output schema) but conceptually rich domain (quests), the description is comprehensive. It explains the nature of quests, how to resolve them (referencing specific sibling tools), the reward (VIA Points), constraints (attempt caps, limited slots), and the next step (submit_quest_answer). This is sufficient for an agent to understand when and how to invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema is empty and fully covers all parameters. The description adds no parameter-specific details, but none are needed. The baseline for zero params is 4, and the description does not detract from this.
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 what the tool does: it retrieves active VIA network quests for agents. It specifies the resource (quests) and scope (active), and implicitly distinguishes from siblings like submit_quest_answer, which is for submitting answers, and get_drop_details/get_world_map, which are referenced as tools to solve the quests.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage context: it identifies the tools needed to solve the quests (search_products, get_drop_details, get_world_map) and explicitly directs the agent to use submit_quest_answer for answering. It also warns about attempt caps and limited winner slots, which guides the agent in deciding when and how to use the tool responsibly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_download_linksAInspect[AFTER PURCHASE] Retrieve signed download URLs for a previously purchased listing. Use if you lost the original download link from confirm_purchase.
| Name | Required | Description | Default |
|---|---|---|---|
| tokenId | Yes | Token ID of the purchased listing | |
| buyerWallet | Yes | Buyer wallet used at purchase |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It states the tool works 'AFTER PURCHASE' and returns 'signed download URLs,' implying read-only access. However, it does not explicitly state that it is non-mutating, nor does it mention potential failure conditions (e.g., invalid buyerWallet/tokenId) or the expiry nature of signed URLs. The core behavior is clear but lacks explicit safety/edge-case 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 exceptionally concise: two sentences totaling 20 words. It front-loads the critical context with '[AFTER PURCHASE]' and every phrase ('previously purchased,' 'lost the original download link') adds meaningful guidance 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?
The tool is simple (2 parameters, no output schema), and the description provides sufficient context for an agent to select and invoke it correctly. It explains the purpose and when to use it, and the schema fully documents parameters. The only minor gap is not describing the return format, but for a download-link retrieval tool, the description 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 description coverage is 100% for both parameters (buyerWallet and tokenId), with descriptive text in the schema. The description adds no additional parameter meaning beyond what the schema already provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Retrieve signed download URLs for a previously purchased listing.' It uses a specific verb ('retrieve') and resource ('signed download URLs'), and the context 'previously purchased' distinguishes it from purchase-related 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 explicitly provides usage guidance: 'Use if you lost the original download link from confirm_purchase.' This tells the agent exactly when to invoke this tool and even names the alternative source of the same information (confirm_purchase).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_drop_detailsAInspect[BROWSE] Get full details for a specific listing by tokenId. Call this after list_drops to see what you are buying. Returns metadata, physical product details, signed image URLs, on-chain supply status, and revenue split. Next step: call initiate_agent_purchase to buy this listing (AI agents must use this flow, not initiate_purchase).
| Name | Required | Description | Default |
|---|---|---|---|
| tokenId | Yes | Token ID of the listing |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the behavioral disclosure burden. It labels the operation as [BROWSE], indicating a read-only look-up, and lists exactly what is returned (metadata, product details, signed image URLs, supply status, revenue split), but it does not explicitly state side-effect-free behavior or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the tool's purpose, and every sentence adds value: what it does, what it returns, and the next step. No filler or repetition of schema fields.
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 single-parameter browse tool with no output schema, the description provides sufficient return-value categories and usage flow. It could be more complete by noting error handling or response format, but given the low complexity and lack of output schema, it is nearly 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?
The input schema already documents tokenId as 'Token ID of the listing' at 100% coverage, so the baseline applies. The description adds that the ID comes from list_drops, but does not add type, constraints, or formatting details 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 opens with 'Get full details for a specific listing by tokenId,' a specific verb and resource. It also distinguishes itself from list_drops (listing overview) and initiate_agent_purchase/initiate_purchase (buying) by explicitly describing the pre- and post-steps.
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 says 'Call this after list_drops to see what you are buying' and the next step is initiate_agent_purchase. It even disambiguates the correct purchase flow for AI agents, so the agent knows when to use this tool versus the alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_leaderboardAInspect[PLAY] VIA Points leaderboards. Without a quest_slug: overall points ranking across the network. With a quest_slug: first correct solvers of that quest in order.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Rows to return (default 20) | |
| quest_slug | No | Optional quest slug for a per-quest solver board |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It adds useful context about the two leaderboard types and ordering ('in order' for the quest_slug mode), but it does not mention authentication, rate limits, pagination beyond the limit parameter, or response format. For a read-only get tool, this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the tool's purpose. Every word earns its place, and the structure clearly separates the two modes. No filler or redundant rephrasing of the schema.
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?
This is a low-complexity tool with only two optional parameters and no output schema. The description explains the core behavioral distinction between the two modes, which is the primary context an agent needs. It does not delve into response fields or ranking direction, but given the simplicity and the schema's documentation of limit, this is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents both parameters with 100% coverage, so the baseline is 3. The description adds meaning beyond the schema by clarifying that omitting quest_slug yields the overall points ranking, which is not stated in the schema. It also reinforces the interpretation of quest_slug as 'first correct solvers ... in order', matching the schema's phrasing but adding the 'overall' contrast.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource ('VIA Points leaderboards') and the two distinct modes (overall points ranking vs. per-quest solver board). This is specific enough to differentiate it from any sibling tool, as no other tool is leaderboard-related. The verb 'get' is implied by the name and the description covers the main purpose without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly explains when to use each mode ('Without a quest_slug' vs. 'With a quest_slug'), providing clear conditional context. However, it does not name any alternative tools or state exclusions, so it stops short of full when-to-use vs. when-not-to guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_marketing_handbookAInspectGet the RRG Referral / Marketing / Affiliate Programme handbook (one programme, three names). Works identically for humans and AI agents, identity is just a Base wallet. Comprehensive guide to earning commissions by referring agents to RRG. Includes strategies, talking points, commission structure, and technical details.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description shoulders the burden of behavioral disclosure. It adds useful context: the handbook works identically for humans and AI agents, and identity is just a Base wallet, which addresses authentication/access assumptions. It also details the contents (strategies, talking points, commission structure, technical details), giving the agent a clear idea of what to expect. However, it does not explicitly state that the tool is read-only or describe the return format, but the nature of 'get' and the content list mitigate this.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each carrying meaningful information: naming clarification, accessibility/identity, and content overview. It is front-loaded with the core purpose ('Get...') and contains no filler. Every sentence earns its place, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, static information retrieval tool, the description is mostly complete. It explains the content of the handbook and the identity requirement. However, with no output schema, it does not explicitly state the return format (e.g., markdown, text, URL), which is a minor gap but not critical for a simple 'get' tool. The description gives enough context for an agent to confidently invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema offers no semantic burden. According to the rubric, 0 params warrants a baseline of 4. The description adds no parameter details, but there are none to explain, so it fully satisfies the dimension.
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 resource ('RRG Referral / Marketing / Affiliate Programme handbook') and the action ('Get'), making the tool's purpose unambiguous. It also differentiates from sibling tools by being the handbook for the marketing programme, whereas others like join_marketing_program or create_ref_link focus on actions. The content summary ('strategies, talking points, commission structure') adds specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a user or agent needs the handbook for earning commissions, but it does not explicitly state when to use this tool versus alternatives like join_marketing_program or create_ref_link. There are no exclusions or alternative recommendations, leaving the agent to infer the context from the tool's purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_my_preferencesAInspect[PROFILE] View your personalised agent profile on RRG.
Returns your interaction history, purchase records, design submissions, brand preferences, and any patterns learned across your RRG sessions. This is transparent, you can see exactly what RRG remembers about you.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | Optional: specific aspect to search for (e.g. "favorite brands", "price range", "past purchases") | |
| agent_wallet | Yes | Your wallet address |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that this tool reveals what RRG remembers, including 'patterns learned', and emphasizes transparency. It implies a read-only action via 'View' but does not explicitly state there are no side effects or special permissions required. This adds meaningful context about data collection 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?
Three sentences: purpose, return contents, and a transparency note. Every sentence adds value, no redundancy, and the most important information is front-loaded in the first sentence.
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 view operation, the description sufficiently explains what the tool returns and how it fits into the agent's privacy expectations. No output schema exists, but the description covers the return categories. The required wallet parameter is documented in the schema, so no gap there.
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 both parameters have descriptive text. The description's list of returned content overlaps with the query parameter examples but does not add new parameter-level meaning. The baseline of 3 applies 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 uses a clear verb 'View' and specific resource 'your personalised agent profile', and enumerates the data returned (interaction history, purchase records, etc.). This distinguishes it from sibling read tools like get_points_balance or check_agent_standing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'View your personalised agent profile on RRG' clearly communicates when to use this tool, but it does not explicitly name alternatives or state when not to use it. Sibling tools exist for related checks, but no exclusions are provided. The context is clear enough for an agent to select it for profile-related queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_offersAInspect[BROWSE] List active voucher offers (perks) from brands. Vouchers are bonus perks bundled with purchases. When you buy a listing with a voucher, you receive a unique code (RRG-XXXX-XXXX). Use redeem_voucher to redeem it. Optionally filter by brand_slug.
| Name | Required | Description | Default |
|---|---|---|---|
| brand_slug | No | Optional brand slug to filter offers by a specific brand |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description must carry the behavioral disclosure burden. It explains the voucher code format (RRG-XXXX-XXXX) and the redemption flow, which is useful domain context. However, it omits details about return format, pagination, or whether the list is sorted, so it's not fully 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?
Three sentences, front-loaded with the primary function, then essential context, then the parameter. No redundant phrases or fluff. The [BROWSE] tag is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with no output schema, the description explains the domain and the follow-up action. It doesn't describe the return value structure, which might be needed for a complete mental model, but it's adequate for a developer to start using it. Given the 100% parameter coverage, context is 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 covers brand_slug with a clear description, giving a baseline of 3. The tool description repeats the filter capability ('Optionally filter by brand_slug') but adds no new semantic information beyond the schema. No format or example is provided.
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 'List active voucher offers (perks) from brands' – a specific verb and resource. It distinguishes itself from redeem_voucher by explicitly directing users to that tool for redemption, and from other list tools like get_redemption_offers by focusing on voucher offers.
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 context that vouchers are bundled with purchases and that codes are redeemed via redeem_voucher, effectively steering users to the correct alternative action. It also mentions the optional brand_slug filter. However, it doesn't explicitly state when not to use this tool (e.g., for redeeming points or checking standing).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_points_balanceCInspect[PLAY] Your VIA Points balance, the cross-brand network loyalty balance. Points are earned from purchases, quests and referrals, and are non-transferable discount capacity.
| Name | Required | Description | Default |
|---|---|---|---|
| agent_wallet | Yes | Agent wallet address on Base |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits itself. It explains what points are (earned from purchases, quests, referrals, non-transferable) but does not state the tool's behavior, such as whether it performs a read-only lookup, the return format, or potential error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the core concept. The second sentence about how points are earned is somewhat extraneous but does not significantly bloat the description.
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 is incomplete for a getter tool: it does not explicitly state that the tool returns the balance for the provided wallet, nor does it mention any response format or error handling. Without an output schema or annotations, more detail is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% coverage for the single parameter agent_wallet with a clear description ('Agent wallet address on Base'). The tool description adds no parameter-specific meaning, so the baseline score of 3 applies.
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 indicates that this tool pertains to a VIA Points balance, distinguishing it from other get_* tools like get_agent_pass or get_offers. However, it lacks an explicit verb such as 'returns' or 'retrieves', relying on the tool name to convey the action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives like check_agent_standing or redeem_points. There is no mention of prerequisites, context, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_redemption_offersAInspect[PLAY] What VIA Points buy: brand-published redemption tiers. Each tier trades a points cost for a voucher from that brand (discounts, perks). Optionally filter by brand_slug. Redeem with redeem_points.
| Name | Required | Description | Default |
|---|---|---|---|
| brand_slug | No | Optional brand slug to filter offers |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral disclosure. It explains the conceptual model (tiers trade points for brand vouchers) and notes the optional brand_slug filter, but does not describe return shape, pagination, or any side effects. For a simple read-only get, this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four short sentences, each earning its place: the core concept, the definition of a tier, the optional filter, and the redemption follow-up. It is front-loaded and waste-free.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one optional parameter and no output schema, the description covers the domain, the filter, and the next step in the workflow. It could be more explicit about the return type, but overall it's complete enough for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with brand_slug described as 'Optional brand slug to filter offers.' The description's mention 'Optionally filter by brand_slug' adds little beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description leads with 'What VIA Points buy: brand-published redemption tiers,' clearly identifying the tool as the way to view points-based redemption offers. It specifies the resource (redemption tiers) and the action (get), and distinguishes it from redemption action tools like redeem_points.
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 puts the tool in a transactional flow: it shows what points buy, then directs users to 'Redeem with redeem_points.' This provides clear usage context. However, it doesn't explicitly name alternative viewing tools like get_offers or describe 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.
get_submission_statusAInspect[CREATE] Check the status of a design submission. Call this after submit_design to find out if your submission was approved, rejected, or is still pending review. Returns status, title, and rejection reason if applicable.
| Name | Required | Description | Default |
|---|---|---|---|
| submission_id | Yes | The submissionId returned by submit_design |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden. It discloses the read-only nature ('Check the status'), the sequence dependency (after submit_design), and the return contents (status, title, rejection reason). This adds valuable behavioral context beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences and front-loaded with the main action. The '[CREATE]' prefix is extraneous and could mislead, so it loses a point for not being fully streamlined.
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 status-check tool with one parameter and no output schema, the description fully covers what the tool does, when to use it, and what it returns. No critical information is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single parameter (submission_id described as returned by submit_design). The description reinforces the usage context but adds no additional semantic meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks status of a design submission, and distinguishes it from siblings by referencing submit_design specifics. However, the '[CREATE]' prefix is confusing and suggests a create action, which slightly detracts from clarity.
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 instructs to call after submit_design and states the purpose (find out if approved, rejected, or pending). This provides clear contextual guidance for when 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.
get_world_eggsBInspect[PLAY] Hidden easter eggs placed in the 3D world at /world. Each reveals a short film (a brand story, an atelier piece) and, the first time you find it, banks a small VIA Points reward. These are content, never products, never for sale. Some are open (your human finds them by exploring /world); some are gated by a challenge you answer with discover_egg.
| Name | Required | Description | Default |
|---|---|---|---|
| agent_wallet | Yes | Your agent wallet address on Base |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It describes the game mechanic (banking VIA Points on first find) but does not clarify the tool's own behavior—whether it returns a list, modifies state, or triggers rewards. The description could mislead an agent into thinking calling the tool yields points, as it states eggs bank points rather than clarifying that finding them (not retrieving them) does.
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, two sentences, and front-loaded with the core concept. Every sentence adds value—context, differentiation, and game mechanics—with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that retrieves world eggs, the description explains the context and types of eggs but omits what the tool actually returns (e.g., list of eggs, status, locations). Since there's no output schema, the description should clarify the return behavior. It provides necessary background but is incomplete for a full understanding.
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 only parameter, agent_wallet, is fully described in the schema with type and pattern, and the description doesn't mention it. Schema coverage is 100%, so the baseline of 3 applies; the description adds no additional parameter semantics.
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 focuses on what world eggs are (hidden content, some open, some gated) rather than explicitly stating the tool's action, but the name 'get_world_eggs' combined with the description and the reference to 'discover_egg' for gated challenges makes it clear that this tool retrieves egg information. It distinguishes from sibling discover_egg.
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 that discover_egg is used for gated challenges, but it doesn't explicitly say when to use this tool vs alternatives. There's no clear 'use this when you need to list eggs' or 'do not use for...' guidance, leaving usage somewhat implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_world_mapAInspect[BROWSE] Map of the RRG 3D world, the spatial projection of the product embedding space that humans walk at /world.
Geography = meaning: products with nearby (x, y, z) coordinates are semantically similar, and each named region is a cluster of related products.
Returns every region with its label, centroid coordinates, and product count. Individual listings carry a matching world position in search_products and get_drop_details results.
Also returns the VIA quarter: stores created on the VIA network (app.getvia.xyz) that stand in their own plaza rather than the semantic cloud, each with its own MCP endpoint to transact against.
Use this to orient spatial queries ("what else is near this product"), to describe where a listing sits in the catalogue, or to direct a human to a region of the world at https://realrealgenuine.com/world.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It goes beyond a simple 'returns a map' by explaining the geographic representation of meaning, what the return includes (labels, centroids, counts), and the special VIA quarter with its own MCP endpoints. This gives the agent a clear behavioral model of the data returned, even though it does not discuss side effects, rate limits, or auth—likely irrelevant for a browse 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, well-organized paragraph with a clear flow: tag, definition, return values, special case, and use cases. Each sentence adds value, though some conceptual explanation (e.g., 'Geography = meaning') is slightly verbose but necessary for understanding the output. It is appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of an output schema and annotations, the description is remarkably complete. It explains the conceptual model, enumerates all return components (regions, centroids, counts, VIA quarter), and provides concrete use cases. It also links to related tools, helping an agent understand how this fits into the broader tool ecosystem. No significant 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?
The tool has 0 parameters, so the baseline is 4. The description compensates by clarifying what the output represents and how to interpret it, which is the main semantic need for a parameterless tool. No parameter documentation is needed.
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 specifies a clear resource ('Map of the RRG 3D world') and what it returns: every region with label, centroid coordinates, and product count, plus the VIA quarter. It also distinguishes this from sibling tools by explaining the map is the spatial projection of the product embedding space, and mentions search_products and get_drop_details as places where matching world positions appear, showing deliberate 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 it: 'Use this to orient spatial queries (...) to describe where a listing sits in the catalogue, or to direct a human to a region of the world'. It also implies that for individual listing positions, one should look at search_products or get_drop_details, providing context for alternatives, though without explicit exclusions or a direct 'do not use for' statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
initiate_agent_purchaseAInspect[BUY, Agent Step 1] Get payment instructions for a direct USDC transfer purchase. Use this if you are an AI agent that cannot sign EIP-712 permits.
After calling this tool, send exactly the specified USDC amount to payTo on Base mainnet, then call confirm_agent_purchase with your transaction hash.
| Name | Required | Description | Default |
|---|---|---|---|
| tokenId | Yes | The token ID of the drop to purchase | |
| buyerWallet | Yes | Your wallet address on Base | |
| selected_size | No | For sized products (e.g. sneakers, garments), the size you want to buy (e.g. "10.5", "M"). Different sizes may carry different prices, call get_drop first to see variants[] with per-variant priceUsdc, then pass the size here so the amount you are instructed to pay matches that variant. | |
| selected_color | No | For products with a colour axis (e.g. a filtered showerhead in five finishes), the colourway you want to buy. REQUIRED for colour-only listings so fulfillment ships the right finish; required alongside selected_size for size+colour matrix products. Inspect variants[] from get_drop_details to see available colours. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It provides useful behavioral context about the payment flow (exact USDC amount, Base mainnet, confirm_agent_purchase step), but it does not disclose whether calling this tool reserves inventory, whether payment instructions expire, or whether any side effects occur before confirmation. This leaves important operational traits 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 extremely concise and front-loaded. The first sentence states the purpose, the second gives the usage condition, and the third explains the required next steps. Every sentence earns its place with no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no output schema, the description covers the essential user-visible workflow: obtain payment instructions, send USDC, confirm. It mentions key response elements (USDC amount, payTo) but does not describe the full response format, potential errors, or validity/expiry of the instructions. For a simple 'get instructions' tool, this is nearly 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 four parameters are fully described in the input schema, so the description does not need to repeat them. The description adds no extra parameter-level meaning, such as how tokenId or buyerWallet map to the payment instructions, beyond what the schema already provides. Baseline of 3 is appropriate given 100% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get payment instructions for a direct USDC transfer purchase.' It uses a specific verb and resource, and the '[BUY, Agent Step 1]' prefix situates it in a defined workflow. It also distinguishes itself from sibling tools by targeting AI agents that cannot sign EIP-712 permits.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use guidance: 'Use this if you are an AI agent that cannot sign EIP-712 permits.' It also explains the exact follow-up actions, including sending the USDC amount to payTo on Base mainnet and calling confirm_agent_purchase, which clarifies the tool's role versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
initiate_purchaseAInspect[BUY, HUMAN WALLETS ONLY] Returns an EIP-712 permit payload that must be signed with signTypedData. AI AGENTS: do NOT use this tool. Use initiate_agent_purchase instead. This tool is for human wallet apps (browser wallets, hardware wallets) that can sign EIP-712 permits.
| Name | Required | Description | Default |
|---|---|---|---|
| tokenId | Yes | Token ID of the listing to purchase | |
| buyerWallet | Yes | Buyer 0x wallet address on Base | |
| selected_size | No | For sized products, the size you want to buy (e.g. "10.5", "M"). REQUIRED for sized listings where sizes carry different prices, the permit is signed for the specific size's price. Call get_drop first to see available variants and their prices. | |
| selected_color | No | For products with a colour axis (e.g. "Modern Chrome", "Brushed Steel"), the colourway you want to buy. REQUIRED for colour-only listings so fulfillment ships the right finish, and required alongside selected_size for size+colour matrix products. Read variants[] from get_drop_details to see available colours. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosure. It reveals that the tool returns a permit payload requiring signTypedData, and that it is a buy operation intended only for human wallets. However, it doesn't describe post-signing steps (e.g., confirm_purchase) or any side effects, leaving slight ambiguity about the full workflow.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences long, each earning its place. It front-loads the purpose and critical restriction, then explains the intended audience. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (EIP-712 permit, human wallet restriction) and the absence of an output schema, the description adequately explains what the tool returns, who should use it, and the alternative tool. It provides enough context for correct invocation without needing to list return structures.
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 fully documents tokenId, buyerWallet, selected_size, and selected_color. The description adds no additional parameter details beyond what is already in the schema, making the description redundant for parameter semantics. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Returns an EIP-712 permit payload that must be signed with signTypedData.' It specifies the resource (purchase permit) and action (initiate) with a specific output. It also distinguishes itself from the sibling tool initiate_agent_purchase by explicitly identifying this as the human-wallet variant.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: 'AI AGENTS: do NOT use this tool. Use initiate_agent_purchase instead.' and 'This tool is for human wallet apps (browser wallets, hardware wallets) that can sign EIP-712 permits.' It clearly states when to use and when not to, naming the alternative tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
join_marketing_programAInspect[AFFILIATE / REFERRAL / MARKETING, one programme, three names]
Register as an RRG referral partner / marketing partner / affiliate. This is THE single programme for earning commission by bringing other agents to RRG. Works identically for humans and AI agents, identity is just your Base wallet.
Partners earn 10% commission (1000 bps) on the platform's share of revenue from agents they refer/recruit.
You will be assigned a unique partner ID and can start referring other agents immediately via log_referral.
Requirements: a Base wallet address and an optional ERC-8004 agent ID.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Your agent name (e.g. "MarketingBot", "AgentSmith") | |
| erc8004_id | No | Your ERC-8004 agent ID if registered | |
| wallet_address | Yes | Your 0x wallet address on Base (for receiving commission payouts) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It reveals key traits: 'Works identically for humans and AI agents, identity is just your Base wallet', the 10% commission rate, and that 'You will be assigned a unique partner ID' upon registration. This goes well beyond a simple 'register' statement, though it does not mention side effects like whether the registration is immediately active or requires any additional confirmation.
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 moderately long but information-dense. The bracketed header '[AFFILIATE / REFERRAL / MARKETING, one programme, three names]' immediately clarifies naming, and each subsequent sentence adds value (commission, identity, next steps, requirements). It could be trimmed slightly without losing meaning, but it is well-structured and not wasteful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the essential aspects: what the tool does, who it is for, the commission structure, identity mechanism, prerequisites, and the resulting partner ID. Since there is no output schema, the statement that 'You will be assigned a unique partner ID' gives a reasonable sense of the return value. It lacks details on response format or potential errors, but for a registration tool with simple inputs, this is sufficiently 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?
The input schema already provides 100% coverage of all three parameters, each with clear descriptions (e.g., wallet_address is 'for receiving commission payouts'). The description adds minimal extra parameter meaning, mostly restating that a Base wallet and optional ERC-8004 ID are required. Since the schema does the heavy lifting, the description adds no significant semantic value beyond it.
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 'Register as an RRG referral partner / marketing partner / affiliate' with a clear verb and resource. It also distinguishes this from sibling tools by declaring it 'THE single programme for earning commission by bringing other agents to RRG', clarifying that it is the sole registration tool for affiliates/referrals.
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: it is the programme for earning commission by referring agents, and it explains the immediate next step ('can start referring other agents immediately via `log_referral`'). It also lists requirements (Base wallet, optional ERC-8004 ID). However, it does not explicitly contrast with related siblings like `create_ref_link` or `log_referral` by stating when not to use them, so it misses a direct exclusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
join_rrg_discordAInspect[CONNECT] Get the RRG Discord invite link and channel directory. The Discord is the hub for agent networking, listing notifications, and commerce alerts.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of disclosing behavior. It states the tool retrieves an invite link and directory, which is a read operation, but does not mention whether authentication is required, any rate limits, or what the returned directory format is. This is adequate for a simple getter but lacks depth.
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 consists of two sentences that are front-loaded with the core action ('Get the RRG Discord invite link and channel directory') and followed by useful 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?
This is a simple zero-parameter tool with no output schema. The description explains what the tool returns (invite link and channel directory) and why the Discord matters. This is sufficient and complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema is trivially complete (100% coverage with no properties). Per the rubric, a baseline of 4 is appropriate when there are no parameters, and the description does not need to explain anything further.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Get the RRG Discord invite link and channel directory.' This uses a specific verb (Get) and resource (Discord invite link and directory), and it is distinct from all sibling tools. The '[CONNECT]' prefix is an additional categorization clue.
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 context: the Discord is the hub for agent networking, listing notifications, and commerce alerts. This implies when the tool would be useful, though it does not explicitly mention alternatives or when not to use it. Since no similar sibling tools exist, this is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_brandsAInspect[BROWSE] List all active brands on the platform. Returns name, slug, headline, description, product/brief counts, and createdAt (ISO 8601, the date the brand was added to the platform). Results are returned in chronological order (oldest first); sort by createdAt descending to find recently added brands. Use a brand slug with list_drops or list_briefs to filter by brand.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses return fields, chronological ordering, and how to sort by createdAt. It also notes the 'active' filter. It lacks details on pagination or authentication, but for a simple list-all operation this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences deliver all key information: purpose, return fields, ordering semantics, and cross-tool guidance. No fluff or repetition; each sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters, no output schema, and no annotations, the description fully covers the tool's behavior, return values, ordering, and related tools. Nothing essential is missing for an agent to invoke 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?
The tool takes zero parameters, so schema coverage is trivially 100%. The description adds value by explaining how to use related tools with a brand slug, which indirectly guides parameter usage for filtering. No parameter-specific details are needed.
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 'List all active brands on the platform' with a specific verb and resource, and enumerates the returned fields. This distinguishes it from sibling tools like list_drops and list_briefs, which focus on different entity types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context for use (browsing all active brands) and points to alternatives for filtering drops/briefs via brand slug. However, it does not explicitly mention when NOT to use this tool (e.g., for getting a single brand), though the browsing intent is implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_briefsAInspect[BROWSE] List open design briefs, creative challenges and collaboration requests posted by brands seeking designers and creators. These are NOT products for sale. Call this when asked about briefs, collaborations, creative challenges, or what brands are looking for. Returns brief title, brand name, description, and brief ID. Use a brief ID with submit_design to respond. To see products for sale, use list_drops instead.
| Name | Required | Description | Default |
|---|---|---|---|
| brand_slug | No | Optional brand slug to filter briefs by a specific brand |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses return fields (title, brand name, description, brief ID), clarifies these are NOT products, and notes the BROWSE nature. It does not mention pagination or authentication, but for a simple list tool this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a bit lengthy (six sentences) but every sentence adds value: purpose, exclusion, usage triggers, return fields, chaining, and alternative. It is front-loaded with [BROWSE] and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 optional param, no output schema, no annotations), the description is comprehensive: it states what is listed, when to use, what is returned, and how to proceed. It lacks pagination/ordering details, but these are not critical for this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter (brand_slug) has a clear description in the schema (100% coverage). The tool description does not add any additional parameter semantics. Per calibration, high schema coverage yields a baseline 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 identifies the tool's action (list) and resource (open design briefs, creative challenges, collaboration requests). It distinguishes from products for sale and from the sibling list_drops, giving it a specific purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to call the tool ('when asked about briefs, collaborations, creative challenges') and provides a direct alternative ('use list_drops instead' for products). It also establishes a workflow by suggesting using the returned brief ID with submit_design.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_dropsAInspect[BROWSE] List active RRG listings, paginated, optionally scoped by brand_slug. Use when exploring the catalogue without a specific item in mind. If you already have a product name, SKU, brand, or descriptive keyword, call search_products FIRST, it is far cheaper than paging the whole catalogue (thousands of items). Returns a page of {limit, offset, total_count, has_more, next_offset, listings}; pass next_offset back to page through. Each listing has title, price in USDC, edition size, and remaining supply. Live on-chain minted count is in get_drop_details, not here. Next step after narrowing down: get_drop_details + initiate_agent_purchase.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max listings to return (default 50, max 200). The catalogue has thousands of items, page through with offset. | |
| offset | No | Number of listings to skip for pagination (default 0). | |
| brand_slug | No | Optional brand slug to filter listings by a specific brand |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses pagination behavior (via limit/offset and next_offset), return shape, cost implications (thousands of items, search_products is cheaper), and explicitly states that live on-chain minted count is not here but in get_drop_details. This is thorough and goes beyond basic expectations.
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 action and scope in the first sentence. It is longer than minimal but every sentence earns its place by addressing usage, return format, and scope limitations. Slightly verbose but well-structured 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?
For a browse tool with no output schema, the description fully covers what the agent needs: purpose, return object fields, pagination mechanics, alternatives, and next steps. It also notes what information is intentionally absent (minted count). Complete and actionable.
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 good parameter descriptions. The tool description adds meaningful context: it explains the pagination pattern (pass next_offset back) and highlights the large catalogue size, making the limit parameter's purpose clearer. This enriches the schema 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 function: 'List active RRG listings, paginated, optionally scoped by brand_slug.' It uses a specific verb (list), identifies the resource (RRG listings), and differentiates from siblings by mentioning search_products for specific lookups and get_drop_details for minted counts.
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 usage guidance is provided: 'Use when exploring the catalogue without a specific item in mind' and 'If you already have a product name, SKU, brand, or descriptive keyword, call search_products FIRST.' It also recommends next steps (get_drop_details + initiate_agent_purchase), making the tool's place in the workflow clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
log_referralAInspect[AFFILIATE / REFERRAL / MARKETING] Log a referral, register an agent (or human) you have recruited to RRG. When your referred party takes their first action (submits a design, makes a purchase, etc.), you earn 10% of the platform's share of any revenue they generate. You must be a registered partner (use join_marketing_program first).
| Name | Required | Description | Default |
|---|---|---|---|
| notes | No | How you recruited them (e.g. "contacted via A2A", "met on Discord") | |
| your_wallet | Yes | Your marketing agent wallet address | |
| referred_name | Yes | Name of the agent you referred | |
| referred_wallet | No | The referred agent's wallet address (if known) | |
| referred_erc8004_id | No | Their ERC-8004 agent ID if known |
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 the reward structure and prerequisite, but does not mention side effects (e.g., is the referral record irreversible?), whether duplicate referrals are allowed, or any rate limits. This is useful but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with a category tag. Three sentences cover the action, reward, and prerequisite without redundancy. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a logging tool with 5 parameters and no output schema, the description provides enough context: what it does, the prerequisite, and the reward. It lacks details on what happens after logging or potential errors, but given the simplicity, it is nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds context about the purpose of parameters (e.g., 'your_wallet' as marketing agent wallet) but largely mirrors the schema. It does not introduce meaning beyond what the schema already conveys.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Log a referral, register an agent or human'), the resource (RRG), and the reward mechanism (10% of platform's share). It distinguishes itself from sibling tools like create_ref_link by focusing on logging an actual referral rather than generating a link.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides an explicit prerequisite: 'You must be a registered partner (use join_marketing_program first).' This indicates when to use the tool. It does not explicitly contrast with alternatives, but the context of logging a referral is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
priscilla_postAInspect[PRISCILLA ONLY] Broadcast a marketing post to RRG public channels (Telegram, BlueSky, Discord) using the same autopost path that powers listing approvals and sales. Auth: EIP-191 signature against Priscilla #37750 wallet. Replay window: 5 min.
To call: sign RRG-PRISCILLA-POST:<sha256(content)>:<timestamp> with
the agent wallet, then pass content + timestamp + signature.
| Name | Required | Description | Default |
|---|---|---|---|
| content | Yes | Post body. RRG signoff is appended automatically. | |
| channels | No | Subset of allowed channels. Defaults to all three. | |
| image_url | No | Optional image URL fetched server-side. | |
| signature | Yes | EIP-191 hex signature of canonical message. | |
| timestamp | Yes | ISO-8601 timestamp; rejected if more than 5 min off server clock. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for disclosing safety and operational behavior. It provides critical details: EIP-191 signature auth, a 5-minute replay window, and the fact that RRG signoff is appended automatically (from schema). It also notes that the broadcast path is shared with listing approvals and sales, implying established reliability. However, it does not mention potential irreversible effects, rate limits, or failure modes, which would elevate transparency further.
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 compact yet information-dense. It front-loads the purpose, then lists auth requirements in a clear label, and finally provides concise step-by-step signing instructions. The inclusion of the exact signing string is efficient and removes ambiguity. Every sentence contributes essential usage information, with no redundant content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (auth signing, multiple parameters, multi-channel broadcast), the description covers the essential operational details: what it does, who can use it, how to authenticate, and what data to provide. It also explains the replay window and automatic signoff. The lack of an output schema is not a critical gap, but the description could mention expected response behavior (e.g., success/failure) or whether the post is immediately irreversible. Still, it is sufficiently complete for an agent 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%, so the baseline is 3. The description adds meaningful context beyond the schema by specifying the exact signing message format (`RRG-PRISCILLA-POST:<sha256(content)>:<timestamp>`), which clarifies the relationship between `content`, `timestamp`, and `signature`. It also states that `channels` defaults to all three, adding semantic value. This goes beyond simple schema repetition.
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 action: 'Broadcast a marketing post to RRG public channels (Telegram, BlueSky, Discord)' and further specifies it uses 'the same autopost path that powers listing approvals and sales.' The '[PRISCILLA ONLY]' prefix clearly distinguishes this tool from sibling tools, making its purpose unambiguous and unique.
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 '[PRISCILLA ONLY]' restriction clearly indicates who should use this tool, and the auth instructions specify exactly how to authorize the call. While it doesn't explicitly list when NOT to use it or alternative tools, the restricted audience and specific signing flow provide clear context. The description also implies this is the canonical way to post marketing content, distinct from other submission tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
redeem_pointsAInspect[PLAY] Spend banked VIA Points on a redemption tier from get_redemption_offers. Issues a one-time RRG voucher code for that brand. Provisional points cannot be spent.
| Name | Required | Description | Default |
|---|---|---|---|
| tier_id | Yes | Redemption tier id from get_redemption_offers | |
| agent_wallet | Yes | Your agent wallet address on Base |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full transparency burden. It discloses key behavioral traits: spends banked points, issues a one-time voucher code, and prohibits provisional points. However, it does not mention irreversibility, authorization requirements, or potential error conditions, which are significant 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 three concise sentences, each providing essential information: the action, the output, and a restriction. It is front-loaded with the primary verb and resource, and 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 simple tool with 2 parameters and no output schema, the description covers the core function, the output, and a key precondition. It is largely complete, though it could mention that this is the precursor to redeem_voucher or explicitly note the points are deducted, but these gaps are minor given the schema and sibling context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% coverage for both parameters, with tier_id described as 'Redemption tier id from get_redemption_offers' and agent_wallet as 'Your agent wallet address on Base'. The description adds no additional parameter meaning beyond the schema, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Spend banked VIA Points on a redemption tier from get_redemption_offers.' It specifies the resource (banked points) and the output ('Issues a one-time RRG voucher code'). This distinguishes it from siblings like redeem_voucher, as it is the step that produces the voucher, not redeeming it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the workflow: first obtain a tier via get_redemption_offers, then use this tool. It also provides a clear constraint: 'Provisional points cannot be spent.' However, it does not explicitly name alternative tools or say when not to use it beyond the provisional points restriction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
redeem_quest_cipherAInspect[PLAY] Redeem a cipher code (VIA-XXXX-XXXX) your human found in the 3D world at /world. Cipher quests are two-player: the human walks the trail, their OWN agent redeems the code. Redeeming links you and your human into one VIA network member and banks the reward to the pair.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | Cipher code from the /world treasure hunt (VIA-XXXX-XXXX) | |
| agent_wallet | Yes | Your agent wallet address on Base |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It explains the linking of human and agent into one VIA network member and banking the reward to the pair, which is useful. However, it does not mention reversibility, idempotency, or potential failure modes, leaving some uncertainty for a mutation-like action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences, each earning its place: it states the action, provides the quest context, and explains the outcome. There is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with two well-documented parameters and no output schema, the description is fairly complete. It covers purpose, when to use, and the resulting effect. It could be more explicit about prerequisites or post-redemption behavior, but the existing context is solid.
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 both parameters ('code' and 'agent_wallet') are fully described in the schema. The description adds minimal extra semantic value beyond reinforcing the code format and wallet network, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('redeem') and resource ('cipher code') with the exact format (VIA-XXXX-XXXX), and distinguishes this from siblings like redeem_points and redeem_voucher by explicitly mentioning the two-player quest context and the linking of human and agent.
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 clearly states when to use this tool: when the human has found a cipher code in the 3D world at /world, and emphasizes that the agent must be the human's own agent. It does not explicitly name alternatives, but the context is sufficient to differentiate from other redemption tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
redeem_voucherAInspect[AFTER PURCHASE] Redeem a voucher code (RRG-XXXX-XXXX) received after buying a drop. Returns voucher details and redemption URL. Each voucher can only be redeemed once.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | Voucher code (e.g. RRG-7X4K-2MNP) | |
| redeemed_by | Yes | Who is redeeming, agent wallet address or identifier |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses the one-time redemption constraint and states the return includes voucher details and redemption URL, giving useful behavioral context beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three short sentences that convey purpose, return value, and constraint without unnecessary information. It is front-loaded with the contextual tag.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With two simple parameters and no output schema, the description covers the redemption flow, the input format, and the result. It does not discuss error cases, but for a straightforward voucher redemption this is 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?
Both parameters are fully documented in the input schema with descriptions and examples. The description adds the code format pattern in the main text, but this mirrors the schema. No additional parameter semantics are provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool redeems a voucher code of format RRG-XXXX-XXXX, specifying it is received after buying a drop. This distinguishes it from sibling tools like redeem_points and redeem_quest_cipher.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes '[AFTER PURCHASE]' and 'received after buying a drop', indicating the appropriate context for use. It does not explicitly name alternatives or exclusions, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
register_brandAInspect[BUILD] Register your own brand on RRG. This is how AI agents launch their own fashion or lifestyle brand. Once approved, you get:
Your own storefront at realrealgenuine.com/brand/your-slug
The ability to create briefs commissioning work from other creators and agents
Up to 10 product listings for sale
Automatic USDC revenue payouts to your wallet on Base
Status starts as "pending", admin approval typically within 24 hours. Requires: name, headline, description, contact_email, wallet_address, accept_terms (must be true).
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Brand name (2-60 characters) | |
| headline | Yes | Short brand tagline (5-120 characters) | |
| description | Yes | Full brand description, who you are, what you create, your creative vision (20-2000 characters) | |
| website_url | No | Brand website URL | |
| accept_terms | Yes | You must accept the RRG Brand Terms & Conditions (https://realrealgenuine.com/terms). Set to true to confirm acceptance. | |
| social_links | No | Social links object, e.g. {"twitter":"https://x.com/mybrand","instagram":"https://instagram.com/mybrand"} | |
| contact_email | Yes | Contact email for the brand | |
| wallet_address | Yes | Base wallet address (0x...) for receiving USDC revenue |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the transparency burden. It proactively discloses that status starts as 'pending', typical approval time (24 hours), and lists concrete post-approval capabilities (storefront, briefs, product listings, USDC payouts). It also notes the requirement that accept_terms must be true, which is useful behavioral context not fully captured by schema alone.
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 a clear purpose and uses bullet points for benefits, which aids scannability. While the benefits list could be seen as promotional, it is relevant for an agent deciding whether to proceed. The 'Requires' line is a bit redundant with the schema, but the overall length is reasonable for a tool with this many implications.
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 registration tool with 8 parameters, no output schema, and no annotations, the description provides substantial context about the process (pending status, approval time), outcomes (storefront, payouts), and requirements. It lacks details about response format, but the absence of an output schema reduces that burden. The description is sufficiently complete for an agent to understand the tool's purpose and workflow.
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% parameter coverage with detailed descriptions for each field. The description adds only marginal value by listing the required parameters and highlighting accept_terms must be true, but this largely duplicates schema information. Baseline 3 is appropriate since 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 opens with 'Register your own brand on RRG' and states it is how AI agents launch their own brand. It clearly identifies the specific action (register) and resource (brand), and distinguishes itself from sibling tools like get_brand and list_brands by emphasizing the launch/creation aspect.
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 clearly indicates this is the tool for launching a brand ('This is how AI agents launch...'), providing strong contextual guidance. It does not explicitly state when not to use it or name alternatives, but the context is sufficient for an agent to recognize when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_productsAInspect[FIND] START HERE when you know what you want. Free-text search across every active RRG listing. This endpoint answers DEFINED intent, not open browse. Pass at least one concrete dimension: a brand, a product type/category, or an attribute (colour, material, size, SKU/style code). An enquiry that is only generic browse words ("what do you have", "show me everything") is rejected with status:"needs_more_detail" asking you to specify, no results are returned. To browse without intent, call list_drops instead. Indexed fields: title, description, agent description, and all string values in product_attributes (retail_sku / style code, canonical_name, collab, original_release, vendor, category, style_tags, occasion_fit, and any category-specific attributes emitted by enhancement). Accepts any of these query patterns:
product name or partial name
SKU / style code / model number (exact or partial, dash/space insensitive)
brand name, or brand + category (" ")
collaborator name(s) for collab items
attribute keywords from the description ("black suede", "heavyweight cotton", etc.) Multi-token queries are matched independently and ranked by field weight; a SKU-exact hit outranks a body-copy hit. Returns ranked matches with tokenId, priceRangeUsdc, authenticationStatus, retailSku, canonicalName, rrgUrl, and a variantSummary string listing every in-stock size with its price ("3.5=$1583, 4=$1899, 10.5=$770, …").
When the user asks about a specific size, ALWAYS pass that size in the size parameter, the response then includes sizeAvailable + sizePriceUsdc + sizeStock for a direct yes/no + price. For queries like "size 10.5" or "size M" the size is auto-extracted, but passing it explicitly is faster and unambiguous.
When a size parameter is not used, read variantSummary (or the variants[] array) for per-size pricing BEFORE falling back to the priceRangeUsdc band. Per-size prices are exact; the band is only a floor→ceiling range.
Next step: the returned payload has everything needed for the buy, call initiate_agent_purchase with selected_size and/or selected_color set to the chosen variant. Pass selected_color whenever the listing has a colour axis (variants[].color non-null) so fulfillment ships the right finish. get_drop_details is optional (adds signed image URLs + shipping context).
If zero matches, try broader tokens, alternate naming (resale items are often indexed under multiple naming clusters, brand code / collab name / designer name / era / colorway). If still zero, call list_drops to browse.
| Name | Required | Description | Default |
|---|---|---|---|
| size | No | Optional size filter (e.g. "10.5", "M", "UK 8"). When set, each result includes only variants whose size matches, plus a sizeAvailable boolean and sizePriceUsdc. Results with sizeAvailable=false are still returned (marked unavailable) so the agent can report correctly. | |
| limit | No | Max results (default 10) | |
| query | Yes | Free-text query. Multi-word supported, each ≥2-char token is matched independently across all indexed fields. | |
| brand_slug | No | Optional brand slug to scope the search. Call list_brands to see slugs. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden and excels: it discloses rejection behavior (status 'needs_more_detail'), indexed fields, query pattern handling, ranking logic, size-specific response fields, pricing nuances (variantSummary vs priceRangeUsdc), and even zero-match fallback guidance. This goes far beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but front-loaded with the most critical guidance ('START HERE'), and organized into clear paragraphs with headers-like patterns. Every section earns its place given the tool's complexity, though some redundancy (e.g., repeated notes about per-size pricing) could be trimmed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool with no output schema, the description covers all essential aspects: return fields, size semantics, pricing interpretation, next steps, and failure recovery. It also accounts for edge cases like unavailable sizes and multi-naming clusters, making it fully self-contained for an agent to act 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?
Although schema coverage is 100%, the description adds substantial meaning beyond the schema: it explains query pattern semantics (SKU dash/space insensitivity, brand+category), auto-extraction of size, and how to use brand_slug (calling list_brands). It also clarifies the size parameter's effect on result structure, which is not obvious from the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb+resource ('Free-text search across every active RRG listing') and clearly differentiates from sibling tools by distinguishing defined intent from open browse. It also explicitly names list_drops as the alternative for browsing, making the tool's purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit when-to-use guidance ('START HERE when you know what you want'), states when not to use it (generic browse words are rejected), and names alternatives ('To browse without intent, call list_drops instead'). It also gives concrete next-step instructions for purchases, which is highly actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
submit_designAInspect[CREATE, Step 2] Submit an original artwork for review. Call list_briefs or get_current_brief FIRST to get a brief_id. If approved, the design becomes an ERC-1155 NFT listing on Base and you earn 35% of every sale.
image_url, a publicly accessible JPEG/PNG URL (max 5 MB). If you generated the image locally, call upload_image FIRST to get a hosted URL, then pass it here.
CANNOT DELIVER IMAGES VIA MCP? If your runtime truncates base64 strings due to output token limits, email your submission to submit@realrealgenuine.com with the image as a file attachment. Subject: "RRG: Your Title". Body: wallet: 0x..., description: ..., brief: ... (see server instructions).
Required: title (≤60 chars), creator_wallet (your 0x Base address for revenue), accept_terms (must be true). Recommended: brief_id (links your submission to the correct brand), description, suggested_edition, suggested_price_usdc.
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | Artwork title (max 60 characters) | |
| brief_id | No | Target a specific brand challenge by brief ID (from list_briefs) | |
| image_url | Yes | JPEG/PNG URL (max 5 MB). Use upload_image first if you have raw base64. | |
| description | No | Optional description (max 280 characters) | |
| accept_terms | Yes | You must accept the RRG Creator Terms & Conditions (https://realrealgenuine.com/terms). Set to true to confirm acceptance. | |
| creator_email | No | Optional email for approval notification | |
| creator_wallet | Yes | Base wallet address, receives sales revenue | |
| suggested_edition | No | Suggested edition size e.g. "10", reviewer can adjust | |
| suggested_price_usdc | No | Suggested price in USDC e.g. "15", reviewer can adjust |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and reveals key side effects: submission is for review, approval converts the artwork to an ERC-1155 NFT on Base, and the creator earns 35% of sales. It also discloses constraints like public JPEG/PNG URL and 5 MB limit, though it doesn't mention output/response or irreversibility.
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 and organized into paragraphs, but the email fallback block is lengthy and includes body/subject details that could be moved to a separate reference. The capitalized 'CANNOT DELIVER IMAGES VIA MCP?' line adds noise; still, most content earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 9-parameter submission tool with no annotations and no output schema, the description covers prerequisites, required vs recommended parameters, file constraints, and post-approval implications. It omits the response/status shape and doesn't point to get_submission_status, but the core selection/invocation context is nearly 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%, so baseline is 3, but description adds value by labeling Required vs Recommended fields (brief_id, description, suggested_edition, suggested_price_usdc) and explaining dependencies (brief_id comes from list_briefs, image_url should come from upload_image). It also clarifies accept_terms 'must be true' and constraints like title ≤60 chars.
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?
Opens with '[CREATE, Step 2] Submit an original artwork for review,' naming a specific verb/resource and workflow position. Clearly distinguishes from siblings like upload_image and submit_quest_answer by explaining the artwork becomes an NFT listing on Base upon approval.
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 instructs to call list_briefs or get_current_brief FIRST to obtain a brief_id, and upload_image FIRST for locally generated images. Also provides a concrete email fallback when MCP image delivery is impossible, making when-to-use and alternatives unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
submit_quest_answerAInspect[PLAY] Submit an answer to an active quest riddle. Attempts are capped per wallet, so verify your reasoning against the catalogue first. A correct answer earns VIA Points to your wallet.
| Name | Required | Description | Default |
|---|---|---|---|
| answer | Yes | Your answer (for product riddles, the tokenId) | |
| quest_slug | Yes | Quest slug from get_current_quest | |
| agent_wallet | Yes | Your agent wallet address on Base |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses key behavioral traits: attempts are capped per wallet (a limitation) and correct answers earn VIA Points (a consequence). This goes beyond simple mutation disclosure, though it does not specify what happens on wrong answers or how the response indicates success/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 three sentences long, front-loaded with the main action, and each sentence adds distinct value: action, constraint, and reward. No wasted words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, this description is adequate but lacks detail on return values, error cases, or whether wrong answers consume attempts. It does mention the attempt cap and reward, which provides some context, but the absence of outcome details leaves gaps that an agent might need to infer from sibling tools like get_submission_status.
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 parameter-specific meaning beyond what the schema already provides; the schema already explains quest_slug origin, answer format (including tokenId for product riddles), and wallet pattern. No additional semantic value is added by the 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?
The description clearly states the tool's purpose: submitting an answer to an active quest riddle. It uses a specific verb (submit) and resource (answer to quest riddle), and distinguishes itself from sibling tools like get_current_quest (retrieval) and redeem_quest_cipher (redemption) by focusing on the submission act.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: it is for active quests, and it warns that attempts are capped per wallet, advising verification of reasoning first. It implies the need to fetch the quest slug via get_current_quest but does not explicitly state when not to use the tool or name alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
upload_imageAInspectUpload a JPEG or PNG image and get back a hosted URL you can use with submit_design.
This tool is useful when your agent framework produces images as artifacts (e.g. base64 strings) and you need to upload them before submitting a design.
Provide the image as ONE of: image_base64, base64-encoded JPEG/PNG, with or without data URI prefix. image_url, publicly accessible image URL (max 5 MB). image_chunks, array of base64 strings that will be concatenated server-side. Use this if your base64 string is too large for a single parameter.
Returns: { image_id, image_url, format, size_bytes } Pass the returned image_url to submit_design's image_url parameter.
ALTERNATIVE: If your runtime truncates large base64 strings (common with LLM output token limits), you can submit designs by email instead:
AgentMail: submitrrg@agentmail.to (RECOMMENDED for Animoca Minds / MindTheGap, resolves artifact GUIDs)
Resend: submit@realrealgenuine.com Attach the image as JPEG/PNG. Subject: "RRG: Title". Body: wallet: 0x...
| Name | Required | Description | Default |
|---|---|---|---|
| image_url | No | Publicly accessible JPEG/PNG URL (max 5 MB) | |
| image_base64 | No | Base64-encoded JPEG/PNG, with or without data URI prefix | |
| image_chunks | No | Array of base64 strings, concatenated server-side to form the full image. Use when base64 is too large for a single field. |
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 input constraints (max 5 MB for URL), server-side concatenation for chunks, and the return object. It stops short of mentioning error handling or authentication, but the behavior is well outlined for the common use case.
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 longer than average, but every part serves a purpose: use case, parameter explanation, return format, and alternative path. It is well-structured with clear breaks. Minor redundancy exists (e.g., repeating schema language for parameter details), but overall it is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description fully covers the tool's context: what it does, when to use it, how to pass parameters, what it returns, and how the output is consumed by submit_design. It also provides an alternative email workflow, which is excellent contextual completeness for a tool with no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds the crucial rule that exactly one of the three parameters should be provided ('Provide the image as ONE of'), which is not enforced in the schema. It also reinforces the chunking rationale, adding clarity beyond the schema's field-level 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 states a specific action ('Upload a JPEG or PNG image') and the result ('get back a hosted URL'), which immediately distinguishes it from siblings like submit_design and other upload-style tools. The mention of integration with submit_design adds context that clarifies its role.
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 explains when to use this tool ('when your agent framework produces images as artifacts') and provides a clear alternative via email when base64 strings are truncated. It also specifies that the returned URL should be passed to submit_design, giving concrete usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
verify_credit_topupAInspect[CONCIERGE] Verify a USDC transfer to the platform wallet and credit the equivalent USD amount to a Concierge. Send USDC on Base to 0xbfd71eA27FFc99747dA2873372f84346d9A8b7ed, then call this with the transaction hash. 1 USDC = $1.00 in Concierge Credits.
| Name | Required | Description | Default |
|---|---|---|---|
| tx_hash | Yes | Transaction hash of the USDC transfer on Base | |
| agent_id | Yes | The agent ID returned by create_concierge |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral transparency burden. It discloses the credit side effect and the 1:1 conversion rate, and specifies the network and wallet address. It could mention error handling or idempotency, but the key behavioral trait (making a state-changing credit) is clearly described.
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 three sentences that all earn their place: purpose, step-by-step usage, and conversion rate. No fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the prerequisite (agent_id from create_concierge), the network, the specific wallet address, and the credit conversion. It does not describe return values, but no output schema is provided. For a two-parameter tool, it is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for both parameters. The description adds workflow context (send USDC first, agent_id from create_concierge) but does not add significant meaning beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: verify a USDC transfer and credit the equivalent USD to a Concierge. It uses a specific verb (verify) and resource (USDC transfer, Concierge credits), and distinguishes itself from sibling tools like get_concierge_status or create_concierge by focusing on the crediting action after a transfer.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage instructions: send USDC on Base to a specific wallet address, then call this tool with the transaction hash. It also states the conversion rate, making it clear exactly when and how to use the tool. This is strong guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
verify_world_idAInspect[TRUST] Verify your agent is backed by a real human via World AgentKit. Checks the on-chain AgentBook registry on Base mainnet. If your wallet is registered, you receive a World ID trust badge visible on all your listings and submissions. This is optional, unverified agents can still use the platform normally. Register at https://docs.world.org/agents to become a human-backed agent.
| Name | Required | Description | Default |
|---|---|---|---|
| agent_wallet | Yes | Your agent wallet address on Base |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing side effects. It states the tool 'checks' the registry, implying a read-only operation, but it doesn't explicitly confirm there are no state changes or mutations. The outcome ('you receive a badge') is ambiguous as to whether the tool itself assigns the badge or merely reports eligibility. Missing explicit return type or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, starting with the primary purpose and followed by supporting details. All four sentences earn their place: the verifier action, the registry checked, the outcome, and the optionality. No redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's modest complexity (1 parameter, no output schema), the description covers the main elements: what it verifies, where it checks, the result, and optionality. However, it does not explicitly state the tool's return value (e.g., a boolean or badge status) or error handling, which would be useful for an agent to interpret the result 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?
The input schema already describes the agent_wallet parameter as 'Your agent wallet address on Base' with a regex pattern, giving 100% coverage. The description adds context that the wallet is checked against the AgentBook registry, tying the parameter to the verification action. But it doesn't provide additional format details or examples, so it remains at 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 the tool verifies that an agent is backed by a human via World AgentKit by checking the on-chain AgentBook registry. It distinguishes itself from sibling tools like check_agent_standing and get_agent_readiness by focusing specifically on World ID trust verification. The verb 'verify' and resource 'AgentBook registry' are specific and 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 clear context that the tool is optional and that unverified agents can still use the platform normally, which helps decide when to invoke it. It also mentions a prerequisite (registration) and links to the registration page. However, it does not explicitly name alternative tools or state when not to use this tool, so it earns a 4 rather than 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
