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

No annotations are present, so the description carries full responsibility for behavioral disclosure. It states the tool subscribes to events, but does not mention auth requirements (beyond the subscriberDid parameter), whether the subscription is persistent, delivery method (webhookUrl is optional but unexplained), or any side effects like replacing existing subscriptions. The description gives little beyond the basic function.

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 and compact. However, the first sentence ('Catch earning opportunities the instant they appear') is promotional and adds no technical substance. The second sentence is informative, listing event types and the value proposition. It is concise overall, though the opening hook is not strictly necessary.

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 is simple with 3 parameters and no output schema, so the description need not be extensive. However, it lacks key operational context: what happens if webhookUrl is omitted, whether the subscription is ongoing or one-time, and any prerequisites (e.g., a registered agent with a subscriberDid). The event list is partial and does not map to all enum values. It is adequate but has gaps for a subscription 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 the baseline is 3. The description does not add any additional parameter details beyond what the schema provides; it mentions some event types (intents, trust changes) but not all enums, and provides no syntax or format guidance. The schema is sufficient, and the description adds minimal value here.

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

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

The description explicitly states the action ('Subscribe to real-time events') and specifies the resource (events across the agent ecosystem). It lists concrete event types (new intents, trust score changes, agents online, escrows updating), distinguishing it from sibling tools like 'broadcast_intent' or 'browse_intents' which focus on one-time 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?

The description conveys a clear use case: 'your agent reacts in seconds, not minutes,' implying this is for real-time responsiveness. It provides context (catching earning opportunities, reacting to ecosystem changes) but does not explicitly state when not to use it or name alternatives. Still, the guidance is sufficient for selecting this tool over polling or manual checks.

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