OptionsBell Options Flow

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

With no annotations provided, the description carries the burden of disclosing behavioral traits. It implies a read-only, metadata-oriented operation through 'Discover what data is available' and 'Call this first,' which strongly suggests a non-destructive query. It also explains what information is returned, adding behavioral context beyond the bare tool name. It does not explicitly state 'no side effects,' but for a stats/discovery tool this is reasonably 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 two sentences: the first front-loads the core purpose and output types, the second gives usage guidance. Every word contributes, with no redundancy or filler. It is concise yet informative.

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 no parameters, no annotations, and no output schema, the description does well to specify both the output content (date ranges, contract counts, symbol counts, sector coverage) and the dataset scope ('unusual-activity dataset and its daily aggregates'). It also provides usage context. It is slightly incomplete in not specifying whether the stats are global or per-symbol/time-window, but for a discovery tool this is adequate.

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, and the rubric gives a baseline of 4 for 0 params. The description adds no parameter-specific semantics, but none are needed. It does mention the content of the returned data, which is not about parameters. The baseline is appropriate.

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: 'Discover what data is available before querying' and enumerates specific outputs (date ranges, contract counts, symbol counts, sector coverage). It distinguishes itself from the sibling data-query tools like get_unusual_activity by focusing on dataset metadata rather than actual activity rows.

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 instructs 'Call this first when unsure about available history,' which gives a clear when-to-use. It also implies using it before other querying tools ('before querying'). However, it does not explicitly mention alternative tools or give when-not-to-use conditions, so it falls short of 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?

With no annotations, the description carries the full burden of behavioral disclosure. It explains the output structure (DTE buckets with splits) and adds interpretive value (event vs. positioning), which goes beyond a simple restatement. It does not mention limitations or edge cases, but the core behavior is well conveyed.

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 main purpose and followed by a concise interpretive heuristic. Every word earns its place, 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 specialized analytics tool with no output schema, the description conveys the core concept, bucket definitions, and suggests how to interpret results. It is sufficient for an expert user, though it leaves some ambiguity about the exact output format (e.g., percentage vs. count).

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 parameters (date and symbols) are already documented. The description adds context about the tool's analytical focus but does not provide additional parameter-level meaning beyond what the schema offers. Baseline 3 is appropriate.

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: showing where the day's unusual premium sits along the expiry axis in DTE buckets with call/put splits. It uses a specific verb ("sits") and distinguishes it from sibling tools by focusing on expiry concentration rather than broader flow or IV metrics.

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 interpretative guidance for when to use this tool: heavy short-dated premium reads as event bets, heavy long-dated as positioning. This gives clear context on how to apply the output, though it does not explicitly name alternatives or state when not to use it.

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. It explains the aggregation filter (not full tape), the single-symbol scope, the specific metrics included, and the ~75-day historical range, offering rich behavioral context beyond a simple 'get history' description.

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 well-structured sentences, starting with the core purpose and then adding detail (metrics, length, use case). Every word earns its place with no redundancy or 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?

Given no output schema, the description lists the output fields (volume, premium, C/P ratios, IV, delta, streak) and explains the data source and aggregation, making it complete for understanding the tool without needing to guess.

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% with clear descriptions for symbol, limit, date_from, and date_to. The tool description adds some context (one symbol, ~75 trading days) but does not explain parameter semantics beyond the schema, resulting in a baseline score of 3.

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 an end-of-day time series of unusual options flow for a single symbol, aggregated from contracts passing the unusual filter. It distinguishes this from a full tape and from sibling tools like get_symbol_flow or get_unusual_activity by emphasizing the historical and filtered 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 includes a concrete example ('how has unusual flow on NVDA developed?') and notes the series is behind back-tests, which implies usage for historical analysis. However, it does not explicitly name alternative tools or state when not to use it, so it falls short of full explicit guidance.

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 burden of behavioral disclosure. It explains the scoring basis ('call/put volumes, premium and net delta') and the two distinct output modes (time series vs snapshot). It does not disclose response structure or rate limits, but it is a read-only data retrieval tool, so the transparency is adequate.

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, consisting of two sentences with no filler. The first sentence defines the purpose and scoring basis, and the second covers usage modes and filters. It is front-loaded and every sentence 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?

