GammaRips Options Intelligence

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

With no annotations, the description fully discloses behavioral traits: classification logic for bracket (including exact vs. heuristic resolution), trailing replay mechanics, thin-tape caveat, and lack of slippage. It also includes empirical context (e.g., EV-negative cheap targets). This is comprehensive.

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

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

The description is well-structured with headings, bullet points, and clear sections. It front-loads the core purpose. While lengthy, every sentence adds value for an AI agent selecting between rule families and understanding output. Minor redundancy (e.g., repeating 'research-only') prevents a 5.

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

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

Given 8 parameters, 0% schema descriptions, and a complex output schema, the description is remarkably complete. It explains both rule families, return fields, and caveats like thin-tape and no slippage. The measured context (e.g., 2026-07-06 pool study) adds practical depth.

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

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

Schema description coverage is 0%, but the description compensates fully. It explains each parameter's meaning, defaults, clamping, and rule-specific requirements (e.g., target_pct required for bracket, trail_pct for trailing). The detailed breakout of bracket classification also clarifies output semantics.

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

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

The description clearly states the tool's purpose: scoring a user-provided exit rule against historical pool contracts. It distinguishes two rule families (bracket and trailing) and explicitly notes it is research-only. This specificity and differentiation from siblings earn a top score.

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

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

The description provides clear context for when to use each rule family (e.g., bracket for fixed target/stop, trailing for trailing stop). It advises that the tool surfaces evidence, not prescriptions. However, it lacks explicit when-not-to-use scenarios, preventing a 5.

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

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

The description discloses the output structure (list of scan_date and signal_count), indicating a read-only operation. Without annotations, it does not mention potential side effects, but the simple getter nature makes this adequate.

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

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

Description is extremely concise with one sentence and a clear returns section. Every part is meaningful and front-loaded.

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

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

Given no parameters and presence of an output schema, the description is sufficiently complete for this simple tool. However, it could mention that it requires no inputs or prerequisites.

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

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

No parameters exist, so baseline score of 4 applies. Description adds no param info, but none is needed due to zero parameters.

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

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

The description clearly states that the tool returns scan dates with data availability and shows the output format including signal_count. It differentiates from siblings like get_contract_snapshot or get_daily_report which deal with different data.

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

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

The description does not explicitly state when to use this tool versus alternatives. It implies usage for checking available dates before leveraging other tools, but no direct guidance is given.

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

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

With no annotations provided, the description carries full responsibility. It discloses that marks are delayed per plan, thin contracts may have gap days (missing dates mean no trades), and the close is the honest end-of-day mark. It also states that the server does not simulate exits. This is thorough, though it could mention authorization or rate limits if applicable.

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

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

The description is well-structured: it opens with the core purpose, then explains caveats, usage guidance, parameter details, and return value structure. It is slightly verbose but every sentence carries meaningful information. Front-loading the main idea helps an agent quickly grasp the tool's function.

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

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

Despite moderate complexity (3 parameters, no nested objects, output schema exists), the description fully covers purpose, usage context, behavioral nuances, parameter formats, and return value shape (contract, dates, bar_count, bars etc.). With an output schema present, the description still adds valuable context, making it complete.

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

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

Although schema description coverage is 0%, the description provides extensive parameter details: the 'contract' parameter expects an OCC-style ticker with an example, 'from_date' and 'to_date' formats are specified ('YYYY-MM-DD') with defaults and a span cap of 120 days. This adds significant meaning beyond the schema's raw property definitions.

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

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

The description clearly states that the tool returns 'DAILY mark series (OHLCV)' for one option contract over a date range. It distinguishes itself from sibling 'get_contract_snapshot' (which provides a right-now read), making the purpose specific and differentiated.

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

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

The description explicitly tells when to use this tool versus alternatives: it composes with 'get_contract_snapshot' for live marking, and suggests using 'estimate_exit_rule' or 'get_harvest_curve' for distributional exit research, and 'get_opportunity_surface' for excursion context. It also advises the user to bring their own exit rule, providing clear guidance on tool selection.

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

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

With no annotations, the description fully discloses behavioral traits: cache refresh frequency (~10 min during market hours), automatic fallback, absence of bid/ask/spread due to data plan, and what the returned fields represent (e.g., OI updates once each morning). No contradictions.

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

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

The description is longer than ideal but well-structured with bullet points and clear sections. Every sentence adds value; no redundancy. Still, some conciseness could be improved by trimming verbose explanations, but overall very good.

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

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

