get_market_snapshot

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

With no annotations provided, the description carries the full behavioral burden and discharges it exceptionally well. It discloses that the operation is read-only and point-in-time, that the result explicitly reports missing data, request-time timestamps, and quality status, that it never emits a trade instruction, and the subtle data-quality caveat that TradingView scanner values lack a common source timestamp so intraday timing is partial-quality evidence.

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 with zero filler: purpose is front-loaded in sentence one, output behavior and exclusions in sentence two, and the data-quality caveat in sentence three. Every sentence earns its place and the total length is appropriate for a tool with this complexity.

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?

Given the tool's complexity (8 parameters, no output schema, no annotations), the description covers the essential behavioral surface: what data is fetched, what the result reports, what it does not do, and the quality limitation. It stops short of enumerating the exact response structure, which would further reduce uncertainty for an agent, but this is a minor gap alongside the highly informative input schema.

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 100%, so the baseline is 3. The description adds high-level framing by grouping parameters into target vs. auxiliary symbols and 'optional economic events' and stressing that the overview and fields are 'shared', but it provides no per-parameter detail beyond what the schema already states. It reinforces the schema's semantics without meaningfully extending them.

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 states a specific verb and resource: 'Build a read-only, point-in-time market data snapshot' that 'fetches quotes and a shared multi-timeframe overview' plus optional economic events. This composite scope clearly differentiates it from siblings such as get_quotes (quotes only), get_mtf_overview (overview only), and get_economic_events (events only). The phrase 'does not produce a trade instruction' further separates it from decision-oriented siblings like get_trade_decision_context.

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 gives a clear use context ('for environment analysis') and an explicit exclusion ('it does not produce a trade instruction'), which helps an agent avoid misusing it as a decision tool. However, it does not name concrete alternative tools or spell out the when-not conditions beyond the trade-instruction exclusion, so the routing guidance stops short of explicit sibling differentiation.

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