Server Quality Checklist

Tool Scores

• get_charm_exposureA
  3.6/5.0
  Behavior3/5

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

  Annotations include readOnlyHint=true, which already indicates a safe read operation. The description adds context about what charm measures and its relevance to hedging flows, but doesn't disclose additional behavioral traits like return format or any limitations. With annotations covering the safety profile, 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.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured with clear sections for purpose, usage, args, and returns. It's concise and front-loaded with the key purpose. The use-case list adds value without being verbose.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is relatively simple with 2 parameters and no output schema. The description covers the purpose, usage, and parameters adequately. However, it doesn't explain what the return data looks like (beyond 'Charm exposure by strike') or any edge cases, which could be useful for a greeks tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  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 lists the parameters (ticker, expiration) with brief explanations ('Stock symbol', 'Specific expiration or None for nearest'), which adds some meaning beyond the schema. However, it doesn't provide format details or examples, and the coverage is minimal.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool gets charm (delta decay) exposure by strike, with a specific verb and resource. It distinguishes itself from siblings by focusing on charm exposure specifically, though it doesn't explicitly contrast with similar greek tools like get_third_order_greeks.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides explicit use cases ('Use this tool when the user asks about: Charm exposure, Delta decay, Time-based hedging flows'), which gives clear context for when to use it. It doesn't explicitly mention when not to use it or name alternatives, but the use cases are specific 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.

• get_greeks_heatmapA
  3.7/5.0
  Behavior3/5

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

  The readOnlyHint annotation already indicates this is a read operation. The description adds that it returns a matrix of Greek values for visualization, which is useful context, but it does not disclose details like default greek/option_type behavior, data granularity, or any limitations. It does not contradict the annotation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured with a purpose statement, usage guidance, Args, and Returns sections. It is mostly concise, though there is minor redundancy between 'Returns a matrix of Greek values that can be visualized as a heatmap' and the later 'Returns: Heatmap matrix data with strikes and expirations.'

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With no output schema, the return description is present but minimal—'Heatmap matrix data with strikes and expirations' does not fully describe the matrix shape or how to interpret it. The description adequately covers the tool's basic purpose and parameters, but lacks deeper context about output structure and relationship to similar sibling tools.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has no descriptions (0% coverage), but the description compensates by explaining each parameter: ticker is a stock symbol, greek lists allowed values ('delta', 'gamma', 'theta', 'vega'), and option_type specifies 'calls' or 'puts'. This adds meaningful semantics beyond the bare schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's function: 'Get Greeks visualization data across strikes and expirations' and mentions it returns a heatmap matrix. It is specific about the resource and scope, though it does not explicitly differentiate itself from sibling tools like get_third_order_greeks or get_monies_surface.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides explicit when-to-use guidance: 'Use this tool when the user asks about: Greeks across strikes, Delta/gamma/theta/vega heatmap, Greek distribution.' It gives clear context but does not mention when not to use it or name alternative tools.

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

• analyze_earnings_historyA
  3.8/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, and the description adds useful context about comparing actual moves to implied expected moves and covering beat/miss patterns. However, it does not disclose return format, data limitations, or what the 'analysis' includes; no contradiction with annotations exists.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise and well-structured: a clear one-line purpose, a brief explanatory sentence, a bulleted 'Use this tool when' list, and compact Args/Returns sections. Every element earns its place without filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a one-parameter read-only tool with no output schema, the description provides enough context for an agent to select and invoke it correctly. The Returns line is vague, but the body already explains what the analysis shows, making the description sufficiently complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The only parameter, ticker, is described as 'Stock symbol,' which adds little beyond the schema's property name and title. With 0% schema description coverage, the description only minimally compensates and provides no format, example, or validation details.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('analyze') and resource ('historical earnings moves for a stock'), and clarifies that it compares actual moves to the expected move implied by options. It does not explicitly distinguish itself from the overlapping sibling 'get_earnings_move_analysis', so it falls short of a 5.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides an explicit 'Use this tool when' list covering historical earnings moves, past reactions, beat/miss patterns, and options pricing accuracy. It does not mention when not to use it or name alternative tools, so it lacks the exclusion guidance needed for a 5.

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

• get_market_overviewA
  3.8/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds useful context about what metrics are included (VIX, put/call, GEX regime), which adds some value beyond the annotation. However, the 'Returns:' section is purely tautological ('Market-wide volatility and positioning overview') and restates the opening, missing an opportunity to disclose details like data frequency, index universe, or whether this triggers expensive computations. Adequate but not exemplary for a read operation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured with clear sections: a one-line purpose, a detail sentence, a 'Use this tool when' bulleted list, and a Returns line. It's front-loaded with the key purpose. Minor deduction for redundancy—the Returns line duplicates the opening sentence ('Market-wide...overview' vs 'aggregate volatility metrics'), and the use-when list could be more compact. Overall efficient at ~60 words with good scannability.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a 0-parameter, read-only, annotation-covered tool, this is well-completed. The description clearly positions it as the macro-level aggregate view among 42 siblings, and the metrics list (VIX, put/call, GEX) disambiguates from get_vix_snapshot and get_gex. The main gap is no mention of how real-time or lagging these metrics are, or typical latency—but given the tool's simplicity and no output schema expectations, this is satisfactory.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  With 0 parameters and 100% schema coverage (trivially), there is nothing for the description to explain. The baseline of 4 applies: the description correctly stays silent on parameters, and no additional semantics are needed. The tool takes no inputs, and the description doesn't invent any, which is consistent and clean.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb+resource+scope pattern: 'Get market-wide volatility overview' followed by concrete metrics (VIX levels, put/call ratios, GEX regime). The 'aggregate' and 'market-wide' framing distinguishes it from the many volatility siblings (get_vix_snapshot, get_gex) by positioning this as the broad umbrella tool. However, it stops short of explicitly naming sibling tools for when they'd be more appropriate, keeping it from a 5.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description includes an explicit 'Use this tool when the user asks about:' section with four concrete triggers (Market overview, Overall market volatility, VIX and market sentiment, Broad market positioning). This gives clear context for an agent to route to this tool. However, it lacks any exclusion criteria or references to alternatives like get_vix_snapshot or get_gex, and some triggers ('Market overview') are tautological with the tool's name.

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

• get_volatility_coneA
  3.8/5.0
  Behavior3/5

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

  The annotations include readOnlyHint: true, and the description does not contradict this. It adds some context about the tool's behavior (comparing current IV to historical RV, returning percentile rankings) but does not disclose additional behavioral traits like data sources, update frequency, or limitations. Since annotations already cover safety, a score of 3 is appropriate.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured with a lead sentence, explanatory context, explicit usage bullets, and args section. It is not overly verbose and front-loads the core purpose. Could be slightly more concise by trimming some repetitive explanation, but it earns a above-average score.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's moderate complexity and lack of an output schema, the description provides a basic overview of returns ('Volatility cone data with percentile rankings') but lacks specifics about the data structure, time horizons, or limitations. It covers usage well but could be more complete for a specialized analysis tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, meaning the schema properties have no descriptions. The tool description compensates by explaining 'ticker: Stock symbol' and 'periods: Comma-separated periods in days (default "10,20,30,60,90")'. This adds meaning beyond the raw schema, but does not deeply explain how periods affect the cone or what 'stock symbol' implies. Moderate value.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's function: 'Get volatility cone comparing current IV to historical realized volatility.' This uses a specific verb ('Get') and resource ('volatility cone') with a clear purpose, distinguishing it from sibling tools like get_iv_rank and get_volatility_risk_premium.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides explicit usage triggers: 'Use this tool when the user asks about: IV vs realized volatility comparison, Volatility cone analysis, Historical volatility distribution, Whether options are fairly priced.' It does not explicitly mention when not to use or alternative tools, but gives clear context for appropriate invocation.

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