Given the complexity of 9 parameters and no output schema, the description provides a good overview but leaves gaps. It fails to clarify the difference between 'symbol' (singular) and 'symbols' (plural) parameters, and does not mention date range parameters for the time series. This could confuse an agent selecting parameters.

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 description adds meaning to key parameters: 'Pass a symbol' explains the symbol parameter's conditional behavior, and 'filterable by sector or minimum strength' ties sector and min_strength to the tool's functionality. It does not address the 'symbols' plural parameter or 'signal_only', but schema coverage is 78%, so it partially compensates.

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: 'Bullish/bearish classification of each symbol's unusual flow with a 0-9 strength score' and specifies the inputs and outputs. It also distinguishes from siblings by contrasting 'Pass a symbol' vs 'omit it for the cross-market snapshot', making it clear when this tool is appropriate.

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 invocation guidance: 'Pass a symbol for that ticker's sentiment time series; omit it for the cross-market snapshot (filterable by sector or minimum strength).' However, it does not explicitly name alternative tools or state when not to use this tool, though the two modes are clearly described.

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 burden and does convey the selection logic (N+ consecutive days, dominant side) and signal interpretation. However, it omits operational behavior such as default date/min_streak/limit handling, sorting, or 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?

Two sentences, front-loaded with the core result and followed by a single actionable use case. No 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 6-parameter tool with no output schema or annotations, the description provides a strong conceptual frame but leaves gaps around default values and result granularity. It still adequately disambiguates from sibling tools like get_unusual_activity, but not enough to fully guide 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 coverage is high (67%) and already describes date, side, symbols, and min_streak defaults. The tool description reinforces the 'N+' streak concept but does not add new meaning for limit or min_volume.

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 identifies the resource as symbols with unusual options activity meeting a multi-day streak criterion and mentions the dominant side. It distinguishes from single-print tools via 'stronger signal than a single print', though it lacks an explicit verb like 'lists' or 'returns'.

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 gives a clear use case: 'where does money keep showing up?' and frames streaks as stronger than single prints, implying not for one-off alerts. It does not explicitly name alternatives or enumerate when-not-to-use cases.

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 behavioral burden. It discloses the 20+ days history requirement, the two operational modes (time series vs snapshot), and the filtering semantics via example. It does not describe response format, pagination, or error behavior, but the core behaviors are covered.

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 exactly two sentences, front-loaded with the core function, and every word adds value. The example is compact and does not waste space.

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 6 optional parameters, no output schema, and no annotations, the description covers the primary modes but leaves some parameter purposes and return structure unexplained. The example gives one use case, but more detail on filtering and series behavior would make it more 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 coverage is only 17% (only symbol has a description), so the description must compensate. It clarifies symbol (pass vs omit) and, via the example, side and min_rank. However, parameters like limit, max_rank, and lookback_days are not explained, leaving their semantics inferable but not explicit.

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 'IV rank and IV percentile per symbol against its rolling history,' which is a specific, distinct function. It distinguishes from all sibling flow/OI tools by naming IV rank as the core resource, and the sentence structure is action-oriented.

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 usage guidance: 'Pass a symbol for its IV-rank time series; omit it for a ranked snapshot' and gives an illustrative example with side=put&min_rank=0.8. However, it does not mention when to choose this tool over sibling alternatives (though no sibling is IV-related) or exclusion cases.

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 must carry the burden of disclosing behavioral traits. It mentions output metrics but does not indicate read-only status, default date ranges, meaning of limit, or how results are aggregated. This leaves significant ambiguity for an agent deciding whether to invoke the 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 a single, focused sentence that front-loads the key output and ends with an explicit use case. Every word contributes value, with no repetition 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?