Given 2 parameters and an output schema, the description is very complete: covers input requirements, caching behavior, alternative tools, return field list, and limitations. The output schema reduces the burden, but the description still adds context about field semantics.

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

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

Schema description coverage is 0%, but the description adds substantial meaning: 'contract' is defined as 'OCC-style option ticker exactly as served by the pool tools' with an example; 'live' is explained as 'force a fresh upstream fetch' with default behavior. This fully compensates for the missing schema descriptions.

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

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

The description clearly states it provides a 'FRESH (entry-day) snapshot for ONE option contract' and explicitly lists the fields it contains. It distinguishes itself from pool rows and sibling tools like get_pool_liquidity, making the purpose unambiguous.

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

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

The description explicitly guides when to use the tool: 'Use it at decision time.' It explains the cache-first behavior and when to use live=true, and provides a direct alternative: 'To refresh a whole shortlist in one call, use get_pool_liquidity instead.' This gives clear context and exclusions.

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

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

With no annotations, the description carries full behavioral burden. It discloses that the tool returns a full report with specific fields (title, content, created_at, scan_date). No side effects or auth requirements are mentioned, but the read-only nature is clear from the 'Returns' phrasing.

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

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

The description is two sentences plus an Args/Returns block. Every sentence provides value: purpose, parameter details, and return structure. No redundant or vague language.

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

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

Given the single optional parameter and the presence of an output schema, the description adequately covers functionality. It lists return fields and parameter behavior. However, it does not clarify how this differs from get_report_list, leaving minor ambiguity.

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

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

Schema coverage is 0%, so the description must compensate. It adds meaning by specifying the format (YYYY-MM-DD) and default behavior (most recent) for the 'date' parameter, which is not present in the schema.

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

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

The description states 'Returns the full daily intelligence report' — a clear verb and resource. It distinguishes from siblings like get_contract_snapshot or get_report_list by specifying 'daily intelligence report'.

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

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

The description implies usage for retrieving a daily report, with optional date filtering. However, it provides no explicit guidance on when to use this tool versus siblings like get_report_list or when not to use it, leaving the agent to infer context.

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

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

With no annotations, the description carries the full burden. It discloses fail-closed behavior (null earnings_in_window treated as in-window), that dates are estimates until confirmed, and the return fields. This provides good transparency for a data lookup tool.

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

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

The description is somewhat long but well-structured with paragraphs and bullet points. It front-loads the main purpose and uses clear language. Minor redundancy could be trimmed, but overall it is effective.

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

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

Given the tool's complexity and the presence of an output schema, the description is complete. It covers return values, edge cases (fail-closed, estimates), and provides sufficient context for an agent to use it correctly.

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

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

The input schema has 0% description coverage, so the description must compensate. It explains each parameter: ticker (optional if contract given), expiration (optional, derived from contract), and contract (OCC-style, supplies both). This adds meaningful meaning beyond the schema's bare names.

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

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

The description clearly states the tool's purpose: get the next scheduled earnings date for a ticker and determine if it falls on or before a given expiration (earnings_in_window). It distinguishes itself from sibling tools by explaining the 'doctrine hard-exclusion check' and that it is used per candidate, not in the pool.

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

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

The description explains when to use the tool (per candidate, not in the pool) and provides context about the engine's behavior. It also includes the fail-closed instruction. However, it does not explicitly list alternatives or when not to use it, but the context is sufficient.

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

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

With no annotations provided, the description carries full burden for behavioral transparency. It thoroughly discloses enrichment conditions, edge ranking, response size details, strict field validation, leakage-safe view, and liquidity caveats (e.g., recommended_spread_pct is permanently NULL). This is highly transparent.

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

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

The description is somewhat long but well-organized into paragraphs and a labeled argument list. Every sentence provides valuable information, and the structure makes it easy to scan. Minor verbosity is justified given the tool's complexity.

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

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

Given the tool's complexity (7 parameters, no enums, with output schema), the description is complete: it covers all parameters, behavioral nuances, caveats, and even references sibling tools (get_playbook). The presence of an output schema means return values need not be described.

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

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

Despite 0% schema description coverage, the description adds detailed meaning for each of the 7 parameters: scan_date defaults to latest, directional filter, ticker filter, limit clamping (1-50), summary vs. full rows, field projection with strict validation, and offset clamping (0-500). This compensates fully for the lack of schema descriptions.

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

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

