Vertical Marketplace

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

With no annotations provided, the description carries the full burden and does well: it explicitly states 'No API key required' and describes the scope of information returned. It also discloses IP posture and domain relationships, giving a transparent picture of the tool's access and content. It does not explicitly state it is read-only, but that is evident from 'returns.'

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 dense paragraph that is information-rich but not overly long. Each sentence adds new detail (economics, operator, interfaces, patents), and it is front-loaded with the core purpose. Slightly more structure would help scanning, but it is far from wasteful.

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

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

Given the tool has no parameters and no output schema, the description adequately explains what the response contains by enumerating the overview components. It covers functional, operational, and legal aspects, making it 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?

There are zero parameters, so the baseline is 4 per the rubric. The description adds no parameter-specific meaning, but none is needed since the schema is empty and the tool requires no input.

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

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

The description clearly states the tool 'Returns a canonical, self-describing overview' of Vertical Marketplace, which is a distinct resource and action. It covers what the platform is, how buying/selling work, and economics, distinguishing it from sibling tools like browse_marketplace or sell_data.

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

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

The description implies when to use this tool (when needing an overview of the marketplace) without explicit exclusions or alternatives. It provides clear context about what it returns, but does not explicitly say when not to use it or which siblings to prefer in other scenarios.

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

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

With no annotations, the description carries the full burden. It discloses the Stripe Connect onboarding link, the 95/5 revenue split, the need to complete onboarding for payouts, and the optional api_key behavior (linking vs. minting a new agent+key). It also explains prohibited items, which is important behavioral context.

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

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

The description is longer than average but each sentence adds substantive context (fees, onboarding, restrictions, alternative tool). It is front-loaded with the main purpose. Slight verbosity in the asset list could be trimmed, but it is not bloated.

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 no annotations, the description is remarkably complete. It covers what the tool does, how payouts work, the fee structure, prohibited categories, and how to handle personal health data. It leaves little ambiguity for an agent deciding whether 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?

Schema coverage is 100%, so parameters are already documented. The description adds value beyond the schema by explaining that api_key is optional and that a new agent+key is minted if omitted, and by framing email as the payout/contact email.

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: 'Become a seller of any asset type' and 'Registers (or links) a seller account and returns a Stripe Connect onboarding link.' It distinguishes from siblings by explicitly redirecting personal health data sales to list_health_data, and the asset list makes the scope 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 gives practical context for when to use the tool, including prohibited item categories and a pointer to list_health_data for personal health data. It does not explicitly contrast with sell_data or other seller-related tools, but the onboarding/linking purpose is implied as the prerequisite for selling.

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 transparency burden. It discloses that every result includes ratingAvg/ratingCount from verified buyers, and that samples='only' returns reference listings that are hidden from default browsing and counted in marketplace stats. This adds behavioral context beyond a simple read-only 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 tightly packed and front-loaded: the first sentence defines the tool's purpose, followed by a compact enumeration of filter/sort options. At roughly 100 words for a 9-parameter tool, 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?

Given the absence of an output schema, the description covers return data (ratingAvg/ratingCount) and the special samples behavior. It doesn't describe pagination or default limits, but for a browsing tool this is acceptable given the rich parameter semantics. The description is complete enough for an agent to correctly select and 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 description adds significant meaning beyond the schema by explaining sort values ('quality' = Bayesian-weighted score, 'trust' = seller reputation), the purpose of min_rating, and the three modes of the samples parameter. Since schema coverage is 78%, these semantics help the agent select correct values and understand trade-offs.

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 as the marketplace browsing/searching function ('Browse and search listings for sale by other agents across all categories'), using a specific verb and resource. It distinguishes this from sibling tools like about_marketplace, buy_data, or preview_listing by focusing on the search/browse 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?

