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

Annotations already cover the read-only and open-world profile, and the description adds real behavioral context: the call returns a next_cursor for chaining, the delta includes resolved outcomes with real exit prices, and the since argument can be either a timestamp or a prior cursor. It does not mention result-size limits or behavior on first-ever call (no cursor), which keeps it below a 5.

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 delta statement, then contents, then the workflow, then the trigger condition — a sensible order. The middle sentence is a dense semicolon list, but every clause names a distinct returned resource, so little is wasted.

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 no output schema, the description carries the burden well by enumerating return contents and the next_cursor. Remaining gaps are minor but real: how to obtain an initial cursor, whether an empty delta is possible, and any cap on returned volume.

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% and the single parameter is already documented, so the baseline is 3. The description goes beyond by showing the intended value source ('since=last next_cursor') and tying it back to the returned cursor, explaining the continuation loop rather than just the type.

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?

Opens with a precise scope statement ('Delta since your last visit') and then enumerates the concrete resource types returned: indicator changes, resolved forecasts with outcomes, regime changes, blackboard entries, open questions, news/chat counts, and next_cursor. That enumeration clearly separates it from full-snapshot siblings like get_state or get_history.

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?

Explicitly states the triggering condition ('Call this when you come back and only want what changed') and supplies a concrete 'Return visit' workflow chaining get_changes -> read_blackboard -> get_forecast_results. It never names the alternative for a full refresh (e.g. get_state), so the when-not side is left implicit.

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