byte-protocol

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

The description discloses the exact process: the MCP server signs an EIP-3009 transferWithAuthorization, the x402 facilitator submits the tx, and data returns with the settlement tx hash. It warns that it settles REAL USDC on Base mainnet and recommends using a dedicated wallet. This goes beyond annotations by explaining the financial mechanism and risks.

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 detailed but every sentence adds necessary information. It is front-loaded with the core action and then provides contextual details. Minor redundancy could be tightened, but overall it is well-structured for a complex financial 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 involves real money transactions on a blockchain, the description covers all critical aspects: what it does, how it works, prerequisites, security recommendations, alternative tools, and where to find feed catalog. The presence of an output schema is not needed because the description already describes the return (inline data with tx hash).

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

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

The only parameter 'feed' is thoroughly documented in the schema with a list of valid slugs. The description adds context: it directs to the catalog for more feeds, and clarifies that for fact-oracle Q&A one should use 'byte_query_fact'. This adds semantic value beyond the schema enumeration.

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 it buys a single data packet from a PayPerByte feed, using the specific verb 'buy' and resource 'data packet'. It distinguishes itself from the sibling tool 'byte_subscribe' by specifying that this is for one-off purchases, while the sibling is for continuous streams.

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 explicitly provides usage context: 'No subscription, no allowance, no prior on-chain setup' and directs to 'Use byte_subscribe instead if you want a continuous stream'. It also mentions the catalog URL for available feeds and prerequisites like the PRIVATE_KEY env var and USDC balance, offering clear when-to-use and alternative guidance.

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

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

Annotations already provide readOnlyHint, idempotentHint, etc. The description adds no extra behavioral context beyond restating the purpose, so it doesn't enhance transparency beyond the structured fields.

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, no wasted words, perfectly concise for a simple check 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, rich annotations, and presence of an output schema, the description is complete enough—it clearly conveys the core function without needing more detail.

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 parameter descriptions are clear. The description adds no further meaning beyond what the schema already provides.

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 verb 'Check' and the resource 'subscription between an address and a publisher', and it distinguishes from sibling tools like byte_subscribe and byte_unsubscribe.

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

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

The description implies when to use (to check a specific subscription), but lacks explicit guidance on when not to use or alternatives, leaving the agent to infer usage context.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, covering risk and idempotency. The description adds the specific data returned (publishers, messages, fees), which goes beyond annotations but doesn't address potential behavioral traits like caching or latency.

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, front-loaded with the verb and resource, no wasted words. Perfectly concise for a zero-parameter 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 output schema is present (so return values need not be explained), the description is complete. It names three specific metrics, and the annotations cover safety and idempotency.

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?

With zero parameters and 100% schema coverage, the description needs no param details. Baseline for 0 params is 4, and the description correctly omits anything redundant.

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

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

The description clearly states the tool returns network-wide statistics including total publishers, messages streamed, and subscriber fees. It distinguishes itself from sibling tools like byte_register_publisher or byte_buy_data by focusing on aggregate metrics rather than individual actions.

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 no explicit when/when-not guidance is given, the tool's name and description make its purpose obvious. For a simple read-only stats tool with no parameters, the context is clear, though a brief note on when to prefer it over alternatives would elevate it.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, covering safety. Description adds behavioral context by listing the specific data returned (status, counts, revenue, schema), which goes beyond 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?

Single sentence, no wasted words. Purpose is front-loaded. Efficiently conveys the tool's function and output fields.

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, the description is sufficient. It lists the key return elements and the tool's purpose. No missing context.

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

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

Schema coverage is 100% and already describes the 'address' parameter. Description adds no additional meaning beyond implying the address identifies the publisher. 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?

Description clearly states 'Get on-chain info for a specific PayPerByte publisher' and lists specific fields (status, counts, revenue, schema). This distinguishes it from siblings like 'byte_search_publishers' which is for finding publishers.

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?

Description implies use when needing info on a specific publisher, but does not explicitly contrast with alternative tools like 'byte_search_publishers' or mention when not to use. No when-to-use guidance 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, openWorldHint, idempotentHint, destructiveHint. Description adds network-specific context (Arbitrum Sepolia) and clarifies scope (only that testnet), which is valuable behavioral info. No contradictions 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?