The description provides detailed context on when to use various filters (category, vertical, sort, min_rating) and explicitly explains the samples parameter, including the 'only' option for fetching reference examples. It doesn't explicitly name alternatives or exclusions, but the browse/search scope makes its position among siblings 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 the full burden of behavioral disclosure. It reveals payment source, per-listing delivery with signed receipts, the $500 price cap, and unchanged 95/5 split. It does not cover failure modes or partial success behavior, but covers major operational traits 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 five sentences, front-loaded with the core purpose. Each sentence adds relevant detail, though the final note about the 95/5 split is tangential for buyers and could be omitted without losing essential operational context.

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 explains the delivery process and directs the user to poll get_purchase per listing. It does not explicitly state what the bulk_purchase response contains, but it provides enough context to invoke the tool and understand the expected flow.

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 fully documents all parameters. The description adds extra meaning by imposing a $500 combined price cap and restricting eligible listing types, which are not fully captured in the schema's listing_ids description. This helps validate input choices.

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: 'Buy multiple standard listings (up to 100) in a single charge.' It distinguishes from sibling 'buy_data' by explicitly targeting multiple standard listings and specifying limits, payment methods, and delivery behavior.

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 when-to-use context for bulk purchasing standard listings, and explicit when-not via ineligibility of exclusive, limited, and Personal Health Data listings. It also instructs to poll get_purchase per delivery, but does not explicitly name a single-purchase alternative like buy_data.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals the Stripe checkout flow for paid listings, immediate delivery for free ones, 95% seller payout, self-purchase prohibition, and the 422 rejection for missing health data attestation. This is rich, actionable context beyond simple 'buy' semantics.

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 pack a lot of information—general flow first, special case second. The second sentence is long but logical, covering the health data exception. While not bulleted, it is efficient with no filler, though the dense middle section about payment flow could be slightly easier to parse.

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

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

For a purchase tool with 5 params and no output schema, the description covers the key flows: free immediate, paid checkout + polling, health data requirements, and self-purchase ban. It does not describe the exact structure of the response (e.g., checkout URL field name or status codes beyond 422), but the agent can infer the next steps from the given 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 covers 80% of parameters with descriptions, so baseline is 3. The description adds critical context: buyer_intended_use and buyer_attestation are only required for Personal Health Data, and the attestation must have all five affirmations true. It also clarifies the 422 error condition, which helps the agent understand parameter requirements without solely relying on 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 'Buy a listing in any vertical,' which clearly identifies the action (buy) and resource (listing). It distinguishes itself from sibling tools like bulk_purchase (single vs bulk) and get_purchase (buy vs poll), while specifying that free listings deliver immediately and paid listings require checkout.

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

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

The description provides clear context for using the tool: buying a single listing, with free vs paid paths and health data requirements. It references get_purchase for polling after payment, implying when to use that tool instead. However, it does not explicitly mention bulk_purchase as an alternative for multiple listings or state when not to use buy_data.

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

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

With no annotations, the description carries the burden. It discloses the key side-effect (charging the saved card automatically) and the dependency on a saved card. However, it does not mention failure modes, reversibility, or what happens to existing settings when disabled, though the toggle behavior is largely intuitive.

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 the main action, and every sentence adds essential information (behavior and prerequisite). 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 4-parameter tool with no output schema, the description is fairly complete. It covers purpose, triggering condition, and prerequisite. It does not describe the response format, but that is not necessary given no output schema, and the overall usage context is adequately 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 value by explaining the behavioral context of threshold and recharge amount (e.g., 'balance below the threshold'), which helps the agent understand how the parameters interact, 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 tool enables or disables automatic wallet top-ups, using a specific verb and resource. It distinguishes itself from sibling tools by describing the auto-recharge mechanism and prerequisite (saved card), making it 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?

Provides clear context: enables/disables automatic top-ups, and explicitly mentions the requirement for a saved card, pointing to setup_payment_method as an alternative. Does not explicitly state when not to use it, but the usage context is well implied.

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

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

With no annotations, the description carries the full burden. It discloses that no API key is required and that including an email is needed for a reply. However, it does not describe what happens after submission (e.g., confirmation, ticket creation) or any side effects, leaving some uncertainty.

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 with no redundancy. It front-loads the purpose and then adds two key usage tips, making every sentence valuable.

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 contact tool with no output schema, the description covers the purpose, a key parameter behavior (email optional for reply), and the authentication requirement (no API key). It lacks details on confirmation or response format, but these are not critical for this low-complexity 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 low (33%, only email and category have descriptions). The description adds value only for the email parameter ('Include an email if you want a reply'). The other parameters (name, subject, message, submittedBy) are self-explanatory but not explicitly documented, so the description does not fully compensate for the low 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 function: sending an inquiry, question, complaint, or partnership request to Vertical Marketplace. The verb 'Send' plus the resource 'Vertical Marketplace' makes the purpose specific and distinguishes it from sibling tools like submit_idea.

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 (contacting the marketplace for these purposes) and mentions that no API key is required and that an email is optional for a reply. It does not explicitly state exclusions or alternative tools, but the context is adequate.

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

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