The description clearly identifies the tool's output as the curated candidate pool of AI-enriched signals for a scan date, mentioning specific features like news, technicals, catalyst context, and momentum. It also distinguishes itself by noting this is the pool the engine's own selection works from and directs to get_playbook for a different purpose.

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

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

The description provides explicit usage guidance: treat it as the daily candidate set, reason to your own contract, and reference get_playbook for running your own tournament. It also explains parameter behaviors like summary mode, field projection, and pagination, though it doesn't explicitly state when not 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.

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

Describes the output including classifications and column safety (only 'feature' columns are safe as selection inputs). While it does not explicitly state read-only or side effects, the description of a 'data contract' implies a read operation. Annotations are absent, so the description carries full burden; it adds value beyond the schema but could be more explicit about non-destructive nature.

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

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

The description is front-loaded with a clear purpose and distinction from a sibling. It is well-structured, using bullet points for the output format. However, it is slightly verbose with phrases like 'RECHENTER / POWER-USER tool' and could be trimmed without losing meaning.

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

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

Given no parameters and an output schema provided in the description (including return structure and field descriptions), the description is fully complete. It also references additional resources like 'get_playbook' for further context, leaving no gaps for the agent.

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

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

No parameters exist, and the schema coverage is 100%. The description does not explicitly note the absence of parameters, but with zero parameters, a baseline of 4 applies. The description adds no extra parameter info, but none is needed.

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

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

The description clearly states it returns the 'substrate DATA CONTRACT, machine-readable' with schema details, using a specific verb and resource. It distinguishes itself from 'get_signal_explainer' by positioning this as a formal contract for research code versus an everyday field meaning tool.

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

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

Explicitly tells when to use this tool vs 'get_signal_explainer' for everyday needs. It also advises to use it to ground research code and references 'get_playbook' for prose rules, providing clear when-to-use and when-not-to-use guidance.

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

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

No annotations are provided, so the description carries the full burden. While the name and description imply a read-only operation, there is no explicit statement about behavioral traits such as permissions, rate limits, side effects, or data freshness beyond 'most recent scan'. This is insufficient for a tool with no annotations.

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

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

The description is extremely concise: two short paragraphs. It front-loads the purpose, then provides parameter and return details. Every sentence adds value with no redundancy.

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

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

The tool has low complexity (1 parameter, simple return type). The description covers purpose, parameter semantics, and return format. Given the existence of an output schema (mentioned in context), the description is complete for the agent to understand and invoke the tool.

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

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

The schema has 0% description coverage for the 'limit' parameter, but the description adds meaning: 'limit: How many preview rows to return (default 5, max 20).' This provides semantics missing from the schema, though it could be more detailed (e.g., format of limit values).

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

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

The description clearly states the tool returns the top N enriched signals for the most recent scan with minimal fields, specifically for public/freemium teasers. It distinguishes itself from sibling 'get_signal_detail' by noting that this tool excludes contract specifics and full thesis.

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

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

The description explicitly states when to use: 'for public/freemium teasers'. It also clearly states when not to use and what alternative to use: 'No contract specifics or full thesis — use get_signal_detail for that.'

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

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

With no annotations, the description carries full burden. It discloses that the curve is computed live from the closed-window opportunity surface and moves as data accrues. It also explains the touch vs fill distinction. However, it doesn't mention idempotency or rate limits.

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

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

The description is well-structured with a clear first paragraph defining the tool, a second with critical caveats, and structured parameter/return sections. Every sentence is informative without redundancy.

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

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

Given the complexity and presence of an output schema, the description covers the key return fields (window, n, targets with day_of_peak, stops) and provides a measured context example. It lacks explicit edge-case handling but is sufficiently complete for most use cases.

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

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

The description includes an 'Args' section that explains each parameter's purpose, default values, and constraints (e.g., targets clamped 5-300, stops clamped 5-95). Since schema description coverage is 0%, this adds significant meaning beyond the bare schema.

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

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

The description opens with a clear, specific verb+resource statement: 'for each profit target X, the probability a pool contract's premium TOUCHED +X% at least once...'. It distinguishes itself from siblings like estimate_exit_rule by focusing on the harvest curve ceiling concept.

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

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

The description warns 'a TOUCH IS NOT A FILL' and states the curve should be used to understand the surface, not as a strategy return. This provides solid context for when to use this tool, though it doesn't explicitly name alternatives.

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

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

With no annotations, the description fully discloses behavioral traits: realized-only (post-exit), returns as fractions of entry premium, paper-traded, not investment advice, and cohort immaturity. No contradictions.

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

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