• optimize_strategyA
  3.9/5.0
  Behavior3/5

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

  The readOnlyHint annotation already establishes that the operation is read-only. The description adds that it 'optimizes' based on criteria, but does not go beyond that to explain computational behavior or any special constraints. It is not contradictory, but it adds minimal additional behavioral context beyond the annotation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and well-organized. It leads with a clear one-line purpose, followed by usage examples, then an Args section, and a brief Returns statement. Every sentence adds value, and the structure makes it easy to scan.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description gives sufficient context for basic use (when to use, what params mean) but lacks detail on output structure (what 'Optimized strategy parameters' includes) and does not mention prerequisites (e.g., needing an option chain). Given no output schema and moderate complexity, a bit more detail on returns or constraints would be beneficial.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The description provides a dedicated 'Args' section explaining each parameter: 'ticker: Stock symbol', 'strategy_type: Type of strategy', and 'target: Optimization target (credit, risk_reward, probability)'. Since the input schema lacks descriptions, this fills a critical gap and gives the agent meaningful guidance on parameter semantics.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the verb ('find'), the object ('optimal strikes'), and the scope ('for a strategy type'). It provides concrete examples like 'optimal iron condor strikes' and 'maximizing credit or probability', which distinguishes it from sibling tools like get_options_chain or analyze_strategy that do not perform optimization.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly lists use cases (e.g., 'User asks about best strikes for a strategy'), which helps the agent decide when to invoke this tool. However, it doesn't contrast with alternatives like analyze_strategy or build_strategy, nor does it mention conditions where this tool is not appropriate, leaving some ambiguity.

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

• get_iv_rankA
  4/5.0
  Behavior4/5

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

  Annotations already provide readOnlyHint=true, and the description adds behavioral detail beyond that: it interprets high/low IV Rank ranges and clarifies the output includes 'interpretation and strategy recommendations.' This gives useful context about what the tool returns and how to interpret it. It doesn't contradict annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured with an opening summary, brief explanatory paragraphs, a clear usage list, and an Args/Returns section. Each section earns its place and the text is not bloated. The heading/repetition of the description and title is minor, but the overall structure helps scannability.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a two-parameter, read-only tool with no output schema, the description is nearly sufficient. It explains what is returned ('IV rank data with interpretation and strategy recommendations') and how lookback_days affects the result. It could be more explicit about the exact fields in the response, but given it is a simple read tool with a clear interpretation, the context is reasonably complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, but the description compensates well with an Args section. It explains ticker with concrete examples ('AAPL', 'SPY') and lookback_days with its default and meaning ('default 252 = 1 year'). This adds practical semantics that the schema lacks.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with a specific verb+resource: 'Get IV Rank and percentile for a stock,' clearly stating the tool's core function. It also explains the conceptual meaning of IV Rank and provides threshold meanings (high >50, low <30). However, it does not explicitly differentiate this from related sibling tools like get_volatility_risk_premium or find_iv_opportunities.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description includes a dedicated 'Use this tool when the user asks about...' section with four concrete use cases, such as 'Whether options are expensive or cheap' and 'Premium selling/buying opportunities.' This is clear and actionable, but it lacks explicit 'when not to use' guidance or references to alternative tools, 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.

• get_smart_money_flowA
  4/5.0
  Behavior3/5

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

  The readOnlyHint is already annotated, so the description adds modest filtering behavior: what criteria are important (large trades, sweeps, blocks) and that returns are 'patterns and significant institutional labels'. The high-level return shape is mentioned but details like output structure, pagination, and lookback window are absent.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact, front-loaded with the capability, and uses clear sections for usage triggers, arguments, and returns. Every sentence contributes; there is no filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a one-parameter, read-only tool with no output schema, this supplies the key behavioral context, explicit user-intent triggers, and a high-level returned value. It would be fully complete if it also detailed the exact output structure or explained how it differs from the sibling get_options_flow tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The description says 'ticker: Stock symbol', which is a small advance beyond the schema's bare 'Ticker' title. For a single self-evident parameter, this meets the minimum viable compensation for schema-less parameter descriptions, but adds little new meaning.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The purpose is crisp and specific: 'Identify institutional/smart money options trades' through large trades, sweeps, and block orders. This clearly differentiates it from more generic flow or analytics tools like get_options_ flow.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives an explicit bulleted list of when to use it: smart money/institutional flow, large trades, blocks, sweeps, and wholes. It does not name analogous alternatives or 'when not to use', so it just misses the top score.

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

• get_options_flowA
  4.1/5.0
  Behavior3/5

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

  With readOnlyHint already set to true, the description doesn't need to state read-only behavior. It adds minimal extra behavioral context: mentions it 'identifies unusual activity that may indicate institutional positioning', but doesn't describe limitations, response format, or potential delays. No contradiction with annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured with a clear opening sentence, bullet-pointed use cases, and separate args/returns sections. It is not overly verbose, though the repetition of 'unusual activity' in the first lines could be tightened. Still, it earns its sentences.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple tool with one parameter and no output schema, the description adequately covers purpose, return types, and usage triggers. It doesn't specify output structure, but that's not required without an output schema. It could mention any data assumptions (e.g., real-time data) but is otherwise complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The description states 'ticker: Stock symbol', which explains the parameter's meaning beyond just the field name. Since schema description coverage is 0%, this compensation is valuable. Could add more detail (e.g., ticker format, case sensitivity), but it's sufficient for a simple string parameter.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool analyzes options flow and unusual activity for a ticker, with specific outputs like call/put volumes and premiums. It distinguishes from siblings like get_options_chain (which shows chains) and get_max_pain by focusing on flow and unusual activity.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Explicitly lists when to use the tool (e.g., 'Options flow', 'Call/put ratio', 'Unusual options activity'), giving clear triggers. It does not explicitly mention alternatives or when not to use it, but the context is strong enough for an agent to select it appropriately.

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

• get_stock_priceA
  4.1/5.0
  Behavior4/5

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

  The readOnlyHint annotation already signals a safe read, and the description adds useful return-content context: current price, bid/ask, and basic company stats. It does not contradict annotations, though it omits caveats like market hours, delayed quotes, or invalid-ticker behavior.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is short, front-loaded, and organized with clear 'Use this tool when' and 'Returns' sections. The 'Args' line is slightly redundant with the schema, but the overall structure is clean and easy to scan.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple single-parameter read tool with no output schema, the description gives enough context: purpose, use cases, and a high-level summary of return values. It could be more detailed about exact output fields or data-source limitations, but it is sufficient for straightforward selection and invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The description provides only 'ticker: Stock symbol,' adding minimal meaning beyond the schema's string type and 'Ticker' title. With 0% schema description coverage, this is a small but not fully compensating clarification; examples or accepted formats would improve it.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb and resource: 'Get current stock price and company information,' and further clarifies that it returns price, bid/ask, and basic company stats. This clearly distinguishes it from the many options/volatility-oriented sibling tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly lists when to use the tool: current stock price, bid/ask spread, and company information. It does not mention when not to use it or point to alternatives, but the listed use cases are clear and actionable.

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