With no annotations provided, the description carries the full burden. It discloses that the status change is versioned, signed, and recorded in the modification history, plus the api_key requirement. This goes beyond a simple 'deactivates listing' and provides useful behavioral context.

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

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

Two sentences, front-loaded with the main purpose, and the second sentence adds valuable audit-trail context without waste. Every word contributes.

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 action with 3 params and no output schema, the description adequately covers what it does, prerequisites, and side effects. It could optionally mention reversibility or impact on pending transactions, but these are not essential 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 all parameters are already described in the schema. The description only reinforces that the api_key must be the seller's, adding little beyond what the schema already states.

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

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

The description uses a specific verb (Delist/deactivate) and resource (listings), clearly stating the outcome: the listing no longer appears or accepts purchases. This distinguishes it from siblings like update_listing and listing_history.

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 clearly states the tool is for the user's own listings and requires a seller api_key, giving clear usage context. It does not explicitly name alternative tools or exclusion scenarios, but the purpose is unambiguous enough that an agent would know 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.

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

With no annotations, the description carries the full burden. It discloses key behaviors: amount limits, balance cap, automatic credit on payment completion, and the return of a checkoutUrl. It could additionally mention whether the checkout link is a one-time redirect or how failures are signaled, but the provided details are substantial.

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 efficiently convey all essential information: action, mechanism, limits, automatic behavior, and return value. No fluff or repetition of schema details.

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 only 2 parameters, no nested objects, and no output schema, the description is remarkably complete. It explains the return value (checkoutUrl), the credit flow, and boundary conditions (min/max amount, cap), providing an agent with enough context to invoke the tool correctly without requiring additional disambiguation.

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 by summarizing the purpose of the amount parameter and adding the $500 balance cap, which is not in the schema. It also clarifies that api_key is the vm_live_ key, matching the schema's description.

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

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

The description clearly states a specific verb+resource: 'Add prepaid credits to your wallet via a Stripe Checkout link.' It also differentiates from sibling tools like get_wallet_balance and wallet_transactions by focusing on the funding action and its automatic post-payment credit.

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 (to add credits before making purchases) and explains the benefit ('buy instantly with no checkout redirect'). It does not explicitly mention alternatives or exclusions, but the context is sufficiently clear for an agent to select it over siblings like setup_payment_method.

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 must carry the full burden of behavioral disclosure. It lists the data contents but does not specify whether the operation is read-only, requires authentication, or returns aggregated/real-time data. The word 'statistics' implies read-only, but this is not explicit, and there is no mention of side effects or 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 a single, well-structured sentence that front-loads 'Platform statistics' and then enumerates the specific metrics. It is concise, with no wordy or redundant phrases, and every word 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 no output schema and no annotations, the description should fully explain what the tool returns. It lists several metrics but leaves 'marketplace activity' vague, and does not clarify the response structure, time range, or level of aggregation. It is adequate but not complete for an agent needing detailed expectations.

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 by the rubric the baseline is 4. The description correctly focuses on the returned content, and there are no parameter details to explain. This score reflects that no extra parameter information 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 clearly identifies the tool as providing platform statistics and lists specific metrics (queriers, queries served, active listings, verticals, marketplace activity). The verb 'get' is implied by the tool name, making the purpose evident. However, it does not explicitly differentiate from the sibling tool 'marketplace_stats', so it falls short of a 5.

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 the tool is used to retrieve platform-level statistics, but it provides no explicit guidance on when to use it versus similar tools like 'marketplace_stats' or 'list_verticals'. There are no exclusions or alternative suggestions, so usage is only inferred from the content.

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 must disclose all safety/relevant behavior. It does mention the api_key requirement and that content is only available once paid/released, but it does not mention whether there are side effects or any additional security implications. 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 concise sentences with the main action and key details front-loaded. Every part adds value, and there is no redundancy.

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

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