Two concise sentences: first states purpose and network, second clarifies exclusion. No wasted words, information is front-loaded.

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

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

Output schema exists, so return values are likely documented. Description clearly states what balances are retrieved (USDC and ETH on Arbitrum Sepolia) and network context. It does not mention pagination or rate limits, but for a simple balance check it is complete for selection and 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?

Input schema covers the single parameter 'address' with description. Schema description coverage is 100%, so the description does not need to add parameter details. Baseline 3 is appropriate as the description adds no extra parameter semantics.

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

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

Description states specific verb 'Get', resource 'USDC and ETH balances for an address', and network 'Arbitrum Sepolia'. It distinguishes itself by noting it does NOT show Base-mainnet USDC balance, which differentiates from sibling tool byte_buy_data.

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

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

Description provides context on when to use (for Arbitrum Sepolia testnet balances) and explicitly states what it does not do (Base-mainnet USDC). It contrasts with byte_buy_data, offering a clear alternative, but lacks explicit 'when not to use' for other scenarios.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false. The description adds that the output includes topics, price-per-KB, and frequency, but does not provide additional behavioral context beyond what annotations convey.

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, clear sentence with no unnecessary words. It is front-loaded with the core action and resource.

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 zero parameters and the presence of an output schema, the description is sufficient for a simple list tool. It could mention ordering or pagination, but that is not essential.

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?

No parameters exist, and schema coverage is 100%. The description does not need to explain parameters. Baseline score for zero parameters 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 lists all active data feeds and specifies the included attributes (topics, price-per-KB, frequency). This distinguishes it from sibling tools like byte_buy_data or byte_publish_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?

No explicit guidance on when to use this tool versus alternatives. However, the context of listing feeds is implied, and sibling tool names suggest differentiation. A more explicit statement would improve clarity.

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?

Description adds output field details beyond annotations (publisher, topic, status, etc). Annotations already confirm read-only, idempotent, non-destructive nature. No side effects mentioned but not needed given 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?

Two sentences, no fluff. Front-loads purpose and output fields, then adds usage guidance. Efficient and well-structured.

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 that output schema exists and description lists the key fields, the tool is fully specified. No missing information for a read-only list operation.

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%. Description does not add meaning beyond schema; it only restates the purpose of the subscriber and indexerUrl parameters. 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?

Description clearly states it lists active subscriptions for a wallet, with specific output fields. Distinguishes from sibling tools like byte_subscribe and byte_unsubscribe.

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 using it to review subscriptions and decide whether to unsubscribe. Provides clear context but lacks explicit when-not-to-use or alternative 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?

Annotations already indicate destructive and mutable behavior. The description adds specific behavioral details: hashing the payload, recording size on-chain, settling fees in USDC, and requiring PRIVATE_KEY. This goes beyond what annotations provide, giving a clear picture of side effects and prerequisites.

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 with no unnecessary words. It is front-loaded with the main purpose and efficiently conveys key actions and requirements.

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

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

The description covers the core functionality, on-chain effects, and auth requirement. With an output schema present, it does not need to explain return values. It could include minor details like address format, but overall it is sufficiently complete for a three-parameter tool.

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

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

Schema description coverage is 100%, so baseline is 3. The description does not add significant meaning beyond the schema's parameter descriptions; it only mentions the payload being hashed and fee in USDC, which is already implied.

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 verb 'publish', the resource 'data to a subscriber via the PayPerByte DataStream contract', and specific actions like hashing, recording size, and settling fees. It distinguishes from siblings by focusing on publishing data, which is not covered by other tools like byte_subscribe or byte_buy_data.

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

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

The description mentions that the tool requires a PRIVATE_KEY, implying that it is for on-chain interaction, but does not explicitly state when to use it over alternatives or when not to use it. 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?

The description comprehensively details behavioral traits: it posts a question to a registered publisher, waits for an on-chain BroadcastStreamed response, and returns structured citations. It explains cost and latency implications via parameters like max_byte_cost and max_response_latency_ms. 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?

The description is three sentences long, front-loaded with the core purpose. Each sentence adds meaningful information without redundancy. It is well-organized and easy to parse.

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

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

