xrpl_pulse_events_by_address

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

With no annotations, the description carries the full burden. It discloses the cost ($0.10 USD) and event categories, which is useful. However, it omits critical behavioral details such as whether payment_signature is required, how pagination works, or what the response contains.

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 front-loads the cost and then states the purpose. It is compact and without waste, though it could have been more structurally complete with an explicit verb.

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 paid tool with 4 parameters and no output schema, the description is under-specified. It fails to explain how payment is made via payment_signature, what the default time window is, or the nature of the response. This leaves significant gaps for an agent trying to invoke 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?

The description adds context about the data (address-specific events) but does not elaborate on individual parameters like limit, since_iso, or payment_signature. With 75% schema coverage, the description provides marginal semantic value beyond the schema's existing parameter 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 tool's function: it returns pulse events (whale, sentinel signal, news, permissioned-domain) referencing a specific XRPL address. It distinguishes itself from siblings by name-dropping xrpl_sentinel_scan and adding 'event history' as a complement.

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?

It implies when to use this tool: for address-specific event history, complementing xrpl_sentinel_scan. However, it does not explicitly state when not to use it or name alternative tools like xrpl_pulse_recent_events, leaving some ambiguity.

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