Server Quality Checklist

Tool Scores

• datahub_reviewA
  3.7/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries full burden for behavioral disclosure. It mentions the review is public (via schema comment description, not in description) but does not state whether ratings can be updated, if multiple reviews per dataset are allowed, error states beyond rejection, or if changes are irreversible. This is sparse 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.

  Conciseness5/5

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

  Two sentences with only essential information: action, constraint, and scope. No wasted words, front-loaded with key purpose.

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

  Completeness3/5

  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 core action and constraint but omits important details: success behavior, error messages, whether review can be edited/deleted, and full public exposure. Adequate but not comprehensive.

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

  Parameters3/5

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

  Schema coverage is 100%, so the description adds minimal value beyond schema. It mentions 'optional comment' and '1-5 stars,' which are already in the schema descriptions. Baseline 3 is appropriate as schema does the heavy lifting.

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

  Purpose5/5

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

  Description clearly states the action: 'Rate a DataHub dataset you have purchased (1-5 stars, optional comment).' It uses a specific verb ('rate') and resource ('dataset'), and the 'verified-purchase only' condition distinguishes it from siblings like datahub_buy or datahub_download.

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

  Usage Guidelines4/5

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

  Explicit condition: 'Verified-purchase only: the marketplace rejects wallets without a receipt for the dataset.' This tells the agent when to use (only after purchase) and implies when not to (if no receipt). Also clarifies 'No payment involved,' differentiating from transaction tools. No explicit alternatives, but context signals provide sibling names.

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

• datahub_subscribeA
  4.2/5.0
  Behavior4/5

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

  The description discloses key behaviors: recurring subscription, on-chain payment, no per-download fee, renewal extends from current expiry, and spending caps. Without annotations, the description carries the full burden and provides a clear behavioral picture.

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

  Conciseness5/5

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

  The description is three sentences, about 50 words, and front-loads the core purpose. Every sentence adds value without redundancy.

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

  Completeness4/5

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

  Given the tool's simplicity and lack of output schema, the description covers the essential aspects: subscription nature, payment, usage, renewal, and spending caps. Missing details about return value are minor.

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

  Parameters3/5

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

  The single parameter 'book_id' is well-described in the schema, specifying it must be a dataset with a subscription plan. The description does not add additional parameter details beyond the schema, but schema coverage is 100%, so baseline is appropriate.

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

  Purpose5/5

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

  The description clearly states the tool subscribes to a recurring DataHub dataset with time-based access and on-chain payment. It distinguishes from siblings like datahub_buy (for datasets without a subscription plan) and datahub_download (for fetching updates after subscription).

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

  Usage Guidelines4/5

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

  The description indicates when to use the tool: for datasets with a subscription plan, identified via datahub_search. It contrasts with datahub_buy for datasets without a plan, and mentions using datahub_download for fetching updates while subscribed. However, it does not explicitly state when not to use it.

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

• gate_find_endpointsA
  4.2/5.0
  Behavior4/5

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

  Discloses important behavior: read-only, free, entries verified by machine. With no annotations, this provides adequate transparency. Could note pagination or rate limits, but still good.

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

  Conciseness5/5

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

  Three sentences, front-loaded purpose, no fluff. Every sentence adds value: purpose, return fields, workflow, data quality.

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

  Completeness4/5

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

  Given 3 optional params and no output schema, the description covers what the tool returns and its place in the workflow. could mention default limit behavior, but still complete enough.

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

  Parameters3/5

  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 minimal extra semantics beyond schema descriptions, but it does tie params to the tool's purpose (finding paid sources).

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

  Purpose5/5

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

  Clearly states it browses a registry of x402-priced endpoints, lists returned fields (url, price, etc.), and distinguishes from siblings like gate_get_price and gate_fetch by describing the workflow: find endpoint, then call those tools.

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

  Usage Guidelines4/5

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

  Explicitly tells when to use it ('find a paid data source without being handed the URL') and what to do next ('call gate_get_price or gate_fetch'). Could be improved by mentioning when not to use it compared to sibling search tools.

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