Given the absence of an output schema and annotations, the description should fully explain behavior, but it only lists a few output fields. It does not clarify what happens with optional parameters, the format of the returned data, or how the regime label is determined. This is incomplete for a tool with 3 optional parameters and no rich structured metadata.

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 67% (date params have descriptions) but the 'limit' parameter has no schema description and is not mentioned in the tool description. The description adds no parameter-specific meaning beyond what the schema already provides, leaving the agent to guess how limit affects the result.

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 what the tool provides: market-wide breadth of unusual flow, breadth score, call/put ratio, and regime label. It distinguishes this tool from siblings like get_symbol_flow and get_sector_flow by focusing on the overall market tone. However, it uses a noun phrase rather than an explicit verb like 'get' or 'return', so it doesn't fully earn a 5.

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 includes a use case: "Use for 'what's the overall tone of the unusual-flow tape?'" This helps the agent know when to select this tool. It doesn't name alternatives or exclusions, which prevents a 5, but the guidance is clear and context-appropriate.

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 implicitly indicates a read-only get operation and adds interpretive context ('fresh positioning being built or unwound'), but it does not explicitly discuss safety, authorization, rate limits, or return format. The behavior is adequately sketched but not fully disclosed.

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 two sentences. The first sentence states the core function and the breakdown, and the second explains the two invocation modes. Every word adds value, with no 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?

With no annotations and no output schema, the description relies on its own wording to complete the picture. It covers the primary use cases but leaves out return shape, definition of gainers/losers, and how parameters like side or min_change_pct interact. It is adequate for a simple query but not fully self-contained.

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 descriptions cover 4 of 6 parameters (67%), which is moderate. The description adds meaningful clarification for the symbol parameter by explaining the pass-vs-omit behavior, but it does not help with the side, limit, min_prev_oi, or min_change_pct parameters beyond what the schema already provides. The overall parameter semantics are acceptable but not enhanced.

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: day-over-day open-interest change per symbol with a breakdown by total, calls, and puts. It also distinguishes from siblings by highlighting the symbol-specific and market-wide gainers/losers modes, which is unique among the listed tools.

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 practical guidance on when to use the tool: pass a symbol for its OI-change series or omit it for market-wide gainers/losers. It does not explicitly name alternative tools or state when not to use it, but the provided context is clear enough for 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, the description must carry behavioral disclosure. It conveys the aggregation level and metrics, but does not state whether all sectors are included or only those with unusual activity, how the 'limit' parameter affects results, or any data caveats. This is a moderate level of transparency.

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 a single well-structured sentence with a colon-delimited list of metrics. Every word contributes information, with no fluff or repetition, making it highly efficient.

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 tool is moderately complex with two parameters and no output schema. The description covers the core return values but lacks usage context, ordering, edge cases, or how this fits into a broader analysis workflow. It is adequate but not complete for an agent without prior knowledge.

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 description does not mention any parameters. The date parameter has a schema description, but 'limit' has none and the description adds no meaning for it, leaving its purpose (e.g., limiting number of sectors) unclear. Schema coverage is only 50%, so the description should compensate but does not.

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 question format to identify GICS sectors as the grouping dimension and explicitly lists the output metrics (total premium, volume, average net delta, bull/bear symbol counts). This clearly distinguishes it from siblings like get_symbol_flow or get_expiry_concentration, which operate at different granularities.

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?

No explicit when-to-use guidance or alternatives are provided. There is no mention of how this tool compares to other sector-level or flow-related tools, leaving the agent to infer its purpose from the output description alone.

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 burden. It discloses a behavioral trait by stating results are 'sorted by Vol/OI', but it does not clarify potential limits (e.g., 'limit' parameter overriding 'every'), return format, or how filters like min_voloi and min_premium affect results. This is adequate but not rich.

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 exceptionally concise and front-loaded: two sentences immediately state the core function and the primary use case. Every word adds value, with no fluff or repetition of schema details.

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 8 parameters and no output schema, the description is thin. It covers the primary purpose and when to use it, and the schema partially documents date/symbol parameters, but it leaves undefined the behavior of `limit`, `type`, `min_voloi`, and `min_premium` in terms of how they shape the returned 'every unusual contract' list.

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 description adds minimal parameter meaning beyond the schema. It mentions 'single ticker' and 'Vol/OI', loosely linking to `symbol` and `min_voloi`, but does not explain the `type`, `limit`, `date_from`/`date_to`, or `min_premium` semantics. With 50% schema coverage, the description does not compensate for the undocumented 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 it returns 'Every unusual contract on a single ticker, sorted by Vol/OI', which precisely identifies the tool's function and scope. It distinguishes itself from siblings by explicitly limiting to a 'single ticker' and focusing on unusual options flow.

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 an explicit usage scenario: 'Use when the question is about one specific stock's unusual options flow.' This provides clear context for when to invoke the tool, though it does not name alternatives or exclusion cases, preventing 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?

