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

With no annotations provided, the description fully carries the transparency burden. It discloses exact signal criteria (Vol/OI ≥ 3.0 high, ≥ 1.5 medium, Vol ≥ 50 with OI = 0 for opening_position), noise filtering (volume < 10), and the complete return structure (FlowResponse JSON with fields listed).

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?

Despite being somewhat long, the description is well-structured with labeled sections (Signals, Plan, Args, Returns) and every sentence provides value. It avoids redundancy and front-loads the core purpose.

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 and lack of output schema, the description provides a complete picture: detection logic, return format with field names, and plan requirements. It is sufficient for an agent to invoke the tool correctly and interpret results.

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 no descriptions (0% coverage), but the description thoroughly explains both parameters: 'symbol: Underlying ticker' and 'expiration: Unix timestamp of a specific expiry, or "all". Omit for the nearest expiry.' This adds semantic meaning well beyond the bare schema names.

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 states the tool's function: 'Unusual options activity detection' with specific signal types (unusual_volume, opening_position). This distinguishes it from sibling tools like get_max_pain or get_greeks, which serve different purposes.

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 usage context such as the plan requirement ('Plan: Trader and up') and signal thresholds for interpretation. It does not explicitly name alternative tools for when not to use this one, but the focus on unusual flow is clear enough to guide selection.

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

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

With no annotations provided, the description carries the burden of explaining behavior. It discloses the return structure and adds interpretive context (positive/negative Net GEX meaning, gamma flip). It does not mention rate limits or errors, but for a read-only data tool this is acceptable.

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 well-organized with a purpose summary, plan requirement, arguments list, and return description. Each section is concise and adds value; the Gamma Flip explanation is brief but relevant.

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?

The description is nearly complete for a read tool without an output schema, listing the main return fields and their meaning. It misses clarifying whether `symbol` is still required when `symbols` is provided (schema says required), which could confuse an agent.

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%, but the description thoroughly documents all three parameters. It explains symbol as the ticker, expiration as Unix timestamp with 'all' and default nearest expiry, and symbols as an optional comma-separated list that takes precedence over symbol.

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 states the tool's function: it provides Gamma & Delta Exposure (GEX/DEX) per strike, total Net GEX, and the Gamma Flip level. It distinguishes itself from siblings like get_greeks and gex_heatmap by focusing on GEX/DEX data and regime transitions.

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 includes 'Plan: Trader and up' which is a subscription constraint, and explains parameter usage like omitting expiration for the nearest expiry. However, it does not provide explicit guidance on when to choose this tool over siblings such as get_greeks or gex_heatmap.

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

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

No annotations are provided, so the description carries the full burden. It discloses key behaviors: default expiration behavior (omit for nearest), the 'all' option, 'atm' range restriction, moneyness format, and limit semantics. It also describes the return JSON structure. It does not explicitly state read-only behavior or error handling, but the read-only nature is strongly implied by the name and output.

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 well-structured and front-loaded: a clear purpose sentence, a brief plan note, then an Args list and Returns section. The Args section is somewhat lengthy but necessary given the lack of schema descriptions. No unnecessary fluff.

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?

The description covers purpose, all parameters, and the return structure, which is especially valuable given no output schema exists. It lacks examples or edge-case handling, but for a data retrieval tool with moderate complexity, it is sufficiently complete.

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%, so the description must compensate. It thoroughly documents all five parameters, including symbol, expiration (with 'all' and default behavior), range ('atm'), moneyness (with example format), and limit (per side). This fully explains the parameters beyond the bare schema.

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 states the tool computes Black-Scholes Greeks (Delta, Gamma, Theta, Vega, Rho) plus theoretical price and mispricing for every contract in the chain. This specific verb and resource distinguish it from sibling tools like get_gex or get_max_pain.

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 usage through its focus on Greeks and mentions 'Plan: Trader and up' as an access constraint, but it does not explicitly state when to use this tool versus alternatives like get_snapshot or get_overview. No exclusions or alternative recommendations are provided.

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

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