• get_vix_snapshotA
  4.1/5.0
  Behavior3/5

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

  Annotations declare readOnlyHint=true, and the description does not contradict that. The description adds useful context by noting the return includes level, change, and term-structure state, but it does not disclose additional behavioral details such as data source, units, freshness, or exactly how 'term-structure state' is represented.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and front-loaded with the core purpose. The bullet list is scannable and useful. Minor redundancy exists because the opening sentence already mentions level, change, and term-structure state, and the 'Returns' section repeats a similar summary, but it does not become verbose.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple, parameterless, read-only snapshot tool, the description covers purpose, usage context, and return content. Since there is no output schema, the return description could be more specific (e.g., units of change, what 'context' includes), but overall it gives enough for an agent to decide and invoke correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters and 100% schema coverage, so the description has no parameter semantics to explain. The baseline for a parameterless tool is 4, and the description adequately focuses on the tool's output rather than inputs.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states 'Get the current VIX snapshot' with an explicit resource (VIX) and the specific data components: level, change, and term-structure state. The listed use cases ('overall market fear level', 'index vol elevated or calm', 'vol regime context') help distinguish it from sibling tools like get_term_structure or get_iv_rank.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear 'Use this tool when' guidance with concrete user intents, which is helpful for selection. However, it does not explicitly mention when not to use it or name alternative tools, so it stops short of full exclusionary guidance.

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

• scan_volatility_arbA
  4.1/5.0
  Behavior3/5

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

  Annotations include readOnlyHint: true, and the description does not contradict this. It adds a 'Returns:' note indicating output, but does not provide additional behavioral context such as rate limits, data sources, or how results are derived. It is adequate but could be more transparent about the scan's scope.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise and well-structured with a brief overview, a use-case bullet list, and a 'Returns:' section. Every sentence adds value without redundancy or verbosity.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given no parameters and no output schema, the description covers the tool's purpose, when to use it, and a general sense of the return value. It doesn't fully describe the output structure or include limitations/edge cases, but for a no-arg scan tool it is fairly complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  There are no parameters, so schema coverage is trivially 100%. The description doesn't add anything about parameters (none exist), but this is fine. Baseline for 0 params is 4, and no deduction needed.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool scans for cross-index volatility arbitrage opportunities, using a specific verb and resource. It distinguishes itself somewhat from siblings but could be more explicit in differentiating from similar tools like scan_relative_value, which may also involve relative value opportunities.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Provides explicit 'Use this tool when the user asks about:' list covering volatility arbitrage, cross-asset vol relationships, vol dislocations, and relative value opportunities. This gives clear guidance on when to select this tool over alternatives, though it doesn't mention what not to use it for.

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

• build_strategyA
  4.2/5.0
  Behavior4/5

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

  The description adds useful behavioral context beyond readOnlyHint: it automatically selects strikes based on target delta, supports fractional widths, treats expiration as None for nearest monthly, and returns legs, Greeks, and expected P&L. No contradiction exists between 'Build' and readOnlyHint since this appears to be an in-memory computation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-organized with a summary, supported types, usage triggers, and Args/Returns sections. Some redundancy exists between the strategy-type list and the strategy_type parameter example, but overall the structure is clear and scannable.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given 5 parameters, no output schema, and no enums, the description provides enough context to invoke the tool: it identifies required params, optional behavior, strategy categories, and return content. It is mostly complete, though it could more explicitly state how 'optimal parameters' are derived when no target_delta is specified.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description carries the full burden. It meaningfully describes all 5 parameters: ticker, strategy_type, expiration, width, and target_delta, including defaults, valid fractional widths, and the 'None' expiration behavior. This goes well beyond the raw schema titles.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb 'Build an options strategy' and lists supported strategy types, making it clear what the tool does. It does not explicitly contrast itself with siblings like optimize_strategy or analyze_strategy, but the use-case list helps differentiate it.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives explicit use triggers: 'Use this tool when the user asks about building a specific strategy', iron condor/credit spread requests, and strategy construction. It does not state when not to use it or name alternatives, so it stops short of full discrimination.

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

• get_cross_index_gexA
  4.2/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, so the safe read nature is known. The description adds some behavioral context by explaining the tool's purpose ('to understand market-wide positioning') and the default ticker behavior, but does not disclose additional traits such as data freshness, rate limits, or output format specifics. This is acceptable given the read-only annotation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured with an introductory sentence, a usage bullet list, and separate Args/Returns sections. It is concise and informative. Minor redundancy exists between the first two sentences ('Compare GEX across major indices' and 'Shows gamma exposure comparison...'), but overall every section earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple 1-parameter read-only tool, the description covers the essential aspects: what the tool does, when to use it, what arguments it takes, and what it returns. The return description ('GEX comparison across indices') is somewhat generic, but given the tool's simplicity and the readOnlyHint annotation, the information is sufficient for correct invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 0% (the schema property has no description), so the description must compensate. It does so effectively with an Args section that explains the tickers parameter: 'Comma-separated tickers or None for defaults (SPY,QQQ,IWM,DIA)'. This provides format, default behavior, and concrete example tickers, far exceeding the schema's bare type definition.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's function with a specific verb and resource: 'Compare GEX across major indices' and 'Shows gamma exposure comparison between SPY, QQQ, IWM, and other major indices'. It distinguishes itself from sibling tools like get_gex (which likely handles a single index) by explicitly focusing on cross-index comparison.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides explicit usage guidance with a 'Use this tool when the user asks about' list covering three specific scenarios. This gives clear context for when to use the tool, though it does not explicitly state when not to use it or mention alternatives like get_gex for single-index GEX analysis.

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

• get_term_structureA
  4.2/5.0
  Behavior3/5

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

  The annotation readOnlyHint=true already covers safety. The description adds interpretive context (contango/backwardation) but does not provide additional behavioral details like rate limits or side effects, which is acceptable given the annotation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise and well-structured, with a brief opening statement and a bulleted list of use cases. No redundant or vague language.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given there is no output schema, the description need not explain return values. It provides sufficient context for a simple tool, including what data is returned (term structure) and when to use it.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The only parameter 'ticker' is described as 'Stock symbol' in the description, but the schema itself only provides type and title. While this adds minimal clarification, it does not fully compensate for the lack of schema description, leaving the parameter's purpose underspecified.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the verb 'Get' and the resource 'IV term structure', specifying 'across all expirations'. This distinguishes it from sibling tools like get_options_chain or get_volatility_cone.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly lists when to use the tool with concrete scenarios (term structure of volatility, calendar spread opportunities, event-driven vol bumps, contango vs backwardation). This provides clear guidance for selection.

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

• calculate_expected_moveA
  4.3/5.0
  Behavior3/5

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

  Annotations already indicate readOnlyHint. Description adds method (ATM straddle) and return units but no additional safety or rate details; no contradiction.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Well-structured with purpose, use cases, args, returns. Every sentence adds value.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only tool with 2 params and no output schema, the description covers behavior, input, and return format sufficiently.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 0%, so description compensates by defining 'ticker: Stock symbol' and 'expiration: Specific expiration or None for nearest', adding meaning beyond schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states 'Calculate the expected move based on ATM straddle pricing' with a specific verb and resource. The use cases list different phrasings, distinguishing it from sibling tools like get_earnings_move_analysis.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Provides explicit 'Use this tool when...' list covering expected move queries. Does not name alternatives but the list gives clear conditions for when to use this tool.

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

