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 indicate safe read-only, idempotent, non-destructive behavior. The description adds context about what statistics are returned (publishers, messages, fees), but does not disclose additional behaviors like pagination or latency. With annotation coverage, this is adequate but not rich.

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 front-loads 'Get' and the resource name, then enumerates the specific statistics. No wasted words or redundancy.

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

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

With zero parameters and an output schema present, the description fully covers what the tool does. It clearly states the scope (network-wide) and the key data points (publishers, messages, fees), making it complete for 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?

The tool has 0 parameters, so the baseline is 4. The description adds no parameter information because none is needed; the schema fully covers the (empty) parameter set.

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 ('Get') and specific resource ('PayPerByte network-wide statistics') with concrete details (total publishers, messages streamed, USDC fees). This clearly distinguishes it from sibling tools that target individual publishers or specific data.

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

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

The description implies this tool is for global network statistics versus publisher-specific tools like byte_get_publisher or byte_list_feeds, but it doesn't explicitly state when to use it or name alternatives. The context is clear but no exclusions or comparisons are 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 declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds value by enumerating the exact data returned (status, counts, revenue, schema), giving context beyond the annotations without contradicting them.

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

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

A single, front-loaded sentence with a clear verb and a parenthetical list of returned fields. No unnecessary words or redundancy.

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

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

For a simple one-parameter read-only tool with an output schema present, the description adequately covers the tool's function and output. The sibling context confirms its specific niche, and no critical information is missing.

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 for the single 'address' parameter is 100%, and the schema already describes it as a 'Publisher Ethereum address (0x...)'. The description does not add new parameter-level meaning but is consistent with the schema.

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

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

The description clearly states the tool's purpose: 'Get on-chain info for a specific PayPerByte publisher' with a detailed list of returned data. The verb 'Get' and resource 'specific PayPerByte publisher' distinguish it from sibling tools like byte_search_publishers or byte_list_feeds.

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 a specific publisher but does not explicitly state when to use it over alternatives or mention exclusions. The phrase 'specific PayPerByte publisher' suggests this is for fetching details by address, but no direct comparison to sibling tools 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 declare read-only, idempotent, and non-destructive behavior. The description adds meaningful context beyond this, such as the testnet nature of Arbitrum Sepolia, the role of MockUSDC in settling subscriptions and fact-oracle queries, and the exclusion of Base-mainnet balances. This helps the agent understand the operational context and constraints.

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 concise and well-structured: two sentences, with the main action front-loaded in the first sentence and critical clarification in the second. Every sentence adds value without redundancy.

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

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

For a simple read-only tool with one parameter and an existing output schema, this description is highly complete. It specifies the exact tokens, network, the address scope, and explicitly mentions what it does not include, providing sufficient context for correct tool selection.

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 provides 100% coverage for the single 'address' parameter with a clear description ('Ethereum address (0x...)'). The tool description adds no additional parameter-specific information, so baseline 3 is appropriate since the schema carries the semantic weight.

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

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

The description clearly states the tool's function: getting USDC and ETH balances for an address on Arbitrum Sepolia. It specifically names the tokens and network, and distinguishes from sibling tool byte_buy_data by explicitly stating what it does NOT show, making the purpose unambiguous.

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

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

The description provides clear context for when to use this tool: when checking USDC/ETH balances on Arbitrum Sepolia, and it explicitly notes it does not show Base-mainnet USDC spent by byte_buy_data. This implies the alternative for Base-mainnet balances but does not explicitly say 'use byte_buy_data for that', so it is not a full when-to-use guide.

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=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, covering safety and side-effect transparency. The description adds concrete behavioral details about the return fields (addresses, topics, subscriber counts, message counts, price-per-KB) and the search/sort behavior, which is useful beyond the 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, well-structured sentence that front-loads the core action and includes essential return information. Every word earns its place, with no redundancy or fluff. It is appropriately sized for a simple search tool.

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 (3 optional params, no required args, no nested objects) and the presence of an output schema (as per context signals), the description fully covers what the agent needs: what it searches, how results are ordered, and what fields are returned. The annotations and schema handle the rest. This is complete for a search 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%: all three parameters (limit, query, sortBy) have descriptions in the schema. The description adds no extra parameter meaning beyond what the schema already provides. The mention of 'topic' and 'sort order' mirrors the schema fields, so the baseline score of 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?