No annotations are provided, and the description only states it returns a LevelsResponse JSON computed by the analytics engine. It does not disclose read-only status, potential errors, or any side effects, leaving the agent under-informed about behavioral traits.

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 concise and well-structured, with a summary line and an Args section, using no unnecessary words. It is appropriately front-loaded with the core purpose.

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 simple 2-param read-only tool, the description is fairly complete, explaining inputs and the general output type. However, it lacks detail on the exact structure of the LevelsResponse and error conditions, so it is not perfect.

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?

Despite 0% schema coverage, the description fully explains the meaning of both symbol and expiration, including the 'all' keyword and default behavior of omitting for nearest expiry, adding significant semantic value beyond the raw schema.

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 states the tool returns key options-derived price levels for a symbol (support/resistance style from gamma and open-interest structure), specifying the resource and distinguishing it from sibling tools like get_gex or get_greeks.

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 explains expiration parameter usage (specific timestamp, 'all', omit for nearest), but it does not explicitly mention when to use this tool compared to alternatives from the sibling list. The usage context is implied but not contrasted with other tools.

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

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

With no annotations, the description carries the full burden. It discloses the return format ('raw MaxPainResponse JSON: symbol, spotPrice, timestamp, and results[]...'), explains the expiration parameter's behavior, and notes the slower performance for 'all'. It also mentions the 15-min delay on free plans. This is strong transparency, though it doesn't explicitly state the read-only nature or potential rate limits beyond plan info.

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 well-structured into Plan, Args, and Returns sections. Every sentence is informative: concept, plan limitations, parameter details, and return schema. No wasted words or redundancy.

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 no annotations and no output schema, the description is exceptionally complete. It covers the concept, plan limitations, parameter semantics, and return fields. The tool is a simple data retrieval, and all necessary context is provided without needing external documentation.

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 0%, but the description fully compensates with an 'Args:' section that explains both parameters. For symbol, it provides examples ('AAPL', 'SPY', 'NDAQ'). For expiration, it clarifies it is a Unix timestamp, supports 'all' (slower/complete), and notes omission defaults to nearest expiry. This adds meaning far beyond the bare schema.

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 states the tool's purpose: 'Max Pain per expiration — the strike that minimizes total option value...' This is a specific verb+resource with a defined concept, and it distinguishes itself from siblings like get_greeks, get_gex, and get_flow by focusing on max pain.

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 clear context for usage, including plan information ('Free (1 symbol, 15-min delay) and up') and detailed expiration behavior ('Omit for the nearest expiry', '"all" for every expiration'). However, it does not explicitly mention alternative tools or when not to use this tool, which would earn a 5.

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

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

Despite lacking annotations, the description discloses the return structure via the OverviewResponse JSON fields, the plan requirement, and the behavior of the expiration parameter ('all' vs omit for nearest expiry). It does not cover error handling or data freshness, but provides substantial behavioral context for a read-only analytics tool.

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 compact yet well-structured with clear sections: summary, plan requirement, args, and returns. Each line provides essential information without redundancy, making it easy to scan and understand.

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 absence of an output schema, the description lists all major return fields (symbol, spotPrice, gexSummary, maxPain[], expectedMoves[], etc.), covering plan requirements and parameter options. However, it omits detailed shapes of nested fields like maxPain[], but overall it is sufficiently complete for a complex overview tool.

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%, but the description fully compensates by defining 'symbol' as 'Underlying ticker' and 'expiration' as 'Unix timestamp of a specific expiry, or "all" (recommended for the full dashboard). Omit for the nearest expiry.' This adds clear meaning beyond the bare schema types.

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 states the tool's function: 'Full analytics dashboard for a symbol in one call' and lists the included components (sentiment, GEX summary, max pain, expected moves, IV surface, term structure, top unusual flow). This distinguishes it from sibling tools that focus on individual metrics (get_max_pain, get_gex).

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?

