Server Quality Checklist

Tool Scores

• byte_search_publishersB
  3.4/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint and idempotentHint, so the description only adds return field details. No additional behavioral traits (e.g., pagination, result ordering) are disclosed beyond what the schema provides.

  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?

  Single sentence that efficiently conveys action, resource, and return payload. No wasted words; front-loaded with the verb and key nouns.

  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 an output schema and clear parameter descriptions, the description is largely complete. Missing details like default sort order or case sensitivity are minor, given the tool's simplicity.

  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?

  All parameters have clear descriptions in the schema (100% coverage). The tool description adds no further meaning to the parameters, so baseline score of 3 is appropriate.

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

  Purpose4/5

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

  The description clearly states the tool searches publishers by topic and sort order, listing specific return fields. It implies a list-oriented search versus a single-publisher retrieval, but does not explicitly distinguish from sibling tools like byte_get_publisher.

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

  Usage Guidelines2/5

  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. It does not specify prerequisites, like requiring a registered publisher or subscription context, nor does it advise against use cases.

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

• byte_check_subscriptionA
  3.7/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the description's lack of explicit safety caveat is acceptable. However, the description does not add behavioral context beyond the annotation: it doesn't mention response details (e.g., whether it returns boolean, subscription info), or if any edge cases (e.g., invalid addresses) exist. It adds minimal value beyond the annotations.

  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 a single concise sentence that clearly conveys the tool's purpose. It is front-loaded and has no unnecessary words or filler.

  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?

  Given the tool's simplicity (two simple parameters, both documented, with a clear purpose), a single sentence is likely sufficient. The output schema exists, so return details are covered by that. However, the description could benefit from telling the agent whether the tool returns a boolean, status, or detailed subscription info, but that may be unnecessary given the output schema. It's minimally complete but not rich.

  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 description coverage is 100%, and each parameter has a clear description ('Subscriber Ethereum address', 'Publisher Ethereum address'). The tool description rephrases the parameters but doesn't add deeper semantic context (e.g., how these addresses are used, what format is expected beyond '0x...', or any relationship to the subscription). Since the schema already covers the parameters, the description adds little extra semantic value.

  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 ('Check if an address is subscribed'), the specific resource (a subscription on PayPerByte), and the key entities (address and publisher). It distinguishes itself from siblings like byte_list_my_subscriptions (which lists current user's subscriptions) and byte_subscription_health (which likely assesses health).

  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?

  While the description implies the tool is for checking a specific subscription status given an address and publisher, it does not provide explicit guidance on when to use this versus alternatives like byte_list_my_subscriptions, byte_subscription_health, or byte_get_token_balances. No exclusions or alternative suggestions are given.

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

• byte_get_publisherA
  4/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true and destructiveHint=false, establishing safety. The description adds value by specifying the returned data components (status, counts, revenue, schema), providing behavioral context beyond annotations. No contradiction.

  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 a single sentence that efficiently conveys the tool's purpose and key data fields. No redundancy or extra 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 low complexity (1 parameter), rich annotations, and existence of an output schema (not shown but implied), the description covers the necessary context. It lists the returned data types, making it complete for a read-only info retrieval tool.

  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's description of the single 'address' parameter ('Publisher Ethereum address (0x...)') is clear. The tool description does not add additional meaning 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 retrieves on-chain info for a specific PayPerByte publisher, listing concrete data fields (status, counts, revenue, schema). It distinguishes from sibling tools like byte_search_publishers (search multiple) and byte_list_feeds (list feeds) by its specificity to a single publisher address.

  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?

  The description implies usage when needing info on a specific publisher by address, but does not explicitly state when to use vs alternatives or provide exclusion criteria. Sibling tools exist, but no guidance is given.

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

• byte_publish_dataA
  4/5.0
  Behavior4/5

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

  The description adds meaningful behavioral context beyond the annotations by explaining what the action entails: 'Hashes the payload, records size on-chain, and settles the fee in USDC.' This is consistent with the destructiveHint and readOnlyHint in the annotations, and it discloses the side effects clearly.

  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, front-loaded with the primary action, and every sentence adds value. It is concise without excessive detail, making it easy for an agent to quickly grasp the tool's purpose and key behavior.

  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 complexity (a write operation with fee settlement), the description covers the essential behavioral aspects: hashing, on-chain recording, fee settlement, and the private key requirement. The presence of an output schema and full parameter descriptions fills the remaining gaps, making this reasonably complete.

  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?

  All three parameters are fully described in the input schema, so the description does not need to add parameter-level details. The description's mention of hashing and settling fees partially clarifies the purpose of 'data' and 'maxFee', but does not significantly exceed what the schema already provides. Thus, baseline of 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 action: 'Publish data to a subscriber via the PayPerByte DataStream contract.' This is a specific verb and resource that distinguishes it from sibling tools like 'subscribe' or 'buy_data'. The purpose is unambiguous.

  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?

  The description implies that this tool is used to publish data to a subscriber, but it does not explicitly state when to use it versus alternatives. It does mention a prerequisite ('Requires PRIVATE_KEY'), which provides some usage context, but there is no explicit guidance on when to prefer this tool over other byte_* tools.

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

• byte_list_my_subscriptionsA
  4.2/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true, idempotentHint=true, etc. The description adds useful behavioral context about the output fields (publisher address, topic, status, timestamps, messages, USDC). 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.

  Conciseness5/5

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

  Two sentences: first clearly states purpose and output, second gives actionable usage context. No redundant or unnecessary 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?

  With an output schema present (not shown but noted), the description adequately covers purpose, usage context, and high-level output fields. Could mention pagination or ordering, but not essential for most uses.

  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% with descriptions for both parameters. The description reiterates 'wallet address' but does not add significant new semantic detail 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 the verb 'list' and resource 'active subscriptions for a given wallet address', specifying output fields. It differentiates from siblings like byte_check_subscription which checks a single 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 provides a clear use case ('see what you're currently paying for and decide whether to unsubscribe') and implicitly distinguishes from siblings by listing all subscriptions. No explicit when-not-to-use or alternative tools mentioned.

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

• byte_register_publisherA
  4.2/5.0
  Behavior4/5

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

  Annotations already indicate a destructive, non-read-only operation. The description adds important context: requires PRIVATE_KEY, registers on-chain, and explains the stake approval flow. This goes beyond what annotations provide and shows no contradiction.

  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?

  Four concise sentences, front-loaded with the core purpose, and every sentence contributes new information. 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 registration tool with six parameters and an output schema, the description covers the essential context: purpose, on-chain side effects, private key requirement, and stake behavior. It does not detail parameter relationships or prerequisites beyond stake, but remains complete enough for an agent to use it correctly.

  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?

  All six parameters have descriptions in the schema (100% coverage), so the baseline is 3. The description adds a little extra meaning, mainly reinforcing the stake parameter's default and approval step, but does not significantly compensate for any missing parameter detail.

  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 ('Register as a data publisher') and specifies that it 'Registers a schema and the publisher on-chain.' This is specific and distinguishes it from sibling tools like byte_publish_data or byte_subscribe.

  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 explicit usage guidance for the stake parameter ('leave stake at 0') and notes the approval requirement for non-zero stakes, giving practical context. However, it does not explicitly name alternative tools or state when not to use this tool.

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

• byte_get_network_statsA
  4.3/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint, destructiveHint, idempotentHint, and openWorldHint, providing strong safety guarantees. The description adds value by specifying the exact output fields, but does not disclose additional behavioral traits like rate limits or data freshness. With annotations covering the safety profile, a score of 4 is appropriate.

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

  Conciseness5/5

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

  The description is a single sentence that efficiently conveys the purpose and details of the output. It is front-loaded with the action ('Get') and resource ('PayPerByte network-wide statistics'), earning its place without wasted 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 the tool has zero parameters and is well-annotated (read-only, idempotent), the description adequately explains what the tool returns. The existence of an output schema further supports completeness, but the description itself covers the key statistics.

  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 tool has zero parameters, and schema description coverage is 100% (trivially). With no parameters to describe, the baseline is 4. The description does not need to add parameter information.

  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 explicitly states the tool's purpose: 'Get PayPerByte network-wide statistics' and lists the specific statistics returned (total publishers, messages streamed, subscriber fees settled in USDC). This clearly differentiates it from sibling tools like byte_get_publisher (which focuses on a single publisher).

  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?

  The description implies usage for network-wide statistics, and sibling tools like byte_get_publisher suggest more focused alternatives, but there is no explicit guidance on when to use this tool versus others, nor any exclusion criteria.

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

• byte_list_feedsA
  4.3/5.0
  Behavior4/5

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

  Annotations already indicate readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true. The description adds specific behavioral context by stating it returns active feeds with topics, price-per-KB, and frequency, which is meaningful beyond the annotations.

  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 a single sentence that is clear, front-loaded, and contains no unnecessary words. It efficiently communicates the tool's purpose.

  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?

  With no parameters, comprehensive annotations, and an existing output schema, the description is complete. It explains what the tool does and what data it provides, leaving no significant gaps.

  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 the description does not need to add parameter information. Schema description coverage is 100%. The description adds value by clarifying what the tool returns, meeting the baseline of 4 for zero-parameter tools.

  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 ('List') and resource ('active data feeds in the PayPerByte catalog'), and mentions what details are included ('topics, price-per-KB, and frequency'). It clearly distinguishes from siblings like byte_search_publishers and byte_list_my_subscriptions.

  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?

  The description implies usage for browsing the catalog but does not explicitly state when to use this tool versus alternatives. No direct guidance on exclusions or when-not-to-use is provided.

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

• byte_get_token_balancesA
  4.4/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint, destructiveHint, idempotentHint, and openWorldHint, covering safety. The description adds valuable behavioral context: the network (Arbitrum Sepolia testnet) and the explicit exclusion of Base-mainnet balance, which goes beyond what annotations provide. No contradiction with annotations.

  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 primary purpose and immediately following with a critical exclusion. Every word serves a purpose, and there is no unnecessary information.

  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 a single parameter, comprehensive annotations, and an output schema, the description provides sufficient context about the network and the scope of balances. It is complete for the agent to understand usage. A minor improvement could be mentioning the expected balance format, but it's not necessary due to output schema.

  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% with a clear description of the address parameter. The tool description does not add additional parameter semantics beyond what the schema provides, so the baseline score of 3 is appropriate.

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

  Purpose5/5

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

  Description explicitly states the tool gets USDC and ETH balances for an address on Arbitrum Sepolia, clearly identifying the specific tokens and network. It distinguishes itself from the sibling tool byte_buy_data by stating what it does not show (Base-mainnet USDC balance), providing strong differentiation.

  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 clearly states when to use this tool (to get specific token balances on a specific testnet) and explicitly excludes when not to use it (for Base-mainnet USDC balance, which is handled by byte_buy_data). This gives the agent clear guidance on tool selection.

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

• byte_subscribeA
  4.7/5.0
  Behavior5/5

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

  The description discloses critical behavioral traits: the auto-allowance to type(uint256).max, the contract's silent failure path with DataStreamed emit and amount=0, and the skipAllowance option. These details go well beyond the annotations (readOnlyHint=false, destructiveHint=false) and are essential for understanding the tool's 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.

  Conciseness4/5

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

  The description is informative but slightly verbose with technical details about the allowance-skip path. However, the information is valuable and well-structured. A minor trim could improve conciseness, but it remains effective.

  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 presence of an output schema (not shown but implied from context), the description need not explain return values. It covers the main action, prerequisite, and edge cases (allowance depletion behavior). It is complete for a mutation tool with two parameters.

  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 significant meaning: clarifying that publisher is an Ethereum address, and explaining skipAllowance's default, the auto-approve logic, and the condition when it is skipped (wallet already has >= $1000 USDC allowance). This enriches the parameter 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 'Subscribe to a PayPerByte publisher's data feed' with a specific verb and resource. It distinguishes itself from sibling tools like byte_unsubscribe and byte_check_subscription by describing the core action and the default allowance setting behavior.

  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 includes a prerequisite ('Requires PRIVATE_KEY') and explains when to use skipAllowance: true vs the default. It could be more explicit about when to choose this tool over alternatives like byte_buy_data or byte_list_my_subscriptions, but it provides sufficient context for an AI agent to select it correctly.

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

• byte_subscription_healthA
  4.7/5.0
  Behavior5/5

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

  The description details behavioral traits beyond annotations: it compares two time windows (7 vs 23 days), explains the signal calculation (cadence, message count, silence), and defines each output value. This fully informs an agent of what the tool does and does not do, with no contradiction to annotations.

  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, with two sentences that front-load the purpose and then provide key usage details. Every part is necessary and there is no wasted text.

  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 output schema exists, the description need not explain return values. It covers the algorithm, edge cases (new publisher), and usage context, making it complete for a health check tool.

  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 both parameters (publisher and indexerUrl) already have descriptions. The tool description adds no additional meaning beyond the schema, so it meets the baseline for high coverage.

  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's purpose: 'Get the content-drift signal for a publisher.' It explains the comparison methodology and the possible return values, making it distinct from sibling tools like byte_check_subscription or byte_list_my_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: 'Use this to detect when a publisher you subscribe to has pivoted content or gone dormant.' This provides clear context and distinguishes the tool from others that might list subscriptions or check for new content.

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

• byte_unsubscribeA
  4.7/5.0
  Behavior5/5

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

  Describes effects (next block, no billing, no data flow) and reversibility (resubscribe via byte_subscribe). Adds substantial context beyond annotations, with no contradiction.

  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?

  Four concise, front-loaded sentences with 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.

  Completeness5/5

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

  Simple tool with one parameter and output schema. Description covers usage context, prerequisites, effects, and reversibility. Fully complete for an agent to select and invoke correctly.

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

  Parameters3/5

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

  Parameter 'publisher' already fully described in schema (address pattern). Description adds no new semantic details beyond what schema provides. With 100% coverage, baseline 3 applies.

  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 'Unsubscribe from a publisher's data feed', specifying the action and resource. Distinguishes from sibling tools like byte_subscribe and byte_subscription_health.

  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 advises when to use (pivoted content or no longer want feed) and suggests checking byte_subscription_health first. Notes requirement for PRIVATE_KEY.

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

• byte_buy_dataA
  4.8/5.0
  Behavior5/5

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

  Adds substantial behavioral context beyond the sparse annotations (readOnlyHint=false only): discloses real-money settlement in USDC on Base mainnet, the EIP-3009 authorization flow, the 402 challenge pricing mechanism, and a security warning to use a dedicated wallet. openWorldHint is consistent with the described external catalog lookup.

  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?

  Front-loaded with the core purpose and dense with high-value details (cost, auth, ports). It is long, but the multi-paragraph structure is earned by the complexity of the operation; every sentence adds information the agent needs to avoid paying real money by accident.

  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?

  Exceptionally complete for a high-stakes paid operation: covers cost, authorization flow, network (Base mainnet), required env/config vars, GET/POST switching, and where to find the full catalog. Return value is partially covered ('data comes back inline with the on-chain settlement tx hash') and an output schema exists, so nothing critical is missing.

  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% (baseline 3), and the description meaningfully enhances both params: it enumerates all feed slugs with per-call prices, explains the conditional behavior of the body param, and gives concrete JSON shape examples for the oracles. Slight redundancy with schema text, but adds clear value.

  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?

  Uses a specific verb+resource ('Buy a single data packet from any PayPerByte feed via the x402 payment gateway') that precisely identifies the action. Clearly distinguishes from siblings by naming byte_subscribe for streams and byte_query_fact for Q&A, and explains the GET vs POST call modes.

  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 tells the agent when to use alternatives: 'Use byte_subscribe instead if you want a continuous stream,' and 'For fact-oracle Q&A use byte_query_fact instead.' Also details when to supply body (POST) vs omit it (GET), and warns about the need for PRIVATE_KEY and USDC funding.

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

• byte_verify_payloadA
  4.9/5.0
  Behavior5/5

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

  The description goes well beyond the readOnlyHint/idempotentHint annotations by explaining the exact mechanism (recompute keccak256 and compare to EIP-712 PayloadAttestation hash), the signer-recovery behavior when txHash is provided, and the operational consequence of verified=false. It also states 'Read-only; no wallet or payment required,' adding auth/context value.

  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 compact yet information-dense. It front-loads the core purpose with 'Verify-before-act', immediately states the critical safety rule, then supplies anchoring options and read-only status. Each sentence contributes distinct value with no filler.

  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 moderate complexity, the description covers the full lifecycle: what it does, when it must be used, both verification modes, failure semantics, and read-only/auth implications. The presence of an output schema means return-value details are already handled, so the description is sufficiently complete.

  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%, so the baseline is 3. The description adds meaningful usage semantics beyond the schema: expectedHash is sourced from byte_query_fact/byte_buy_data, txHash recovers the attestation signer, and hashMode 'raw' matches byte_publish_data. This enriches parameter understanding without duplicating 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 names a specific verb and resource: verify a data payload against an on-chain attestation hash. It clearly distinguishes this from sibling tools by framing it as the verify-before-act counterpart to publish/query/buy data operations.

  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 call the tool ('ALWAYS call this on BYTE-sourced data before acting on it'), what to do on failure ('if verified=false the bytes were tampered/corrupted... MUST NOT be used'), and how to anchor the check with either expectedHash or txHash. This is strong, actionable usage guidance.

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

• byte_query_factA
  5/5.0
  Behavior5/5

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

  The description discloses key behaviors: posts a question, waits for broadcast, returns answer + citations. Emphasizes that signed receipt proves provenance, not answer correctness. Also provides latency estimates. No contradiction with annotations (readOnlyHint=false, openWorldHint=true).

  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?

  Concise yet comprehensive: 5-6 sentences covering purpose, process, caveats, and parameter specifics. No wasted words; front-loaded with purpose.

  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 complexity (6 params, output schema exists), the description covers all essential aspects: what it does, how it works, caveats, parameter meanings, and publisher availability. Output schema presumably handles return values, so no gap.

  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?

  Even with 100% schema coverage, the description adds meaningful context for all parameters: question (specific/verifiable), topic_filter (default), max_byte_cost (cost estimation), min_publisher_pqs (BPS scale), subscriber_address (subscription requirement), max_response_latency_ms (typical times). 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 clearly states the tool's purpose: query a fact-oracle publisher for a signed answer with citations. It distinguishes from sibling tools (e.g., searching publishers, subscribing) by focusing on the querying 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?

  Explicitly states when to use (need a signed answer with citations) and prerequisites (must be subscribed to a publisher). Also explains caveats like availability and timeout, and mentions the proof vs. correctness distinction.

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