Given the tool's complexity (6 parameters, annotations, output schema), the description covers all essential aspects: purpose, usage, behavior, and parameter details. It is sufficiently complete for an AI agent to understand and invoke the tool 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?

With 100% schema coverage, the baseline is 3. The description adds value by providing examples and contextual defaults (e.g., 'max_byte_cost defaults to 2000, ≈$1 at $0.0005/byte'), which goes beyond the schema's basic descriptions.

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 ('query'), the resource ('PayPerByte fact-oracle publisher'), and the output ('verified factual answer with citations'). It distinguishes itself from sibling tools like byte_buy_data or byte_publish_data by specifying its unique role in grounding LLM outputs with real-time verified information.

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 explicit guidance on when to use the tool ('for grounding LLM outputs in real-time verified information'), implying a clear use case. It does not explicitly mention alternatives or when not to use it, but the context and sibling list offer sufficient differentiation.

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 destructiveHint=true, but the description adds valuable behavioral context: it requires a PRIVATE_KEY, explains the stake default and approval process, and clarifies that PayPerByte v1 publishers are first-party and unstaked. This goes beyond the annotations' binary safety flags.

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-loading the core action. It is compact and avoids redundancy, though the last sentence about stake is somewhat dense and could be split for clarity. Still, it earns its space.

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, the description does not need to detail return values. It covers prerequisites, parameter behavior, and the on-chain nature. However, it omits error handling, confirmation, or next steps after registration. Still, it is nearly complete for this tool's complexity.

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

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

Schema coverage is 100% with detailed parameter descriptions. The tool description reiterates the stake parameter's behavior but does not add significant new meaning beyond the schema. 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's purpose: 'Register as a data publisher on PayPerByte. Registers a schema and the publisher on-chain.' It uses specific verbs ('register') and resource ('data publisher', 'schema', 'publisher on-chain'), and the distinct name distinguishes it from sibling tools focused on buying data, subscribing, etc.

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 (registering as a publisher) and mentions a prerequisite ('Requires PRIVATE_KEY'), but it does not explicitly state when to use this tool versus alternatives or what conditions exclude its use. No guidance on when not to use it.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. Description adds that it returns specific fields (addresses, topics, etc.), providing useful context beyond annotations without 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?

Two short sentences, front-loaded with the action and resource. No redundant words; every part earns its place.

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

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

With 3 optional params fully documented, good annotations, and an output schema (though not shown), the description is complete. It covers the what, how, and what is returned.

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 parameters described). Description does not add new meaning beyond the schema's parameter descriptions; it only restates that search is by topic and sort order.

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?

Clear verb 'Search' with specific resource 'PayPerByte publishers' and criteria 'by topic and sort order'. Distinguishes from siblings like byte_get_publisher (single) and byte_list_feeds (list all).

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?

Description clearly indicates when to use: search by topic and sort order. No explicit when-not or alternatives, but the context is clear enough for an agent to infer appropriateness.

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?

Fully discloses the default USDC allowance setting behavior and the failure path (emits DataStreamed with amount=0 on transferFrom failure). Explains the skipAllowance option and the auto-skip condition. No contradiction with annotations (readOnlyHint=false, destructiveHint=false).

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 front-loaded with the core purpose and provides necessary details without excessive fluff. It is slightly lengthy due to technical explanation, but each sentence adds value. Could be slightly more concise.

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 parameter count (2) and complete schema coverage, the description fully explains the tool's behavior, including edge cases (allowance depletion, skipAllowance). The presence of an output schema (not shown but provided in context) means return values need not be described. Entirely complete for this tool's complexity.

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

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

Schema coverage is 100% with clear descriptions for both parameters. The description adds meaning by explaining the skipAllowance default and the logic behind auto-approval. Also mentions the PRIVATE_KEY requirement, which is not in the schema. Adds 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 explicitly states 'Subscribe to a PayPerByte publisher's data feed,' clearly identifying the action (subscribe) and resource (publisher's data feed). It distinguishes from siblings like byte_unsubscribe and byte_check_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?