• calculate_probability_of_profitA
  4.3/5.0
  Behavior4/5

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

  Annotations already provide readOnlyHint=true, which covers the safety profile. The description adds a meaningful behavioral detail: it uses N(d2)-based probabilities on the combined position payoff, which gives the agent context about the calculation method. It also states the return format ('Probability of profit percentage'). No contradiction with annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-organized with a purpose statement, method note, usage bullet list, args list, and returns section. The example JSON is useful but adds length. Every section contributes meaningfully, and the structure makes it easy to scan. It is appropriately concise for the complexity.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a calculation tool with no output schema, the description adequately covers inputs, the method, and the return value. It does not describe edge cases or assumptions (e.g., day-count convention, validity of legs), but these are not critical for the tool's primary function. The description is sufficient for an agent to invoke it correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  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 does so effectively for the `legs` parameter by providing a JSON example and clarifying that 'iv accepts percent or decimal; premium is per share'. The other parameters are briefly described (current stock price, days to expiration), but without additional unit or format details. Overall, it adds significant value beyond the raw schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states 'Calculate the probability of profit for a set of option legs' with a specific verb and resource. It distinguishes itself from sibling tools like calculate_expected_move by focusing on PoP, and further clarifies use cases via the bullet list.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly enumerates when to use the tool ('when the user asks about Probability of profit / PoP for a trade' and 'Odds a spread or condor expires profitable'). It does not mention when not to use it or point to alternatives, which would push it to a 5.

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

• generate_stress_testsA
  4.3/5.0
  Behavior4/5

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

  The description adds context beyond the readOnlyHint annotation by explaining that it runs simulations and returns P&L under stress scenarios. This helps the agent understand the tool's non-mutating, analytical nature and its output.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured and front-loaded. It opens with a clear purpose, then provides usage triggers, input format details, and output summary. Every sentence adds value, with no redundancy or filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description is fairly complete for a single-parameter tool: it covers input format, example, dependency on get_options_chain, and output (P&L under scenarios). It could list specific stress scenarios, but the examples given (crashes, vol spikes, rallies) suffice for most use cases.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  With 0% schema description coverage, the description fully compensates by providing a detailed JSON example, explaining the expected position format, including option Greeks, and noting that plain text works for stock-only portfolios. This is excellent parameter guidance.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool 'Run stress test scenarios on a portfolio' and explains extreme market conditions like crashes, vol spikes, and rallies. It does not explicitly distinguish from similar sibling tools like run_scenario_analysis, but the purpose is specific and actionable.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly provides when-to-use scenarios (stress testing, crash scenarios, worst-case analysis). It does not mention when not to use it or alternatives, but gives clear usage context and even a prerequisite (get option Greeks from get_options_chain first).

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

• get_expirationsA
  4.3/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true, so the tool is known to be safe. The description adds the behavioral context of returning a list of all available expiration dates and its usefulness for planning trades or term structure, going beyond the annotation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is highly concise, with a clear first sentence, bullet-pointed usage examples, and structured Args/Returns sections. Every sentence earns its place without redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is simple with a single parameter and no output schema. The description adequately explains the return (list of dates) and provides usage context. It doesn't mention edge cases like market exclusivity or ordering, but given the simplicity, these are not critical gaps.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  With 0% schema description coverage, the description should fully compensate for the parameter. It only provides 'ticker: Stock symbol', which is minimal and adds little beyond the parameter name itself. There is no additional format, constraints, or examples.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool gets available expiration dates for a ticker, with a specific verb and resource. It also distinguishes from siblings like get_term_structure by explicitly framing it as 'when the user asks about expiration dates'.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly says 'Use this tool when the user asks about' and lists specific scenarios (when options expire, available expiration dates, weekly vs monthly). It provides clear context without requiring inference.

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

• get_gexA
  4.3/5.0
  Behavior4/5

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

  Annotations only provide readOnlyHint=true, so the description carries the burden for behavioral disclosure. It explains what GEX measures and the dealer hedging implications (positive/negative GEX behavior), which adds meaningful behavioral context. It does not cover rate limits, but for a read-only analytics tool, the provided context is substantial.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured with clear sections (purpose, explanation, usage, args, returns). It is concise, with no filler, but it could be more front-loaded: the first sentence is good, but the explanatory paragraph on GEX mechanics is useful yet adds length; it earns its place though.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is moderately complex (3 params, no output schema), but the description covers the output ('GEX by strike, total GEX, and key levels') and provides enough conceptual background. It lacks details on return format, but for a data retrieval tool, it is reasonably complete. So it is a strong 4.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  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 briefly mentions ticker, expiration, and aggregate parameters, but it does not explain the format of expiration (e.g., 'YYYY-MM-DD'), nor does it clarify the semantics of the aggregate parameter beyond its name. The Args section adds minimal value beyond the schema, though the overall purpose and return description help.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states what the tool does: 'Get Gamma Exposure (GEX) levels and flip points.' It specifically identifies the resource (GEX) and the action (get), and the use cases ('when the user asks about gamma exposure, support/resistance from options, dealer hedging, market maker positioning') distinguish it from sibling tools like get_options_chain or get_charm_exposure.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides explicit 'Use this tool when' conditions and lists specific question types, which is clear context for invocation. However, it does not explicitly state when NOT to use it or mention alternatives (e.g., get_charm_exposure for charm, get_third_order_greeks for higher-order Greeks), so it lacks explicit exclusions.

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

• get_options_by_deltaA
  4.3/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, so safety is covered. Description adds that it returns 'Strike and option details at the target delta', but does not specify matching behavior (e.g., nearest strike, interpolation) or limitations. Acceptable since it's a read-only lookup.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Approximately 100 words, front-loaded with purpose, followed by when-to-use and a minimal Args list. Every section earns its place; no fluff.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple 4-param read-only tool with no output schema, the description is sufficiently complete: it covers purpose, use cases, arguments, and return summary. Minor gaps like delta matching precision are acceptable but not fully addressed.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, but description compensates by explaining all 4 params: ticker, target_delta range 0.0–1.0 and default, option_type values, and expiration 'None for nearest'. This adds meaningful usage detail beyond schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Clear verb 'Find options at a specific delta'; identifies resource (options) and unique filter (delta). This distinguishes it from sibling tools like get_options_chain, which likely returns full chain.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Explicitly states 'Use this tool when the user asks about...' with concrete examples (30 delta calls, 20 delta puts, strikes by delta). No when-not cases or named alternatives, but usage context is clear.

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

• get_third_order_greeksA
  4.3/5.0
  Behavior4/5

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

  With readOnlyHint=true, the annotation already indicates a safe read operation. The description adds value by defining each Greek (Speed, Zomma, Color, Vomma, Ultima) and what it measures, giving the agent a better understanding of the returned data beyond the annotation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured and front-loaded with the purpose. The bullet-like definitions are useful, though the 'Returns: Third-order Greeks data' line is redundant with the first sentence. Overall, it is concise and every major section earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the lack of output schema and the mathematical nature of the tool, the description adequately explains what the tool returns (the five Greeks) and their meanings. It also covers usage context and parameter basics. It could mention edge cases or result format, but it is complete enough for an 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.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 0%, but the description compensates with an Args section: 'ticker: Stock symbol, expiration: Specific expiration or None for nearest.' This adds meaning beyond the bare schema names, especially the expiration semantics. It could be more detailed (e.g., date format) but is adequate for the two parameters.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool 'Get third-order Greeks: Speed, Zomma, Color, Vomma, Ultima' with a specific verb and resource. It enumerates the exact outputs, distinguishing it from sibling tools like get_greeks_heatmap or get_gex.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Explicit guidance is provided: 'Use this tool when the user asks about: Third-order Greeks, Speed, zomma, color, Advanced Greeks analysis.' This clearly indicates when to use it, though it does not mention alternatives or exclusions, so it's a 4 rather than a 5.

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