• gate_prepaid_balanceA
  4.2/5.0
  Behavior4/5

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

  No annotations provided, so description carries burden. Explains prepaid mechanism (deposited once, debited per request, no signing each time). Declares read-only nature clearly. Could mention auth requirements or rate limits, but sufficient.

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

  Conciseness5/5

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

  One sentence with parenthetical qualifier and 'Read-only'. Front-loaded key info, no filler. Efficient given tool simplicity.

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

  Completeness4/5

  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, description covers purpose, behavior, and parameter semantics. Does not specify output format, but not critical given low complexity. Differentiates from siblings adequately.

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

  Parameters4/5

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

  Schema has 100% coverage, but description adds context: 'Balances are tracked per token, so USDC and USDT are separate pots' and notes default. This adds meaning beyond enum description.

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

  Purpose5/5

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

  Clearly states it shows the prepaid balance for a stablecoin, with specific verb 'show' and resource 'pre-paid balance'. Distinguishes from siblings like gate_prepaid_deposit (deposit) and gate_get_price (price).

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

  Usage Guidelines3/5

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

  Indicates read-only nature but lacks explicit when-not-to-use or alternatives. Implies usage for checking balance without signing, but no direct guidance on when to use this versus gate_fetch or other tools.

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

• pay_get_sessionA
  4.2/5.0
  Behavior4/5

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

  No annotations are provided, so the description carries full burden. It declares 'Read-only,' which is a key behavioral trait. It does not detail auth needs or rate limits, but for a simple read-only tool, this is sufficient.

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

  Conciseness5/5

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

  Two concise sentences with zero waste. The main purpose is front-loaded, and every word adds value.

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

  Completeness4/5

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

  With no output schema, the description mentions return fields (amount, merchant, order id, status) but does not specify format or additional details. For a simple inspection tool, this is nearly complete, though a bit more detail on the output would push it to 5.

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

  Parameters3/5

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

  Schema coverage is 100%, and the schema already provides a detailed description of the 'session' parameter (accepts UUID or URL, extracts ID). The description adds no extra parameter information beyond the schema, so baseline 3 is appropriate.

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

  Purpose5/5

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

  The description clearly states the tool inspects a Solinkify Pay checkout session and lists key fields (amount, merchant, order id, status). It differentiates from sibling pay_checkout by noting it should be called before spending.

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

  Usage Guidelines4/5

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

  The description explicitly says 'call it first to confirm what pay_checkout would spend,' providing clear guidance on when to use it. It does not explicitly state when not to use it, but the context implies it's for pre-payment inspection.

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

• datahub_searchA
  4.3/5.0
  Behavior4/5

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

  With no annotations, the description carries full burden. It states the tool returns search results with specific fields and notes price is in USD stablecoin. It also reveals that API listings have per-request pricing and are accessed via gate_fetch, which is important behavioral context. However, it doesn't 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.

  Conciseness4/5

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

  The description is concise (two sentences) and front-loads the main purpose. The second sentence, though slightly run-on, packs useful information about how to handle different result types. Minimal waste.

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

  Completeness4/5

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

  Given no output schema, the description lists the return fields explicitly. It also covers the two distinct data kinds and their follow-up tools. It does not mention pagination, ordering, or error handling, but for a search tool this is largely sufficient.

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

  Parameters4/5

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

  Input schema coverage is 100%, so baseline is 3. The description adds value by explaining that the 'limit' parameter defaults to 10 and must be between 1 and 50, and that the 'query' parameter uses plain keywords with no syntax. It also provides usage guidance for different listing kinds, which goes beyond schema.

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

  Purpose5/5

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

  The description starts with a clear verb+resource ('Search the Solinkify DataHub marketplace') and specifies the return fields (id, title, price, etc.). It further distinguishes between dataset listings (use datahub_buy) and API listings (use gate_fetch), effectively differentiating this tool 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.

  Usage Guidelines4/5

  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 search the marketplace) and how to act on results: buy datasets with datahub_buy, access API listings via gate_fetch. It also clarifies query behavior ('Plain keywords work best; there is no query syntax'). It doesn't explicitly state when not to use it, but the guidance is clear enough.

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

