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

Annotations already declare readOnly/idempotent/closed-world, but the description adds a genuinely behavioral point beyond them: values are 'computed point-in-time from data published by that day', which tells the agent there is no look-ahead bias and that historical answers are trustworthy. It also discloses coverage bounds (since 1990-01-01, filters since 2006), though it says nothing about payload size or latency for what is clearly a large response.

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 whole definition is effectively one long run-on sentence enumerating outputs ('the dollar index, crisis meter, market shock, market-top and recession risk with zones, the market-anomalies share, every sensor, the eight filters...'), which is hard to parse and includes vague filler like 'every sensor'. It is front-loaded and has no wasted preamble, but it would read far better as a short purpose sentence plus a compact output list.

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 enumeration of returned metrics is doing necessary work, and the point-in-time computation plus historical coverage boundaries give an agent enough to call correctly. The only real gap is response size/shape expectations for what is obviously a wide payload.

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 schema already documents the weekend/holiday rollback rule, so the description cannot add much for the single date parameter. Its one contribution, the 1990-01-01 lower bound, is a useful constraint not present in the schema, but it is stated in the context of outputs rather than the parameter, which keeps this at baseline.

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 a specific verb+resource ('what Isoba showed on any working day since 1990-01-01') and enumerates the returned metrics, so there is no ambiguity about what the call produces. It distinguishes itself from get_current_readings only implicitly, via the 'before 2008 / day of COVID' framing, rather than by naming the sibling.

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 closing line gives concrete usage questions ('what did it show before 2008 / on the day of COVID?') that make the historical-lookup use case clear and implicitly exclude 'what does it show now'. It stops short of naming an alternative tool (get_current_readings, get_monthly_history) or stating when not to use it.

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