thetadata-mcp

by drmartell

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation5/5
Each tool follows a clear pattern of asset class (stock/option/index), data type (list/snapshot/history/at_time), and specific metric (ohlc/trade/quote/greeks/etc.), making them easily distinguishable. Even the many greeks tools are differentiated by order and trade vs. snapshot.
Naming Consistency5/5
All tool names use a consistent lowercase_with_underscores convention and a predictable structure (e.g., stock_snapshot_ohlc, option_history_trade_greeks_first_order). No mixed conventions or arbitrary verbs.
Tool Count1/5
With 59 tools, the server far exceeds even the 'too many' threshold of 25+. While the granularity may reflect the data API's breadth, it creates an overwhelming selection burden for agents and would benefit from consolidation or parameterization.
Completeness5/5
The tool surface comprehensively covers listing, real-time snapshots, historical data, at-time queries, greeks, and market calendar information across stocks, options, and indices. No obvious dead ends for typical market data workflows.
Average 3.2/5 across 59 of 59 tools scored. Lowest: 2.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry transparency. It discloses a 1-month limit and expiration requirement, but does not explain the nature of trade data, output format, or how parameters like version, rate_type, or date range affect behavior. The claim 'IV calculated at each trade' is minimal and vague.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but poorly structured; the '[PROFESSIONAL]' prefix is fluff, and the main sentence lacks an imperative verb. It is under-specified rather than concise, sacrificing clarity for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a 15-parameter tool with no output schema and no annotations, so the description carries a heavy burden. The two short phrases are severely inadequate: they do not explain what data is returned, how trades are scoped, or how to set up a valid request. Critical context for correct invocation is entirely missing.
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 100%, so baseline is 3. The description adds no parameter-level detail beyond the schema; 'requires expiration' simply repeats a required field. Since all parameters are already documented, the description provides no additional semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'IV calculated at each trade' is a noun phrase rather than a clear verb+resource statement. It doesn't explicitly say 'fetch' or 'list', and it fails to distinguish this from sibling option_history_* tools. The name suggests the resource, but the description does not provide a clear purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description only mentions constraints ('Max 1 month, requires expiration') but gives no guidance on when to use this tool versus alternatives like option_history_greeks_implied_volatility or option_snapshot_greeks. There are no explicit when/when-not statements or references to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only mentions the one-month request limit and does not specify whether the data is OHLC, trade, or quote, nor any other behavior like data adjustments or interval restrictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short with two sentences, but the leading '[VALUE]' placeholder is unnecessary and adds noise. The content is concise, but the placeholder undermines professionalism and clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 7 parameters, no output schema, and no annotations, the description is too thin. It fails to explain what 'price reports' includes, how date and time parameters interact, or the meaning of interval options. The one-month limit is the only extra context provided.
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 schema covers all seven parameters with descriptions, so the baseline is 3. The one-month limit adds context to date parameters but does not add specific parameter semantics beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it provides historical price reports for an index, which is clear about the resource and general action. However, it does not differentiate from sibling tools like index_history_eod or index_history_ohlc, leaving ambiguity about what specific price data is returned.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives such as index_history_eod or index_at_time_price. The only constraint mentioned is the one-month limit, which is a limitation rather than a usage guideline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does disclose that the report is generated at 17:15 ET daily, which is a useful timing detail, but it does not explain what data is included, whether it is a read-only operation, any rate limits, or the structure of the report. For an 8-parameter tool, this is insufficient transparency.
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 extremely concise, consisting of a single sentence with no filler or redundancy. It front-loads the key fact that it is an end-of-day report. However, its brevity borders on under-specification, so it does not achieve a 5, but it is still an efficient use of words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having 8 parameters, no output schema, and no annotations, the description provides almost no contextual information. It does not explain what the report contains, how to use filters, what return values look like, or any prerequisites. This is a severely incomplete description for a tool of this complexity.
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 input schema has 100% description coverage for all 8 parameters, so the structural meaning of each parameter is already documented. The description itself adds no parameter-specific semantics, but per the rubric, a baseline of 3 is appropriate when schema coverage is high. No additional value is provided by the description in this dimension.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states this is an 'End-of-day report for options', which indicates the resource (options) and the type (end-of-day) but lacks a specific verb like 'retrieves' or 'lists'. It does not distinguish this from sibling tools like option_history_greeks_eod, which is also an end-of-day report, so differentiation is weak.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as option_history_ohlc or option_snapshot_*. It only mentions the generation time (17:15 ET daily), which is a scheduling detail, not usage context. There are no exclusions or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits such as read-only guarantees, output format, pagination, or rate limits. The tool implies a simple listing operation, but the description fails to specify what the return data represents or how 'request type' affects results.
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 single concise sentence, efficient in length. The '[FREE]' prefix is somewhat extraneous but not harmful. The structure is front-loaded with the core action, though the ambiguous 'by request type' could be removed for better clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, and a single parameter, the description should explain what the returned dates mean, how 'request type' factors in, and what symbols are valid. It does none of this, leaving critical gaps for an agent to understand the tool's full behavior.
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 schema fully documents the 'symbol' parameter with a descriptive explanation. However, the tool description mentions 'by request type' but the schema has no such parameter, creating a mismatch that could mislead an agent into expecting a request type argument. This reduces the semantic clarity beyond what the schema provides.
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 verb 'List' and the resource 'available data dates for an index', which distinguishes it from sibling tools like stock_list_dates or option_list_dates. However, the phrase 'by request type' introduces an ambiguous concept that is not represented in the parameter schema, slightly muddying the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as stock_list_dates or index_list_symbols. The '[FREE]' prefix hints at cost but does not clarify usage context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden of behavioral disclosure. It states only that the tool provides equity market holidays for a year, without any additional context such as return format, data source, timezone, or the fact that it performs a read-only lookup. There is no contradiction, but the disclosure is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence and is concise, but it is not polished due to the unresolved '[VALUE]' placeholder. It front-loads the essential topic but the placeholder detracts from clarity and professionalism, preventing a higher score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple tool with a single parameter and no output schema, but the description still leaves significant gaps: it does not clarify what 'equity market holidays' include (e.g., which exchanges), the expected output structure, or how it differs from the sibling calendar tools. An agent would be uncertain about the response format and the exact scope.
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 coverage is 100% because the only parameter 'year' includes a description ('The year to fetch data for.'). The tool description's phrase 'for a given year' adds no meaning beyond the schema. This matches the baseline of 3 when structured data fully documents parameters.
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 core description 'Equity market holidays for a given year' clearly identifies the resource (holidays) and scope (yearly), which is specific enough to infer the tool's function. However, the leading '[VALUE]' placeholder is an obvious template artifact and there is no explicit verb, so it loses the top marks for a clean purpose statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. Although sibling tools like calendar_open_today and calendar_on_date exist, no mention is made of them or of any selection criteria such as 'use this for annual holiday lists'. The only hint is the phrase 'for a given year', which is implicit rather than explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions interval aggregation and a 1-month limit but does not describe the response format, whether bid/ask sizes are included, or error handling. This is insufficient for a data retrieval tool with no output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loads the core purpose, but the '[VALUE]' placeholder suggests a template error. While it contains no redundant sentences, it lacks the polished structure expected and feels underdeveloped.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the large schema (12 params), no annotations, and no output schema, this description is far too sparse. It doesn't explain the meaning of NBBO, the return format, or how this tool differs from other sibling quote/trade history tools, making it incomplete for effective 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?
All 12 parameters have schema descriptions (100% coverage), so the baseline is 3. The description adds no parameter-specific information beyond what the schema already provides, such as date format details or filtering behavior, so it stays at baseline.
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 states 'NBBO quote history for options', which clearly identifies the tool's function as retrieving historical quote data. However, the leading '[VALUE]' placeholder is unprofessional and the description does not explicitly contrast with other option history tools, though the name and content do provide some differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool over alternatives like option_history_trade_quote. It only mentions constraints ('Max 1 month, requires expiration'), which are limitations rather than usage scenarios or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It states 'Real-time last NBBO quote' but does not explain response structure, whether multiple contracts are returned, or any market-hour/data coverage nuances. It gives only a minimal behavioral hint and no safety or side-effect context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise, but it is under-specified for a tool with 7 parameters and numerous filtering options. The '[VALUE]' prefix appears to be a placeholder artifact, reducing polish and structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations and no output schema, the description must provide context. It only covers the core function and omits the flexible filtering options (strike, right, DTE, wildcard expiration) and the fact that it can return multiple contracts. This leaves an agent without enough context to scope requests effectively.
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 schema provides descriptions for all 7 parameters, so the baseline is 3. The tool description adds no parameter-specific meaning beyond the generic 'option contract', leaving the schema to carry the parameter semantics.
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 identifies the resource as a real-time NBBO quote for an option contract, clearly distinguishing it from sibling snapshot tools like trade or OHLC. It lacks an explicit verb such as 'Gets' or 'Returns', so it reads as a noun phrase rather than an actionable instruction, which is why it is not 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives such as option_snapshot_trade or option_history_quote. There is no mention of scenarios, prerequisites, or alternative tool recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations to lean on, the description carries the burden of disclosing behavior, but it only reveals the 1-month limit. It omits critical behaviors such as date override precedence, single-day restrictions for sub-minute intervals, and default venue, leaving the agent to infer these from schemas or trial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, which avoids fluff, but it includes a confusing '[VALUE]' placeholder and lacks structural front-loading of key differentiators. It is more under-specified than genuinely concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/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 (8 parameters, no output schema, no annotations), the description fails to convey essential context such as return format, date range behavior, venue selection, or how this relates to sibling history/snapshot tools. The 1-month limit alone is not enough.
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 schema already provides 100% coverage for all 8 parameters with detailed descriptions. The tool description adds no additional parameter semantics beyond the 1-month limit, which is a constraint not tied to a specific parameter's meaning.
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 states the tool returns historical OHLC bars for a stock, which clearly identifies the core resource and action. However, it does not explicitly distinguish from stock_history_eod, which also provides OHLC data, and lacks any mention of intraday intervals that differentiate it from daily bars.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like stock_snapshot_ohlc for real-time data or stock_history_eod for daily bars. The only constraint mentioned (max 1 month per request) is a limitation, not a usage guideline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It does not explain what 'Equity market schedule' includes, whether it returns holidays, trading hours, or other details, nor does it mention any edge cases or limitations.
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 single concise sentence, efficiently communicating the core purpose. The leading '[VALUE]' placeholder is slightly odd and adds no value, preventing a perfect 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?
For a simple one-parameter tool with no output schema, the description provides a basic viable understanding. However, it lacks detail about the return value or behavior, which would be helpful for the agent to know what to expect, especially since no annotations exist.
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 schema provides a clear description for the 'date' parameter, and schema coverage is 100%, so the baseline is 3. The description adds no extra meaning beyond what the schema already states, which is acceptable given the high schema clarity.
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 states the tool returns the equity market schedule for a given date, clearly identifying the resource and input. It is distinct from sibling tools like calendar_open_today and calendar_year, though it lacks an explicit verb like 'get' or 'retrieve'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus calendar_open_today or calendar_year. The description gives no context about preferred scenarios or alternatives, leaving the agent to infer selection based only on the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only restates the core function and offers no details about time zone handling, behavior outside market hours, exact-match vs. interpolation, or how date range parameters affect results. The sparse description fails to disclose any behavioral nuances.
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 single sentence, making it concise and front-loaded. However, the '[VALUE]' prefix appears to be a placeholder artifact and detracts slightly from clarity. Overall, it is appropriately sized for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 4 parameters and no output schema, yet the description only mentions symbol and time_of_day implicitly, completely ignoring the optional start_date and end_date parameters. It also fails to clarify what the return value looks like or how the date range interacts with the time-of-day price. This is insufficient for a tool with this complexity.
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 100%, so the input schema already documents all four parameters (symbol, end_date, start_date, time_of_day). The description does not add any parameter-level meaning beyond what the schema provides, so the baseline of 3 is appropriate.
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 'Index price at a specific time of day' clearly states the resource (index price) and the specific temporal context (specific time of day). It implies the action of fetching/retrieving, but it does not explicitly distinguish this tool from siblings like index_snapshot_price or index_history_price, so it lacks explicit differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. The description does not mention when this is appropriate (e.g., for historical point-in-time prices) or when not to use it (e.g., for current snapshot or full history). It simply states the tool's function without contextual usage hints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure, but it only states what the data is (OHLC bars) without explaining behavior such as supported intervals, date range constraints, or response format. It adds no context about intraday vs EOD or any special limitations.
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 a single sentence with no filler or redundancy. The [STANDARD] tag and direct noun phrase are front-loaded and immediately convey the tool's purpose, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 6 parameters, no annotations, and no output schema, the description is severely underspecified. It fails to explain how this relates to sibling history tools, what intervals are supported, or any behavioral constraints, leaving significant gaps in context.
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 input schema has 100% description coverage for all 6 parameters, so the baseline is 3. The description adds no additional parameter meaning beyond what the schema already provides, leaving parameter semantics entirely to the 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 it provides historical OHLC bars for an index, distinguishing it from similar tools for stocks and options. However, it lacks an explicit verb like 'get' or 'retrieve', relying on a noun phrase, which slightly reduces clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives such as index_history_eod, index_history_price, or snapshot tools. The description is purely declarative and offers no contextual or exclusionary information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only mentions 'Real-time' and does not describe return format, units, pagination, authentication needs, or side effects. This is a minimal disclosure that falls short of what is needed.
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 single sentence with no wasted words, and the key information is front-loaded. It is efficient, though somewhat under-specified for a tool with no output schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple snapshot tool with no output schema, the description should at least explain what the returned market value represents (e.g., value of index units, total market cap) or how it differs from price. This information is missing, making the description incomplete for agent decision-making.
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 100%, so the schema already documents both symbol and min_time. The description adds no additional parameter context beyond what the schema provides, so the baseline of 3 applies.
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 provides real-time market value for an index, using a specific verb and resource. It is distinct from sibling tools like index_snapshot_ohlc and index_snapshot_price, though it does not explicitly explain the difference between market value and price, so it loses a point.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as index_snapshot_price or index_snapshot_ohlc. The description simply states what it does without context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the burden of behavioral disclosure, but it only says 'last option NBBO quote at a specific time of day.' It does not clarify that this is historical, how 'last' is determined, timezone handling, or what the response contains. The schema mentions timezone, but the description adds little value.
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 single concise sentence that communicates the core purpose efficiently. However, the '[VALUE]' prefix is extraneous and slightly detracts from the structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This tool has nine parameters and no output schema, yet the description is a single sentence that does not explain parameter interactions, filtering behavior, or return format. It is insufficient for an agent to fully understand the tool's behavior beyond the schema descriptions.
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 100%, so every parameter already has a description. The tool description does not add any additional parameter semantics, which aligns with the baseline score of 3 for high schema coverage.
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 identifies the tool as returning the last option NBBO quote at a specific time of day, which distinguishes it from snapshot or historical range tools. However, it lacks an explicit action verb like 'get' or 'fetch', and the leading '[VALUE]' placeholder adds noise.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as option_snapshot_quote or option_history_quote. The description simply states what it does, leaving the appropriate use case implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It merely restates the tool's name and offers no detail about timezone handling, ambiguity in 'at a specific time' (exact vs last as of), error behavior, or return format. The schema provides parameter definitions but not behavioral context.
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 single short phrase, highly concise and front-loaded with the core purpose. It is not a full sentence, but it avoids any wasted words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 9 parameters, no output schema, and many sibling tools, this description is inadequate. It does not explain the semantics of 'specific time of day' (exact timestamp vs last available before), what data is returned, or how it relates to snapshot/history trade variants.
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 coverage is 100%, so all 9 parameters already have descriptions. The tool description adds no additional meaning about parameter interactions or special cases (e.g., wildcard usage, how time_of_day is applied). Baseline 3 is appropriate since the schema does the heavy lifting.
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 states 'Last option trade at a specific time of day' which clearly identifies the resource (options) and the specific action (last trade at a time). It helps distinguish from option_at_time_quote and history tools, though it lacks an explicit imperative verb like 'retrieves'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance is provided. There is no mention of alternatives, preconditions, or scenarios where this tool is preferred over option_at_time_quote or option_history_trade.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the full burden of behavioral disclosure. It mentions the midpoint-price source and the one-month max window, but it does not explain what 'all orders' means, which specific Greeks are returned, or the structure of the response. It also omits any details about pagination, rate limits, or data coverage, which is a significant gap for a historical data tool.
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 very brief and front-loaded, with the purpose stated first and a key constraint in a second sentence. However, the '[PROFESSIONAL]' prefix is unnecessary and adds noise. The text is concise but arguably too short to be fully informative, earning a 4 rather than a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 15 parameters, a large set of sibling tools, and no output schema, this one-sentence description is insufficient. It does not clarify what 'all orders' means, how the various date/rate/strike parameters interact, or what kind of data the agent should expect in the response. The rich parameter schema partially compensates, but high-level behavioral context remains severely lacking.
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 input schema has 100% description coverage for all 15 parameters, each with a clear explanation. The tool description adds no parameter-specific information beyond what the schema already provides, so it stays at the baseline of 3. The one-month limit is a general constraint rather than a parameter-level detail.
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 states the tool provides historical Greeks for options, computed from midpoint prices, and notes a one-month request limit. It clearly identifies the resource and key constraint, though it lacks an explicit action verb and the phrase 'all orders' is somewhat ambiguous. It partially distinguishes itself from sibling tools like the trade-based 'option_history_trade_greeks_all' via the midpoint-price source.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus its many siblings such as option_history_trade_greeks_all, option_history_greeks_eod, or order-based variants. The phrase 'from midpoint prices' implies one use case, but no alternatives or exclusions are mentioned, leaving the agent uncertain about tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden for behavioral disclosure. It does disclose a one-month limit per request, which is useful, but it fails to mention the return format, whether data is point-in-time, timezone handling, or any rate-limiting implications. The lack of output schema further increases the need for such detail.
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 single sentence with minimal waste. The '[STANDARD]' prefix is terse but likely meaningful, and the whole text is front-loaded with the key verb and resource. It is appropriately sized for the limited content it conveys.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is complex with 15 parameters and no output schema, but the description is extremely sparse. It does not explain what the response looks like, how intervals behave beyond a one-month cap, or any prerequisites. While the schema provides parameter details, the description leaves critical usage context uncovered, making it incomplete for a tool of this complexity.
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?
All 15 parameters have descriptions in the schema, so the baseline is 3. The description adds no parameter-level detail beyond the schema, although the phrase 'from bid, mid, and ask prices' hints at the data source but does not clarify how parameters like version or rate_type affect the IV calculation. Thus it neither elevates nor degrades parameter understanding.
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 states the tool provides historical implied volatility from bid, mid, and ask prices, which conveys the core action and resource. It implies a time-series endpoint but does not explicitly distinguish from the trade-based variant (option_history_trade_greeks_implied_volatility) in the sibling list, though the 'bid, mid, and ask' qualifier hints at the distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives such as snapshots or trade-greeks variants. It only notes a maximum request window of one month, which is a constraint but not a usage rule or comparison. No exclusions or alternative recommendations are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It only mentions 'Real-time' and the wildcard expiration hint, but fails to disclose output structure, defaults, rate limits, or how the many parameters interact.
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 extremely concise, containing one purpose sentence and a practical hint. The '[PROFESSIONAL]' prefix adds minimal value but does not significantly detract.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 12 parameters and no output schema, this description is inadequate. It does not clarify which Greeks are returned, the response format, or how it differs from other greeks snapshot tools.
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 coverage is 100% with detailed parameter descriptions (e.g., right, strike, expiration, version). The description adds no extra semantics beyond the schema, so the baseline of 3 applies.
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 provides real-time greeks for all contracts on an expiration, which indicates a bulk snapshot operation. It distinguishes from sibling tools by emphasizing the 'all contracts' scope, though it does not explicitly contrast with first/second/third order greeks tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool vs. alternatives like option_snapshot_greeks_first_order or option_history_greeks_all. The only usage hint is 'Use expiration=* for all,' which is a parameter tip rather than tool selection guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations available, the description carries the full burden of behavioral disclosure. It only states 'Real-time first-order greeks' and 'for all contracts on an expiration,' but does not describe read-only semantics, response structure, pagination, or potential size of results. The scope (all contracts) is useful but minimal.
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 single, front-loaded sentence that efficiently conveys the core purpose. The '[STANDARD]' prefix adds no substantive value but does not significantly hurt. It could be slightly more informative about return scope, but remains appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 12 parameters, no output schema, and no annotations, the description is under-specified. It does not explain what data is returned (e.g., timestamp, greek values, contract identifiers), how defaults behave, or how the tool relates to the broader greeks snapshot family. The high complexity demands more contextual detail.
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 100%, so the baseline is 3. The description adds no additional parameter context beyond what the schema already provides; it does not highlight required parameters (symbol, expiration) or explain how filters like strike_range or min_time affect results.
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 identifies the tool as returning real-time first-order greeks (delta, gamma, theta, vega, rho) for option contracts on a given expiration. It distinguishes itself from sibling tools via the 'first-order' qualifier and the specific list of greeks, though it does not explicitly contrast with second/third-order or IV tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided for when to use this tool versus alternatives. It does not mention when to prefer it over option_snapshot_greeks_all, second_order, or history variants, nor any prerequisites or context for choosing this snapshot endpoint.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden of behavioral disclosure. It only states the source prices (bid/mid/ask) but does not disclose any limitations, return format, pagination, rate limits, or handling of invalid inputs. The real-time nature is implied by the name and the phrase 'Real-time', but no additional behavioral context is given.
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 single concise sentence that front-loads the core function. Some words like '[STANDARD]' add no value, but the core message is efficiently delivered.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 12 parameters, no annotations, no output schema, and a large set of sibling tools, this description is severely under-specified. It does not explain return values, filtering options, or relationship to other greeks tools, and lacks any guidance for proper usage in different scenarios.
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 input schema has 100% description coverage, with all 12 parameters documented including defaults, enums, and formats. The description does not add any parameter-specific meaning beyond what the schema already provides, so the baseline score of 3 is appropriate.
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 identifies the tool as providing real-time implied volatility computed from bid, mid, and ask prices, which clearly distinguishes it from sibling snapshot tools that return all Greeks or other specific data. However, it does not explicitly mention the tool's scope as an options snapshot, relying on the tool name and schema to convey that context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool compared to the many related options snapshot tools, such as option_snapshot_greeks_all or option_snapshot_quote. There is no mention of use cases, exclusions, or alternative tools, leaving the agent without direction for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure, but it only states 'Real-time second-order greeks for all contracts on an expiration.' It does not explain return format, whether results are paginated, any rate limits, or that this is a read-only operation. It adds little beyond the tool name and schema descriptions.
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 single sentence, which is highly concise and front-loaded with the key phrase 'Real-time second-order greeks'. However, the leading '[PROFESSIONAL]' tag is unnecessary filler and does not add meaningful information, preventing a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (12 parameters, no output schema, no annotations, and numerous sibling tools), a one-sentence description is insufficient. It does not specify what fields are included in the response (e.g., gamma, vanna, charm), how filters interact, or what makes this snapshot different from history or at-time variants. The schema documents parameters but not the overall behavior or return expectations.
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 input schema covers all 12 parameters with descriptions (100% coverage), so the description does not need to repeat them. Baseline is 3 because the schema does the heavy lifting. However, the description itself adds no semantic value about parameters or their relationships, so it earns exactly the baseline.
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 identifies the tool's function: returning real-time second-order Greeks for all contracts on a given expiration. It effectively distinguishes itself from sibling tools like first/third-order and implied volatility by naming 'second-order'. However, it lacks an explicit action verb (e.g., 'retrieves'), making it slightly less direct than a fully specified purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided about when to use this tool versus alternatives such as option_snapshot_greeks_first_order or option_snapshot_greeks_all. The description implies usage through the phrase 'second-order greeks', but it does not state exclusions, prerequisites, or alternative scenarios. A user must infer from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden for behavioral disclosure. It only states 'Real-time' and does not describe return format, pagination, calculation methodology, or any side effects.
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 single sentence, front-loaded with the core purpose. The '[PROFESSIONAL]' prefix is unnecessary but does not significantly harm conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 12 parameters and no output schema or annotations, the description is minimal. It doesn't explain what data is returned, how filtering works (right, strike, etc.), or how third-order greeks differ from other orders.
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 100%, so the schema fully documents all 12 parameters. The description adds no parameter-specific semantics beyond what the schema already provides, matching the baseline score.
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 identifies the tool as providing real-time third-order greeks for all contracts on an expiration, distinguishing it from first/second-order greeks tools. However, it lacks an explicit verb like 'retrieves' or 'returns'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool over option_snapshot_greeks_first_order, second_order, or all. It only implies real-time use via the word 'Real-time', but does not mention exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without any annotations, the description must fully disclose behavioral traits. It indicates the value is real-time and derived from the last NBBO quote, but it fails to explain the return format, what happens when multiple contracts match (e.g., all strikes), or whether the value is a midpoint, mark, or other calculation. No output schema exists to compensate.
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 a single, focused sentence with zero filler. It is front-loaded with the primary purpose and is appropriately concise for the information it conveys.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 7 parameters, no output schema, and no annotations, the description is too sparse. It does not describe what the output looks like, how the market value is computed, or how filters like strike_range and max_dte affect the results. This leaves significant gaps for an agent attempting to invoke the tool correctly.
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 100%, so the input schema already documents every parameter and its meaning. The description itself adds no extra parameter-level detail beyond the schema. The baseline of 3 applies because the schema carries the burden.
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 identifies the tool's purpose: returning real-time market value for an option contract based on the last NBBO quote. This distinguishes it from sibling snapshot tools like option_snapshot_quote or option_snapshot_trade. However, it lacks an explicit verb such as 'Get' or 'List', making it slightly less direct than ideal.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention any prerequisites, exclusions, or comparisons with sibling tools like option_snapshot_quote or option_snapshot_market_value for stocks. The user is left to infer usage from the name and schema alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It only states that it returns the real-time last trade, but it does not disclose that multiple contracts may be returned when strike='*' or right='both', how 'real-time' is defined, or whether there are any data delays. The behavior is under-specified even for a read-only tool.
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 single, direct sentence without unnecessary words, making it concise and front-loaded. While it omits useful context, it does not waste any space. The brevity is a positive trait even though the content is thin.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 parameters, no output schema, no annotations) and the crowded sibling namespace, the description is incomplete. It does not explain the snapshot concept, how filters affect the result set, or why to choose this tool over option_at_time_trade or option_history_trade. The description is far too minimal to guide an agent effectively.
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 schema already describes all six parameters with 100% coverage, so the description does not need to add parameter details. However, the description adds no extra meaning about how parameters interact (e.g., that filters can be combined). Baseline of 3 is appropriate because the schema does the heavy lifting.
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 resource and action: 'Real-time last trade for an option contract.' It is specific enough to distinguish from quote/ohlc/open_interest snapshot tools, but it does not explicitly differentiate from option_at_time_trade or option_history_trade. The use of 'real-time' helps contrast with historical endpoints, but the differentiation is implicit rather than explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus its siblings. It does not mention any filters, limitations, or alternative tools for different scenarios (e.g., option_snapshot_quote for quotes, option_history_trade for historical data). Usage context is completely absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It fails to explain what 'last quote' means (e.g., close vs. latest), timezone nuances beyond the schema, or behavior when no data exists for the specified time. The schema adds a timezone assumption, but the description adds no behavioral context.
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 a single, front-loaded sentence with no fluff. It states the core value proposition directly, making it appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 5 parameters, no output schema, and no annotations. The description is extremely minimal for a temporal query tool, omitting information about optional date parameters, return value structure, and edge cases. This leaves significant gaps for an agent attempting to use the tool correctly.
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 100%, so all parameters are individually documented. The description does not add extra semantics beyond the schema, but the baseline of 3 applies because the schema handles parameter documentation adequately.
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 states the tool returns the 'last quote at a specific time of day for a stock,' which clearly identifies the resource (stock quote) and the temporal specificity. It distinguishes from trade and history tools by the quote and at-time focus, though it does not explicitly differentiate from snapshot tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not indicate when to use this tool over siblings like stock_snapshot_quote or stock_history_quote, nor does it offer any exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the report is '[FREE]' and 'Generated at 17:15 ET daily,' which adds context about cost and data availability timing. However, it does not disclose what the report contains, whether it is delayed, historical depth, or any limitations (e.g., no real-time data). Given no annotations, the description carries the burden for behavioral disclosure, and this is insufficient.
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 single sentence, concise and free of fluff. It earns its place by adding the 'FREE' and generation time details. However, it omits critical information (like what the report contains), so while concise, it is under-specified rather than efficiently comprehensive.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, so the description must compensate. It does not explain the nature of an 'end-of-day report' (e.g., fields, historical range, accuracy), nor how to use the date parameters effectively. The context of sibling tools suggests this is a daily snapshot, but the description lacks the completeness needed for an agent to invoke it confidently.
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 input schema provides descriptions for all three parameters (symbol, start_date, end_date), covering 100% of the schema. The tool description adds no additional meaning to these parameters. The baseline for high schema coverage is 3, and there is no extra semantic value added by the description.
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 states it is an 'End-of-day report for a stock,' which clearly identifies the resource (stock) and the action (providing an EOD report). It adds the generation time and FREE status, but it does not explicitly distinguish itself from sibling tools like stock_history_ohlc or stock_snapshot_ohlc beyond the name. The word 'report' is vague about what data is included (e.g., price, volume, adjustments).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. With many sibling history tools (e.g., stock_history_ohlc, stock_history_trade), there is no explanation that eod is the daily aggregate or how it compares to intraday or snapshot tools. The description relies on the tool name and general context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits on its own. It does mention a maximum request duration and the concept of 'contemporaneous' matching, but it does not explain how quotes are matched, whether the response includes both trade and quote records in a single structure, or what happens when the 1-month limit is exceeded.
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 single, tightly worded sentence that communicates the core purpose and a key constraint without wasting words. It is concise and front-loaded, though it lacks structural elements like explicit headings or examples, which is acceptable for a short description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity—8 parameters, no output schema, and no annotations—the description is too sparse. It does not explain the response format, the nature of the quote-trade pairing, or how this tool relates to the many similar sibling tools, leaving substantial gaps for an AI agent attempting to select and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides full descriptions for all 8 parameters (100% coverage), including the date override behavior, venue selection, and the exclusive matching option. The description itself adds no parameter-level meaning, so it relies entirely on the schema, which is already adequate.
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 that the tool provides 'Trade history paired with contemporaneous BBO quotes', which identifies its core function of combining trade and quote data. This distinguishes it from the sibling tools stock_history_trade and stock_history_quote, which focus on only one of these data types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no explicit guidance on when to use this tool versus alternatives such as stock_history_trade or stock_history_quote. The only usage-related information is the constraint 'Max 1 month per request', which is a limitation, not a recommendation for use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry full behavioral disclosure. It only states 'real-time last trade' without mentioning return format, filtering behavior via min_time, venue selection, or any limitations. The minimal wording leaves critical behavioral traits undisclosed.
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 single sentence that front-loads the core concept ('Real-time last trade'). It is concise and free of fluff, though it could be structured to include more contextual detail without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations and output schema, the description needs to explain what the tool returns and its behavioral nuances. It does not mention that this is a snapshot (single point) rather than a history, nor does it address the min_time filter or default venue. The description is too sparse for an agent to confidently select and invoke this 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 100%, so the baseline of 3 applies. The description adds no parameter-specific meaning beyond what the schema already provides; it does not mention symbol, venue, or min_time. This meets the baseline but adds no extra value.
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 indicates the tool returns the latest trade for a stock, distinguishing it from sibling snapshot tools like stock_snapshot_quote and stock_snapshot_ohlc. However, it lacks an explicit verb (e.g., 'get' or 'retrieve'), so it doesn't fully meet the standard for 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as stock_history_trade or stock_at_time_trade. The description offers no context for selecting this snapshot over other time-based or historical tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the trade-level granularity and the 1-month limit, but omits what the response contains (e.g., trade price, volume, Greeks values by delta/gamma), any pagination behavior, or whether it is historical only. For a data retrieval tool, this is insufficient disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise but lacks structured prose; it is two fragments rather than complete sentences. The '[PROFESSIONAL]' prefix is unnecessary noise. It front-loads the main point (Greeks at each trade) but could be more polished without adding length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 15 parameters, no output schema, and no annotations, the description is too sparse to fully prepare an agent. It does not explain the interaction of date/time parameters, how 'max_dte' or 'strike_range' affect results, or the return structure. The tool is complex, and the description only scratches the surface.
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 100%, with each parameter well-described (e.g., 'date', 'strike', 'version', 'rate_type'). The description adds no parameter specifics beyond what the schema already provides, but calling out 'requires expiration' reinforces a required field. Baseline of 3 is appropriate when the schema handles parameter documentation.
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 states the core function: 'Greeks calculated at each trade.' This clearly identifies the tool as providing trade-level historical data with Greeks calculations, distinguishing it from EOD or snapshot Greek tools. It also includes constraints (max 1 month, requires expiration) that further define its scope.
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 gives constraints: 'Max 1 month, requires expiration.' This implies the tool is for short-term trade-level analysis and that an expiration is mandatory, but it does not explicitly mention when to prefer this over alternative sibling tools (e.g., option_history_greeks_all). The guidance is present but not comprehensive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states '[FREE] Current day equity market schedule,' which does not explain what output to expect, timezone handling, or whether it returns open/close times or just open/closed status. This is insufficient for the agent to understand the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief and compact, but it is more under-specified than truly concise. It is a noun phrase fragment rather than a complete sentence, and a structured description with a verb would be more effective without adding much length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite being a simple zero-parameter tool, the description is not complete enough. It does not clarify whether the schedule includes market hours, holidays, or just open/close status, and there is no output schema to fill the gap. This leaves significant ambiguity about the tool's result.
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, so the baseline of 4 applies. The description does not need to explain parameter meanings, and no parameter information is missing.
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 identifies the resource ('equity market schedule') and scope ('current day'), distinguishing it from siblings like calendar_on_date and calendar_year. However, it lacks an explicit verb (e.g., 'get') and does not specify what 'schedule' includes (open/close times, holidays, status).
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 implies usage for today's schedule through the phrase 'current day', but it does not explicitly state when to use this tool versus calendar_on_date or calendar_year. No exclusions or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 mentions 'Real-time' and 'current-day', but does not disclose data latency, output structure, pagination, error handling, or any side effects. It also does not explicitly state that this is a read-only operation. The description adds minimal behavioral context beyond the basic function.
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 single, front-loaded sentence with no filler. It is highly concise and easy to parse. However, the '[STANDARD]' prefix is unexplained, and the terseness borders on under-specification, though it remains effective as a brief summary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-parameter snapshot tool, the description is too sparse given the rich sibling set. It lacks guidance on when to use this tool versus index_snapshot_price, index_snapshot_market_value, or index_history_ohlc. While the schema covers parameters, the description does not provide necessary usage context or clarify the scope of 'current-day'.
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 input schema provides descriptions for both parameters (symbol and min_time), achieving 100% schema description coverage. The tool description adds nothing about parameters, but the schema already documents their meaning sufficiently. Baseline of 3 is appropriate.
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 provides 'Real-time current-day OHLC for an index', which conveys the action (retrieve snapshot) and resource (index). It distinguishes from historical OHLC tools by emphasizing 'current-day', but does not explicitly mention sibling alternatives.
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 phrase 'Real-time current-day' implies this tool is for current intraday data, as opposed to historical or end-of-day tools. However, there is no explicit guidance about when to choose this over index_snapshot_price, index_snapshot_market_value, or index_history_ohlc. It gives a clear time scope but lacks explicit when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but it only adds the 'Max 1 month' constraint. It does not disclose return format, pagination behavior, calculation methodology nuances, or how 'second-order greeks' are computed. This is a significant transparency gap for a data-returning tool with no output schema.
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 extremely concise, with two short phrases that convey the core purpose and key constraints. It is front-loaded and wastes no words, though it is arguably too sparse given the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a complex tool with 15 parameters, no output schema, and many sibling variants. The description only mentions a date-range limit and required expiration, leaving unclear the exact nature of second-order greeks, how results are structured, and how this tool compares to first/third-order variants. It is incomplete for the tool's complexity.
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 100%, so the baseline is 3. The description adds a 'Max 1 month' constraint that applies to date parameters, which is useful context beyond the schema. However, it does not explain any parameter semantics beyond that, relying on the schema's own descriptions.
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 provides 'Second-order greeks at each trade', identifying the specific resource (trade-level second-order greeks) and operation. However, it does not explicitly differentiate from closely named siblings like option_history_greeks_second_order or option_history_trade_greeks_first_order/third_order, so it lacks strong sibling differentiation.
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 gives practical constraints: 'Max 1 month, requires expiration.' This implies when the tool is usable and what inputs are needed. However, it does not explicitly state when to prefer this over alternative greeks-history tools, nor does it provide exclusions or comparison guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It only states 'Real-time current-day OHLC' but does not disclose any behavioral traits such as default strike_range, behavior when no filters are applied, or limitations like data freshness 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, highly concise and front-loaded. However, it begins with '[VALUE]' which appears to be a placeholder and adds no semantic value, slightly reducing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having 7 parameters and no output schema or annotations, the description is extremely minimal. It fails to explain the response structure, how parameters like strike_range or min_time affect results, or any edge cases. This is insufficient for an agent to use the tool effectively.
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 input schema has 100% coverage for all 7 parameters, each with detailed descriptions. The tool description adds no extra parameter semantics, but the schema already provides sufficient meaning, so the baseline of 3 applies.
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 provides real-time current-day OHLC data for an option contract, using a specific verb+resource+scope. This distinguishes it from sibling tools like option_snapshot_trade (which provides trades) and option_history_ohlc (which provides historical OHLC).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. There is no mention of scenarios where other option_snapshot_* tools would be more appropriate, nor any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must reveal behavior. It mentions the generation time (17:15 ET daily) and that it is free, but does not explain what an 'end-of-day report' contains, response format, or any refresh/delay implications. This is minimal behavioral disclosure.
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 two sentences, front-loaded with '[FREE]', and every word adds value. It is appropriately terse for a simple data retrieval tool with no unnecessary repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema, the description should explain what the 'end-of-day report' contains (e.g., OHLC, close-only) to set expectations. It does not, leaving the return value ambiguous. The tool is simple, but the description leaves a significant gap.
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 input schema has 100% description coverage for all three parameters, so the schema already explains symbol, start_date, and end_date. The description adds no parameter-specific semantics beyond this, matching the baseline for high coverage.
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 states 'End-of-day report for an index', which clearly identifies the tool's resource (index) and the type of data (EOD report). This distinguishes it from siblings like stock_history_eod and option_history_eod by specifying 'for an index', though it does not contrast with index_history_price or index_history_ohlc.
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 provides useful context: '[FREE]' signals cost, and 'Generated at 17:15 ET daily' tells when data becomes available. However, it does not explicitly state when to use this tool versus alternatives like index_history_price or index_history_ohlc, nor any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description carries the full burden. It only discloses 'Real-time' and 'last price', which implies a live snapshot, but lacks details on latency, data coverage, error handling, or return 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 a single sentence that is front-loaded with purpose. The '[STANDARD]' prefix is slightly unexplained but does not harm overall clarity.
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 simple with full schema coverage, making the description mostly adequate. However, the lack of an output schema and any usage guidance leaves gaps in knowing what the response will contain and when to use this 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 100% and both parameters (symbol, min_time) have detailed descriptions. The tool description adds no extra parameter meaning, so the baseline of 3 is appropriate.
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 'Real-time last price for an index' with a specific verb and resource. It distinguishes from sibling tools like index_snapshot_ohlc (OHLC data) and index_snapshot_market_value (market value).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention exclusions, prerequisites, or contrast with sibling tools such as index_at_time_price.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states that the tool returns EOD greeks, with no mention of read-only nature, output format, pagination, or historical depth. This leaves significant behavioral assumptions unclear.
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 a single, front-loaded sentence with zero wasted words. It efficiently communicates the core purpose and includes one practical usage tip, making every word earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a complex tool with 13 parameters, no output schema, and no annotations. A one-sentence description is inadequate to convey the tool's role among many sibling greeks history tools, nor does it describe the structure of the response or how EOD data differs from trade/quote data. The description is too sparse for the tool's complexity.
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 schema covers all 13 parameters with descriptions (100% coverage), so the baseline is 3. The description adds no new parameter information beyond restating that symbol and expiration are the primary filters and the wildcard usage for expiration, which is already documented in the 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 it returns EOD greeks for all contracts by symbol and expiration, providing a specific verb, resource, and scope. However, it does not explicitly distinguish this tool from closely related siblings like option_history_greeks_all, which also likely provides greeks history data.
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 includes a usage tip ('Use expiration=* for all') but gives no explicit guidance on when to use this tool versus alternatives such as option_history_greeks_first_order or option_history_trade_greeks_*. The [STANDARD] tag implies it is the default choice, but this is not made explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses 'tick-level', 'Max 1 month', and 'requires expiration' which are useful behavioral traits, but omits other aspects like return format, pagination, or error 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 a single, front-loaded sentence that delivers essential information efficiently. No filler or redundancy, every word contributes value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 11 parameters, no output schema, and no annotations, the description is incomplete. It lacks return value explanation, usage context relative to siblings, and any guidance on parameter interactions or output behavior.
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 coverage is 100%, so the baseline is 3. The description only adds 'requires expiration', reinforcing the schema's required field without offering additional meaning beyond what's already in the input 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 'Tick-level trade history for options' which identifies the tool's verb and resource. It distinguishes from quote or greeks siblings by specifying 'trade', though it doesn't mention alternatives like option_history_trade_quote.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides constraints (max 1 month, requires expiration) but no explicit guidance on when to use this tool versus alternatives. Sibling tools such as option_history_eod or option_history_trade_quote are not referenced.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations available, the description carries the full burden of behavioral disclosure. It adds some context (real-time, derived from last quote) but fails to disclose expected output format, whether multiple symbols are allowed in a single call, any permission requirements, or behavior for invalid symbols. For a snapshot tool with no annotations, this is minimal transparency.
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 a single sentence of eight words that fully states the core function. Every word earns its place, with no filler or redundancy. The '[STANDARD]' prefix adds a minor label but does not detract from conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, so the description should describe what the response contains. It only says 'market value derived from last quote' without specifying whether the output is a single number, includes a timestamp, or supports multiple symbols. With 3 parameters and no annotations, the description is too sparse to be fully actionable for an agent.
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 coverage is 100%, so the parameters are already well-documented. The description adds no parameter-specific information beyond what the schema provides. Baseline 3 is appropriate since the schema handles the semantics.
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 identifies the resource ('market value for a stock') and the scope (snapshot, real-time). It distinguishes from siblings like stock_snapshot_quote by specifying 'derived from last quote' rather than the raw quote itself. However, it lacks a direct action verb like 'retrieve' or 'get', leaving the purpose slightly implicit.
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 implies usage: use this when you need the current market value computed from the last quote. However, it provides no explicit guidance on when to prefer this over alternatives like stock_snapshot_quote or stock_snapshot_trade, and no exclusions or alternative tool references are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of disclosing behavior, but it only mentions 'real-time current-day,' which is a temporal scope. It does not state what happens when multiple symbols are passed, whether any side effects exist, or what the return structure looks like. This is minimal disclosure for a tool with no annotation safety net.
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 very short and front-loaded, but the leading '[VALUE]' token is a meaningless placeholder that should be removed. Aside from that, the one-sentence structure is efficient.
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 schema provides solid parameter documentation, but there is no output schema, so the description should compensate by explaining what data is returned. It mentions OHLC but omits details like whether volume or timestamps are included, and does not clarify that the symbol array allows multiple symbols or wildcard. Given the tool's simplicity and good schema, the description is just barely adequate.
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 100%, with all three parameters (symbol, venue, min_time) already having meaningful descriptions. The tool description adds no additional parameter-level detail, so the baseline of 3 is appropriate.
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 identifies the resource (stock) and the type of data (real-time current-day OHLC), which distinguishes it from history and other snapshot tools. However, it lacks an explicit verb (e.g., 'get') and begins with a placeholder '[VALUE]', which adds noise without contributing meaning.
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 phrase 'current-day' implies this is for real-time data, contrasting with history tools, but it does not explicitly name alternatives or state when not to use this tool. No direct sibling differentiation such as 'for historical OHLC use stock_history_ohlc' is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, but it only gives a minimal definition. It does not explain behavior around date ranges (start_date/end_date interplay), timezone handling (beyond schema), or edge cases like missing trades at the specified time. The '[STANDARD]' prefix adds no behavioral context.
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 single, front-loaded sentence with no extraneous words. However, it is very minimal and could include a second sentence to clarify usage or behavior without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has five parameters including a date range and venue, the description is incomplete. It does not explain how start_date and end_date relate to time_of_day, nor the impact of venue selection. With no output schema or annotations, the description should cover more of the tool's behavior.
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 schema provides 100% coverage for all parameters with descriptions, so the tool description does not need to repeat them. The description's mention of 'time of day' aligns with the time_of_day parameter but adds no additional meaning beyond what the schema already specifies.
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 the last trade for a stock at a specified time of day. This distinguishes it from sibling tools like stock_snapshot_trade (current trade) and stock_history_trade (range-based), making the resource and scope explicit.
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 implies usage for point-in-time trade queries but does not explicitly state when to prefer this over alternatives such as stock_snapshot_trade or stock_history_trade. No exclusions or decision guidance are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the basic read/list action and does not disclose return format, date ordering, pagination, empty-result behavior, or any limitations. The '[FREE]' label is a commercial note, not behavioral transparency.
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 a single, front-loaded sentence that directly states the tool's purpose and key parameters. There is no filler or redundant restatement, making it highly concise and efficient.
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?
For a simple two-parameter list tool with no output schema, the description covers the core purpose but omits return shape and fails to position itself among closely related sibling tools. It is adequate but leaves clear gaps in behavioral context and usage strategy.
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 100%, so the description adds little beyond what the schema already provides. It confirms that request_type and symbol are the inputs, but introduces no new details about symbol formatting, date ranges, or request type 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 uses a specific verb ('List') and clearly identifies the resource ('available data dates') and scope ('for a stock by request type and symbol'). This distinguishes it from sibling tools like option_list_dates or index_list_dates, which handle different asset classes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is given on when to use this tool versus alternatives. It does not mention that option_list_dates or index_list_dates should be used for options or indexes, nor does it suggest checking symbol lists first. Usage must be inferred entirely from the tool name and purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the core behavior: returns the real-time last BBO/NBBO quote. However, it does not mention any side effects, limitations, data delays, or prerequisites, which is a gap for a simple read operation. It is not misleading, but it is not deeply 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 single, short sentence, making it easy to parse. However, the '[VALUE]' prefix appears to be an unfilled template placeholder, which is a minor structural defect and slightly reduces clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema, the description fails to explain the return structure, multiple-symbol support (despite the schema allowing arrays), or how venue affects the response. The tool has only one required parameter but still offers optional filters (venue, min_time) that are not contextualized. Given the abundance of similar sibling tools, this description leaves significant gaps for an agent to invoke the tool correctly.
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 input schema provides descriptions for all three parameters (venue, symbol, min_time) and covers 100% of the schema. The description adds no additional parameter-level details, so the baseline of 3 is appropriate.
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 identifies the tool as returning a real-time BBO/NBBO quote for a stock, which distinguishes it from sibling tools like stock_snapshot_trade or stock_snapshot_ohlc. However, it lacks an explicit verb (e.g., 'Gets') and begins with the placeholder '[VALUE]', making it a noun phrase rather than a proper action-oriented description.
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 implies usage for current quote retrieval (real-time last BBO/NBBO), but it does not explicitly state when to use this tool versus alternatives (e.g., historical quotes via stock_history_quote or stock_snapshot_market_value). No exclusions or alternative comparisons are provided, so the guidance is implicit rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does mention the midpoint-price source and a 1-month limit, but it fails to describe the response format, output structure, or any access requirements. The description also omits what specific Greek letters (delta, gamma, etc.) are included, leaving the agent to guess.
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 extremely concise and front-loaded, delivering the core purpose and a key constraint in a single sentence. The '[STANDARD]' tag is minor but does not detract. Every word contributes value, making it appropriately sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (15 parameters, 3 required) and the absence of an output schema, the description is too sparse. It does not explain how date ranges, intervals, or strike filtering work together, nor does it indicate what the response will look like. The agent would need to rely entirely on the schema, which lacks usage context.
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?
All 15 parameters have descriptions in the input schema (100% coverage), so the description adds no parameter-specific meaning. Per the rubric, a baseline of 3 is appropriate when the schema already fully documents parameters, and the description does not need to compensate.
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: it provides historical first-order Greeks derived from midpoint prices. The constraint 'Max 1 month per request' adds scoping. It distinguishes itself from sibling tools like option_history_greeks_second_order and option_history_greeks_all by the 'first-order' qualifier.
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 implies usage for fetching historical first-order Greeks data, but it does not explicitly state when to prefer this over alternatives such as option_history_trade_greeks_first_order or option_history_greeks_eod. No exclusions or alternative tool names are provided, leaving the guidance merely implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the data source (midpoint prices) and a request limit, but does not disclose whether this is a read-only operation, what the output format is, or any pagination/permission considerations. This leaves significant unknowns for the 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 two sentences with no filler. It front-loads the primary purpose and includes a key constraint, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the rich schema, the tool has no output schema and no annotations. The description does not explain the return structure, the meaning of 'third-order greeks,' or how to handle multi-day requests. For a tool with 15 parameters and complex behavior, this is incomplete.
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 input schema provides descriptions for all 15 parameters (100% coverage), so the description need not add parameter details. The description itself does not add any parameter-level meaning beyond the schema, making the baseline 3 appropriate.
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 returns historical third-order greeks computed from midpoint prices. This distinguishes it from sibling tools like option_history_trade_greeks_third_order, which likely use trade prices. The verb 'Historical' and resource 'third-order greeks' 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a usage constraint (max 1 month per request) but does not explicitly state when to use this tool over alternatives such as the trade-based version. The context is implied by the midpoint price source and the historical nature, but exclusions are not provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full transparency burden. It does disclose important behavioral limits (max 1 month, expiration required) and that it returns per-trade data, but it does not describe output format, error behavior, or data freshness. The disclosure is minimal but not misleading.
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 a single concise sentence, front-loaded with the core purpose and followed by key constraints. Every word 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.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 15 parameters, no output schema, and no annotations, yet the description only states a one-line summary and two constraints. It does not explain return structure, time range handling, or how it differs from similar tools, leaving significant gaps for such a complex endpoint.
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 100%, so the schema fully documents all 15 parameters. The description adds no extra parameter semantics beyond what the schema already provides, hitting the baseline of 3.
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 indicates the tool provides first-order Greeks on a per-trade basis, and distinguishes it from related tools by noting the 1-month limit and expiration requirement. However, it lacks an explicit verb like 'Get' or 'Fetch', so it is not maximally specific.
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 gives useful constraints (max 1 month, requires expiration) that imply when this tool can be used, but it does not explicitly state alternatives or provide when-not-to-use guidance. Context is clear but exclusions are absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses two behavioral facts: supports interval aggregation and has a 1-month request limit. These are useful but incomplete; it does not mention response format, pagination, timezone handling, or that it is a read-only operation (though 'history' implies it).
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 three short sentences, front-loaded with the core purpose, and contains no fluff. Every sentence contributes functional information: what it does, a feature, and a limit.
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 has 8 parameters, no output schema, and no annotations, but the schema descriptions are rich and cover all parameters. The description adds key constraints (max 1 month, interval aggregation) but omits broader context like data source caveats, trading hours, or return structure. It is adequate but minimal.
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 100%, so baseline is 3. The description adds meaningful constraint 'Max 1 month per request' which directly informs how to set date parameters, a detail absent from the schema. 'Supports interval aggregation' also gives context on using the interval parameter, adding value beyond the enum list.
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 states 'NBBO quote history for a stock', which clearly identifies the resource and type of data. It distinguishes from sibling history tools (e.g., trade, OHLC, EOD) by specifying 'quote' and 'NBBO'. However, the initial '[VALUE]' placeholder weakens the verb, making it less direct than 'Retrieve' or 'Get'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives such as stock_snapshot_quote for current quotes or stock_history_trade for trades. It mentions constraints like 'Max 1 month per request' but does not explain selection criteria or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses the data source (midpoint prices) and a request limit (1 month). With no annotations provided, the description carries the burden, but it remains sparse, lacking details on pagination, return format, or rate limits. No contradiction with annotations since none exist.
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?
A single sentence with no fluff. Front-loads the core purpose and immediately provides a critical constraint. Very efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 15 parameters, no output schema, and complex interactions (e.g., interval restrictions for single-day requests), this description is too minimal. It omits important context about response structure, multi-day behavior, and how the 1-month limit should be handled. The schema helps but the description alone is insufficient for an agent to fully understand the 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 100%, so the schema already documents all parameters. The description adds no additional parameter meaning beyond the existing schema descriptions.
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?
Clearly states it provides historical second-order greeks from midpoint prices. The phrase 'second-order' and 'midpoint prices' distinguishes it from sibling tools like first-order, third-order, and trade-based greeks history.
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?
Implies usage by name (second-order greeks history) and adds a key constraint (max 1 month per request). However, it does not explicitly state when to use this versus alternatives or provide exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It adds one meaningful behavioral trait: the maximum 1-month request limit. However, it does not mention output format, pagination, timezone handling, or explicit read-only confirmation. The term 'Historical' implicitly suggests a safe read operation, but the description does not elaborate beyond the age constraint.
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 a single, focused statement that front-loads the core purpose and includes a crucial constraint. Every word earns its place, with no redundancy or unnecessary detail. It is appropriately sized for the information it conveys.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (11 parameters, no output schema, no annotations), the description is severely incomplete for real-world use. It omits critical context such as how to construct date ranges, the interplay between parameters, the availability of sub-minute intervals only for single-day requests, and what the response looks like. The schema provides parameter detail, but the description fails to add higher-level usage guidance or return expectations.
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 input schema has 100% description coverage for all 11 parameters, so a baseline of 3 is appropriate. The description adds no parameter-specific meaning beyond the schema; for example, it does not explain how 'date' interacts with 'start_date'/'end_date' or how 'strike_range' filters contracts. All parameter semantics are delegated to 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 'Historical OHLC bars for options', specifying the resource (OHLC bars), scope (options), and action (historical). This distinguishes it from sibling tools like option_history_eod or option_history_trade, which target different data types. The addition of 'Max 1 month per request' further defines the scope.
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 provides a key constraint ('Max 1 month per request') but offers no explicit guidance on when to use this tool compared to siblings like option_history_trade or option_history_quote. The name implies it is for OHLC history, but there is no direct statement of 'use this for OHLC bars' or exclusions. Usage context is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 the pre-requisite of expiration and a 1-month maximum, which is useful context beyond the schema. However, it omits other behavioral traits such as return format, handling of wildcard expiration ('*'), or whether it is a read-only operation.
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 a single short sentence, front-loaded with the core purpose. There is no fluff or repetitive content, and every word earns its place (aside from the 'PROFESSIONAL' prefix, which is marginal but not harmful).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a complex tool with 15 parameters, no output schema, and many similar siblings. The description fails to explain how it differs from other trade greeks variations (e.g., first-order, all) or what the return structure looks like. It leaves the agent to infer context from the name alone, which is insufficient for correct 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?
Schema description coverage is 100%, so the baseline is 3. The description adds no parameter-level detail beyond what the schema already provides; the 'requires expiration' note merely repeats the schema's required field. The 'Max 1 month' constraint is a global limitation, not a parameter semantic.
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 'Third-order greeks at each trade', which is a specific verb+resource (fetch third-order greeks for trade data). This distinguishes it from sibling tools by order (first/second/all) and trade-level vs EOD, so it is easy to identify the correct tool.
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 implies usage for trade-level third-order greeks and provides constraints ('Max 1 month, requires expiration'), but does not explicitly state when to prefer this over alternatives or when not to use it. No exclusions or alternative tool names are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the data's reporting time and that it reflects the prior day, which is valuable context beyond the schema. However, it doesn't outline other behaviors like date range handling, default symbols, or response format.
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 very brief and front-loaded with the core purpose. However, the '[VALUE]' prefix is an unexplained placeholder that slightly detracts from clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 9 parameters and no output schema, the description provides minimal guidance on how to construct requests or interpret responses. It lacks details on filtering behavior, date precedence, or output structure, making it incomplete for a tool of this complexity.
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 descriptions cover all 9 parameters at 100%, so the description doesn't need to add parameter details. The description adds no extra semantic meaning 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 phrase 'Historical open interest for options' clearly identifies the tool as fetching historical open interest data, distinguishing it from snapshot and other history tools. The timing note adds context. The verb is implicit but 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?
It specifies that data is reported at ~06:30 ET and reflects prior day, setting expectations for data recency. However, it doesn't explicitly mention alternatives or 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It indicates a read-only listing operation ('List available data dates') and includes a '[FREE]' tag, but does not disclose return format, pagination, or any other behavioral traits. The description is adequate for a simple read operation but lacks depth.
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 a single concise sentence that front-loads the '[FREE]' tag and immediately states the purpose. There is no wasted wording, and every word contributes meaning. This is highly efficient for an agent consuming the description.
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 covers the essential purpose and required parameters, but with no annotations and no output schema, it leaves gaps such as the return format of the date list and whether all historical dates are included. Given the simplicity of a date-listing tool, the description is adequate but not comprehensive.
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 100%, so the schema thoroughly documents all five parameters. The description adds marginal value by naming three key parameters (symbol, request type, expiration) but does not provide additional semantics beyond what the schema already defines. Baseline 3 is appropriate since the schema does the heavy lifting.
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: 'List available data dates for an option by symbol, request type, and expiration.' It uses a specific verb ('List'), identifies the resource ('available data dates'), and specifies the key filters. This distinguishes it from sibling tools like option_list_symbols and option_list_expirations, which serve different listing purposes.
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 implies usage by identifying the required input parameters, but it does not explicitly state when to use this tool versus alternatives. No when-not-to-use guidance or alternative tool references are provided. However, the tool's name and description make its purpose clear enough that an agent can infer when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It adds useful context: '[FREE]' indicates no cost and 'Updated overnight' signals data freshness. However, it does not disclose output format, pagination, or any special behaviors or limitations, leaving the agent partly guessing.
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 extremely compact: two short sentences front-load the primary purpose and then a second sentence conveys update frequency and cost. Every word earns its place; there is 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?
Given this is a simple list tool with one parameter and no output schema, the description covers the essential purpose and freshness. It does not state the return format, but for a straightforward list of dates that is likely predictable. Overall, it is reasonably 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides a detailed description for the single 'symbol' parameter, including wildcard and comma-separated syntax, achieving 100% coverage. The description adds no additional parameter-level details, so the baseline of 3 is appropriate.
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 'List' and clearly identifies the resource: 'available expiration dates for an option symbol.' It is unambiguous and distinguishes from similar sibling tools like option_list_strikes or option_list_contracts. Even though option_list_dates exists, 'expiration dates' adds clarity.
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 implies usage: use it when you need expiration dates for an option symbol. However, it does not explicitly state when not to use it or mention alternatives among the many sibling listing tools. No exclusions or comparison to option_list_dates or other list tools is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description provides some behavioral context: 'Updated overnight' indicates data freshness, and '[FREE]' indicates no cost. However, it does not disclose other potentially important behaviors such as output format, ordering, or rate limits, leaving the description only partially transparent.
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 two short sentences, front-loaded with the primary purpose, and contains no unnecessary words. It is concise and well-structured.
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 list tool with two well-documented parameters and no output schema, the description is adequately complete. It conveys the core function and update frequency, though it does not elaborate on return details. Given the tool's simplicity, this is sufficient.
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 input schema already provides thorough descriptions for both required parameters (symbol and expiration), so schema coverage is 100%. The description merely restates the parameters without adding additional meaning, syntax, or context beyond what the schema already offers.
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: 'List available strikes for an option symbol and expiration.' This uses a specific verb and resource, and it is easily distinguished from sibling list tools like option_list_symbols, option_list_dates, and option_list_contracts.
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 implies usage when strikes are needed for a given symbol and expiration, but it provides no explicit guidance on when to use this tool versus alternatives. There is no mention of exclusions or alternative tools, so the usage guidance is inferred rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It adds a key non-obvious trait: the value is reported daily at ~06:30 ET, meaning data is a once-daily snapshot. It does not cover rate limits, error cases, or reversibility, but the daily report time is valuable context.
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 two short sentences, front-loaded with the core purpose. No redundant or repetitive content. It is appropriately sized for the tool's simplicity.
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 7 parameters with full schema coverage and no output schema, the description provides adequate context: what it returns (last open interest) and the daily update time. It could be more explicit about the return format or the distinction from historical tools, but it is complete enough for basic selection.
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 coverage is 100%, so baseline is 3. The description does not add any parameter-specific meaning beyond what the schema already provides. It mentions 'for an option contract' but does not elaborate on filters like strike or right.
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 identifies the resource (open interest) and the context (last value for an option contract). It distinguishes from sibling snapshot tools (quote, trade, OHLC) by naming open interest specifically. However, it lacks an explicit verb like 'Get' or 'Retrieve', and the '[VALUE]' prefix is a bit ambiguous.
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 daily reporting time (~06:30 ET) implies this is the latest daily snapshot, but it does not explicitly guide on when to use this vs. option_history_open_interest or other snapshot tools. No alternatives or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 adds 'Real-time' and 'Supports symbol filtering,' but does not disclose potential pagination, rate limits, or the exact structure of returned data. As a read-only list operation, the risk is lower, but transparency remains partial.
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 extremely concise, front-loading the core purpose in the first sentence and adding only essential details (filtering and real-time) in two short follow-ups. No redundant or filler content.
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 absence of an output schema and the complexity of options data, the description adequately states the core function but does not clarify what fields are returned for each contract, nor how this tool relates to other option_list_* tools. It is minimally sufficient but leaves room for ambiguity.
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 input schema already covers all four parameters with descriptions, including the request_type enum and max_dte. The description's mention of 'symbol filtering' and 'traded or quoted' adds no new semantics beyond what the schema provides, so it neither improves nor detracts from schema clarity.
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 action ('List'), the resource ('contracts'), and the scope ('traded or quoted on a date'). It also mentions symbol filtering, which differentiates it from sibling tools like option_list_symbols, option_list_dates, and option_list_strikes that focus on specific contract attributes.
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 implies usage context: use this tool to fetch contracts for a given date, optionally filtered by symbol. However, it does not explicitly exclude alternatives or explain when to use a more specific sibling tool, such as option_list_expirations or option_list_strikes, instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the transparency burden. It adds behavioral context with '[FREE]' and 'updated overnight', indicating cost and data freshness. However, it does not disclose return format, ordering, pagination, or possible limitations.
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 a single, front-loaded sentence with no filler. '[FREE]', the list action, the scope, and update frequency are all conveyed efficiently.
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?
For a simple no-parameter list tool, the description states the core purpose and update schedule. However, with no output schema, it would be more complete if it described the expected return format or any size/ordering caveats.
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 an empty schema, so the baseline of 4 applies. There is no parameter-level meaning for the description to add beyond what the schema already conveys.
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?
Clearly states it lists all traded option underlying symbols, specifying the resource and scope. The 'option' qualifier distinguishes it from stock_list_symbols and index_list_symbols. 'Updated overnight' adds a useful temporal note.
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?
Implied use is when the agent needs available option underlyings rather than stock or index symbols, but the description gives no explicit when/when-not guidance. Sibling names help infer context, but the description itself does not mention alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the maximum 1-month date range and tick-level granularity, but omits other behavioral traits such as response format, pagination, timezone handling, and whether the data is delayed or real-time. This is a minimal disclosure for a read-only tool.
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 two short sentences, front-loaded with the core purpose ('Tick-level trade history') followed by a key limitation. There is no wasted wording, and the most important information appears first.
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?
Although the schema fully documents parameters, there is no output schema, so the description should explain what the response contains. It does not mention return fields (price, volume, timestamp, etc.) or pagination behavior, leaving a gap for a tool with 7 parameters. The description is adequate but not 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?
With 100% schema description coverage, the baseline is 3. The description adds value by indicating a critical cross-parameter constraint: the date range (start_date/end_date) cannot exceed one month, which is not stated in the schema. This helps the agent understand valid parameter combinations.
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 fetches tick-level trade history for a stock, using a specific verb and resource. This distinguishes it from sibling tools like stock_history_ohlc (OHLC bars) and stock_history_quote, while the 'stock' qualifier sets it apart from option history tools.
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 implies usage for historical trade data but provides no explicit guidance on when to use this tool versus alternatives such as stock_snapshot_trade for real-time quotes or stock_history_eod for daily bars. The max 1-month constraint is stated but no longer-period alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It adds 'Updated overnight', informing about data freshness. However, it does not explicitly state that this is a read-only operation or describe any limitations, though for a list tool this is minimal risk. The 'FREE' label is more marketing than behavioral.
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 front-loaded with the primary action. Every word earns its place, with 'Updated overnight' providing useful context without redundancy. It is appropriately sized for a tool with no 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?
For a simple list tool with no parameters and no output schema, the description provides the essential information: what it returns and when data is updated. It might not describe the exact format of the symbol list, but for typical usage this is sufficient. The tool's simplicity means minimal additional context is needed.
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 the input schema is empty. According to the rubric, the baseline is 4 since there are no parameters to explain. The description does not need to elaborate on parameters, and the schema coverage is 100% vacuously.
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 'List all index symbols' with a specific verb and resource, clearly distinguishing it from sibling tools like stock_list_symbols and option_list_symbols by specifying 'index'. The prefix 'index' in the name reinforces this, 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.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes clear that this tool is for listing index symbols, which is distinct from stock and option symbol listings. It does not explicitly mention when not to use it, but the sibling tool names provide context. For a simple list tool, the use case is unambiguous, and the 'Updated overnight' note adds a timing consideration.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses key behavioral traits: the time limit of 1 month, the requirement for an expiration, and the pairing of trades with quotes. This gives the agent important context about what to expect, though it could detail more about pagination or error handling, but it's adequate for a data retrieval tool.
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 a single sentence that conveys the core function and key constraints. It is front-loaded with the main action and avoids unnecessary words.
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 has 12 parameters and no output schema, the description provides essential context: what data it returns, its scope (options), and constraints. It doesn't explain return structure, but for a history endpoint, this is often implied. The presence of many sibling tools makes the pairing aspect crucial, and it is covered.
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 covers 100% of parameters with descriptions, so baseline is 3. The description adds the 'requires expiration' reminder, which is already in the schema, and 'Max 1 month' which relates to date range parameters. No additional parameter-level meaning is provided 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 retrieves option trade history paired with contemporaneous NBBO quotes. This distinguishes it from sibling tools like option_history_trade or option_history_quote by emphasizing the pairing. The constraints (max 1 month, requires expiration) further specify the tool's scope.
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 provides usage constraints ('Max 1 month', 'requires expiration') which inform when this tool can be used. However, it doesn't explicitly contrast it with alternative tools (e.g., option_history_trade for trades only), leaving some room for interpretation given the large sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the tool is free and data is updated overnight, giving useful context about cost and freshness. For a simple read-only list operation, this is adequate behavioral disclosure.
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 two short sentences, front-loads the core purpose, and contains no wasted words. It earns its place by adding the 'FREE' and 'Updated overnight' details 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?
For a zero-parameter, no-output-schema tool, the description is reasonably complete. It tells what is listed and when data is updated. It lacks details about output format or coverage universe, but these are not critical for such a simple tool.
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, so the schema is trivially complete and description needs to add nothing. Per rubric, 0 params earns a baseline of 4, and the description does not introduce any parameter-related ambiguity.
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 ('List') and resource ('all traded stock symbols'), clearly distinguishing it from sibling tools like option_list_symbols and index_list_symbols. The purpose is unambiguous and directly matches the tool's name.
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 context that this returns stock symbols, which logically differentiates it from option/index list tools. However, it doesn't explicitly state when to use it over alternatives or mention exclusion criteria, so it stops 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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![thetadata-mcp MCP server](https://glama.ai/mcp/servers/drmartell/thetadata-mcp/badges/card.svg)](https://glama.ai/mcp/servers/drmartell/thetadata-mcp)

Score Badge

Copy to your README.md:

[![thetadata-mcp MCP server](https://glama.ai/mcp/servers/drmartell/thetadata-mcp/badges/score.svg)](https://glama.ai/mcp/servers/drmartell/thetadata-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/drmartell/thetadata-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server