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

Annotations already declare readOnlyHint=true and idempotentHint=true. The description goes beyond by enumerating the exact return fields (publisher address, topic, status, subscription date, message counts, USDC spent, last message timestamp) and clarifying it lists only active subscriptions. It does not mention pagination or error behavior, but that is acceptable for a read-only list.

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, front-loaded with the action verb and resource. The field list is compact and the use case sentence adds value without unnecessary prose. No 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?

An output schema is present, so return structure is documented elsewhere. The description covers purpose, resource, fields, and intended use. It is complete for a simple read-only listing tool with no complex edge cases or side effects.

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% for both parameters. The description adds no new meaning beyond the schema; it simply references the subscriber as 'a given wallet address.' Since the schema already documents indexerUrl and subscriber with descriptions, the baseline 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 uses a specific verb+resource: 'List every active subscription for a given wallet address.' It clearly differentiates from siblings like byte_list_feeds (feeds vs subscriptions) and byte_check_subscription (single vs all). The detailed field list further clarifies the scope.

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 use case: 'Use this to see what you're currently paying for and decide whether to unsubscribe.' This gives context for when to use it. However, it does not explicitly name alternative tools or state when not to use it, so it falls short of full exclusion guidance.

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