Provides clear guidance on when to use the tool (subscribing to a publisher) and when to use the skipAllowance parameter. Also explains the default allowance behavior and the PRIVATE_KEY requirement. However, it does not explicitly compare to alternative tools like byte_check_subscription for checking status.

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, idempotentHint=true, and destructiveHint=false, establishing safety and idempotency. The description adds substantial behavioral detail: it explains the algorithm (comparing last 7 days against a 23-day baseline), the possible return values ('stable', 'moderate', 'significant', 'unknown'), and the conditions for each. This fully compensates for any missing annotation detail and provides valuable context beyond 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 concise and well-structured, with the primary purpose stated first. It consists of three sentences that efficiently convey the tool's function, algorithm, and recommended usage. No extraneous information is included, and every sentence contributes to understanding.

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 annotations (readOnly, idempotent, non-destructive) and output schema (present but not needed for completeness), the description is remarkably complete. It covers the tool's purpose, the algorithm, the possible output values, and the context for use. It does not miss any critical behavioral information, making it fully adequate for an AI agent to select and invoke the tool correctly.

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

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

Schema coverage is 100%, meaning both parameters (publisher, indexerUrl) are described in the input schema. The description does not add new semantic information about the parameters beyond what the schema provides. The schema descriptions are already clear, so the description adds no additional value for parameter understanding. 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's purpose: 'Get the content-drift signal for a publisher.' It specifies the verb (Get), the resource (content-drift signal), and the context (publisher). This is distinct from sibling tools like byte_check_subscription, which likely checks subscription status, making it easy to differentiate.

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 explicitly advises when to use the tool: 'Use this to detect when a publisher you subscribe to has pivoted content or gone dormant.' This provides clear context for usage. It does not explicitly mention when not to use it or list alternatives, but the guidance is sufficient for an AI agent to understand its applicability.

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 the mutation effect, timing ('next block'), and reversibility. Notes PRIVATE_KEY requirement. Annotations (destructiveHint=false, idempotentHint=false) do not contradict. Could mention prerequisites like existing subscription.

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 concise sentences: definition, effect+reversibility, usage guidance. No wasted words, front-loaded with core action.

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 unsubscription tool with output schema, description covers key aspects. Could mention error conditions or prerequisites (e.g., must be subscribed) but implied by context.

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

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

Only one parameter (publisher) with full schema coverage (pattern and description). Description adds no extra semantic meaning beyond schema. 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?

Clearly states 'Unsubscribe from a publisher's data feed' and explains the effect (next block, no billing/data flow). Distinguishes from siblings 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 tells when to use (publisher pivoted content or simply don't want feed) and mentions checking byte_subscription_health first. Also notes reversibility via byte_subscribe. Does not explicitly state when not to use, but context is strong.

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, so the description adds value by explaining the verification mechanism (recomputing keccak256 and comparing to on-chain hash) and the recovery of the attestation signer when txHash is used. It discloses that if verified=false the data is tampered. 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 a single paragraph that front-loads the core purpose. Every sentence contributes necessary information (purpose, method, mandatory usage, failure consequence, anchoring options). It is slightly dense but not verbose. No redundant or filler content.

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

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

The tool has an output schema, so return values are assumed to be documented there. The description covers the verification process, the two anchoring methods, and the critical failure implication. Given that this is a verification tool with clear inputs and outputs, the description is sufficiently complete for an agent to understand when and how to use it.

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%, providing baseline descriptions for all parameters. The description adds context beyond the schema by explaining how the parameters are used in the verification flow (e.g., 'data' as the exact payload to verify, 'txHash' to also recover signer, and the difference between 'raw' and 'canonical' hashing modes). This helps the agent choose between expectedHash and txHash.

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 starts with a clear verb-resource pair: 'Verify-before-act: confirm a data payload ... actually matches what the publisher cryptographically attested to on-chain.' It specifies the resource (BYTE-sourced data payload) and the action (cryptographic verification). This distinguishes it from siblings like byte_query_fact (query) and byte_buy_data (purchase), as it is a safety check to be used before acting on 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 explicitly states when to use the tool: 'ALWAYS call this on BYTE-sourced data before acting on it.' It also explains the consequence of verification failure ('bytes were tampered/corrupted in transit and MUST NOT be used') and provides two anchoring methods (expectedHash or txHash). While it does not mention when not to use it, the use case is clear and imperative.

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