• gate_subscribeA
  4.3/5.0
  Behavior4/5

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

  With no annotations, the description carries full disclosure responsibility. It discloses that the tool 'moves money,' reads the plan price on-chain, checks spending caps, and fails if no plan exists. These are important behavioral traits beyond the basic action, though it could mention success response or idempotency.

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

  Conciseness5/5

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

  The description is exceptionally concise at three sentences. The main action ('Buy or renew ... plan') is front-loaded, and every sentence adds essential information without redundancy.

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

  Completeness3/5

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

  While the description covers the input and failure condition, it does not mention the return value or success behavior. Given the absence of an output schema, this gap could confuse an agent about what to expect after a successful subscription purchase.

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

  Parameters4/5

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

  Schema coverage is 100% with decent descriptions, but the tool description adds value by clarifying that 'creator_wallet is the endpoint owner, not the agent's wallet' and that 'endpoint_id comes from the 402 manifest, not a URL.' This extra context helps an agent avoid common mistakes.

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

  Purpose5/5

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

  The description clearly states the action 'Buy (or renew) a creator's subscription plan' and identifies the resource as a 'Gate endpoint with unlimited access until expiry.' It differentiates from siblings by specifying the one-payment subscription model and mentions moving money, which is unique to this tool among siblings.

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

  Usage Guidelines4/5

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

  The description provides clear usage context: it is for buying or renewing a subscription, and it fails if the endpoint has no subscription plan. However, it does not explicitly compare to alternatives like gate_get_price or datahub_subscribe, nor does it provide when-not-to-use guidance.

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

• datahub_downloadA
  4.4/5.0
  Behavior4/5

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

  No annotations provided, so description carries the full burden. It discloses ownership proof requirement, cost-free nature, and failure conditions. However, it does not specify the return format or any side effects, which would be ideal.

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

  Conciseness5/5

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

  Two sentences, front-loaded with the core action, and 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.

  Completeness4/5

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

  For a simple one-parameter tool with no output schema, the description covers usage conditions, cost, and alternatives. It could be slightly more complete by describing the response (e.g., URL), but not a major gap.

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

  Parameters3/5

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

  Only one parameter (book_id) with 100% schema coverage. The schema description already includes the same information as the tool description regarding ownership conditions, so the description adds no new semantic value beyond the schema.

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

  Purpose5/5

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

  The description clearly states it fetches a download link for a dataset the agent already owns, distinguishing it from buying or subscribing via siblings like datahub_buy and datahub_subscribe.

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

  Usage Guidelines5/5

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

  Explicitly says when to use (when owning dataset from purchase or subscription), advises to prefer it over buying again due to zero cost, and notes the requirement of a signed wallet message.

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

• gate_prepaid_depositA
  4.4/5.0
  Behavior4/5

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

  No annotations provided, so description covers key behaviors: moves money, affects daily cap, supports withdrawal. Adds useful context about token matching requirement. Little missing on return value or confirmation, but overall informative.

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

  Conciseness5/5

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

  Two sentences, no filler. First sentence states purpose and action, second explains consequences. Highly efficient.

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

  Completeness4/5

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

  Given 2 parameters, no output schema, the description covers behavior (daily cap, withdrawal, token matching). Could mention confirmation or transaction ID, but overall sufficient for typical deposit tool.

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

  Parameters4/5

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

  Schema coverage is 100% with decent descriptions, but the description adds value beyond schema: clarifies token must match endpoint pricing and amount_usd is in whole units with daily cap constraint. This extra context earns above baseline 3.

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

  Purpose5/5

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

  Clearly states the action 'Deposit stablecoin' into 'Solinkify pre-paid balance' and explains the purpose: to enable future gate_fetch calls to debit it without per-request fees. This distinguishes it from siblings like gate_fetch and gate_prepaid_balance.

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

  Usage Guidelines4/5

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

  Provides context: full deposit counts against daily cap and is withdrawable, implying use for prepayment without per-request charges. Does not explicitly state when not to use, but siblings and context make alternatives clear.

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