With no annotations, the description carries full burden. It discloses ranking by estimated premium and daily scope, but it does not explain what qualifies as a 'print,' whether the premium is total per trade, or any filtering behavior. This is a moderate level of transparency for a read-only list 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 two short, front-loaded sentences that immediately convey the tool's purpose and an example query. No redundant or filler content.

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 tool is a simple filtered list with 5 optional params and no output schema. The description covers what it returns and gives a concrete use case. It lacks detail on return fields, but given the tool's simplicity and well-described schema params, 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 80%, so the baseline is 3. The description itself does not add param-specific meaning, but the schema already documents date, limit, symbols, and min_premium. The description implies date/default behavior by 'day's' but doesn't enhance parameter understanding beyond 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 'the day's biggest options bets ranked by estimated premium,' which is a specific verb-resource pair (get/top prints). It also distinguishes itself by referencing the same view used in alert emails, making it unambiguous what the tool provides.

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 ('what were the largest options trades today?') and says it's 'Perfect for' that query. However, it does not explicitly mention when to avoid this tool or compare it to sibling tools, so it falls short of full guidance.

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 responsibility for behavioral disclosure. It lists the output fields (strike, expiry, volume, OI, IV, delta, sector, premium), which tells the agent what to expect. It does not mention data freshness or rate limits, but for a read-only scanner this is reasonably 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 three concise sentences: purpose, filters, and output/use case. Every sentence carries meaningful information, and it is front-loaded with the most important details. No fluff 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 10 parameters, no output schema, and no annotations, the description effectively covers the tool's purpose, filter capabilities, output columns, and a sample question. It does not explain every parameter individually, but the schema handles that. Overall it provides sufficient context 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?

Schema coverage is 100%, so the baseline is 3. The description adds value by grouping filters ('symbols, side and thresholds') and explicitly naming Vol/OI ratio, premium, IV, and days-to-expiration, which map to the parameters. The example question ties parameters to a real use case, going beyond the 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 performs a 'contract-level unusual options activity scan across 7,000+ US stocks'. This is a specific verb+resource combination that distinguishes it from sibling tools like get_symbol_flow or get_top_prints. It even names the dataset behind OptionsBell alerts, giving extra 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 provides a concrete usage example ('Use for questions like ...'), which gives clear context on when to use the tool. However, it does not explicitly mention alternatives or when not to use it, so it falls 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.

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

With no annotations provided, the description carries the burden of disclosing behavioral traits. It adds the key detail that no API key is required, which is a behavioral trait. It does not describe the return value or error behavior, but for a simple liveness check, this is sufficient for an agent to understand what to expect.

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 a single, front-loaded sentence: 'Liveness check for the OptionsBell MCP server. No API key required.' Every word earns its place, with no redundancy or filler. It is appropriately brief for a tool of this simplicity.

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 health-check tool with no parameters, no output schema, and no annotations, the description is fully complete. It states the purpose and the absence of authentication requirements, which is all the context an agent needs to select and invoke this 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 input schema has zero parameters (empty properties object), and the description adds no parameter information. Per rubric, a zero-parameter tool receives a baseline of 4, and the description need not compensate since there are no parameters to explain.

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 'Liveness check for the OptionsBell MCP server', specifying both the verb (check) and the resource (server). This distinctly sets it apart from the sibling tools, which are all data retrieval operations (e.g., get_flow_history, get_iv_rank), making the tool's purpose 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 phrase 'No API key required' provides useful context for when to use the tool, implying it can be called without authentication setup. However, it does not explicitly mention when to use it versus alternatives or provide exclusions, though the liveness-check nature clearly suggests using it for connectivity verification before data calls.

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