US Stocks & Market Data

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

The annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds no extra behavioral context beyond the basic retrieval intent, such as result ordering, pagination, or handling of invalid tickers, but it does not contradict the annotations.

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

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

The description is extremely concise, with one sentence stating the purpose and a short argument definition. It is front-loaded and contains no filler or redundant information.

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

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

For a simple one-parameter tool with an output schema present, the description provides sufficient context for correct invocation. It could optionally mention what kind of news is returned or behavior when no news exists, but this is not essential given the output schema.

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

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

The input schema has no description for the ticker parameter (0% coverage), but the description fully compensates by explaining that it is the stock's ticker symbol and providing an example ('AAPL'). This gives the agent complete understanding of the parameter.

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

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

The description clearly states the tool retrieves news for a given ticker symbol, using a specific verb and resource. It is distinct from sibling tools that cover financial statements, historical prices, market overview, recommendations, and stock info.

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

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

There is no explicit guidance on when to use this tool versus alternatives. It does not mention when to prefer this over get_stock_info or other siblings, and no exclusion criteria are provided.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds the list of allowed financial statement types, which is useful, but it does not disclose other behaviors like return format or error conditions, and the output schema handles return structure.

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

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

The description is reasonably short and front-loaded with the main purpose, but it redundantly repeats the list of financial statement types in both the opening sentence and the financial_type parameter description. This duplication adds unnecessary length without new information.

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

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

The tool is simple with two parameters and an output schema, so the description need not explain return values. It covers the purpose, allowed values, and parameter semantics. The only minor gaps are the lack of typical use cases or examples, but overall it is adequate for the tool's complexity.

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

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

Schema description coverage is 0%, but the description thoroughly documents both parameters. For 'ticker' it provides the format and an example ('AAPL'); for 'financial_type' it lists all allowed values (income_stmt, quarterly_income_stmt, etc.). This fully compensates for the schema's lack of descriptions.

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

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

The description clearly states the tool's function: 'Get financial statement for a given ticker symbol.' It also enumerates the exact types of financial statements (income_stmt, balance_sheet, etc.), which distinguishes it from sibling tools like get_finance_news or get_historical_stock_prices.

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

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

The description provides clear context that this tool is for retrieving financial statements, implying it should be used when such data is needed. However, it does not explicitly mention alternatives or when not to use it, 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.

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

Annotations already declare readOnlyHint=true, so the description's lack of mutation warning is fine. The description adds useful behavioral context: valid periods, intervals, the 60-day intraday restriction, and defaults. However, it incorrectly mentions 'start and end' as alternative parameters that do not exist in the schema, introducing confusion. Thus a 3 is appropriate.

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

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

The description is organized with an Args section and clear bullet-like formatting, making it scannable. The purpose sentence is front-loaded, and parameter details are separated. However, the inclusion of 'start and end' adds unnecessary confusion, and the output field list could be more clearly labeled as return values.

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

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

Given the 3 parameters and the presence of an output schema, the description covers essential operational details: valid periods, intervals, defaults, and the intraday data limitation. It lacks authentication or rate-limit info, but those may be out of scope for a wrapper. The start/end inconsistency is a notable gap, hence a 4.

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

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

The input schema provides only type and default for each parameter, with no descriptions (0% coverage). The description compensates by explaining ticker, period, and interval with valid values and examples, plus the relationship between period and interval. This gives the agent the necessary semantics to invoke the tool correctly.

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

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

The description clearly states the tool retrieves historical stock prices for a ticker symbol, with a specific verb ('Get') and resource ('historical stock prices'). It is immediately distinct from sibling tools like get_finance_news or get_stock_info by focusing on historical price data.

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

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

The description provides clear context for when to use this tool – when historical price data is needed – and adds constraints such as intraday data not extending beyond 60 days. However, it does not explicitly mention alternatives or when not to use this tool, and the reference to 'start and end' parameters (which are not in the schema) could mislead an agent about usage.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds valuable behavioral context beyond annotations: it reports whether the US regular session is currently open, and explains how closed-market responses should be interpreted. This exceeds the baseline expectation for tools with annotations.

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

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