• spend_authority_statusA
  4.4/5.0
  Behavior4/5

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

  Without annotations, the description carries full burden. It declares read-only behavior, that enforcement happens on-chain, and that it defaults to a configured wallet. It does not contradict any annotations (none provided) and adds useful context about trust boundaries, though it lacks detail on error conditions or authentication requirements.

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

  Conciseness5/5

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

  Two concise sentences cover the purpose, output fields, read-only nature, enforcement, and default wallet. Every sentence adds value with no redundancy or filler.

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

  Completeness4/5

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

  For a tool with one optional parameter and no output schema, the description is largely complete: it specifies what data is returned (cap, ceiling, spent/left, revoked), the read-only behavior, and default wallet. It could be improved by mentioning error cases (e.g., if authority doesn't exist) but is still solid.

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

  Parameters4/5

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

  Schema coverage is 100% with one optional parameter 'owner'. The description adds value by explicitly stating to omit it to use the configured wallet, which goes beyond the schema's basic description.

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

  Purpose5/5

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

  The description clearly states it shows the on-chain SpendAuthority (ADR-008), listing specific details like per-payment cap, daily ceiling, usage, and revocation status. It uses a specific verb ('Show') and resource, distinguishing it from sibling tools that deal with payments, subscriptions, or data purchases.

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

  Usage Guidelines4/5

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

  The description explains it is read-only and defaults to the configured SOLINKIFY_OWNER_WALLET, providing clear context for when to use it. However, it does not explicitly state when not to use it or mention alternatives, though no sibling tool duplicates this functionality.

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

• gate_fetchA
  4.5/5.0
  Behavior4/5

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

  The description discloses key behaviors: automatic payment, payment priority (prepaid then escrow), refusal on cap exceed, and no cost for ungated URLs. Since no annotations are provided, the description adequately carries the transparency burden, though it could mention that it deducts from the wallet balance.

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

  Conciseness5/5

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

  Three concise sentences with no fluff. The main action is front-loaded, making it easy to understand quickly.

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

  Completeness5/5

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

  Given one parameter, no output schema, and no nested objects, the description provides sufficient information about purpose, usage, and behavior. It mentions return value (content and payment info).

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

  Parameters4/5

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

  Only one parameter 'url' with 100% schema coverage. The parameter description adds value by explaining the automatic payment on HTTP 402 and advising to check price first when cost matters.

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

  Purpose5/5

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

  The description clearly states the tool fetches a Gate-protected URL and automatically pays the paywall. It is distinct from sibling tools like gate_get_price and gate_prepaid_balance.

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

  Usage Guidelines4/5

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

  The description explains that the tool automatically pays from the wallet, prefers prepaid, uses escrow otherwise, and refuses if caps exceeded. It also mentions ungated URLs are free. It suggests checking price first with gate_get_price, but does not explicitly state when not to use it.

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

• social_buy_blinkA
  4.5/5.0
  Behavior5/5

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

  Discloses key behaviors: moves money, settlement on Solana, returns receipt and download link, checks price against spending caps. Since no annotations are present, the description fully carries the burden and does so thoroughly.

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

  Conciseness5/5

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

  Extremely concise (two sentences plus a short third) with no wasted words. Front-loaded with the core purpose, then adds behavioral details efficiently.

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

  Completeness4/5

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

  Covers purpose, behavior, parameters, and return values well given no output schema. Minor gap: no mention of failure scenarios (e.g., insufficient funds, invalid link), but overall sufficient for a mutation tool.

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

  Parameters5/5

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

  Adds significant meaning beyond schema: explains that the 'url' parameter accepts share links, actions URLs, or raw product IDs in the same form as social_get_blink; explains the 'email' parameter as optional for receipt, with anonymous purchase support and that the download link is returned regardless.

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

  Purpose5/5

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

  Description clearly states the action ('Buy') and the specific resource ('product from a Solinkify Blink link as shared on X'). The verb is specific and the resource is well-defined, distinguishing it from sibling tools like datahub_buy which likely handle different types of purchases.

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

  Usage Guidelines3/5

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

  No explicit guidance on when to use this tool over alternatives. The context 'as shared on X' implies it's for purchases initiated from social media Blinks, but no exclusion criteria or alternative suggestions are provided.

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

• datahub_buyA
  4.7/5.0
  Behavior4/5

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

  No annotations are provided, so the description must carry the full burden of behavioral disclosure. It covers the purchase flow, settlement (x402 on Solana), token options, and that spending caps apply. However, it omits details about error conditions, refunds, or post-purchase state changes, which would improve transparency.

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

  Conciseness5/5

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

  The description is two sentences long, front-loading the core action and result. Every phrase adds value: the settlement info, default token, alternative, and the caveat about re-buying. No redundant words.

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

  Completeness4/5

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

  Given the tool has 2 parameters, no output schema, and no annotations, the description covers the essential context: what the tool does, what information is needed (book_id, token), and key gotchas (spending caps, duplicate purchase). However, it could be more complete by describing error handling or the download link format.

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

  Parameters5/5

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

  Schema coverage is 100%, but the description adds value beyond the schema: for token, it explains the default and wallet requirements; for book_id, it specifies the correct format (uuid from datahub_search) and warns against duplicate purchases. This enriches the schema definitions.

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

  Purpose5/5

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

  The description clearly states the action (buy), resource (DataHub dataset), and the outcome (returns download link). It also distinguishes from siblings like datahub_download (for re-fetching) and datahub_subscribe by mentioning the one-time purchase nature.

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

  Usage Guidelines5/5

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

  The description specifies when to use this tool (to buy a dataset) and when not to (buying again if already owned, use datahub_download instead). It also notes the default token (USDC) and alternative (USDT), and mentions spending caps, providing clear usage guidance.

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

• gate_check_deliveryA
  4.7/5.0
  Behavior5/5

  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 explicitly states the tool is read-only and free, and notes a key nuance: it records which bytes were delivered, not content correctness. This is comprehensive for a simple read operation.

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

  Conciseness5/5

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

  The description is concise at three sentences, front-loading the core action and adding necessary nuance. No superfluous information.

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

  Completeness5/5

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

  Given the tool has one parameter, no annotations, and no output schema, the description covers purpose, usage context, behavioral traits, and parameter origin. It is complete for effective agent selection and invocation.

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

  Parameters4/5

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

  Schema coverage is 100% for the single parameter, but the description adds valuable context: payment_id is returned by gate_fetch and only exists for escrow-settled payments. This goes beyond the schema's description and aids correct usage.

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

  Purpose5/5

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

  The description clearly states the tool checks delivery hashes for a payment, comparing gate and agent records. It specifies the purpose: confirm purchase arrival or show discrepancy. This differentiates it from sibling tools like gate_fetch (which returns payment IDs) and datahub_buy (purchase).

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

  Usage Guidelines4/5

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

  The description explains when to use the tool (post-purchase verification) and the parameter description clarifies that payment_id only exists for escrow-settled payments, implying it should not be used for prepaid or subscription access. However, it does not explicitly state when not to use it or list alternatives.

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

• wallet_statusA
  4.7/5.0
  Behavior4/5

  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 clearly states that the tool 'takes no arguments and never moves money,' which are key traits. However, it does not mention possible error conditions or output format, but given the simplicity and read-only nature, the description is sufficiently transparent.

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

  Conciseness5/5

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

  The description is extremely concise: two sentences. The first sentence lists what the tool provides, and the second gives usage guidance. No unnecessary words, and the key information is front-loaded. It earns its place.

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

  Completeness5/5

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

  Given the tool has no parameters, no annotations, and no output schema, the description must be self-sufficient. It fully enumerates what information is returned: address, SOL, stablecoin balances, pre-paid balance, and spending budget. This is complete for a status-check tool.

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

  Parameters4/5

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

  The input schema has no parameters, so schema_description_coverage is 100%. The description reinforces that there are no arguments, adding no further parameter detail needed. Baseline 4 is appropriate as the schema already handles it.

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

  Purpose5/5

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

  The description clearly states what the tool does: it shows the agent wallet details including address, SOL balance, stablecoin balances, pre-paid balance, and remaining budget. It uses specific verbs ('Show') and resource identifiers, and the detail distinguishes it from sibling tools that handle payments or subscriptions.

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

  Usage Guidelines5/5

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

  The description explicitly states when to use the tool: 'Call it first when a payment fails, to tell an empty wallet apart from a cap that has been reached.' This provides clear context and a concrete use case, which helps the agent decide when to invoke it over alternatives.

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

• social_get_blinkA
  4.8/5.0
  Behavior4/5

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

  No annotations provided, so the description carries the full burden. It declares the tool is 'Read-only', which is a key behavioral trait. However, it could mention behavior on invalid URLs or other potential issues, but is sufficient for a simple inspection tool.

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

  Conciseness5/5

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

  Two sentences, no wasted words. The most important information (purpose, usage, parameter flexibility) is front-loaded and concise.

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

  Completeness5/5

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

  Given the tool's simplicity (1 parameter, no output schema, no annotations), the description is fully adequate. It covers what the tool does, what data it returns, and when to use it.

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

  Parameters5/5

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

  Schema coverage is 100%, but the description adds significant meaning beyond the schema's property description. It explains that the parameter accepts multiple formats (share link, Actions URL, raw product id) and that the id is extracted automatically, which is not in the schema.

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

  Purpose5/5

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

  The description uses a specific verb 'inspect' and states the resource 'Solinkify Blink', listing what information it returns (title, description, price, seller). It also distinguishes from the sibling tool social_buy_blink, making the purpose clear.

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

  Usage Guidelines5/5

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

  Explicitly states when to use: 'confirm the price before social_buy_blink'. It also notes the tool is read-only, guiding the agent to use it before performing a purchase.

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

• pay_checkoutA
  4.9/5.0
  Behavior5/5

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

  With no annotations provided, the description fully discloses behavioral traits: settles on Solana, 99% instant transfer to merchant, spends from agent or owner wallet, irreversible, and refuses paid/expired sessions. 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.

  Conciseness4/5

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

  The description is well-structured and covers all necessary points without redundancy. Slightly verbose due to technical details like ADR-008, but still efficient. Could be trimmed slightly.

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

  Completeness5/5

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

  For a single-parameter tool with no output schema or annotations, the description provides complete context: payment flow, wallet modes, prerequisites, and restrictions. No gaps remain.

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

  Parameters5/5

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

  Schema coverage is 100%, and the description adds meaning: session must be 'pending', amount/token are fixed by merchant, and it accepts UUID or full URL. This enhances clarity beyond the schema's basic description.

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

  Purpose5/5

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

  The description clearly states the verb (pay) and resource (pending Solinkify Pay checkout session). It distinguishes from sibling tools like pay_get_session and spend_authority_status by specifying 'pending' status and the settlement process.

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

  Usage Guidelines5/5

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

  Explicit guidance: check spend_authority_status when owner wallet is used, confirm amount with pay_get_session first, and note that paid/expired sessions are refused. Clearly differentiates from read-only tools.

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

• gate_get_priceA
  5/5.0
  Behavior5/5

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

  No annotations provided, so description carries full burden. It fully discloses non-monetary nature ('costs nothing and never moves money'), behavior when URL not paywalled ('the tool says so instead of returning a price'), and preview functionality without side effects.

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

  Conciseness5/5

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

  Three concise sentences, each providing essential information: first states purpose and outputs, second provides usage guidance, third confirms no cost. No redundant words.

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

  Completeness5/5

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

  Given simple tool (1 parameter, no output schema, no nested objects), description is fully complete: covers purpose, inputs, return info, edge case, and usage context. No gaps.

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

  Parameters5/5

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

  Schema has 100% description coverage for the single 'url' parameter. The description adds context: specifies absolute https URL, gives example ('https://example.com/api/report'), and explains edge case behavior if not paywalled, exceeding schema info.

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

  Purpose5/5

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

  The description uses specific verb 'Preview' and resource 'Solinkify Gate paywall', detailing price, currency, and access modes. It distinguishes itself from sibling tool 'gate_fetch' by stating 'Call this before gate_fetch to learn the price' and clarifies it costs nothing and never moves money.

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

  Usage Guidelines5/5

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

  Clearly states when to use ('Call this before gate_fetch'), what it does not do (cost nothing, never moves money), and provides safety guarantee. Explicitly tells the agent to use this to learn price before gate_fetch.

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