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

Beyond the annotations (readOnlyHint=false, idempotentHint=false), the description discloses the real payment consequence ('pay-per-call USDC settlement'), the auth prerequisite (server signs EIP-3009 on behalf of the wallet whose PRIVATE_KEY is configured), the settlement flow via the x402 facilitator, and the inline response format: data plus the on-chain tx hash. It even states what is NOT needed (no subscription, no allowance, no prior on-chain setup). This is exactly the context annotations don't carry.

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

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

Six dense sentences front-loaded with purpose and payment model, then mechanism, alternative, catalog URL, and usage rules in logical order. Every sentence carries distinct info, though the enumeration of the 10 POST oracles duplicates the schema's feed description — a mild redundancy rather than waste.

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

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

With an output schema present and annotations covering idempotency/safety traits, the description fills all remaining gaps for a money-spending call: settlement mechanics, wallet/PRIVATE_KEY prerequisite, feed discovery URL, GET vs POST input rules, and explicit sibling routing. An agent has everything needed to invoke this tool correctly and understand what will happen.

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

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

Schema description coverage is 100% — both `feed` (with all 12 slugs and prices) and `body` (POST-oracle requirements) are already fully documented. The description restates the GET/POST switching rule and the oracle list in prose, adding marginal browsing value but no new meaning beyond the schema. Baseline 3 for high coverage is appropriate.

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

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

The description opens with a specific verb and resource: 'Buy a single data packet from any PayPerByte feed via the x402 payment gateway.' It explicitly differentiates from siblings by naming byte_subscribe ('continuous stream') and the feed schema names byte_query_fact for fact-oracle Q&A, so an agent can tell this purchase tool apart from subscription and query tools.

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

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

Gives exdirect when-to-use vs alternatives: 'Use byte_subscribe instead if you want a continuous stream of broadcasts from a publisher,' plus a schema note pointing to byte_query_fact for Q&A. It also tells the agent where to discover feed slugs (the free catalog GET) and exactly when to supply `body` — the GET feeds vs 10 POST oracles split.

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

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

Annotations already indicate readOnlyHint, idempotentHint, and non-destructive behavior. The description adds behavioral detail beyond annotations by explaining that it returns all active subscriptions with specific per-entry fields, and frames the operation as a read-only review activity. No contradictions found.

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

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

The description is compact and front-loaded: first the operation, then the exact output fields, then the intended use. Every sentence earns its place with no redundant phrasing or filler.

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

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

For a list-type read-only tool with a rich output schema and complete annotations, this description is sufficient. It tells the agent what the tool returns, why it should be used, and provides enough context alongside the schema for correct invocation.

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

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

Schema description coverage is 100%, so both `subscriber` and `indexerUrl` are already documented in the schema. The description only reiterates that the wallet address is used to list subscriptions, adding little semantic value beyond the schema.

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

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

The description states a specific operation: 'List every active subscription for a given wallet address.' It precisely identifies the resource (subscriptions), the scope (active, per wallet), and even enumerates the returned fields. This clearly separates it from sibling tools like byte_check_subscription, which checks an individual subscription.

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

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

The description provides a clear when-to-use statement: 'Use this to see what you're currently paying for and decide whether to unsubscribe.' It does not explicitly mention alternative tools or exclusions, but the context is unambiguous for the primary use case.

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

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

The description 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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

Goes beyond the readOnly/idempotent annotations by explaining the exact comparison windows (7 days vs 23-day baseline), the thresholds for each return value, and the edge case 'unknown' for new publishers. No contradictions with annotations; the description and annotations agree this is a read-only, idempotent operation.

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

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

Three sentences: one for purpose, one for algorithm and returns, one for usage. Every sentence carries necessary information and there is no redundancy. The most distinguishing content (signal categories and thresholds) is compactly and clearly presented.

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

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

With an output schema present for return values, the description still adds the algorithmic context, threshold meanings, and intended use-case. It covers the edge cases (new publisher, insufficient baseline) and enough operational detail that an agent can select and invoke the tool correctly without further clarification.

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

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

Schema description coverage is 100%: publisher and indexerUrl already have clear descriptions in the schema. The description adds only contextual flavor ('a publisher you subscribe to') without introducing new parameter meaning, syntax, or format details, so baseline 3 applies.

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

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

States a specific verb and resource: 'Get the content-drift signal for a publisher.' It further distinguishes itself from siblings by describing a unique comparison of recent activity against a baseline and enumerating the exact signal categories. The use case ('detect when a publisher you subscribe to has pivoted content or gone dormant') makes the tool's role in the sibling set unmistakable.

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

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

Provides clear context with 'Use this to detect when a publisher you subscribe to has pivoted content or gone dormant.' It does not explicitly name sibling alternatives or state when not to use it, such as versus byte_check_subscription for plain subscription status, so it stops short of full exclusionary routing.

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

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

Describes 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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.