Well-structured with introductory paragraph, warnings, and clear Arg/Returns sections. Slightly verbose in places but no unnecessary repetition. Front-loads the core purpose effectively.

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

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

Given the tool's moderate complexity and presence of an output schema, the description covers all essential aspects: data source, timing, filtering, interpretation caveats, and return format. No gaps remain.

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

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

Despite 0% schema coverage, the description includes an 'Args' section explaining each parameter's purpose, default, and constraints (e.g., lookback_days clamped 1-365, direction filter case-insensitive). This adds significant value beyond the schema.

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

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

The description clearly states that the tool aggregates realized paper-trading performance over a lookback window for one tournament pick per day. It specifies the engine's receipts and real-fill simulation, distinguishing it from siblings like get_signal_performance which may handle unrealized or other data.

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

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

Provides explicit guidance: defaults to live cohort, warns about small N and noise, suggests using policy_version='all' for broader view. Does not directly contrast with sibling tools but offers sufficient context for appropriate use.

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

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

No annotations are provided, so the description carries full burden. It explains it uses pandas_market_calendars (NYSE) deterministically, knows about holidays and early closes, and lists the return fields exhaustively. There are no contradictions, and the behavior is well-documented.

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

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

The description is efficiently structured with a clear first sentence stating purpose and benefit, followed by a second paragraph with the return format. Every sentence adds value with no redundant content.

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

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

Given zero parameters and a detailed output schema included in the description, the tool is fully specified. It covers all necessary context: what it returns, how it works (deterministic calendar), and the data format. No gaps.

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

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

The tool has zero parameters, so the baseline is 4. The description does not need to add parameter details but provides extensive return value semantics which is beneficial beyond the schema.

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

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

The description clearly states the tool returns whether the US equity market is open today plus the next open/close. It specifies the verb 'returns' and the resource 'market calendar status', and distinguishes itself from sibling tools by addressing a specific common hallucination problem.

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

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

The description implies usage when an agent needs accurate market open/close times, calling out the hallucination class it eliminates. However, it does not explicitly state when not to use it or mention alternative tools, though the sibling list doesn't overlap in function.

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

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

Although no annotations are provided, the description explains that the tool returns realized excursions only for closed windows by default, warns it's not a tradeable label, and mentions NULL columns for open rows. Lacks explicit statement on read-only nature but context is clear.

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

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

The description is information-dense, well-structured with bolded sections, and front-loaded with the core concept. Every sentence adds value.

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

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

Given the output schema exists, the description covers the return format, explains each field in rows, and includes meta information. It is complete for the tool's complexity.

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

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

All four parameters (scan_date, ticker, days, include_open) are explained with usage details, compensating for 0% schema coverage.

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

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

The description clearly states the tool returns per-contract realized excursions of option premium with no exit rule, distinguishing it from sibling tools like get_harvest_curve and estimate_exit_rule.

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

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

Explicitly states when to use this tool vs alternatives: use get_harvest_curve for distributional summaries and estimate_exit_rule for scoring exit rules. It also clarifies data returned.

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

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

No annotations provided, so description carries full burden. Describes return statistics, notes fractions, and warns that whole-pool composite is negative by design. Missing explicit statement about being read-only or safe, but otherwise thorough.

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

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

Well-structured with sections, front-loaded purpose, no wasted sentences. Each sentence adds value: purpose, important note, parameters, returns.

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

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

Output schema exists, so return details not needed. Description covers purpose, usage guidelines, parameters, and critical context about composite negativity. Complete for this tool's complexity.

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

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

Schema has 0% description coverage; description provides allowed values for horizon ('same_day'/'3d' with explanations), whitelists group_by values, explains date format. Compensates fully for missing schema descriptions.

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

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

Clearly states verb 'aggregate' and resource 'realized-label statistics over the full labeled pool', distinguishes from sibling 'query_outcomes' as exploration companion before row-level data.

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

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

Explicitly tells when to use ('see how outcomes distribute before pulling row-level data') and when not to use ('not to compute a strategy track record'), names alternative 'query_outcomes'.

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

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

With no annotations provided, the description carries the full burden. It discloses that the data is raw and unfiltered ('wide net BEFORE curation'), which is a key behavioral trait. However, it does not mention any performance characteristics, ordering, or limitations beyond the contrast with the curated version.

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

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

The description is extremely concise: two sentences with no wasted words. The first sentence states the core purpose, and the second adds crucial context about the sibling tool. It is well front-loaded and every sentence earns its place.

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

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

