timeframe_alignment

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

The description goes far beyond the annotations, disclosing data provenance (daily source, resampled weekly/monthly), absence of 4H/1H/15m and intraday OHLC, the ~500-session reach, and why monthly RSI(14) becomes null. It also directs the agent to read the `limits` field, making failure behavior explicit. No contradiction with annotations.

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 dense but each sentence carries material data-availability information; there is no filler. It front-loads the core purpose, though the four sentences could be tightened slightly without losing 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?

For a read-only analysis tool with a 2-parameter schema and no output schema, this description covers almost everything an agent needs: input semantics, data limitations, null behavior, and the `limits` field. It stops short of describing the overall response shape, but the stated outcome is sufficient for selection.

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%, so the baseline is 3; the description adds useful semantics beyond the schema by explaining that `bars` folds daily sessions and that monthly needs all of them (500). It also introduces `limits` as an output field, giving the agent context on what the parameters affect.

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 by framing the tool's purpose as determining whether daily, weekly and monthly views of a stock agree and what each timeframe can support. This is specific to a resource and distinct in intent from sibling price/indicator tools, though it lacks an explicit imperative verb like 'compute' or 'return' and does not name sibling differentiations.

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 description conveys implied usage: use it when time-frame agreement and data support matter, because it clarifies that weekly/monthly are resampled and intraday is unavailable. However, it does not explicitly state when to prefer this tool over siblings like technicals, price_chart, or quote, nor give exclusions.

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