• scan_relative_valueA
  4.3/5.0
  Behavior3/5

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

  The description adds some context beyond the readOnlyHint annotation by stating returns are 'Scan results ranked by stretch', but it does not disclose any additional behavioral traits such as rate limits, data freshness, or potential side effects. The annotation already covers read-only safety, so the bar is lower, yet it still lacks depth about the underlying behavior.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is highly structured with bullet points for the two views and a clear 'Args' section. It is concise, front-loaded with the core purpose, and each sentence adds value. No fluff or redundant information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description covers purpose, views, parameters, and a high-level return statement. However, without an output schema, it lacks detail on the exact structure of results (e.g., fields, ordering) beyond 'ranked by stretch'. For a scan tool, this is adequate but not exhaustive, so a slight deduction is warranted.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  With schema description coverage at 0%, the description is the sole source for parameter meaning. It thoroughly explains each argument: 'view' with valid options, 'limit' with a 1-50 range, and 'threshold' with its default and purpose. This exceeds what the schema provides and is essential for correct usage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's purpose as 'Market-wide relative-value scans' and breaks down two specific modes ('mean_reversion' and 'pairs') with concrete use cases (rich/cheap vol candidates, pairs trading). This distinguishes it from sibling tools like scan_volatility_arb, which likely targets a different strategy.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It explains the two views and when each is appropriate (e.g., 'mean_reversion' for stretched IV/SPY ratios, 'pairs' for rich-vs-cheap pairs), giving clear context for selection. However, it does not explicitly exclude alternatives or name sibling tools, so it falls short of perfect guidance.

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

• screen_marketA
  4.3/5.0
  Behavior4/5

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

  Annotations declare readOnlyHint=true, and the description does not contradict it. It adds context beyond the annotation: mentions bulk data usage, cheap on quota, and the ability to fetch catalog with screen_type='list'. This is helpful for understanding performance and side effects. It doesn't describe pagination or return volume, but the added quota/bulk detail is valuable.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is organized with bullet points and sections, front-loading the primary purpose. It includes a comprehensive list of screen types that is essential for correctness. While somewhat lengthy, each bullet earns its place. The structure is clear, though it could be trimmed slightly without losing value.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is complex with many screen types, and there is no output schema. The description ends with a generic 'Returns: Stocks matching the screen criteria' without detailing fields, result limits, or how to interpret the data. Given the variety of screens, more specifics on return format would be helpful. It doesn't mention error scenarios or quota limits beyond 'cheap on quota'. Overall, it's adequate but leaves room for clarification.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Although schema coverage is 0%, the description contains an 'Args' section that details each parameter (e.g., screen_type list, min_market_cap default $1B, exclude_earnings_days semantics). This fully compensates for the empty schema descriptions and even clarifies defaults. Parameter meanings are explicit and actionable.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states it screens the market for trading opportunities and enumerates specific screen types (e.g., high_iv_rank, unusual_volume, pin_risk). It distinguishes itself from siblings like scan_volatility_arb and scan_relative_value by focusing on preset multidirectional screens across the full universe. The verb 'screen' + resource 'market' is specific.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides an explicit 'Use this tool when' section listing user intents such as finding trading opportunities, screening high IV stocks, unusual activity scans, and what to trade. While it doesn't name alternatives or when not to use it, the context is clear enough for typical queries. It misses explicit exclusions but is still directive.

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

• analyze_strategyA
  4.4/5.0
  Behavior4/5

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

  The readOnlyHint annotation already signals a non-mutating operation. The description adds behavioral detail by specifying what the analysis computes (P&L, Greeks, probabilities, risk metrics) and the expected leg format. It does not cover error handling or data sources, but the added behavioral context goes beyond the annotation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact, front-loaded with the purpose, then structured into usage cases, args, and returns. Every sentence adds value; the example format is essential and the 'Use this tool' list is actionable. No redundant or filler text.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool has few parameters and no output schema, but the description covers purpose, use cases, parameter format, and high-level return contents. It could mention output structure or limitations, yet for a strategy analyzer this is a solid, self-contained definition. It is slightly less complete than top-tier tools with explicit output schemas.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  With 0% schema description coverage, the description must compensate. It does so by explaining 'ticker: Stock symbol' and providing a concrete leg format example ('BUY 1 C 150, SELL 1 C 155'). This is more informative than the raw schema, though it could be more explicit about expiration dates or option types.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool 'Analyze a custom options strategy' and enumerates specific outputs: 'full P&L profile, Greeks, probability of profit, and risk metrics.' This distinguishes it from sibling tools like optimize_strategy or build_strategy by focusing on analysis rather than construction or optimization.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Explicit usage guidance is provided: 'Use this tool when the user asks about: Analyzing a specific trade, Strategy P&L profile, Greeks for a position.' It does not mention when not to use it or name alternatives, but the use cases are clear and contextually sufficient for most query routing.

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

• find_iv_opportunitiesA
  4.4/5.0
  Behavior4/5

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

  The annotations already declare readOnlyHint=true, and the description adds meaningful behavioral detail: it identifies statistically extreme IV and suggests mean reversion strategies. It does not contradict the annotation and provides context beyond the annotation's safety signal.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise and well-structured with a summary line, usage triggers, args, and returns. Every sentence provides value, and the layout makes it easy to extract key information quickly.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a two-parameter, read-only discovery tool with no output schema, the description is complete: it states the purpose, when to use, and what it returns ('Opportunity assessment with strategy recommendations'). It lacks only a few edge-case details, but overall it's sufficient for effective tool selection.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  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. The 'Args' section defines each parameter in plain language: 'ticker: Stock symbol' and 'z_score_threshold: Statistical threshold (default 2.0)'. This adds the necessary meaning for both parameters, though not deeply detailed.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states a specific verb and resource: 'Find IV mean reversion trading opportunities.' It further specifies the statistical criterion (>2 std from mean) and distinguishes itself from sibling tools by focusing on mean reversion and strategy suggestions, not just data retrieval.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Explicit usage guidance is provided: 'Use this tool when the user asks about: Mean reversion opportunities, Extreme IV levels, When to sell/buy volatility, IV statistical analysis.' This gives clear context for when to invoke the tool, though it does not explicitly mention alternatives or 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.

• get_earnings_move_analysisA
  4.4/5.0
  Behavior4/5

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

  Annotations already indicate readOnlyHint=true, and the description aligns with that by using non-mutating language like 'analyze' and 'returns'. It adds useful behavioral context about the kinds of outputs each analysis mode produces, without contradicting the annotation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Description is well organized with a short purpose statement, an explicit use-case sentence, and a compact Args section. The seven bullet points are slightly long but necessary to disambiguate the analysis argument.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  There is no output schema, so the description's note about returning 'the selected earnings analysis payload with a compact summary' is helpful but abstract. For the selection task, the mode-specific descriptions and parameter guidance give the agent enough context to invoke the tool correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description carries full responsibility for explaining parameters. It clearly explains ticker, the seven analysis options, and the comma-separated day horizons for periods, including defaults and scope.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states exactly what the tool does: analyze stock moves around earnings and whether options misprice them. It further distinguishes itself from broad earning-domain siblings by listing seven specific analysis modes tied to this tool.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly says when to use this tool: when users ask whether earnings options are over/underpriced, how a stock usually moves on earnings, or if a straddle is worth buying. It does not mention alternatives or when not to use it, but the use-case guidance is clear enough.

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