For a simple read tool without an output schema, the description covers the key return elements, the condition for content delivery, and the authentication requirement. It omits error handling or response format, but given the simplicity, it is mostly 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 schema already describes api_key, and the description adds that it is the buyer's key needed for delivery. The purchase_id parameter is not explained in the description, though it is a common identifier. With 50% schema coverage, the description adds some context but not enough to fully cover the gap.

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 purchase's status, receipt, and delivered content. The verb 'Retrieve' and resource 'purchase' are specific, and the distinction from purchase-creation tools like buy_data or bulk_purchase is evident.

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 use after a purchase and notes the 'paid/released' condition, plus the api_key requirement. However, it does not explicitly compare with alternative tools or state when not to use this tool, so guidance is mostly implied.

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

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

With no annotations provided, the description carries the full burden and does well: it implies read-only behavior via 'Check', explicitly requires the vm_live_ API key, and adds a meaningful guarantee that the wallet never changes pricing or the 95/5 split. This discloses auth and non-mutational behavior beyond what structured fields provide.

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

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

Two sentences, front-loaded with the action and resource, followed by a compact list of covered data points. Every phrase adds value—no filler or repetition. The additional context about wallet optionality and pricing is concise and relevant.

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 (one parameter, no output schema), and the description fully explains what the response includes (balance, funding totals, auto-recharge, card status, cap, activity) and key context (optionality, no pricing impact). No critical gaps remain for an agent to decide whether to call it or interpret its result.

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, api_key, has 100% schema description coverage ('Your vm_live_ API key'). The description merely repeats this phrase, adding no new semantic detail beyond the schema. Baseline 3 applies since the schema already documents the 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 uses a specific verb ('Check') with a clear resource ('your wallet') and enumerates exact data points returned: prepaid balance, total funded/spent, auto-recharge settings, saved-card status, the $500 cap, and recent activity. This clearly distinguishes it from siblings like fund_wallet or wallet_transactions.

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 what the tool covers (wallet overview) and adds context about the wallet being optional and not affecting pricing/split. However, it does not explicitly name alternative tools for related actions (e.g., fund_wallet, wallet_transactions) or state when not to use it, so it falls short of fully explicit usage guidance.

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

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

With no annotations, the description carries full burden and excels: it discloses the inline consent flow, notarization (SHA-256 + Ed25519), 6-year retention, zero-storage relay, per-query sales model, and the absence of exclusive buyouts. This goes beyond typical listing tools and provides substantial behavioral context.

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

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

The description is long but information-dense; every sentence adds a meaningful constraint (eligibility, pricing, storage, consent details). It is front-loaded with the core purpose and then provides necessary specifics, with minimal 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 covers eligibility, consent, pricing, storage, and sales constraints comprehensively for a listing creation tool. It does not mention the API response or post-listing behavior, but given the lack of output schema and the high schema detail, 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 coverage is high (82%), and the schema's consent description already details the required fields and state-specific authorizations. The description reiterates minimum price and de-identification choices but adds little new meaning beyond the structured schema, fitting the baseline of 3.

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

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

The description opens with 'List your OWN personal health data for sale' — a clear verb, resource, and scope. It enumerates the health data verticals (body scans, blood work, etc.), which distinguishes it from generic sell_data and other marketplace 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 clearly states eligibility ('Individuals only — providers/insurers may NOT sell patient data') and the required consent flow. It implies usage context via the health data vertical, but does not explicitly name alternative tools like sell_data, so a clear when-to-use vs. alternatives is slightly lacking.

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 public access, no API key requirement, Ed25519 signing, version/signature inclusion, and that raw content is never exposed (fingerprints only). This is rich, non-obvious behavior.

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

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

Two concise sentences front-load the action and provide essential details in a structured way without any waste.

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

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

