tv_preopen_symbol_snapshot

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

With zero annotations, the description carries the full behavioral burden, but it only discloses that the result is 'compact' (a summarized response). It is silent on the clear auth expectations hinted at by the cookie/sessionid/sessionid_sign/authenticated parameters, on rate-limit or scraping-failure risks of a TradingView data pull, and on the return shape. This is a significant disclosure gap for a tool with no annotation safety profile.

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?

A single 12-word sentence that is front-loaded with the verb and includes zero filler. Every token earns its place: source (TradingView), data scope (pre-open/extended-hours), content type (review snapshot), size (compact), and granularity (one symbol).

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?

Despite its low complexity of a single required parameter, the tool has no output schema, no annotations, and several auth-related optional parameters whose roles are obscure. The description is complete enough to initiate a call but not complete enough for an agent to know whether a session must be established first, what the snapshot contains, or how it differs from tv_preopen_batch_snapshot and tv_auth_symbol_full. A cross-reference to those siblings is missing.

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 0% across 7 undocumented parameters, so the description must compensate — and it barely does. It only loosely maps 'symbol' (one symbol) and the broader pre-open context to market/session, leaving cookie, exchange, market, authenticated, sessionid, and sessionid_sign completely unexplained. An agent cannot know that session/auth fields likely must be populated from a tv_auth_session_* call.

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 uses a specific verb ('Return'), a precise resource ('compact TradingView pre-open/extended-hours review snapshot'), and a clear scope ('for one symbol'). The qualifiers 'compact' and 'pre-open/extended-hours' plus 'one symbol' differentiate it from siblings like tv_preopen_batch_snapshot and tv_auth_symbol_full without needing to open their schemas.

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?

Usage context is only implied by the phrasing 'compact... for one symbol' — an agent can infer it is for a quick single-symbol pre-market check rather than a batch or full export. However, it never explicitly names alternatives like tv_preopen_batch_snapshot, nor gives when-to-use / when-not-to-use conditions, so the routing decision is left to inference.

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