get_execution_snapshot

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

With no annotations provided, the description carries the full burden. It discloses critical behavior: normalization of spread and tick/pip units, rejection of crossed quotes and delayed data, and the readiness condition (only ready after a streaming bid/ask change). It also explicitly states it does not access accounts or place orders. This is rich, non-obvious behavioral context that an agent could not infer from the schema.

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?

Three dense sentences, each earning its place: what it observes, critical filtering/normalization behaviors, and explicit exclusions. The most important scoping ('read-only', 'one or more symbols') is front-loaded. No filler or repetition.

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 observation tool with 4 parameters and no output schema, the description covers the key behavioral guarantees (data quality checks, readiness condition, no account access). It could have mentioned what the return value looks like (e.g., aggregated bid/ask per symbol) since there is no output schema, but the readiness semantics effectively inform the agent what to expect.

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 75%, and the description adds context around timing parameters ('polling interval while waiting for an update', 'how long to poll for a post-request bid/ask change'). The main parameter 'symbols' has pattern constraints in the schema but the description adds the semantic that these are scanner symbols. Coverage is good, but the description could have clarified the units/meaning of max_quote_age_ms beyond 'chart lp_time'.

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 a specific verb ('Observe') and resource ('read-only TradingView scanner bid/ask conditions for one or more symbols'), clearly distinguishing itself from order-execution or account tools. It even states what it does not do ('does not access accounts or create, modify, or execute orders'), which eliminates ambiguity and reinforces its read-only nature.

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 implies when to use this tool for observing scanner bid/ask conditions and explicitly says it is read-only, which signals against using it for trading actions. It names no direct alternative among siblings, but the contrast with execution tools is implicit. It does not state explicit exclusions like 'use get_quotes for ...', so it stops short of a full 5.

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