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

No annotations are provided, so the description carries the full burden, and it does disclose the most consequential behavior: the default view is an aggregation scoped to a 7-day window returning counts plus a latest-per-type sample, while passing event_type/canonical_key switches to a paginated raw feed. Undisclosed are read-only/auth expectations and whether the aggregation is capped or how the legend is structured.

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?

Front-loaded with the core action, then branches efficiently into mode behavior and parameter effects, closing with the usage trigger. The first sentence is long and semicolon-chained, but every clause carries information about modes, pagination, or date format rather than filler.

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 5-parameter, no-annotation tool the description covers the mode switch, pagination, date format, and output shape, which is substantially complete; an output schema exists so return values need no further explanation. Missing are parameter defaults, valid event_type domain, and any note on the provenance/window boundary of 'recently'.

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 0% for all 5 parameters, so the description must compensate, and it largely does: it explains that limit/offset page through the feed, that since takes a YYYY-MM-DD value and widens the window, and that event_type and canonical_key switch to the full feed. It does not state valid event_type values, the meaning of canonical_key, or the defaults (limit=100, offset=0).

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?

States a specific verb and resource ('List tracked ecosystem events') and then precisely delineates its two operating modes: unfiltered aggregation (counts per event type over the last 7 days plus latest event per type plus legend) versus filtered full feed. This is far more specific than a generic list tool, but it never names or contrasts itself against likely-overlapping siblings such as get_mcp_ecosystem_summary, get_protocols_timeline, or pulse.

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?

Gives a clear situational trigger ('Use when the user asks what changed recently in the ecosystem') and conditional branches for parameter choice: set event_type or canonical_key for the full feed, set since to widen the window. It stops short of any when-not guidance or explicit alternative-tool routing.

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