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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the scoping constraint to 'nearest weekly/monthly expiry,' which is useful but not deep. It does not disclose how the expiry is selected, whether results are approximate, or any other behavioral traits beyond what annotations provide. Thus, it adds moderate value but not rich context.

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 extremely concise: one line for the purpose and a short Args block. It front-loads the core functionality without any fluff or repetition of schema content. Every sentence contributes meaning, making it easy to parse quickly.

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 has only one parameter and no output schema, the description carries the burden of explaining the return value. It lists the four key metrics, which gives a solid idea of what to expect. However, it does not specify the output format (e.g., price levels vs. percentages), how 'nearest' expiry is determined, or whether the map is numeric or descriptive. Still, it is fairly complete for a simple read-only tool, so it earns a 4 rather than a 3.

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 schema has only one parameter 'ticker' with no description (0% coverage). The description fully compensates by stating 'ticker: Stock symbol, e.g. "SPY".' which precisely conveys the expected input format and example. This is exactly what an agent needs to invoke the tool correctly, and the simplicity of the single parameter makes the coverage complete.

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 clearly specifies the tool's output: an option-chain pressure map for the nearest weekly/monthly expiry, listing concrete metrics (Max Pain, dealer Gamma Wall, likely weekly high, extreme squeeze target). This distinguishes it from sibling tools like get_iv_radar or get_pretrade_risk_scan, which focus on different market dimensions. Although it lacks an explicit verb, the combination of the tool name and description makes the action (generate/return a pressure map) unambiguous.

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 provides no guidance on when to use this tool versus alternatives such as get_iv_radar or get_pretrade_risk_scan. It does not mention any use cases, exclusions, or conditions. The only contextual hint is 'for the nearest weekly/monthly expiry,' which is a scoping detail rather than a usage recommendation.

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