Despite having 5 parameters and no behavioral annotations, the description only covers the general purpose and relationship to another tool. It does not provide enough context for parameter usage, return format, or invocation guidance, leaving significant gaps for an agent to correctly use the tool.

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

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

The schema description coverage is 0%, meaning the description must add meaning to the 5 parameters (limit, ticker, direction, min_score, scan_date). The description does not explain any of these parameters, leaving the agent without guidance on how to use them effectively.

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

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

The description clearly states the verb 'get' and the resource 'overnight scanner signals', specifying they are raw and before curation. It explicitly contrasts with the sibling tool 'get_enriched_signals', providing distinct differentiation.

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

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

The description directly tells the agent to use this tool to 'see where unusual options activity concentrated overnight across the full scan universe' and contrasts it with the curated pool 'get_enriched_signals'. It implies when not to use it (for curated data) but does not explicitly state exclusions or alternative contexts.

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

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

Given no annotations, description fully bears the burden. It explains the behavior: fetches markdown, returns structured data, and warns about dynamic content. No contradictions; transparency is high.

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

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

Every sentence serves a purpose: purpose first, then usage guidance, then parameter details, then return format. Efficient and well-structured, with no waste.

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

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

Despite its simplicity (1 param, 0 nested objects, output schema present), the description covers all needed context: what to fetch, how to find playbooks, caching advice, and return structure. Integrated with sibling tool `list_playbooks`.

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

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

Schema has 0% coverage for parameter description. The description compensates fully by detailing valid values with examples and referencing `list_playbooks` for discovery, adding significant meaning beyond the schema.

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

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

Clearly states 'Fetch one methodology playbook (markdown) by name.' with specific verb and resource. Distinguishes from sibling `list_playbooks` by noting its role in listing available names.

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

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

Explicitly guides the agent to start with 'start-here', use `list_playbooks` to see all, and re-fetch instead of caching due to living documents. Mentions 'changelog' for changes, providing clear when-to-use and when-not-to scenarios.

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

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

Despite no annotations, the description fully discloses the read-only nature, data source, column constraints, caveats (e.g., frozen fields, NULL values), data lag, and return format. No contradictions.

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

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

The description is well-structured with clear sections and front-loaded with the main purpose. It contains some detailed caveats but each sentence adds value. Could be slightly more concise but is efficient.

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

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

Given the tool's complexity, presence of an output schema, and detailed parameter explanations, the description covers all necessary aspects: data source, timing, field caveats, and return structure. It is complete for an AI agent.

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

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

The description provides an 'Args' section explaining each parameter's meaning, defaults, and constraints (e.g., scan_date format, limit clamp). This adds significant value beyond the schema, which only has titles and defaults.

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

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

The description clearly states that the tool returns 'point-in-time FEATURE VECTORS for the labeled candidate pool' from a specific view, distinguishing it from siblings like get_enriched_signals. It specifies the data source and purpose.

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

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

Explicitly states when to use this tool (for research, joining against outcomes) and when to use an alternative (get_enriched_signals for live pool narrative enrichment). Also mentions the data lag, guiding appropriate usage.

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

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

Without annotations, the description carries the full burden. It discloses refresh behavior (every ~10 minutes during market hours, with pre-open pass) and data field absence (bid/ask/spread only with quote feed). It could explicitly state read-only nature but is otherwise thorough.

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

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

The description is well-structured with sections and front-loaded key points, but it is somewhat lengthy with some redundant phrasing (e.g., 'in ONE call', 'the batch companion'). Still, every sentence adds value.

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

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

Given the tool's complexity (batch snapshot with freshness provenance), the description is complete. It explains the output shape referencing another tool, covers freshness, field availability, and use cases. No critical gaps for an AI agent.

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

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

Schema has 0% description coverage, so description must add meaning. It explains the default behavior of scan_date (most recent pool with snapshots, live during market hours) and the optional shortlist filter contracts with max 60 items. This goes well beyond the schema types.

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

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

Description clearly states it provides the latest liquidity snapshot for the whole pool or a shortlist, distinguishing it from sibling 'get_contract_snapshot' which is for single contracts. It uses specific verbs and describes the resource and scope.

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

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

Explicitly explains when to use (the ~10:00 ET decision window, replacing N per-contract fetches) and when to use alternative 'get_contract_snapshot(..., live=true)' for a single contract or fresher read.

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

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

With no annotations provided, the description carries full behavioral disclosure. It comprehensively explains that data appears only after trade exit (never same-day), includes no-trade days separately, excludes invalid-liquidity rows, and details the live policy parameters. This fully informs the agent of the tool's behavior and limitations.

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

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