Given the simplicity (one parameter, no output schema), the description is quite complete, describing the output elements and access requirements. It could mention ordering or pagination for full completeness, but is adequate for the tool's scope.

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 0% and the description does not explicitly explain the listing_id parameter. However, the single parameter's purpose is inferable from the tool name and description context, but the description adds no explicit 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 clearly states the action ('Get'), the resource ('modification history for a listing'), and enumerates the types of changes tracked. It distinguishes itself from siblings by emphasizing the signed, fingerprint-only nature of data changes.

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 implies when to use this tool (to retrieve a listing's public modification history) but does not explicitly mention alternatives or exclusions relative to sibling tools like preview_listing or get_purchase.

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

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

No annotations provided, so description carries full burden. Description only states what it does; it does not disclose any limitations, performance characteristics, or whether the data is real-time or cached. No mention of read-only nature or access requirements.

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

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

Single sentence, concise, and front-loaded with the core action. 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?

For a parameterless list tool, the description is sufficiently complete, indicating it returns verticals with counts. No output schema exists, but the description covers the main value. However, lacks details on response format or pagination (though likely unnecessary for a simple list).

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?

Tool has zero parameters, so no parameter descriptions are needed. The description clarifies the output (active listing counts), which adds context beyond the empty 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?

Description uses specific verb 'List' and resource 'industry verticals' with additional detail 'active listing counts,' clearly distinguishing it from sibling tools like browse_marketplace and marketplace_stats.

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

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

No guidance on when to use this tool versus alternatives. No mention of scenarios where browsing or stats would be preferred. The purpose implies its use for viewing verticals, but no explicit exclusions or 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 must disclose behavior on its own. 'Statistics' implies a read-only operation, but the description does not explicitly state that it does not modify data, nor does it mention any caveats like caching or rate limits. It adds minimal behavioral context beyond the tool's name.

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, front-loaded sentence that efficiently enumerates the key statistics provided. No wasted words, easy to scan, and every part adds meaning.

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 (no params, no annotations, no output schema), and the description lists core return values. However, it omits details about the response format and fails to differentiate from overlapping sibling tools, leaving some ambiguity about its exact scope.

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 vacuously covers 100% of them. The description adds no parameter details because there are none. Baseline for zero parameters is 4, and no deduction 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 clearly states the tool provides marketplace-wide statistics, listing specific metrics like active listings, sellers, sales volume, and top verticals. This is a clear purpose, though it doesn't differentiate from the sibling tool 'get_platform_stats' which likely overlaps.

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 usage guidance is provided. The description does not mention when to use this tool over alternatives like 'get_platform_stats' or 'seller_dashboard', nor does it give context such as 'use for a marketplace overview'.

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 discloses the critical limitation that no paid data is delivered, which is a key behavioral trait. However, it omits details about authentication, error handling, or what 'full details' include, leaving some behavioral ambiguity.

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, tightly written, and front-loaded with the primary purpose. The second sentence adds a crucial limitation without unnecessary elaboration. Every word earns its place.

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

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

For a simple tool with one parameter and no output schema, the description covers the core purpose and key limitation. However, without an output schema, it should more concretely specify what 'full details' and 'seller-provided preview' return, leaving some uncertainty about the exact output structure.

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 has one required parameter (listing_id) with 0% description coverage. The tool description only alludes to 'a single listing', providing minimal semantic context. It does not specify the format, source, or constraints of the listing_id, failing to compensate for the lack of schema-level 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 a specific verb ('Get') and resource ('full details and seller-provided preview for a single listing'). It also distinguishes itself from the buying action by noting 'before buying' and explicitly stating it does not deliver paid data, setting it apart from sibling tools like buy_data.

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

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

The description provides clear context for when to use the tool ('before buying') and an explicit exclusion ('Does not deliver the paid data'). However, it does not name alternative tools directly, so the guidance is clear but not fully explicit about when to use a different sibling tool.

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

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

With no annotations, the description fully discloses key behaviors: re-rating updates the existing rating, the rating is anonymous, it includes a platform-signed attestation that is not a quality guarantee, and it affects the listing's public quality score and seller reputation. This is exemplary transparency 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?

Every sentence in the description serves a purpose: the main action, eligibility and re-rating behavior, anonymity and attestation details, side effects on scores, and required credentials. There is no filler or repetition; the density is appropriate for the amount of critical information conveyed.

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 and no output schema, the description covers the core purpose, prerequisites, behavioral nuances, and even mentions the attestation in the response. It does not fully specify the response format, but the most important output elements are described, making it sufficiently complete for an agent to use correctly.

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

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

Schema coverage is 100%, with descriptions for each parameter already explaining constraints (e.g., rating is integer 1-5, api_key must be the buyer, purchase_id must be your paid purchase). The description reinforces these requirements but does not add new parameter-level details beyond what the schema already provides, 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 opens with a specific verb and resource: 'Rate a listing you have purchased (1-5 stars, optional comment).' It clearly distinguishes this from sibling tools like buy_data or browse_marketplace, and adds behavior such as re-rating updating existing rating, 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 states when to use the tool: only a verified buyer can rate, and it requires the buyer's api_key and purchase_id. It also references browse_marketplace sort='quality' to show where the rating impacts. It does not name alternatives, but the prerequisites and context are clear enough to guide 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?

With no annotations, the description carries the transparency burden. It discloses that registration is immediate, requires no human, and the key is universal across verticals. This adds useful behavioral context beyond the tool name and 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?

Two sentences, front-loaded with the primary action and outcome. The second sentence adds valuable details (universal key, immediate registration) without padding.

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 registration tool with only two parameters and no output schema, the description covers the key outcome (API key) and usage scope. It lacks details about parameter purposes, but given the simplicity, 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 description coverage is 0%, so the description should explain the parameters. It does not mention 'name' or 'email' or their roles. The overall purpose is stated, but the individual parameter semantics are left to 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 action ('Register as a querier') and the outcome ('receive a vm_live_ API key'), and it explains the key's utility for browsing, previewing, rating, and purchasing data. This distinguishes it from sibling tools like become_seller or buy_data by focusing on the querier 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 implies the tool is for anyone wanting to become a querier, with notes that one key works everywhere and registration is immediate with no human involvement. It does not explicitly mention when not to use it or compare to alternatives, but the 'querier' framing contrasts with seller-oriented siblings.

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

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

With no annotations, the description carries full burden for behavioral disclosure. It usefully adds that results are backed by consent records and that purchase requires attestation, but it omits search-specific behaviors such as pagination (limit/offset), error handling, authentication requirements, or result format. These are significant gaps for a search 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 first sentence is well-structured and immediately conveys the tool's purpose. The second sentence, however, focuses on buy_data and purchase attestation, which is tangential to the search operation; it adds context but also clutters the description. It is reasonably short but not entirely focused.

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, no annotations, and no output schema, the description is incomplete. It lacks return value details, pagination defaults, error behavior, and sibling differentiation. The consent and attestation context is valuable, but it does not sufficiently round out the operational picture for an autonomous agent.

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

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

Schema coverage is 60%, and the description partially maps 'data type' to subcategory and 'keyword' to q, but it also introduces 'demographics', which has no corresponding parameter in the schema, misleading the agent. It does not explain the behavior or defaults of limit/offset or the sort values, so the description does not compensate for the uncovered parameters.

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

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

The description clearly states a specific verb ('Search'), resource ('Personal Health Data listings'), and search criteria ('by data type, keyword, and demographics'). This distinguishes it from generic browsing, but it does not explicitly differentiate from sibling tools like browse_marketplace or list_health_data, so it falls just short of a 5.

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

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

No explicit guidance is provided about when to use this tool versus alternatives. The mention of buy_data and attestation is relevant to the purchase flow, not to selecting search_health_data over browse_marketplace or list_health_data. The agent is left to infer usage from the name and context.

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

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

With no annotations provided, the description fully discloses the tool's behavior: it acts as a 'ZERO-STORAGE BROKER' that 'never stores what you sell' and relays the deliverable live. It states that only the preview is stored and that the deliverable must not be sent, which is critical 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 dense but well-structured with clear separation of the broker model, prerequisites, metadata requirements, and exclusions. Each sentence adds value, though a few details (e.g., preview being the only stored content) are stated more than once.

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 annotations or an output schema, the description covers purpose, usage, behavioral traits, and parameter semantics, which is strong. It omits return-value/response details, but that is not explicitly required for a create-style tool. Overall, it is sufficiently 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?

Schema coverage is 75%, and the description adds meaningful semantics for key parameters: 'a small, already-scrubbed preview' shown before purchase, 'price_cents 0 = free', and 'consent=true confirms you own what you list'. It explains the preview as the only stored content, which enriches 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 opens with a specific verb phrase 'Publish a per-purchase listing for any asset type' and then lists the supported asset types, making the tool's function unambiguous. It also explicitly distinguishes itself from the health-data sibling tool with 'use the list_health_data tool', which clarifies scope boundaries.

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 workflow guidance: 'Register + verify that endpoint first with set_delivery_endpoint' and warns not to send the deliverable itself. It also states a clear exclusion with an alternative: 'Personal health data is NOT accepted here — use the list_health_data tool', satisfying the when-to-use and when-not-to-use criteria.

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

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

No annotations are provided. The description discloses the authentication requirement and the type of data returned, but it does not explicitly state that the operation is read-only or describe any side effects. Given the dashboard nature, this is acceptable but 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?

The description is three sentences that efficiently cover purpose, requirements, and related actions. It front-loads the main contents. 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 sufficiently explains the return content and provides pointer to related tools. It could mention response format or pagination, but given the simplicity, it 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?

The only parameter, api_key, is fully described in the schema (100% coverage). The description adds the context that it is the seller key, but no additional semantic detail beyond that. Baseline 3 applies because the schema carries the load.

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

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

The description clearly identifies this as the seller dashboard and enumerates its contents (listings, sales, earnings, payout/onboarding status, notifications). It distinguishes from sibling tools like browse_marketplace by focusing on the user's own seller data, though it lacks an explicit verb like 'view' or 'get'.

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 tells the user they need a seller api_key, and it directs them to update_listing, deactivate_listing, and listing_history for related actions, implicitly defining what this tool is for (viewing) versus those (editing/deleting/history). However, there is no explicit 'when not to use' statement.

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

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

With no annotations provided, the description fully carries the behavioral burden. It discloses that the marketplace stores no data, that broker listings relay from this URL at query time, that a signed nonce must be echoed, and that a seller API key is required. This provides rich, safety-relevant behavior 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?

Three focused sentences, each carrying essential information: purpose, data-flow behavior, and requirements. No filler or repetition. The most critical information is front-loaded.

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

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

The tool is moderately complex with 3 parameters and no output schema. The description explains what it does, auth needs, endpoint requirements, and data handling. It doesn't describe the response format after verification, but the verification action is implied. Given the absence of output schema, a brief note on return value would improve completeness, but the description still covers essential operational context.

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

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

Schema coverage is 100% and descriptions are already clear. The tool description adds meaning to callback_url by specifying public HTTPS and the nonce verification behavior, and clarifies api_key as a seller API key. This enriches parameter understanding beyond the raw 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 explicitly states the action ('Register and verify') and the target resource ('BROKER delivery endpoint'), clearly distinguishing it from sibling tools like register_agent or become_seller. It goes further to explain the data relay semantics, making the tool's 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 gives clear context for when this tool is relevant: setting up a broker endpoint for data relay. It explains prerequisites (public HTTPS, nonce echo) but does not explicitly state when not to use it or mention alternatives. This is clear situational guidance without explicit exclusions.

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

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

With no annotations, the description carries the full burden. It discloses key behavioral traits: no charge is made during setup, a Stripe setupUrl is returned, a human must complete it once, and afterward the agent can pay from the saved card without redirects. This provides essential safety and workflow information, though it omits potential edge cases like URL expiration or failure handling.

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 the primary purpose and followed by the workflow details. Every sentence contributes meaning with 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?

The tool has one parameter, no output schema, and no annotations. The description explains the return value (Stripe setupUrl), the one-time human step, and the subsequent benefit. It sufficiently covers the tool's lifecycle for its simplicity, though it could mention prerequisite conditions (e.g., valid api_key) or post-setup verification steps.

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 only one parameter, api_key, with a clear description ('Your vm_live_ API key'), giving 100% schema coverage. The tool description adds no additional parameter-specific details, but none are necessary given the schema already fully documents the parameter. 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 uses a specific verb and resource: 'Save a card for instant off-session purchases and auto-recharge.' It clearly distinguishes from sibling tools like fund_wallet or configure_auto_recharge by focusing on card setup and the resulting ability to pay without redirects. The purpose is 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 explains when to use the tool: to establish a saved card for off-session purchases and auto-recharge, with a human completing a one-time Stripe setup. It implies a specific workflow (setup then future automated payments) but does not explicitly name alternatives or exclusions. Still, the context is clear enough for an agent to decide.

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

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

With no annotations, the description carries the burden of behavioral disclosure. It states 'No API key required,' which is a useful permission-related detail, and the verb 'suggest' implies a non-destructive write action. Yet it does not disclose what happens after submission (e.g., whether it creates a ticket or is reviewed), nor does it mention any limits or side effects, leaving a transparency gap.

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, focused sentence that front-loads the action ('Suggest an improvement') and includes only essential clarifications (examples and API key note). Every word earns its place, with 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 has 5 parameters, no annotations, and no output schema, the description is too sparse to fully guide an agent on how to correctly fill out the request. It lacks explanations of required fields, optional fields like 'impact' and 'category' expectations, or any indication of return behavior. The simplicity of the action does not compensate for the missing parameter guidance.

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

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

Schema description coverage is 0%, so the description must compensate, but it does not explain any of the five parameters (title, description, impact, category, submittedBy). The phrase 'a new vertical, data source, feature, or fix' hints at possible category values but does not explicitly map to the schema fields, providing minimal semantic value beyond the parameter names.

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

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

The description clearly states the tool's purpose with a specific verb ('Suggest') and resource ('improvement to Vertical Marketplace'), enumerating examples like 'a new vertical, data source, feature, or fix.' This clearly distinguishes it from sibling tools such as buy_data or list_verticals, which handle transactions or listings rather than suggestions.

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 a clear context for when to use the tool: whenever an improvement to Vertical Marketplace is being proposed. It implies the tool is for submitting ideas rather than executing marketplace actions, and it adds a usage note ('No API key required'). However, it does not explicitly mention alternatives or exclusions, 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.

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

With no annotations, the description carries the full burden and does so well: it discloses versioning, Ed25519 signing, public modification history, that content is not stored/updated, and the return value (updated listing plus signed receipt). This is rich behavioral context beyond the simple 'modify' verb.

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, each earning its place: scope and fields, versioning/authentication consequences, and return/auth requirement. Front-loaded with the action and fields, 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?

The description covers purpose, ownership, safety profile, versioning, delivery-endpoint alternative, and return value. Since there is no output schema, the mention of the return is useful, though a bit more detail on the receipt structure or required listing_id would make it 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 high (75%), so the schema already documents most parameters. The description adds useful context for active ('delist/relist') and clarifies ownership, but does not add meaningful detail for title or description beyond what the schema lacks. 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 opens with a specific verb and resource ('Modify one of your existing per-query listings') and lists the exact editable fields. It also distinguishes itself from set_delivery_endpoint by clarifying that underlying content is never updated here, making the tool's scope clear.

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

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

The description gives clear directional guidance, explicitly pointing to set_delivery_endpoint for changing underlying data content. It does not compare with the sibling deactivate_listing, but the active field covers delisting/relisting, so the usage context is mostly clear but not fully exhaustive.

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

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

With no annotations provided, the description carries the full burden. It discloses key behaviors: purchases are shown as negative, results are newest first, and pagination is available. It also notes the API key requirement. It does not detail return structure or error handling, but for a read-only view 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?

A single, well-structured sentence with an em-dash for added detail. Every word earns its place, and the most important information is front-loaded.

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

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

For a simple read tool with no output schema, the description covers purpose, ordering, pagination, and auth. It does not explain the exact fields in the response, but the ledger contents are reasonably implied. Given the tool's simplicity, 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?

Schema description coverage is 100%, so the baseline is 3. The description adds no extra parameter meaning beyond the schema; it only repeats the API key requirement already documented.

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 ('View') and resource ('your wallet ledger'), and elaborates on the contents (credits, purchases, refunds) and ordering (newest first, paginated). This clearly distinguishes it from sibling tools like get_wallet_balance or fund_wallet.

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

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

The description provides clear context for when to use this tool (viewing wallet ledger) but does not explicitly mention alternatives or exclusions. It implies the tool is for full transaction history rather than balance, which is sufficient for an agent to infer usage.

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