It explicitly positions the tool as 'the cheapest way to get everything for a symbol at once', indicating when to use it for comprehensive data. It also notes the plan requirement ('Plan: Pro and up'), but does not explicitly name alternatives or state when not to use it, leaving some room for ambiguity.

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

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

With no annotations provided, the description carries the full burden for behavioral disclosure. It adds useful context by explaining the expiration parameter's special values ('all', omit for nearest expiry) and states the return type as SnapshotResponse JSON. However, it does not disclose any potential side effects, authentication needs, data freshness, or error behavior. For a read-only snapshot tool, the description is adequate but not exceptionally transparent.

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 concise and well-structured. The opening sentence states the purpose, followed by an 'Args' section that explains each parameter, and a closing line for the return type. Every sentence earns its place, with no redundant information. It is appropriately front-loaded and easy to skim.

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 tool with 2 parameters, no annotations, and no output schema, the description covers the essential aspects: purpose, parameters, return type, and key behavioral nuance (expiration default). It does not include examples or error-handling details, but given the simplicity of the operation, it is reasonably complete. The lack of an output schema means the return format is not detailed, but the description explicitly names the response type, which is sufficient for basic invocation.

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%, so the description must compensate. It provides clear semantics for both parameters: 'symbol' is described as 'Underlying ticker', and 'expiration' is fully explained with the Unix timestamp format, the special value 'all', and the default behavior when omitted. This goes well beyond the bare schema types and tells the agent exactly how to supply each argument.

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 states the tool provides a 'Compact analytics snapshot for a symbol' and distinguishes it from a 'full overview', which aligns with the sibling tool get_overview. The verb 'get' is implicit in the name, but the description makes it explicit by saying it returns the SnapshotResponse JSON. This is a specific resource (snapshot) with a clear scope (symbol and optional expiration).

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 says it is 'suitable for quick checks and cards' and explicitly frames it as a 'lighter-weight summary than the full overview', giving a clear use case. However, it does not explicitly name alternative tools or provide 'when not to use' conditions. The guidance is sufficient for most agents to infer when to choose this over a more detailed overview, but it lacks the named alternative or exclusion that would earn a 5.

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

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

There are no annotations, so the description carries the full burden. It discloses IP rate-limiting, caching for ~5 minutes, that no key is needed, and that symbols outside the watchlist return an error. This is significant behavioral context that goes beyond typical tool descriptions.

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 well-structured with a clear opening sentence, an Args section, and a Returns section. However, there is minor redundancy: 'no key needed' and 'lightweight, unauthenticated way' convey the same point. It could be slightly tightened without losing clarity.

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 simple tool with two parameters, no output schema, and no annotations, the description is remarkably complete. It covers the purpose, usage guidelines, parameter semantics, error behavior, and return format, making it fully sufficient for an AI agent to select and invoke the tool correctly.

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 provides no parameter descriptions (0% coverage), so the description must compensate. It fully explains `symbol` with examples (SPY, QQQ, AAPL, etc.), the default, and the error case for invalid symbols. For `expiry`, it clarifies it is an optional Unix timestamp and gives practical advice ('omit for the nearest expiry'). This adds substantial meaning beyond the bare schema.

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 states it is a 'Public GEX-by-strike heatmap for a watchlist symbol' and explains its purpose as 'a lightweight, unauthenticated way to see gamma exposure per strike.' It distinguishes itself from the sibling tool `get_gex` by noting the watchlist-only scope and the authenticated alternative for arbitrary symbols.

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 explicitly specifies when to use this tool: for watchlist symbols, without a key, and without a plan. It provides a direct alternative by saying 'use the authenticated `get_gex` for arbitrary symbols,' which gives clear separation of usage scenarios.

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

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

No annotations provided, so the description carries full burden. It discloses that the endpoint is public, requires no key, and returns a structured object with status, supabase, and stripe keys. This is transparent about access and output behavior.

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?

Two sentences, front-loaded with the tool's essence, zero fluff. Every word earns its place.

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 zero-parameter health check with no output schema, the description fully covers purpose, output shape, authentication, and usage context. Nothing important 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?