The description is well-structured with clear paragraphs and a bulleted list of arguments. It is front-loaded with the core purpose and efficiently covers behavioral context, policy details, and parameter semantics without redundancy. Every sentence adds value.

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

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

Given the tool has an output schema, the description still fully explains the return format and fields. It covers all aspects: what data is returned, timing, policy versions, and parameter constraints. No gaps remain for the agent to infer.

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

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

Schema description coverage is 0%, so the description must add meaning. It does so by describing each parameter's purpose, default values, and constraints (e.g., days clamped 1-365, limit clamped 1-200, policy_version default live cohort). This adds significant value beyond the schema's type and default annotations.

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

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

The description clearly states the tool retrieves realized paper trades from the engine's daily selection. It specifies the content (closed positions, row-level, tournament picks per day) and distinguishes from potential siblings by emphasizing it is realized-only and not front-runnable.

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

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

The description provides usage context such as the fact that rows appear only after exit and that cohorts should not be mixed. However, it does not explicitly state when to use this tool over siblings or when not to use it, lacking direct comparison to alternatives.

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

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

With no annotations provided, the description carries full burden. It discloses key behaviors: leakage-safe point-in-time, fail-close rail condition when VIX > VIX3M, and data lag from labeled substrate.

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

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

Description is well-structured: purpose first, then rail explanation, then data source, then parameter details. At about 100 words, it is appropriately concise given the complexity.

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

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

The description covers the tool's purpose, inputs, behavioral notes, and return structure (referencing output schema). Given the presence of an output schema, it provides sufficient context for effective use.

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

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

Schema coverage is 0% (no descriptions in schema). The description compensates by explaining the scan_date parameter: defaults to latest scan date with regime features, and format YYYY-MM-DD, adding meaning beyond the schema.

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

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

The description clearly states it provides point-in-time market-regime context for a scan date, listing specific variables (VIX, VIX3M, SPY trend, VIX delta, regime rail). It distinguishes from 29 sibling tools by being the dedicated regime context function.

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

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

The description explains the tool's purpose and notes that data lags the live pool by ~1-2 days, which guides appropriate use. However, it does not explicitly contrast with sibling tools or state when not to use it.

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

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

Discloses key behavioral traits: deduplication of repeated titles across dates, most recent first ordering. With no annotations, this provides necessary transparency for a list tool.

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

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

Very concise, structured with Args/Returns, no redundant text. Every sentence adds value.

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

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

For a simple list tool with one parameter and an output schema (implied), the description covers essential behavior. Could mention scope or lack of filtering, but not critical.

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

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

Only parameter 'limit' is described with default and role, but this merely restates schema info. Schema description coverage is 0%, so description should add more meaning, but it doesn't.

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

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

Description clearly states it lists available reports with ordering and deduplication. Verb 'list' and resource 'reports' are precise. However, no explicit differentiation from sibling tools like get_daily_report or list_playbooks.

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

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

No explicit guidance on when to use this tool versus alternatives. Does not mention when not to use or provide context for choosing among sibling tools.

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

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

The description discloses that long narrative fields are omitted by default to keep response tight, that thesis and decision fields are always included, and that errors include alternative dates if the ticker is not found. With no annotations provided, these behavioral details are valuable, though it could mention that the operation is read-only and safe.

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

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

Three sentences front-load the main purpose, then efficiently cover default behavior, optional flag, and error handling. Every sentence adds value without redundancy.

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

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

Given the presence of an output schema, the description need not detail return values. It covers core behavior, optionality, and error handling. It omits rate limits and authentication, but these are less critical for a read-only single-item retrieval. Overall, complete enough for effective use.

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

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

All three parameters (ticker, full, scan_date) receive meaningful explanation: ticker is the subject, full=true includes omitted fields, scan_date determines the date, and error behavior is described. Since schema descriptions are missing (0% coverage), the description fully compensates.

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

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

The description clearly states the tool provides a 'deep dive on a single ticker's enriched signal — thesis, catalyst, the recommended contract, and point-in-time features.' It uses a specific verb and resource, and the scope (single ticker vs. list) distinguishes it from siblings like get_enriched_signals.

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

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

The description implies usage for detailed analysis of one ticker and explains default behavior and error handling. However, it does not explicitly contrast with sibling tools or state when not to use it, relying on the name and context to imply differentiation.

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

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