The description is concise and well-structured: the first sentence states the primary purpose and contents, the second gives usage guidance with examples, and the third clarifies the no-arguments and session-open behavior. Every sentence earns its place with no filler.

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

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

Given the tool's moderate complexity (multiple asset classes plus session status) and the presence of an output schema, the description covers all essential aspects: what data is included, when to use it, and how to interpret the closed-market flag. No critical gaps are evident.

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

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

The tool takes zero parameters, and the schema confirms this. The description reinforces 'Takes no arguments' and lists what data is included, which is helpful context. With no params, the baseline is 4, and the description satisfies that baseline without needing to explain parameter syntax.

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

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

The description opens with a specific verb and resource: 'Get a snapshot of the overall US market', followed by a detailed enumeration of included asset classes (indices, VIX, yields, commodities, USD/KRW). This clearly distinguishes it from sibling tools focused on single companies or financial news, earning a top purpose clarity score.

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

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

The description explicitly states when to use the tool: 'for questions about the market as a whole rather than a single company', with concrete example queries. It clearly signals the when-not case (single company) but does not explicitly name an alternative tool, so it falls just short of the highest benchmark.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds useful context about the months_back parameter applying only to upgrades/downgrades and its default of 12. It does not detail other behaviors like pagination, but the output schema likely provides return structure.

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

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

The description starts with a clear, concise one-sentence summary followed by a structured Args block. It is appropriately sized, with no redundancies or fluff. Each section earns its place, especially given the schema's lack of parameter descriptions.

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

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

With three parameters, the description covers all of them thoroughly and benefits from an output schema. It doesn't need to explain return values. A minor gap is that it doesn't explicitly state that months_back is ignored when recommendation_type is 'recommendations', but this is implied by the wording. Overall, it's complete for the tool's complexity.

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

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

The schema has no descriptions for any parameter, but the description's Args section fully documents each one. It provides a concrete ticker example, enumerates allowed recommendation_type values (recommendations, upgrades_downgrades), and clarifies the default for months_back. This adds significant meaning beyond the raw schema.

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

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

The description clearly states the tool gets recommendations or upgrades/downgrades for a given ticker symbol. This is a specific verb+resource combination and distinguishes it from sibling tools like get_stock_info or get_financial_news.

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

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

The description implies usage for fetching recommendations for a ticker but does not explicitly compare to alternatives or state when not to use it. It lacks guidance on when to prefer this over sibling tools, so an agent must infer usage from the description alone.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds context about the scope of returned data (price, market cap, etc.) and names an alternative tool, but does not disclose potential error behavior, rate limits, or what happens if the ticker is invalid. With annotations present, this is adequate but not rich.

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

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

The description is structured with a clear purpose statement, an alternative guidance sentence, and an Args block. It is efficient with no fluff, though the first sentence includes a long enumerated list of data points that could be slightly more condensed. Overall, every section earns its place and the key information is front-loaded.

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

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

For a simple single-parameter, read-only tool with an output schema, the description provides complete context: it explains what the tool does, what data it returns, when to use a different tool, and the parameter meaning. The output schema handles return value structure, and annotations cover safety, so no critical information is missing.

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

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

The input schema only defines ticker as a string with no description, and schema description coverage is 0%. The tool description compensates fully with an Args block explaining that ticker is the stock symbol and providing an example ('AAPL'). This gives the agent clear semantic understanding beyond the raw schema.

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

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

The description clearly states the tool retrieves a summary of key stock information for a given ticker, enumerating specific data points like price, market cap, valuation multiples, and analyst targets. It also distinguishes itself from the sibling tool get_financial_statement by explicitly mentioning that tool for detailed financial statements.

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

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

The description provides explicit usage guidance by stating 'For detailed financial statements use get_financial_statement', which tells the agent when NOT to use this tool and directs to an alternative. This is a clear when/when-not distinction, even though other siblings are not mentioned.

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