The description specifies the exact action ('Search PayPerByte publishers') and scope ('by topic and sort order'), clearly distinguishing it from siblings like byte_get_publisher (likely single publisher lookup) and byte_list_feeds (listing feeds). The verb 'Search' plus the explicit resource and modifiers makes the purpose unambiguous.

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

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

The description implies usage: use this when searching publishers by topic with sort/limit options. It does not explicitly mention alternatives or exclusions, though the sibling tool names provide context. Without explicit 'when to use vs. alternatives' guidance, it falls at the 'implied usage' level.

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 annotations (readOnlyHint=false, destructiveHint=false) by detailing the default USDC allowance behavior, the allowance-skip path with its silent payment loss mitigation, the `skipAllowance` opt-out, and the PRIVATE_KEY requirement. It also explains the contract's transferFrom failure behavior, providing deep behavioral insight that helps the agent predict 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 concise (three sentences) and front-loaded with the main purpose. Each subsequent sentence adds distinct value: the allowance default, the skipAllowance option, and the PRIVATE_KEY requirement. While it is a bit dense with technical details, it is appropriately sized for the complexity and does not contain redundancy.

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

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

Given the existence of an output schema and the moderate complexity of the tool, the description covers all essential aspects: what the tool does, the default allowance behavior, the opt-out path, and a critical requirement (PRIVATE_KEY). It doesn't need to describe return values because the output schema exists, and it provides enough context for an agent to select and invoke the tool correctly without additional information.

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

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

The input schema already describes the `publisher` and `skipAllowance` parameters with 100% coverage. The description adds a small but useful nuance: 'Pass skipAllowance: true to opt out and set a finite cap manually.' This adds a new semantic (finite cap) not explicitly mentioned in the schema, slightly enhancing the parameter understanding. Given the high schema coverage, a score of 4 is appropriate for the extra value added.

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: 'Subscribe to a PayPerByte publisher's data feed.' It uses a specific verb ('Subscribe') and resource ('data feed'), and it adds the key behavior of setting an allowance, which distinguishes it from sibling tools like byte_buy_data or byte_unsubscribe. The scope is unambiguous and aligns with the tool name.

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

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

The description provides a clear context for when to use the tool (when you want to subscribe to a data feed), but it does not explicitly mention alternatives or when-not-to-use cases. It does explain the `skipAllowance` option, which is a parameter-level guideline, but there is no explicit comparison to sibling tools like byte_buy_data or byte_list_my_subscriptions. This is implied rather than explicitly stated.

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

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

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?

The description adds valuable behavioral context beyond annotations: it discloses the timing effect ('next block'), the consequences ('no more billing, no more data flow'), reversibility, and the authentication requirement (PRIVATE_KEY). This complements the annotations (readOnlyHint=false, destructiveHint=false) without contradicting them.

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 concise and front-loaded with the main action, then adds key details in just three sentences. Every sentence provides essential information—purpose, effects, reversibility, use case, and auth—without 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?

For a single-parameter tool with good annotations and an output schema, the description fully covers the lifecycle: when to use, what happens, reversibility, and prerequisites. There are no critical gaps; it elegantly combines purpose, usage, and technical effect.

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 the parameter described as 'Publisher address to unsubscribe from,' which is clear. The description doesn't add extra parameter semantics, but the baseline for full schema coverage is a 3, and the description's mention of 'publisher' aligns with the schema. No additional insight needed.

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

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

The description clearly states the action: 'Unsubscribe from a publisher's data feed.' It uses a specific verb and resource, and distinguishes itself from sibling tools by immediately referencing the reverse operation (byte_subscribe) and the health check tool (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 provides when to use: 'when a publisher has pivoted content... or when you simply don't want the feed anymore.' It also names alternatives like checking byte_subscription_health first and resubscribing via byte_subscribe, giving 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?

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.