No annotations provided, so description carries full burden. It discloses key behaviors: deterministic lookup table, no LLM/no hallucination, returns 'unknown' row for missing fields, and includes available_fields for misspellings. This is highly transparent for a lookup tool.

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

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

Description is well-structured with section headers (Args, Returns) that improve readability. It front-loads the core purpose. A minor but acceptable trade-off: the docstring format is slightly verbose for an MCP description, but every sentence is informative.

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

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

Given one simple parameter, the output schema exists, and the description covers purpose, usage, edge cases (missing field), and return structure. Nothing essential is missing; it's complete and actionable.

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

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

Single parameter field_name has 0% schema coverage, but the description adds rich context: 'Field name as it appears in tool responses' with concrete examples ('premium_score', 'volume_oi_ratio', 'recommended_contract'). This fully compensates for the lack of schema description.

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

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

Description clearly states it returns a plain-English definition and role of a GammaRips signal field. It uses specific verbs and resource ('Return... definition + role'), and distinguishes from siblings like get_signal_detail by emphasizing deterministic lookup and no-LLM behavior.

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

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

Explicitly says 'Use this for the "what does X mean?" pattern when a chat user asks about a metric we surfaced.' It also explains behavior for missing fields. Though it doesn't list when not to use or alternatives, the context is clear enough given the tool's specific purpose.

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

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

With no annotations provided, the description carries full burden. It explains the 3-day forward window, the discrepancy between underlying movement (54%) and option PnL (41%), and the reason (theta, IV, exit bracket). It does not explicitly state read-only, but the context implies a safe query operation. Minor gap: no mention of data freshness or pagination.

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

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

The description is well-structured with a clear paragraph explaining purpose, a bullet list for arguments, and a return format definition. It is efficient without being overly verbose, though the first line's all-caps could be softened. Every sentence adds value.

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

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

Given the presence of an output schema and a moderate number of parameters, the description covers the essential behavioral and input information. It does not address edge cases like pagination or large result sets, but for a straightforward query tool, it is sufficiently complete.

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

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

Schema description coverage is 0%, so the description must explain parameters. It lists all 5 args with brief but sufficient descriptions (e.g., 'scan_date: Filter by date (YYYY-MM-DD)', 'direction: "bull" or "bear"'). No further constraints or examples, but adequate for typical use.

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

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

The description clearly states the tool measures 'UNDERLYING-STOCK directional outcomes' for a broad enriched pool over a 3-day forward window. It distinguishes from option PnL and specifically names sibling tools for alternative use cases, leaving no ambiguity about what the tool does.

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

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

The description explicitly contrasts this tool with option PnL and directs users to 'get_position_history' for realized option trades and 'query_outcomes' for full-pool option labels. This provides clear when-to-use and when-not-to-use guidance, with named alternatives.

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

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

Discloses behavioral traits: not an option PnL win rate, not paper-trading track record, no bare win_rate field. Mentions lookback window and metric variants. No annotation provided, so description carries burden; lacks info on error handling or auth but is sufficient.

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

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

Well-structured with Args/Returns sections, front-loaded main purpose. Slightly verbose but every sentence adds value.

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

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

Given simple parameter set and existence of output schema, description provides necessary context: what metric is returned, universe markers. Does not overexplain output schema details.

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

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

Schema coverage is 0%, but description explains the single parameter 'days' as lookback period with default 30, adding full semantic meaning.

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

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

Clearly states it aggregates underlying-stock direction statistics and distinguishes itself from related tools (get_historical_performance, get_outcome_summary). Specifies the exact metric name: underlying_direction_win_rate.

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

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

Explicitly states when to use (direction win rate on stock) and when not to (option PnL, paper-trading). Names alternative tools for those use cases.

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

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

No annotations are provided, so the description carries the full burden. It explicitly states 'List the methodology playbooks' implying a read-only, non-destructive operation. Given the context of listing server-side documentation, the behavior is clear. However, it could explicitly state safety (e.g., 'Read-only, no side effects') which would improve transparency.

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

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

The description is concise (three sentences), front-loaded with the main purpose, then elaborates with context and return format. Every sentence adds value: first sentence states action, second explains what playbooks are and references the sibling tool, third specifies the return type. No wasted words.

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

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

Given the tool's simplicity (no parameters, clear output schema), the description is complete. It explains the tool's purpose, the nature of playbooks, how to fetch a specific one, and the return format (list of objects with name, title, summary). The context signals (output schema exists) mean return details are already covered, so no further explanation needed.

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

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