• get_hedge_recommendationsA
  4.4/5.0
  Behavior4/5

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

  Annotations provide readOnlyHint: true, and the description adds the non-obvious behavior that recommendations are 'share-equivalent, not beta-weighted.' It also discloses that option Greeks must be passed from get_options_chain first. No contradictions; the description enriches the annotation without redundancy.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-organized into clear sections with front-loaded purpose. The example JSON is verbose but necessary given the lack of schema descriptions. No wasted words, though the use-case bullets could be seen as slightly redundant with the first sentence.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a read-only recommendation tool with no output schema, the description covers behavior, dependency on get_options_chain, parameters, and return value. It could add edge-case behavior (e.g., what if a position is invalid) but is generally complete for an agent to invoke it correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  With 0% schema description coverage, the description fully compensates via an Args section containing a realistic JSON example, clarification that plain text works for stock-only portfolios, defaults for hedge_ticker and target_delta, and a cross-tool dependency note. This goes far beyond the bare schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with 'Get delta-hedge recommendations for a portfolio' and details the computation ('Computes net portfolio delta and suggests a stock hedge plus an option-based alternative'). It clearly distinguishes itself from sibling tools like get_options_chain or get_portfolio_greeks by focusing on hedge recommendations.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  A dedicated 'Use this tool when' section lists three specific intents (hedging, delta-neutrality, protective puts) and references get_options_chain as a prerequisite. However, it does not explicitly name sibling tools as alternatives or state when not to use it, so it falls just 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.

• get_monies_surfaceA
  4.4/5.0
  Behavior4/5

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

  The readOnlyHint annotation already discloses the tool is non-mutating. The description adds meaningful behavioral context beyond that: what each surface mode means, including the comparison mode's purpose of highlighting potential rich/cheap spots. It also indicates the output shape ('rows per expiration'), which is useful for an agent.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is appropriately sized, front-loaded with the core purpose, and uses a clean bulleted list for the three surface modes. Every sentence adds value, and there is no redundant repetition of schema or annotation data.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is low complexity with two parameters, one required, and the description covers parameter meanings, usage intent, and a rough return shape. It could more explicitly describe the row fields or whether multiple expirations are returned together, but the given context is sufficient for an initial invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Although the input schema provides only types and defaults, the description fully explains the 'surface' parameter with its three valid values and their semantics. The 'ticker' description is minimal ('Stock symbol') but adequate for a well-known parameter.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb and resource: 'Get the ORATS monies volatility surface for a ticker.' It clearly differentiates the tool from siblings by naming the specific surface type and enumerating the three modes ('implied', 'forecast', 'comparison'), which no other sibling covers.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly states when to use the tool: for the vol surface or smoothed IV by delta, model-vs-market disagreement, and rich/cheap IV spots. It does not explicitly name alternative tools for related but different tasks, such as get_term_structure, 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.

• get_orats_coresA
  4.4/5.0
  Behavior3/5

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

  Annotations already include readOnlyHint=true, and the description does not contradict that. It adds context about being 'raw' and 'straight from the data vendor', but does not disclose additional behavioral aspects like rate limits or data freshness. Given the annotations cover the safety profile, 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.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured with an opening summary, a use-case list, and an Args/Returns breakdown. It is longer than minimal but every section earns its place, providing essential information without excessive verbosity.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a read-only tool with two simple parameters, the description covers the data scope, field selection, and return count. It doesn't mention error handling or rate limits, but those are not critical for this type of tool. The description is sufficiently complete given the sibling context.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description fully compensates. It explains the 'fields' parameter with three options (specific names, 'all', or empty for curated default) and clarifies 'ticker' as 'Stock symbol'. This adds meaningful semantics beyond the bare schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool retrieves raw ORATS analytics with 340+ fields, and distinguishes it from curated endpoints by saying 'Use when the curated endpoints don't carry the specific field you need.' It also lists specific user requests that map to this tool.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Explicitly provides when-to-use guidance including three bulleted examples ('A specific ORATS field by name', 'Deep vendor-level analytics not in other tools', 'Bulk fundamentals+vol context for one ticker') and references curated endpoints as alternatives, making usage conditions clear.

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

• get_volume_profileA
  4.4/5.0
  Behavior4/5

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

  With readOnlyHint already set to true, the description adds behavioral context about showing concentration, support/resistance, and notable OI changes. It also discloses the default expiration behavior, enhancing transparency beyond annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is tightly written with a clear structure: purpose, use cases, args, and returns. Every line adds value without redundancy, making it easy to parse.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's simplicity (2 parameters, no output schema), the description adequately covers purpose, inputs, and return format ('Per-strike volume/OI profile'). It provides enough contextual information for correct selection and invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The description fully compensates for the 0% schema coverage by explaining each parameter: 'ticker: Stock symbol' and 'expiration: Expiration date YYYY-MM-DD (default: nearest)'. This adds meaningful semantics and default behavior beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states it 'Get the option volume and open-interest profile by strike' with a specific verb and resource. It distinguishes itself from sibling tools by focusing on volume and open interest positioning, unlike chain or GEX tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly lists 'Use this tool when the user asks about' with three concrete use cases, providing clear context for when to invoke it. It does not mention alternative tools or exclusions, but the usage context is unambiguous.

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

• calculate_portfolio_greeksA
  4.5/5.0
  Behavior4/5

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

  readOnlyHint already indicates a non-mutating tool, and the description avoids any contradictory action. It adds useful behavioral context like prerequisite data sourcing from get_options_chain, support for plain text stock-only portfolios, and a risk-level assessment in return. It does not disclose edge case behavior or return structure, so not a 5.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured and efficient: a one-line summary, explicit use-case bullets, a clear Args section with example, and a Returns line. It is short enough to be understood quickly but contains all essential input prerequisites.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description covers inputs, prerequisites, and the output category sufficiently for a one-parameter read-only tool. However, since there is no output schema, the Returns line is minimal and does not define the shape or semantics of the risk-level assessment or aggregated Greeks.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema provides only a string named 'positions' with zero coverage. The description largely compensates by explaining the expected JSON array, providing a concrete example, documenting fields such as ticker, position_type, quantity, current_price, strike, expiration, delta, theta, and vega, and noting that plain text works for stock-only inputs.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly specifies the verb and resource: aggregate Greeks for a portfolio of positions, specifically net delta/theta/vega plus risk-level assessment. It differentiates from sibling tools by focusing on portfolio-level calculation rather than fetching or estimating a single-chain or third-order Greeks.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives explicit user-intent triggers such as Portfolio Greeks, Net delta/theta/vega, and Position exposure. It also instructs users to get option Greeks from get_options_chain first. However, it does not explicitly mention when-not-to-use or compare against closely related siblings, 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.