Input schema has zero parameters, so baseline is 4. The description adds value by clarifying the call is simple and can be made without credentials, even though it does not explicitly state 'no parameters'.

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 states the tool is a service health check that returns status fields, with a specific verb and resource. It distinguishes itself from the sibling financial data tools by being a health/readiness endpoint.

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?

Explicitly advises using this tool to verify GREEKS_BASE_URL is reachable before other calls, providing clear when-to-use guidance. The public/no-key note also informs access conditions.

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

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

With no annotations provided, the description carries the transparency burden. It discloses that the endpoint is public and requires no key, which is important auth context. The verb 'List' implies a read-only operation, but the description does not explicitly state that it is non-destructive or describe any rate limits or output format details.

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 two sentences, front-loaded with the primary purpose, followed by practical usage guidance. Every sentence provides distinct value with no redundancy or filler.

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 zero-parameter, no-output-schema tool, the description is fully complete. It covers what the tool does, the available plans, the fact that it is public, and when to use it. No additional context is needed for an agent to select and invoke it correctly.

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 tool has zero parameters, so the baseline is 4. The description adds meaning by explaining what the response contains (prices, limits, included routes), which is useful for an agent to understand the tool's output. There are no parameter semantics to elaborate on.

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 states the verb 'List' and the resource 'commercial plans', specifying the included attributes (prices, limits, included routes) and distinct plan names. This distinguishes it from sibling analytics tools, which focus on market data rather than plan information.

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 explicit use cases: to explain which analytics a plan unlocks and to diagnose 402/403 errors. It gives clear context for when to use the tool, though it does not explicitly mention alternatives or when-not-to-use scenarios.

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

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

With no annotations, the description carries full responsibility. It discloses that the tool is public, requires no key, is IP rate-limited, takes no arguments, and returns a specific JSON structure, giving a transparent behavioral 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?

The description is compact, front-loading the core purpose and usage, then adding technical details. Every sentence is informative with no fluff.

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 zero-argument tool with no output schema, the description covers all essential context: purpose, usage, public nature, rate limiting, return structure, and watchlist composition. It is fully complete for an agent to select and invoke the tool.

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?

Although the schema has zero parameters, the description explicitly states it takes no arguments and that the watchlist is fixed server-side, adding meaningful semantic clarity beyond the empty schema.

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 identifies the tool as a public options screener over a curated watchlist and specifies the return format (per-symbol row with spot price, sentiment, headline analytics). It explicitly distinguishes this from authenticated analytics tools by framing it as a discovery-first step.

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?

It states to use the screener as the fastest way to discover interesting symbols before drilling into authenticated analytics tools, and clarifies it is public with no key needed but IP rate-limited. This provides clear when-to-use context and differentiates it from siblings.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It explicitly mentions the tool is public, requires no key, takes no arguments, and returns a server-computed JSON with updatedAt and records. This covers key behavioral aspects like authentication and output shape.

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 concise and front-loaded, with the main purpose in the first sentence. It uses only three short paragraphs, each adding distinct value: purpose, usage conditions, and return format. No fluff or redundant 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 zero-parameter read-only tool, the description provides sufficient context: what it measures, the time window, input requirements, and output format. It could be slightly more detailed about the structure of 'records' but the given information is adequate for understanding 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?

The tool has 0 parameters, and the description explicitly confirms 'Takes no arguments.' This eliminates any ambiguity and adds clarity beyond the empty schema, fully satisfying the parameter semantics dimension.

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 states it provides a 'Public track record — aggregated accuracy of the published analytics' over roughly the last 35 days. It specifies the exact resource (historical performance of signals) and uses an explicit verb ('gauge'), distinguishing it from sibling tools that focus on current data (e.g., get_snapshot, get_gex).

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 case: 'Use it to gauge how the signals have performed historically.' It also states it's public and requires no key. While it doesn't explicitly exclude other tools, the unique purpose makes the intended usage clear.

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