VIA Network: Agentic Commerce

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

With no annotations provided, the description fully covers behavioral traits: forwarding to buyer MCP, auto-accepting within delegation caps, and queuing for approval otherwise. No contradictions.

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

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

The description is two sentences (25 words), concise and front-loaded with the main action. Every sentence adds value with 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 description explains the auto-accept/queue behavior well, it lacks information about the return value or what the agent can expect as a response. Given no output schema, the description should cover this gap.

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 each parameter having a description. The tool description adds no additional meaning beyond what the schema already provides, so a baseline score of 3 is appropriate.

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

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

The description clearly states the tool's function: asking a buyer's Buying Agent to accept a negotiated offer. It specifies the resource (buyer's Buying Agent) and action, distinguishing it from sibling tools like negotiate or counter_quote.

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 after negotiation but does not explicitly provide when-to-use or when-not-to-use guidance. It does not mention alternatives or conditions for choosing this tool over siblings.

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

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

Discloses that it answers in the seller's voice using locked-in memories. No annotations provided, so description carries burden. Lacks mention of side effects, authentication needs, or whether read-only.

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

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

Four sentences with no redundancy. Front-loaded with the key action and then adds detail. Every sentence adds value.

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

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

Covers purpose, parameter usage, and behavioral traits. Lacks mention of response format or potential limitations, but given no output schema and 3 simple params, 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?

Adds context beyond schema: seller_mcp_url from discovery result, contact as reach-back identifier. Schema descriptions already cover each parameter, but the description clarifies their origin and purpose.

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

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

Clearly describes the action (ask a question), the resource (seller's Sales Agent), and the context (anywhere on network, without leaving connector). Distinct from sibling tools like find_seller or buy_product.

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?

Specifies to pass seller_mcp_url from a discovery result and optional contact. Implies use after discovering a seller. Does not explicitly state when not to use or mention alternatives, but context is clear.

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

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

With no annotations, description fully discloses behavior: returns x402 payment requirement and order_ref, details settlement process (EIP-2612 permit or raw USDC transfer), and mentions rejection with missing fields.

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

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

Description is thorough but slightly verbose; however, every sentence adds necessary information and it is front-loaded with main purpose.

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

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

With no output schema, description compensates by explaining return value and settlement flow, and addresses different product types and prerequisites, making it complete for agent use.

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

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

Schema coverage is 90%, but description adds context like source of seller_mcp_url and product_id from mcp_ref, conditionality of delivery/attendee blocks, and requirement for buyer_country with shipping.

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 'Buy a listing from anywhere on the network, settled in USDC on Base' with specific verb (buy) and resource (listing), and distinguishes from sibling tool claim_pass for free passes.

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

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

Explicitly says when not to use ('Free passes are not bought here: use claim_pass'), provides prerequisite ('Call get_shipping_quote first'), and gives conditional instructions for physical vs event products.

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

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

No annotations provided, but description fully discloses behavior: no payment, no wallet, emails confirmation, notifies organizer, one pass per email/account. No contradictions.

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

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

Single well-structured paragraph with front-loaded main action. Every sentence adds value—no fluff, no repetition.

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 lacking output schema, description explains what happens (records place, emails, notifies organizer) and constraints (one per email/account, free only). Parameters are fully documented. Complete for a 5-param tool.

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

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

Schema covers all parameters with descriptions. Description adds context: source of product_id from find_seller/get_seller_products, and explains optional nature of buyer_wallet and buyer_agent_id.

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

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

Clearly states 'Claim a FREE entry pass' with specific verb and resource. Distinguishes from sibling tools like 'buy_product' by explicitly stating that this tool is for free passes only.

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

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

Explicitly states when to use (free tiers with price 0) and when not to use (paid products), providing a direct alternative: 'use buy_product (USDC via x402)'. No ambiguity.

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

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

No annotations are provided, so the description carries the full burden. It discloses the two-step process, the mint/payout/download flow, and special requirements for physical products. However, it does not detail potential failure modes or recoverability.

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

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

The description is a single paragraph of four sentences, front-loading the main action and then providing key details. It is fairly concise, though a bit dense; slight restructuring could improve readability.

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

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

Given no output schema and a complex tool with 9 parameters including a nested object, the description covers prerequisites, workflow, and special cases. It does not explain error handling or return values, but overall it provides sufficient context for correct invocation.

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

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

Schema coverage is 100%, so baseline is 3. The description adds significant value by explaining the role of tx_hash (USDC transaction), buyer_wallet (sender), selected_size and selected_color (must match buy_product), and buyer_email (required for physical products). This context greatly aids parameter understanding.

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: settling a network-MEMBER purchase after sending USDC. It distinguishes from sibling tools by explicitly stating that VIA-native purchases do not use this tool, and it references the prerequisite buy_product call.

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

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

The description provides explicit guidance on when to use: after sending USDC and calling buy_product. It also states when not to use: for VIA-native purchases. Alternatives are implied (e.g., the /api/x402/purchase endpoint).

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

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

No annotations are provided, so the description bears the full burden. It discloses that the action forwards to the seller, appends a round, and remains non-binding. It does not cover authentication or rate limits, but the core behavioral traits are well communicated.

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: first sentence states purpose and direction, second lists key parameters, third explains behavior. Front-loaded with no wasted words.

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

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

For a tool with 5 parameters, nested objects, and no output schema, the description covers purpose, usage, and behavioral outcome. It could mention prerequisites (e.g., existing quote) and return format, but overall is adequate.

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 high (80%). The description adds usage context beyond the schema: 'Pass the quote_ref and a target price, revised selections, or both.' However, 'note' and 'seller_mcp_url' are not described in the description, leaving some gaps.

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 'Counter an existing quote, forwarded to the owning seller.' It specifies the action (counter), resource (quote), and direction (to seller). This distinguishes it from siblings like accept_offer or request_quote.

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?

Description explains when to use: 'Pass the quote_ref and a target price, revised selections, or both.' It also clarifies outcome: 'Appends a round to the negotiation; stays non-binding until the seller approves.' However, it lacks explicit exclusions or comparisons to alternatives.

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

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

No annotations are provided, so the description carries full burden. It discloses that results are teasers with limited info, that full briefs require a micro-fee, and that ranking already considers full briefs. This is comprehensive and honest about limitations.

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 strategic bolding and line breaks. While it is longer, each sentence is purposeful and adds unique value (teaser details, fee info, ranking insight). Slightly verbose but not wasteful.

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

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

Given no output schema, the description adequately explains what is returned (fields of teaser). It covers the main workflow (search, teaser, unlock, offer). Lacks details on pagination, error handling, or edge cases, but for a simple list tool with 2 parameters, it 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 coverage is 100% (both limit and query described). The description adds meaningful context: query examples ('raw selvedge denim'), the option to omit query for browsing, and default/max for limit. This goes beyond the schema's basic 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 tool name and description clearly indicate it finds buyers based on demand. The description uses specific verbs ('Discover live DEMAND') and resource ('buyers'), and distinguishes from siblings like find_seller by focusing on active buyers.

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: search by what you have, or omit query to browse. It explains the teaser structure and the paid tier for full briefs. However, it does not explicitly state when this tool should not be used or list alternatives.

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

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

With no annotations, the description fully discloses behavior: response structure (results vs need_more_info), fields in results, null image_url possibility, and the rule to not silently pick one. All important behavioral traits are covered.

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

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

The description is longer than ideal but every sentence serves a purpose. It is front-loaded with the core purpose and progressively adds detail. A minor trim would not harm, but it remains efficient for its 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?

Without an output schema, the description clearly explains the return format (results with page_url, seller, price_usdc, image_url, mcp_ref) and the need_more_info response. All scenarios (match, no match, multiple matches) are addressed. No gaps.

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

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

Schema coverage is 100% with basic descriptions. The tool description adds value by giving concrete query examples and explaining the search scope beyond the schema. The limit parameter gains no additional context, but queries are well-illustrated.

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 searches the VIA network for products and sellers, combining product catalogue and seller profile matching. It distinguishes from sibling tools like list_sellers or get_product by blending both sources.

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 guidance on when to use (defined intent returns results, loose/no match returns need_more_info), how to present results (side-by-side with prices), and how to handle failures (ask one clarifying question, retry with broader term, never say nothing is available).

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

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

The description discloses that teasers are free and carry a paid door_url for full access, and that the tool does not provide full briefs or offer capability. With no annotations, this transparency adds significant value.

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 each serve a distinct purpose: defining the tool, explaining the paid component, and providing usage guidance. No unnecessary words or repetition.

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 a simple tool with one parameter and no output schema, the description covers input (implied), output (teasers with door_url), and the business process. It is fully complete for an agent to understand and use 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 single parameter is fully described in the schema as 'A buyer's mcp_url from a find_buyers result.' Schema coverage is 100%, so the description does not need to add extra detail; the schema already handles parameter semantics adequately.

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

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

The description clearly states the tool retrieves a buyer's open demand as free teasers. The verb 'see' and resource 'buyer's OPEN demand as free teasers' are specific, and the tool is easily distinguishable from siblings like find_buyers or get_buyer_preferences.

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

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

The description provides clear context that the tool is for initial screening: 'Use a teaser to decide if your stock fits, then go to the door.' It implies when to use and what to do after, though it lacks explicit exclusion or mention of alternatives.

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

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

No annotations are provided, so the description carries full burden. It discloses that delegation caps and private notes are never exposed, and implies a read operation (no mutation). This adds important behavioral context beyond just stating it's a read.

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-load the purpose and essential usage. Every sentence adds value: first explains what it does, second gives usage and a caveat. No wasted words.

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

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

For a simple tool with one parameter and no output schema, the description is complete enough. It covers purpose, usage, and a key behavioral limitation. A minor gap is not describing the response structure, but without output schema, this is acceptable.

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

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

Schema coverage is 100% for the single parameter. The description reinforces the schema's instruction ('Pass the buyer_mcp_url from a find_buyers result') but does not add new meaning beyond what the schema already provides.

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

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

The description clearly states 'Read a buyer's public buying preferences', specifying the verb (read) and the resource (buyer preferences). It distinguishes from siblings like get_buyer_briefs by focusing on preferences and mentioning forwarding to the buyer MCP.

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

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

The description provides explicit context: 'Pass the buyer_mcp_url from a find_buyers result', guiding when to use it. It does not explicitly exclude alternatives, but the instruction is clear enough.

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

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

No annotations are provided, so the description carries full burden. It discloses that the tool returns a message to sign and a challenge token, and that it forwards to the seller. However, it does not mention side effects, permissions, or error conditions, leaving some gaps.

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

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

Two sentences: the first states the purpose, the second states the return value and next step. No redundant words, very 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?

With 3 parameters, no output schema, and no annotations, the description covers the return value and the next call. It lacks details on the signing process and prerequisites, but is sufficient for a step in a sequence.

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 does not add meaning beyond the schema—it simply names the parameters (e.g., seller_mcp_url from discovery) without elaborating on their semantics or relationship.

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 'Begin retrieving a digital deliverable you bought'—a specific verb+resource pair—and distinguishes itself from the sibling 'get_download_links' by framing it as the first step. It also mentions forwarding to the owning seller, adding scope.

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 tells when to use this tool (when retrieving a purchased digital deliverable) and explicitly directs to call 'get_download_links' next. It does not list when not to use it, but the sequential context is clear.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions that links are time-limited and that a signature is required, but does not disclose potential side effects (e.g., no destructive action implied), error behaviors, or idempotency. This is adequate but not thorough.

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, conveying the purpose and prerequisite steps without any extraneous information. Every sentence earns its place—no fluff, efficient communication.

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

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

Given the tool has 5 required parameters and a multi-step workflow, the description explains the prerequisite but omits details about return values (e.g., format of download links) and potential error conditions. The lack of output schema increases the need for description completeness, which is partially met.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value by explaining the workflow: signing the challenge with the paying wallet before calling the tool. This contextual relationship between parameters (challenge, signature, buyer_wallet) goes beyond individual schema descriptions, justifying 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 explicitly states the tool retrieves time-limited download links for a specific digital product (bought and settled), with a clear action and resource. It distinguishes from siblings by referencing the prerequisite get_download_challenge tool, providing context for its specific 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?

The description provides clear step-by-step usage instructions: first call get_download_challenge, sign the message, then call this tool with the challenge and signature. It does not explicitly exclude other scenarios, but the prerequisite is clearly stated, guiding appropriate use.

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

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

No annotations provided, so description carries full burden. Discloses return content (option groups, choices, quantity rules, surcharges) and mentions forwarding to seller. Could be more explicit about being read-only, but 'fetch' implies that.

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 purpose, no redundant information.

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

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

No output schema, but description explains return structure. Addresses edge case (fixed-price products). Differentiates well among 26 siblings.

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 description adds little beyond schema. It provides context for seller_mcp_url being from discovery, but 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?

Description clearly states verb (Fetch), resource (configurable option space for a per-order product), and distinguishes from buy_product for fixed-price products.

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

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

Explicitly states when to use (before requesting a quote for configurable products) and when not to (fixed-price products, use buy_product). Also mentions forwarding to seller.

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

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

Discloses that the tool forwards to the owning seller (network call) and that it returns price, stock, and purchase requirements. No annotations existed, so description fully covers behavioral traits.

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

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

Two sentences with critical information front-loaded. First sentence states core purpose, second gives parameter guidance and return info, third explains forwarding and buy loop. 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?

Despite no output schema, the description fully explains the tool's role in a multi-step buy flow, parameter provenance, and what the response contains. Complete for a single-listing detail fetch tool.

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

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

Schema description coverage is 100%, but the description adds value by specifying the exact source of the parameter values (mcp_ref.seller_mcp_url and mcp_ref.product_id from discovery results), which is not in the schema.

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

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

The description uses specific verb 'Fetch' and resource 'full detail for ONE listing', clearly distinguishing it from sibling tools like find_seller or get_seller_products by focusing on purchase intent. It also positions itself within a buying workflow.

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

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

Explicitly states when to use ('before buying'), how to pass parameters ('exactly as they appear in find_seller / get_seller_products result'), and places the tool in a sequence (get_product -> get_shipping_quote -> buy_product). Provides both usage context and alternative steps.

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

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

No annotations provided, so the description carries the full burden. It mentions forwarding to the seller but doesn't disclose if the operation is read-only (idempotent, no side effects). Returns are listed but safety profile is unclear.

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

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

Two sentences with no wasted words. Front-loaded with the action and key parameters, returns are succinctly listed.

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

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

No output schema, so the description compensates by listing returned fields: status, binding total, negotiation thread. Missing details like error handling or format, but adequate for a simple retrieval tool with two parameters.

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. Description adds context that seller_mcp_url is from discovery and that the tool forwards the request, which aids understanding beyond the schema descriptions.

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

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

Clearly states the action ('check a quote's status'), the resource ('quote's status'), and the required identifier ('quote_ref'). The forwarding behavior distinguishes it from sibling tools like request_quote or counter_quote.

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

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

Implies usage after requesting a quote, but no explicit when-not or alternatives (e.g., don't use for creating or modifying). Among siblings, negotiate and counter_quote serve different purposes, but this isn't stated.

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

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

No annotations provided, so description carries full burden. Discloses return fields (price, sizes, web_url) and behavior on omitted query. Lacks error handling or auth details, but sufficient for safe use.

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 focused sentences: first states action and input source, second describes output and when to use. 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?

Covers primary use case and essential fields. No output schema, but description sufficiently describes returns. Could mention pagination or error cases, but minimal gap.

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?

100% schema coverage. Description adds critical context: seller_mcp_url source and format, query example, limit default. Exceeds schema 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?

Clear verb+resource scope: 'Drill into ONE seller's catalogue' with direct use case. Distinguishes from siblings like find_seller by specifying post-find_seller context.

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

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

Explicitly states when to use ('right after find_seller') and gives example query. Does not list exclusions or alternatives among siblings, but context is strong.

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

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

No annotations are provided, so the description carries the full burden. It discloses return types (flat rate, per-order-quote, rejection) and implies non-destructive behavior (resolve cost), but does not mention side effects, auth requirements, or rate limits. Adequate but not extensive.

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-loading the purpose and providing essential usage details. It is fairly concise, though could be slightly trimmed without losing 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 two well-documented parameters, no output schema, and the explanation of return types and workflow integration with buy_product, the description provides sufficient context for a simple query tool.

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

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

Schema coverage is 100% with descriptions for both parameters. The description adds context by indicating that seller_mcp_url comes from mcp_ref of find_seller/get_seller_products, and buyer_country is ISO alpha-2, adding value 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 resolves shipping cost to a destination country before buying, with specific inputs (seller_mcp_url, buyer_country) and outputs (flat rate, per-order-quote signal, rejection). It distinguishes from sibling tools like buy_product by specifying the call order.

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

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

The description explicitly says 'call this before buy_product' and explains how to pass buyer_country there, providing clear when-to-use guidance. It does not mention when not to use, but the context is sufficient for correct usage.

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

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

No annotations are provided, so the description must fully disclose behavior. It indicates a read operation and returns 'not_found' for unknown slugs, which is clear but lacks details on permissions or side effects. Adequate but not exceptional.

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

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

Two sentences: first defines the core purpose, second details return content. No wasted words, though could be split for readability. Efficient 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 single-parameter read tool with no output schema, the description effectively covers return contents (price, co-creators, buy method) and error handling. Lacks only pagination or size limits, but overall complete.

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

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

Schema coverage is 100% and the description adds the context of slug format (shared link example), which complements the schema's parameter description. 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 it reads a VIA store card by slug, lists the contents (price, co-creators, how to buy), and distinguishes from sibling tools like get_taste_card or get_product. The verb 'Read' and resource 'store card' are specific.

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

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

The description does not explicitly state when to use this tool versus alternatives. While it mentions 'product co-created by members of a Back Room', it lacks when-not or alternative recommendations. Usage is implied but not guided.

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

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

Despite no annotations, the description discloses the return states (pending, approved, rejected with reason) and additional data upon approval. It does not cover error behavior or side effects, but for a read-only status check it is fairly 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?

Two sentences, no unnecessary words. Information is front-loaded and every sentence adds value.

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

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

Given the low complexity (one parameter, no output schema), the description provides sufficient information about what the tool does and returns. It is complete for its purpose.

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 already describes the slug parameter well. The description adds little new meaning beyond stating the slug is from register_store. 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 checks the review status of a registered store, specifying the exact return values and additional details once approved. It is distinct from sibling tools like register_store or get_store_card.

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 implicitly clarifies usage by connecting to register_store, indicating it should be used after registration. It does not explicitly mention when not to use or alternatives, but the context is clear enough.

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

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

With no annotations, the description appropriately discloses that it is a read operation and indicates the return behavior for unknown/published slugs. No other side effects or auth requirements are needed given the tool's nature.

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 with no wasted words; the purpose is front-loaded and clearly communicated.

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

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

For a simple read tool with one parameter and no output schema, the description fully explains the return values and the resource structure, providing sufficient context for an agent.

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

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

The schema covers the single parameter with 100% description coverage. The description adds context by explaining where the slug comes from (shared link example), which aids correct usage beyond 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 clearly states the action ('Read a published VIA taste card by its slug') and specifies the resource and its contents, distinguishing it from sibling tools like get_store_card.

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

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

The description notes that cards are shared by owners and there is no directory, implying when to use (when you have a slug). However, it does not explicitly mention when not to use or suggest alternative tools.

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

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

No annotations provided, so description carries full burden. It indicates a read-only, non-destructive overview. Does not disclose any special behaviors (e.g., authentication needs, rate limits). Adequate for a simple info retrieval.

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

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

Single sentence that is front-loaded with purpose, no wasted words. Every part is informative and earned.

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

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

Given zero parameters and no output schema, the description adequately covers the tool's functionality. Could mention that it is safe and idempotent, but not necessary for a simple overview 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?

No parameters exist, so schema coverage is 100%. Description adds context about the content of the output (overview, entrypoints, onboarding). Baseline 4 applies as no compensation 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?

Clearly states it provides a 'short overview of VIA Labs' including what it does, key entrypoints for buyers and sellers, and where to onboard. Distinct from sibling tools which focus on specific actions like buying, selling, or quoting.

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

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

No explicit when-to-use or when-not-to-use guidance. Usage is implied as a starting point for orientation, but no mention of alternatives or exclusions. Adequate for a simple informational tool.

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

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

No annotations are provided, so the description fully carries the burden. It discloses that VIA never receives raw email, taste signals immediately affect matching, and the budget signal becomes a proposed cap requiring approval. This covers safety, privacy, and post-import 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?

Five sentences, each adding essential context without redundancy. The main action is front-loaded, and 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 2-param tool with nested objects and no output schema, the description covers prerequisites, data structure, privacy, and behavioral effects. No gaps identified.

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

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

Schema coverage is 100%, but the description adds value by clarifying that evidence_summary is for prose only and never raw email, and explaining the effect of budget_signal. The description also reiterates the link_token requirement.

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 imports a buyer's shopping-preference appraisal onto their VIA buying agent, specifying the source (Mind from email) and target. It distinguishes from siblings like get_buyer_preferences by focusing on import rather than read.

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

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

The description explains the prerequisite (link_token minted by owner) and scoping to exactly one buyer. It also describes the privacy policy (no raw email). It does not explicitly say when not to use, but context is clear.

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

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

No annotations provided, so description carries full burden. Implies read-only behavior through 'List', but does not explicitly state that the operation is safe, idempotent, or free of side effects. Also does not mention authentication or rate limits.

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

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

Two sentences, no fluff. Front-loaded with purpose and scope, immediately followed by key output details. Every sentence earns its place.

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

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

Given 2 optional parameters and no output schema, the description covers the primary purpose, output structure (platform tag and MCP URL), and links to further tools. Could benefit from listing all fields in the result, but overall sufficient for selection and invocation.

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

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

Input schema has 100% coverage, but description adds value: clarifies that 'category' applies only to VIA-app sellers and that omitting 'limit' enumerates entire network. This extra context improves understanding beyond the schema.

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

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

Clearly states the verb 'List' and resource 'active sellers' with specific scope 'across the VIA network (VIA app + RRG + integrated platforms)'. Distinguishes from sibling tools like 'find_seller' which searches for a specific seller, and 'get_seller_products' which is more specific.

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

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

Provides clear context for use: listing all active sellers. Mentions that results include MCP URLs for deeper interaction, guiding subsequent tool use. However, lacks explicit exclusion criteria or when not to use it.

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

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

No annotations are provided, so the description carries the full burden. It adds context that the tool is paid and requires a prior payment transaction, but does not disclose potential side effects, failure modes, or rate limits.

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 plus workflow instruction, all essential. It is front-loaded with the main purpose and provides clear step-by-step guidance without any 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?

The description explains prerequisites and workflow adequately given the parameter set and no output schema. It lacks details on return values or error handling, but the complexity is moderate and the rest is covered.

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

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

Schema coverage is 100%, so baseline is 3. The description adds workflow context beyond the schema by explaining that brief_id and payment_tx_hash come from a prior offer and that buyer_mcp_url comes from find_buyers, enhancing understanding.

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 negotiates a paid offer with a buyer's buying agent, distinguishes it as a post-door step, and explicitly says there is no free pre-door pitch, differentiating it from sibling tools.

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

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

The description explicitly outlines when to use the tool: after submitting a paid offer at the brief door, and provides the required steps. However, it does not explicitly mention alternatives or when not to use it, though the 'no free pre-door pitch' implies a condition.

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

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

No annotations are provided, so the description carries full burden. It discloses key behaviors: store is created PENDING, invisible until human review within 24 hours, on approval ERC-8004 identity minted, and polling via get_store_status. It also explains wallet handling and fees. This is transparent but could mention idempotency or error states.

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

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

The description is a single paragraph of about 150 words, organized with clear logical flow: what it does, wallet requirement, fee, pending status, review, polling. Every sentence provides necessary information; no redundancy or filler. Excellent conciseness.

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

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

Given the tool has 9 parameters (5 required), no output schema, and no annotations, the description is remarkably complete. It explains the entire lifecycle from creation to approval, including how to track status. The agent gets sufficient information to invoke the tool correctly and handle the response.

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 value beyond schema by explaining that payout_wallet is for USDC and store profit share, that slug is optional, and that email/password become dashboard credentials. This helps the agent understand the role of each parameter.

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 registers a store on the VIA network, using a specific verb 'register' and resource 'store'. It distinguishes from sibling tools by explaining the unique process (no thirdweb, one wallet, pending review). This is a specific and unambiguous purpose.

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

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

The description provides clear context for when to use the tool (registering a store on VIA network) and what is needed (only payout_wallet). It does not explicitly exclude alternative scenarios, but the purpose is singular enough that no alternative fits. It additionally explains the review process and polling, which guides the agent on next steps.

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

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

No annotations provided, so description carries burden. Mentions non-binding, seller reviews, and returns quote_ref and proposed total. Lacks auth or rate limit info, but adequate for core behavior.

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

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

Three sentences, front-loaded with purpose, no wasted words. Every sentence adds value.

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

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

Covers core async workflow and key outputs. No output schema, so description must explain return values, which it does briefly. Missing explicit return structure but sufficient for use.

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

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

Schema coverage 60%; description adds context for spec (free-form brief) and links selections to get_offering_schema. Does not detail all parameters, but compensates somewhat.

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?

States clear verb 'Request' and resource 'advisory price for a configurable product'. Distinguishes from siblings like get_quote (poll for decision) and buy_product (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?

Implies workflow by referencing get_offering_schema for input and get_quote for polling. Does not explicitly list when-not-to-use or alternatives, but context is clear.

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

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

With no annotations, the description carries full burden. It mentions verification but does not disclose error handling, authentication requirements, or whether the URL is transient. Minimal behavioral insight.

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

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

Single sentence, directly states purpose. No wasted words. Length is appropriate for the tool's simplicity.

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

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

Given no output schema and one parameter, the description explains the core function but omits the return format. Adequate for a simple tool but slightly incomplete.

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 schema already documents 'slug'. The description adds no extra 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 action ('Return'), the resource ('per-seller MCP endpoint URL'), and the condition ('verified against the active seller index'). It distinctly differentiates from sibling tools like list_sellers or find_seller.

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

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

The description provides no guidance on when to use this tool versus alternatives. No explicit context, exclusions, or references to sibling tools are given.

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

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

Describes return values (matches, broadcast:true, door_url), enforcement of hard requirements, ranking with soft preferences, anonymised broadcast behavior. No annotations provided, so description carries full burden, which it largely meets. Could mention if operation is idempotent or rate limits, but not essential.

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

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

Description is dense but not excessively long. Every sentence adds value. Could be better structured with line breaks or bullet points, but as a single paragraph it remains clear and organized.

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

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

Given 7 parameters, no output schema, and no annotations, the description covers behavior, return values, usage context, and parameter nuances comprehensively. Provides a complete picture for an AI agent to use correctly.

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

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

Schema coverage is 100%, so baseline is 3. Description adds context beyond schema: explains 'reply_to' is strongly recommended for seller responses, distinguishes 'requirements' (exclusion) from 'preferences' (ranking), and clarifies 'brief' should be natural language.

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

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

The description clearly states the tool submits a buyer's intent and performs matching and broadcast. It distinguishes from sibling tools by specifying when to use this generic version versus the buyer-specific MCP endpoint.

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

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

Explicitly says 'Use this when you are buying ON BEHALF of someone and want defined matches plus live broadcast.' Also provides alternative: for buyer-specific taste and budget, use the buyer's MCP endpoint.

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