• get_ticker_analyticsA
  4.5/5.0
  Behavior4/5

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

  Annotation readOnlyHint=true already signals a safe read operation. The description adds valuable behavior: it explains the tool's multimodal nature (eight analyses) and even specifies that some analyses have sub-views ('view' argument) and which arguments are relevant per analysis. It does not disclose any side effects (none expected) or potential errors, but given the annotation coverage, it adds sufficient context beyond the schema.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Despite its length, the description is well-structured and every sentence earns its place. It opens with a clear statement of purpose, then uses a concise bullet-point list to enumerate the eight analyses and their specific views, followed by a compact Args section and a simple Returns note. The structure allows quick scanning while providing necessary detail for such a multi-purpose tool.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's complexity (eight analyses, multiple nuance fit-for-purpose parameters) and the absence of an output schema, the description does a good job of covering the input side and indicating the output ('The selected analytics payload with a compact summary'). It could be more explicit about the structure of the return payload or what the 'compact summary' contains, but for a read-only analytics tool, this is adequate. No output schema means the description carries some burden, but it meets the bar.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 0%, so the description must compensate, and it does fully. Every parameter is explained in prose: ticker, analysis (with a list of valid values), expiration (only for greeks_exposure), days (for specific analyses), view (for skew/hv_regimes), compare_with (for correlation). It also notes defaults (days default 252) and which arguments are optional. This goes far beyond the bare schema titles and adds meaningful semantics.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's purpose: 'Get a specific per-ticker analytics view.' It further enumerates eight distinct analyses, making it obvious what the tool covers and distinguishing it from siblings that focus on single analytics (e.g., get_iv_rank, get_volatility_cone). The verb 'get' and the resource 'per-ticker analytics' are specific and unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implicitly tells when to use this tool: whenever one of the eight listed analyses is needed. It provides per-analysis context (e.g., 'borrow_rate' for short-squeeze context) and clarifies which arguments apply to which analyses. However, it does not explicitly contrast with alternatives or state when NOT to use this tool (e.g., 'for volatility cone, use get_volatility_cone instead'), so it stops short of full exclusion guidance.

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

• search_tickersA
  4.5/5.0
  Behavior4/5

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

  The description adds behavioral context beyond the readOnlyHint annotation by explaining matching behavior, ranking, and exact-match/supported flags. It also implies fuzzy lookup via company-name fragments, enhancing the agent's understanding of results. No contradiction with annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact, well-structured with Args and Returns sections, and every sentence adds value. It avoids fluff, front-loads the core purpose, and uses clear formatting for parameters.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's simple nature and lack of output schema, the description gives a sufficient preview of return values (ranked matches, flags). It's complete for its purpose, though a bit more detail on result ordering or flag semantics could elevate it further.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Despite 0% schema coverage, the description provides rich parameter semantics: it defines query as a symbol or company-name fragment with examples ("NVDA", "nvidia") and states limit is a max matches (1-20). This fully compensates for the sparse schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states it searches or validates tickers against the platform's coverage universe, with a specific verb and resource. It distinguishes itself from sibling tools by explicitly mentioning its role before deep analysis and resolving company names, differentiating from data-retrieval tools like get_stock_price.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It explicitly instructs when to use the tool ('before deep analysis when unsure a symbol is supported, or to resolve a company name to its ticker'), providing clear context. While it doesn't explicitly name alternatives or say when not to use, the guidance is actionable and sets expectations.

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

• simulate_option_chainA
  4.5/5.0
  Behavior4/5

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

  The description goes well beyond the readOnlyHint annotation by explaining the Black-Scholes simulation behavior, that the server fetches the current chain, and that the output is a re-priced chain with Greeks. It also discloses parameter semantics like IV shift range (-50 to +50) and sim_dte=0 meaning at expiry.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-organized with a short purpose statement, a clarifying analogy, a use-case bullet list, an Args section, and a Returns section. Every sentence adds useful information and there is no filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given there is no output schema, the description appropriately states the return as 'The re-priced chain with Greeks at the simulated conditions.' It covers the purpose, expected inputs, and output at a high level. It could specify the chain structure or edge cases, but for a simulation tool with clear annotations and docs, this is quite complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  With 0% schema description coverage, the description fully compensates by explaining all five parameters, including ticker's server-side chain fetch, sim_price's hypothetical role, sim_dte's expiry interpretation, iv_adjustment's range and example, and expiration's format and default.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with a specific verb and resource: 'Re-price an options chain at a hypothetical stock price, DTE, and IV shift.' This clearly distinguishes the tool from sibling chain readers like get_options_chain and scenario analyzers like run_scenario_analysis by emphasizing the hypothetical what-if nature.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides explicit use-case bullets ('What an option would be worth if the stock moves', 'How theta decay reshapes the chain over time', 'IV crush / IV spike what-ifs'). It gives clear context for when to use the tool, though it does not explicitly name alternatives or exclusions.

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

• get_earnings_calendarA
  4.6/5.0
  Behavior4/5

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

  ReadOnlyHint annotation already marks it as a read-only operation. The description adds context about the output including expected moves implied by options pricing, which is a key behavioral trait beyond the annotation. It does not mention pagination or edge cases, but the read-only status is established.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and well-structured: a one-line summary, a clarifying sentence, a usage trigger list, and a concise Args/Returns block. Every section earns its place without redundant phrasing.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description covers purpose, usage guidelines, parameter semantics, and return value. Since output schema is absent, the Returns statement fulfills that need. For a simple read-only calendar tool, this is complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema has 0% description coverage and both parameters are undocumented in the schema. The description's Args section explains days_ahead as the number of days to look ahead with default 7, and min_market_cap as a minimum market cap filter in billions, providing essential semantics that compensate fully for the schema gap.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with 'Get upcoming earnings announcements'—a specific verb plus resource. It further elaborates that it shows companies reporting earnings in the upcoming period including expected move implied by options pricing, which distinguishes it from related tools like economic calendar or earnings history.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description includes an explicit 'Use this tool when...' section listing concrete user intents: upcoming earnings, what companies report this week, earnings calendar. It doesn't mention when not to use it or alternatives, so it's clear context but lacks exclusions.

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

• get_economic_calendarA
  4.6/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, covering the safety profile. The description adds default date-range behavior (from today, to ~1 week out), but does not disclose other behavioral details like timezone handling, inclusivity of dates, or response size limits.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Four compact sections (purpose, when-to-use, args, returns) with no fluff. Front-loaded with the core purpose, and every bullet is actionable and necessary.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only calendar tool with two optional parameters and no output schema, the description covers purpose, usage, parameter format/defaults, and return shape. It is self-sufficient and complete for this complexity level.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description fully compensates. The Args section defines both parameters with YYYY-MM-DD format and explicit defaults, adding meaningful semantics beyond the bare string type in the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Description opens with a specific verb+resource: 'Get the macro economic-event calendar' and enumerates concrete examples (CPI, FOMC, jobs reports). It distinguishes from the sibling get_earnings_calendar by noting 'Event risk beyond earnings'.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Explicit 'Use this tool when the user asks about:' section lists three concrete query types. It implicitly signals alternative usage via 'Event risk beyond earnings,' suggesting not to use for earnings-related events.

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

• get_historical_chainA
  4.6/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true. The description goes beyond that by explaining this is an EOD snapshot with multi-year historical availability, which clarifies the temporal behavior. It could add more details about data caveats (e.g., splits/dividends), but it is transparent enough for safe invocation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured and front-loaded: a crisp definition, then use guidance, then args, then return summary. Every line adds value and there is no filler or redundant restating of the title.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a read-only tool with three simple string parameters and no output schema, the description covers purpose, usage, parameters, and return type. It stops short of describing the exact shape of the chain snapshot, but the provided context is sufficient for selecting and invoking the tool correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must carry the burden. It does so by listing each parameter with a semantic hint and date format ('Stock symbol', 'Expiration date YYYY-MM-DD', 'The historical date to snapshot YYYY-MM-DD'). No enums or nesting, so this is adequate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb phrase ('Get the options chain as it looked on a past trading day') and clearly identifies the resource (historical options chain). It distinguishes itself from the current-chain sibling by emphasizing the historical EOD snapshot nature.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Explicitly states 'Use this tool when the user asks about' and provides concrete use cases like historical pricing, pre/post-event chain views, and backtesting. These exclusions help an agent select it over current-chain or other options tools.

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