The input schema has zero parameters, so schema coverage is effectively 100%. Per guidelines, baseline is 4 for zero parameters. The description adds useful context about the return structure and the nature of playbooks, providing value beyond the empty schema.

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

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

The description clearly states the tool lists methodology playbooks, defines what playbooks are (versioned server-side documentation), and distinguishes from the sibling tool `get_playbook(name)` used to fetch an individual playbook. The verb 'list' is specific, and the resource 'methodology playbooks' is well-defined.

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

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

The description implies when to use this tool (to see available playbooks) and explicitly points to `get_playbook(name)` for fetching one, providing a clear alternative. However, it does not explicitly state when not to use it or enumerate all alternatives, but the sibling context and mention of the related tool suffice.

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

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

With no annotations, the description fully discloses important behaviors: exclusion of NULL labels and illiquid exits, the non-random nature of illiquid exclusion, the two distinct horizons, and the behavior of aggregate_only mode. It also notes the feature source and label join pattern.

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

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

The description is well-structured with sections for purpose, horizons, exclusions, args, and returns. It is somewhat lengthy but each part adds value and is front-loaded with the core purpose.

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

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

Given 10 parameters (0 required) and an output schema described in the text, the description covers all critical aspects: data content, exclusions, filtering options, aggregation mode, and metadata. It is fully sufficient for an agent to understand the tool's behavior.

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

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

Schema coverage is 0%, but the 'Args:' section adds meaning beyond the schema for most parameters, such as explaining horizon options, delta bounds (0-1), limit clamping (1-200), and aggregate_only behavior. Some parameters like ticker and exit_reason get only minimal descriptions, but overall the description compensates well.

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

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

The description clearly states it provides row-level realized labels joined to feature vectors, with specific examples like 'how did pool contracts with |delta| 0.20-0.46 behave under the same-day bracket?'. It distinguishes from siblings by focusing on granular data and offering an aggregate_only mode, which is not available in summary tools like get_outcome_summary.

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

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

The description includes explicit guidance on when to use, such as asking specific research questions and using aggregate_only when only the shape is needed. It also warns that the two horizons should never be pooled together. However, it does not explicitly state when not to use this tool or compare to alternatives like get_outcome_summary.

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

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

With no annotations, the description carries full burden. It discloses that pool contracts are served from the minute-path table and others fallback, mentions thin tape limitations, and states that the tool does not simulate or validate exits. This covers key behavioral traits, though it could explicitly state read-only nature.

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

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

Description is detailed but well-structured: purpose first, then bracket behavior, then pool/fallback logic, then tape caveats, then disclaimer. It is front-loaded and each sentence adds value. Slightly lengthy but justified by complexity.

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

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

Given the complexity (optional brackets, first-crossing logic, fallback, thin tape) and the presence of an output schema, the description covers most aspects. It explains return fields like anchor, first_crossing, retrieved_from, note. It could mention error handling, but overall complete.

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

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

Input schema has 0% description coverage, so the description must explain parameters. It does so clearly: contract is OCC-style ticker with example, date is ET session date, target_pct and stop_pct are optional percentages of anchor. This adds substantial meaning beyond schema.

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

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

The description clearly states the tool replays the intraday minute path for one option contract on one session, and distinguishes itself from sibling `estimate_exit_rule` by noting the latter is for cohort-level rule scoring. The verb 'replay' and resource 'contract minute path' are specific.

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

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

The description provides explicit context: use for per-contract replay, and 'For cohort-level rule scoring use estimate_exit_rule' is a clear alternative. It does not explicitly list when not to use, but the differentiation is strong.

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

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

No annotations provided, so description carries full burden. It mentions the API and direct HTTP requests, and that it returns a formatted string. Lacks details on rate limits, authentication, or error handling.

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

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

Description is succinct, front-loaded with purpose, then logically lists args and returns. Every sentence is informative without fluff.

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

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

Tool is simple with two parameters and output schema. Description covers purpose, parameters, and return format. Could mention error handling but not necessary for basic usage.

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

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

Schema description coverage is 0%, but description compensates with clear explanations: query is 'The search query string', num_results is 'Number of results... default 5, max 10'. Adds value beyond schema.

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

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

Description clearly states it performs a Google Web Search via direct HTTP requests, and specifies use cases (real-time info, news, grounding). Distinct from sibling tools which are all about contract data and signals.

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

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

Gives explicit use cases (finding real-time information, news, verifying facts) but does not explicitly state when not to use or list alternatives. Implicitly distinct from siblings.

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