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

Annotations already declare readOnly, idempotent, non-destructive, open-world, so the safety profile needs no repeating. Beyond that the description discloses genuinely useful behavior: a failed warehouse read reports as 'degraded' rather than 'none' (critical for interpreting empty results), the cost model ($0.03/call over x402 on Base), the prepaid x-credit-token header for unlimited calls, a 1-free-call/day allowance, and that no API key is required. It does not state pagination or freshness/latency for the feed, keeping it out of 5 territory.

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 core scope is front-loaded and informative, but the delivery is a long run-on sentence stitched with em-dashes, followed by fragments ('The record cost-basis and NAV need.'). The payment/access sentences earn their place for invocation, yet the whole is denser than needed and the grammar occasionally obscures meaning.

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, return-shape explanation is unnecessary, and the description instead supplies what the schema cannot: exact data coverage, the degraded-vs-none error semantics, access/pricing model, and one optional filter's effect. It is essentially complete for calling the tool correctly; only freshness/latency or pagination behavior 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 is 100% with only 2 optional params, so the schema already carries limit and symbol semantics; baseline is 3. The description reinforces symbol as a narrowing filter ('symbol= narrows to one stock') but adds nothing about limit's interaction with the events returned, and does not explain how limit applies across the three datasets (applied vs. announced vs. cumulative).

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 the exact resource and its three constituent datasets: applied dividends/splits with multiplier before/after and share accrual, announced-but-not-applied events, and cumulative accrual per stock, all scoped to Coinbase tokenized stocks on Base. That is concrete enough to separate it from generic siblings like corporate_actions or tokenized_stock_price. It stops short of naming any sibling explicitly, so it stays at 4.

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?

There is an implied use case — 'The record cost-basis and NAV need' points at portfolio/accounting reconciliation — and 'symbol= narrows to one stock' hints at drill-down vs. full-feed use. But there is no explicit when-to-use/when-not, no stated alternative for someone who just wants a current price (tokenized_stock_price) or generic corporate actions. Usage must be inferred.

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