• get_options_chainA
  4.6/5.0
  Behavior4/5

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

  Annotations already provide readOnlyHint=true, and the description adds useful context beyond that: default expiration selection, default 20-strike width, and the ability to override with expiration or full chain. It does not disclose potential data delays or rate limits, but it gives enough behavioral transparency for tool selection.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured with a brief purpose, return summary, usage triggers, and a clean Args section. Every section helps the agent decide and invoke correctly; there is no filler or redundant elaboration.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given there is no output schema, the description adequately describes the return content (calls, puts, Greeks, IV, volume, open interest, metadata) and documents defaults, overrides, and constraints. This is sufficient for effective tool selection and invocation without additional structured metadata.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, yet the description fully compensates by documenting every parameter: ticker with examples, expiration format and override behavior, num_expirations range, and strikes_around semantics including 0 for full chain. This is strong added value beyond the bare schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb and resource ('Get the options chain for a ticker') and clearly enumerates the returned content: calls, puts, Greeks, IV, volume, and open interest per strike. This distinguishes it from sibling tools like get_options_by_delta or get_historical_chain.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly lists user intents that should trigger this tool: options prices, call/put prices, volume/open interest, and full chain information. It also advises to use the default narrow strike range unless the analysis genuinely needs a wider one, but it does not explicitly name alternatives or exclusion cases.

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

• get_max_painA
  4.7/5.0
  Behavior4/5

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

  The readOnlyHint: true annotation is appropriately reflected, and the description adds meaningful behavioral context: it explains the concept of max pain and notes that the return includes 'the loss profile by strike.' While it doesn't detail every edge case, it doesn't need to for a read-only lookup tool. It goes beyond the annotation by specifying the return structure.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise and well-structured: a one-sentence summary, a brief explanatory definition, a bulleted usage list, and a compact Args/Returns section. Every sentence adds value, and the structure front-loads the most critical information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple two-parameter read-only tool, the description covers all essential aspects: purpose, usage context, parameters, and return value. It omits potential details like response format or error conditions, but these are not critical given the tool's simplicity and the presence of clear descriptions.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  With 0% schema description coverage, the description fully compensates by documenting each parameter: 'ticker: Stock symbol' and 'expiration: Expiration date YYYY-MM-DD (default: nearest)'. It provides format, requiredness, and default behavior, making the schema immediately usable.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with a clear, specific statement: 'Get the max pain strike for a ticker.' It uses a precise verb-noun structure and uniquely identifies the tool's function among many options-related siblings like get_options_chain and get_gex. The purpose is immediately understandable and distinct.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly lists 'Use this tool when the user asks about:' followed by three clear scenarios (max pain level, pinning at expiration, option-writer positioning). This gives the agent direct, actionable guidance on when to invoke this tool over alternatives.

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

• get_zero_dteA
  4.8/5.0
  Behavior4/5

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

  Annotations only declare readOnlyHint: true, which the description does not contradict. The description adds valuable context by listing the specific analytics returned and noting the tool's limitation on daily-expiration tickers and trading days. While it doesn't discuss return format or edge cases, it goes beyond the annotation's minimal info, so a 4 is appropriate.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is tightly organized: purpose, includes, usage triggers, restriction, args, and returns. Every section adds value and there is no redundancy or filler. It is front-loaded with the core action, making it easy to scan.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given one simple parameter, a read-only annotation, and no output schema, the description covers all necessary aspects: what it does, what it includes, when to use it, parameter format, and return content. There are no missing critical elements for an agent to successfully select and invoke the tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema provides only type and title for ticker with 0% description coverage. The description compensates fully with: 'Args: ticker: Stock symbol with 0DTE listings (e.g., 'SPY')'. It clarifies the parameter's meaning and provides an example, giving the agent everything needed.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with a specific verb and resource: 'Get 0DTE (same-day expiration) analytics for a ticker.' It enumerates the exact data included (gamma exposure, gamma flip level, max pain, theta decay projection, today's chain), clearly differentiating it from sibling tools like get_gex or get_options_chain. The purpose is unambiguous and precise.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It provides explicit use cases: 'Use this tool when the user asks about: 0DTE setups... intraday gamma/pinning levels... today's expiration chain.' It also gives a critical restriction: 'Only meaningful for tickers with daily expirations (SPY, QQQ, SPX...) on trading days.' This covers both when and when-not, meeting the highest bar.

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

• run_scenario_analysisA
  4.8/5.0
  Behavior4/5

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

  Annotations declare readOnlyHint: true, which the description does not contradict. The description adds beneficial behavioral context beyond the annotation by noting the approximation method ('linear delta/vega/theta approximation') and what the output contains ('Estimated P&L under the scenario with per-Greek contributions'). It avoids claiming any side effects not covered by the read-only hint. While not exhaustive, it supplements the annotation with useful technical detail.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured and concise, with a clear introductory sentence, a short list of use cases, and a structured Args section. Every sentence provides essential information—purpose, usage, and parameter details—without redundancy. It is appropriately sized for a tool with 4 parameters, front-loading the core purpose and then detailing parameters in a scannable format.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's complexity (4 parameters, 1 required, no output schema, nested examples), the description covers all necessary aspects: input format with full example, parameter explanations, a note on data source (Greeks from another tool), and output description. It provides enough context for an agent to invoke it correctly, including default values implied through examples. Even without an explicit output schema, the description tells what to expect.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, and the description fully compensates. It provides a detailed example for the 'positions' parameter, including JSON structure and a note that plain text works for stock-only portfolios. It also explains each parameter's meaning with examples (e.g., 'stock_move_pct: Percent stock price change to simulate (e.g. -5)'). This is far more informative than the schema alone and fully clarifies parameter usage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's purpose: 'Run what-if scenario analysis on a portfolio' and describes what it shows ('how portfolio value changes under different market conditions'). It distinguishes itself from siblings by focusing on scenario/P&L analysis, listing specific use cases like 'What-if scenarios' and 'Portfolio P&L under different conditions', which sets it apart from sibling tools that serve other analytical functions.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly states when to use it with bullet points: 'Use this tool when the user asks about: - What-if scenarios - Portfolio P&L under different conditions - Price/vol sensitivity'. It also provides a practical prerequisite ('Get option Greeks from get_options_chain first') linking to a sibling tool, effectively guiding the agent on proper workflow. This is actionable guidance.

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

• get_volatility_risk_premiumA
  4.9/5.0
  Behavior5/5

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

  The tool is annotated readOnlyHint, and the description does not suggest any side effects. It clearly states what it calculates and returns, without ambiguity. The description also explains the meaning of the metric, making its behavior transparent.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a bit long but well-structured. It includes the formula, interpretation, use cases, args, and returns. It could be slightly more concise, but the extra information is valuable and not redundant. The structure with sections makes it easy to read.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description includes the formula, the interpretation of positive/negative values, explicit usage scenarios, explanations of parameters, and what it returns. It provides all necessary context for a caller to understand the tool's behavior and output. There is no missing critical information.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Even though the schema lacks descriptions, the tool description provides clear explanations for all parameters: ticker as stock symbol, lookback_days for realized vol calculation, and view with three options. Defaults are mentioned. This fully covers the parameter meanings.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly defines the tool's function: calculating the volatility risk premium and provides the formula. It distinguishes the tool by focusing on VRP, which is unique among the sibling tools. The explicit use cases help clarify its purpose.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly states when to use the tool, listing specific user queries such as 'Volatility risk premium or VRP' and 'IV vs RV spread'. It also explains the interpretation of positive/negative VRP, which helps in deciding when it's appropriate. This is explicit guidance.

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