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

With no annotations, the description takes on the full disclosure burden. It explains an important behavior: minute_tier.included:false is not a gap, on_demand:true means sub-hour bars are fetched on first request with a latency range. It does not detail error cases or full response shape, but covers the most misleading behavior.

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 three sentences, front-loads the core definition, and keeps the critical caveat at the end. Every sentence earns its place: definition, recommended usage, and an important edge-case clarification. No 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?

With no output schema, the description must stand in for response semantics. It covers what the report contains (intervals, columns, time range, depth) and the key on_demand nuance. It does not specify the exact container or every possible response field, but it provides enough for correct invocation and interpretation.

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 sole parameter ticker has 100% schema description coverage ('Symbol'), so the baseline is 3. The description adds only the contextual notion of 'one ticker', which does not materially deepen the parameter semantics.

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 opens with 'Data-coverage report for one ticker' and specifies what it reports: intervals, columns, time depth, and depth. This clearly distinguishes it from data-retrieval siblings like get_ticker_bars or get_series by framing it as a coverage-checking endpoint.

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 explicitly instructs when to use the tool: 'ask this before assuming a gap in bars/series is a data outage vs. genuinely-never-covered.' It could be stronger by naming specific alternative tools, but the usage context is clear and actionable.

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