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

Annotations already declare readOnlyHint and openWorldHint, so safety is covered; the description adds substantive context beyond them, namely the equity-only restriction, the explicit error behavior for non-equity symbols, and a concrete inventory of what is returned. It stops short of noting rate limits or how many future events are covered.

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

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

Three short sentences, front-loaded with the verb and resource, followed by return contents and then the constraint. Every sentence earns its place with no repetition of the schema or annotations.

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?

An output schema exists, so return-value structure need not be explained, and the description still sketches the payload. The equity-only behavior and the symbol requirement are both covered. The remaining gap is routing guidance relative to the overlapping get_earnings/get_dividends siblings.

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

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

Schema description coverage is 100% and there is only one parameter, so the schema already documents the symbol format, ISIN support and the 'use search first' fallback. The description's only parameter-adjacent content is the equity-only constraint, which is behavioral rather than semantic; baseline 3 is correct.

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?

States a specific verb and resource ('Get upcoming corporate-calendar events for a Yahoo symbol') and enumerates the payload (next earnings date(s) with analyst estimate ranges, next dividend/ex-dividend dates). It is clearly distinguishable from most siblings, though it never contrasts itself with the closely overlapping get_earnings and get_dividends tools.

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

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

Usage is implied by the scope: this is the combined calendar view (earnings + dividends). The 'Equity-only' sentence functions as a real exclusion — an ETF/fund/crypto symbol will error — which is useful when-not guidance. However, it names no alternative for those cases (e.g. get_fund_data) and never tells the agent when to prefer this over get_earnings or get_dividends.

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 openWorldHint=true, so the safety profile is covered. The description adds genuinely useful behavior beyond that: the ISIN-to-ticker resolution via 'resolved_symbol'. It says nothing about auth, rate limits, or failure modes for invalid symbols.

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?

Front-loaded with purpose in the first sentence, then a dense but useful field enumeration, ending with the ISIN caveat. No filler, though the parenthetical metric list is long enough to border on a return-value dump.

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 an output schema, full parameter coverage, and readOnly/openWorld annotations, the description only needs to frame scope and it does so, including the ISIN edge case. It could be slightly stronger by naming which sibling to use for pure price data.

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

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

Schema description coverage is 100% for the single parameter, so the schema already documents the accepted ticker/ISIN formats and the 'search' fallback. The description's ISIN note is largely redundant with the schema, so baseline 3 is appropriate.

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

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

States a specific verb and resource ('Get a company profile and key statistics') and enumerates the returned data (sector/industry, employees, valuation metrics, business summary), which separates it from get_quote and get_financials. It does not explicitly name a sibling it replaces, so it falls short of a 5.

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

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

Usage is only implied: the enumeration of static profile fields signals this is the tool for company-level facts rather than price history or statements. There is no explicit when-to-use/when-not, and the 'use search first for a company name' routing lives in the schema, not the description.

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 openWorldHint=true, so the safety and external-data profile is covered. The description adds that the data is historical (dividend and split history) and scoped to a Yahoo symbol, which is useful but not rich behavioral detail. It does not describe output shape or ordering, though an output schema exists to carry that. A 3 is fair given annotations do the heavy lifting.

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?

One sentence, front-loaded with the verb and resource, containing zero filler. Every word earns its place, and there is no redundancy with the schema or annotations. Ideal economy of expression.

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 single-parameter, read-only historical data tool with a 100% covered schema and a present output schema, the description is nearly complete. The task of return-value explanation is delegated to the output schema, which is acceptable. The only minor gap is the absence of usage routing relative to siblings like get_history, but nothing an agent needs to call the tool correctly 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?

Schema description coverage is 100%, so the single parameter 'symbol' is fully documented in the schema (including maxLength, ISIN support, and the fallback to 'search' for company names). The description adds no syntax, format, or constraint detail beyond what the schema already provides. Baseline 3 is correct when schema coverage is high.

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?

Clear verb+resource: 'Get the dividend and stock-split history for a Yahoo symbol.' The scope (dividends and splits, historical) is specific enough for an agent to distinguish from siblings like get_quote or get_history, though it does not name those alternatives explicitly. This is a solid, specific purpose statement that needs no further decoding.

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 (fetch dividend/split history for a given symbol) but offers no explicit when-to-use vs when-not-to-use guidance. It does not tell the agent to prefer get_dividends over get_history when only dividend/split data is needed, nor does it state the conditions that make this the right call. Adequate but thin.

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 cover readOnly and openWorld, so the bar is lower; the description adds real value by disclosing the equity-only restriction and the resulting error, plus the returned fields (EPS estimate, reported EPS, surprise %). It stops short of describing pagination or limit interaction.

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

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

Three tight, front-loaded sentences: purpose first, return content second, constraint third. No filler, and all content earns its place, though the return-detail sentence partly overlaps the output schema.

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 two-parameter read tool with an output schema and annotation coverage, the description is essentially complete; the equity-only caveat is a helpful addition. Since return values are already captured by the output schema, the description need not do more.

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

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

Schema coverage is 100%, so both 'symbol' and 'limit' are fully documented in the schema. The description reinforces that a Yahoo symbol is expected but adds no syntax or format detail beyond what the schema already provides, matching the baseline 3.

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

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

States a specific verb ('Get') and resource ('upcoming and historical earnings') for a Yahoo symbol, making the tool's function immediately clear. It does not explicitly distinguish itself from overlapping siblings like get_estimates or get_calendar, so it falls short of a 5.

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

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

Usage is implied by the resource name rather than stated. It notes the equity-only constraint (ETF/fund/crypto returns an error), which is useful, but gives no explicit when-to-use guidance or named alternatives vs get_estimates/get_calendar.

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 openWorldHint=true, so the safety profile is covered. The description adds value beyond that by disclosing a failure mode not present in any structured field: non-equity symbols (ETF, fund, crypto) return an error saying so, and results are 'small tables keyed by period'. It stops short of describing rate limits or auth, but the error behavior is a useful 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.

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

Three tight sentences, front-loaded with the core purpose before the return contents and the equity-only caveat. The middle sentence restating return values is mildly redundant given an output schema exists, but it is brief and earns most of its place.

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

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

For a single-param read tool, the definition covers purpose, output shape, and the key failure mode, and annotations plus an output schema carry the safety and return-value burden. The only real gap is the absence of sibling routing, which is minor given how self-descriptive the tool is.

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

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

Schema description coverage is 100%, so the single 'symbol' parameter is already fully documented in the schema (Yahoo ticker or ISIN, with the search fallback for company names). The description adds no format or syntax detail beyond that, so the baseline 3 is appropriate.

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

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

The description opens with a specific verb+resource ('Get forward analyst estimates for a Yahoo symbol') and enumerates the returned content (earnings/revenue estimates, EPS trend/revisions, growth estimates), which lets an agent distinguish it from broader siblings like get_financials. However, it never explicitly contrasts itself with the closest sibling, get_earnings, leaving some differentiation to inference.

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?

Usage is implied rather than stated: the agent infers it should call this when it wants forward-looking analyst estimates. The 'Equity-only' note functions as a genuine exclusion (ETF/fund/crypto will fail), but there are no explicit alternatives or when-to-use routing against siblings such as get_earnings or get_recommendations.

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 openWorldHint=true, so the safety profile is covered. The description adds genuine value by disclosing the return layout (rows are line items, columns are reporting periods, most recent first), but says nothing about frequency/statement interactions or limits.

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

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

Two tight sentences with the purpose front-loaded and no filler. The second sentence earns its place by describing the data orientation, which is not obvious from the schema.

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 an output schema present, the description needn't explain return values, and annotations plus full schema coverage handle safety and parameters. The layout note rounds it out; only minor usage-routing context 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?

Schema description coverage is 100%, so freq, symbol, and statement are all fully documented in the schema, including the 'ttm' restriction to income and cashflow. The description adds no parameter meaning beyond that, so the baseline 3 applies.

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?

States a specific verb and resource ('Get a financial statement'), which is clearly distinct from siblings like get_earnings, get_quote, and get_company_info. However, it never names an alternative, so differentiation is inferred from the resource noun 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.

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

The description gives no when-to-use or when-not-to-use guidance and names no alternative tool. The useful routing hint ('For a company name, use search first') lives only in the symbol parameter's schema description, not in the tool description itself.

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 openWorldHint=true, so safety is covered. The description adds genuinely useful behavior the annotations don't: it will raise/error on stocks and crypto, telling the agent how failure manifests. It does not discuss rate limits or pagination of holdings beyond the limit param.

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

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

Three short sentences, front-loaded with the purpose, then the return payload, then the key restriction. No filler or restated title content.

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

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

An output schema exists, so return shape need not be detailed, yet the description still summarizes the payload; identifiers, scope, error behavior, and safety are all covered. Nothing an agent needs to invoke this correctly 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?

Schema description coverage is 100%, with both 'symbol' (ticker/ISIN format, search-first hint) and 'limit' (1-100 max holdings) fully documented in the schema. The description only echoes 'Yahoo symbol' and adds no format or default detail beyond what the schema provides, so the baseline 3 applies.

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?

Specific verb ('Get') plus resource ('fund/ETF profile data') and an explicit enumeration of what comes back (overview, asset-class and sector weightings, top holdings). The asset-class scope ('Fund/ETF-only') cleanly separates it from the company/equity siblings like get_company_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?

States a clear when-not condition: it 'raises for stocks and crypto, which have no fund data,' which steers the agent away from using it on regular equities. It stops short of naming the sibling to use instead (e.g. get_company_info or get_sector).

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 and openWorldHint, so safety is covered. The description adds real behavioral context beyond the annotations: the 250-row cap and the fact that a `truncated` flag is set when results are cut.

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

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

Three tight sentences with the core purpose front-loaded, then query modes, then the truncation caveat. No filler, though the middle sentence partly duplicates schema content.

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

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

With full schema coverage and an output schema present, the description need not explain return values, and it covers the key non-obvious behavior (row cap, truncated flag). Complete enough for an agent to call it correctly.

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

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

Schema description coverage is 100%, so the baseline is 3. The description's note that period and start/end are alternatives largely restates what the schema already states ('Overrides period when set', 'Ignored when start is given'), adding little new parameter semantics.

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

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

The description states a specific verb and resource ('Get historical OHLCV data for a symbol'), which clearly separates it from siblings like get_quote/get_quotes that return current pricing. It stops short of naming the alternative explicitly, so the differentiation is implicit rather than stated.

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

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

The description explains how to query (period vs. start/end range) but does not say when to choose this tool over siblings such as get_quote or screen. Usage is implied by the resource rather than guided.

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 and openWorldHint, so safety is covered; the description adds real value beyond them by disclosing the equity-only failure mode and the exact composition of the response. It omits any note on data freshness/delay, which is the main remaining behavioral gap for a market-data read.

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

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

Three short sentences, front-loaded with purpose, then return contents, then the constraint. No filler and nothing redundant with the schema.

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 an output schema present, return values need no explanation, and the description still covers the one gotcha an agent would hit (non-equity symbols erroring). It is nearly complete, lacking only peripheral context such as data recency.

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

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

Schema description coverage is 100%, so both 'symbol' (ticker/ISIN format plus the 'use search first' hint) and 'limit' (per-list cap) are fully documented in the schema. The description adds no syntax or format detail beyond that, so the baseline 3 applies.

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?

States a specific verb+resource ('Get the ownership breakdown for a Yahoo symbol') and enumerates exactly what comes back: insider/institutional percentages plus top institutional and mutual-fund holders. The equity-only clause implicitly separates it from get_fund_data and get_insider_activity, so an agent can distinguish it from siblings without opening a schema.

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

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

Gives a clear when-not rule: ETF, fund or crypto symbols return an error saying so, which prevents wasted calls on non-equity tickers. It does not name alternatives (e.g. get_fund_data for funds, get_insider_activity for transaction-level detail), so routing guidance is implied rather than explicit.

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 establish readOnlyHint and openWorldHint, so safety is covered. The description adds real context beyond that: the data source convention for the key and the fact that the response mixes several curated company lists. It does not discuss failure modes for invalid keys, which is the main remaining gap.

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?

Front-loaded with the action and the single most common mistake. The 'not a ticker symbol' warning appears twice (opening line and closing line), which is redundant but defensible as emphasis on a high-frequency misuse.

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?

An output schema exists, so return values need not be detailed further. Key acquisition, format caveat, and limiting behavior are all covered; nothing an agent needs to invoke this correctly 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?

Schema coverage is 100%, so the `key` format and `limit` bound (1-100, default 25) are already documented. The description's key-vs-ticker note largely repeats the schema's own wording rather than adding new semantics.

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

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

Specific verb+resource: 'Browse an industry by its Yahoo key' and it enumerates the payload (overview, parent sector, top companies, top-performing/growth). It also quietly distinguishes itself from the nearby get_sector, so an agent can tell the two apart without opening schemas.

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

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

Gives a concrete discovery path (valid keys come from the `industries` list returned by `get_sector`) and an explicit exclusion ('not a ticker symbol'). It lacks a stated when-not/conditional alternative, but the routing guidance is clear.

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 and openWorldHint, and the description adds real context on top: the three-part return shape and, importantly, the equity-only constraint with a defined failure mode for ETF/fund/crypto symbols. It does not discuss pagination or how the 6-month window is computed, which keeps it short of a 5.

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

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

Three short sentences, front-loaded with the action, then returns, then the constraint. No filler, no restatement of the title.

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 two-parameter read tool with full schema coverage, annotations covering the safety profile, and an output schema covering the response, the description supplies everything else an agent needs: what comes back and the one input class that fails.

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

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

Schema description coverage is 100% and both parameters (symbol formats, limit bounds) are fully documented in the schema, so the baseline of 3 applies. The description adds no format or default information beyond what the schema already states.

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?

"Get insider trading activity for a Yahoo symbol" pairs a specific verb with a specific dataset, then itemizes the three payloads (individual transactions, 6-month purchases/sales summary, insider roster). That distinguishes it from the nearest sibling, get_holders, without the agent needing to open either schema.

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?

Usage is only implied: call it with a symbol when insider data is wanted. There is no explicit when-to-use or when-not-to-use versus siblings such as get_holders or get_company_info, and the 'use search first for a company name' routing lives in the schema, not the description.

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 cover only read-only/open-world safety, and the description adds a genuinely valuable behavioral disclosure: `status` is populated only for `US` and is null elsewhere, explicitly framed as an upstream limitation rather than an error. That pre-empts an agent misreading a null as a failure — exactly the kind of context annotations cannot carry.

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?

Front-loads the purpose in one sentence, then qualifies input semantics and the US-only status caveat. Every sentence earns its place, though the prose runs slightly longer than a single-parameter tool strictly needs.

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 an output schema present, return-shape detail is not required, yet the description still sketches what the index summary contains (price, previous close, change) and covers the one edge case an agent would otherwise trip on. Nothing needed to call it correctly 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?

Schema coverage is 100% and the key enum is documented there, but the description still adds meaning: it reinforces that `key` is a market key rather than a ticker, gives concrete examples (`US`, `EUROPE`), and ties the parameter to the null-status behavior. Marginal but real value above the schema.

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

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

States a specific verb and resource ('Get the trading status and headline index summary for a market') and immediately scopes it apart from ticker-oriented siblings by noting it takes a market key 'such as `US` or `EUROPE` — not a ticker symbol'. An agent can distinguish this from get_quote/get_quotes without opening any schema.

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?

Enumerates the questions it answers — market open, next open/close, index performance — which gives clear context for when to reach for it. It does not name an explicit alternative tool to prefer when the agent wants per-symbol data, so it stops short of full when/when-not routing.

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 openWorldHint=true, so the safety and external-source profile is covered. The description adds no behavioral context beyond that — no rate limits, freshness window, or coverage caveats — and its return-field list is redundant with the existing 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.

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

Two short sentences, front-loaded with the core action and free of filler. The second sentence duplicates the output schema's content, which is a small waste but not enough to hurt readability.

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 read-only lookup with an output schema present, the description covers purpose and scope adequately; return values need not be re-explained. The only real gap is the absence of any routing hint toward or away from sibling tools.

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

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

Schema description coverage is 100%, so both parameters are fully documented in the schema itself. The description restates the 1-10 limit range but adds no new semantic detail (e.g., defaulting or behavior when the symbol has no news), making this the baseline 3.

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

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

The description states a specific verb and resource ('Get recent news headlines') scoped to a Yahoo symbol, which an agent can distinguish from sibling tools like get_quote or get_sec_filings. It is clear but never explicitly contrasts itself with those siblings.

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

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

No guidance on when to prefer this tool over siblings, nor on prerequisites beyond the schema's own note about using 'search' for company names. Usage must be inferred entirely from the name and the schema.

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?

Beyond the readOnlyHint/openWorldHint annotations, it discloses real behavioral traits: a 60-strike cap centred on current price, a `truncated` flag when a wider chain is cut, and the US-listing-only coverage rule with an explicit warning against misreading an empty result. This is exactly the context annotations cannot carry.

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?

Front-loaded with the core purpose, then two tight sentences covering the two invocation modes and the coverage caveat. No filler; every sentence carries information an agent needs to call correctly.

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?

An output schema exists, so return structure need not be spelled out, yet the description still flags the `truncated` field an agent should check. Combined with the mode switching and the non-US caveat, nothing needed to invoke or interpret this tool 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?

Schema coverage is 100%, so the baseline is 3, but the description adds meaning the schema does not: `expiration` must be a value drawn from the list returned by the parameterless call, and it changes the response shape from an expiration list to calls/puts. The two-mode semantics are explained rather than restated.

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?

States a specific verb and resource ('Get the option chain') for a named source (Yahoo symbol), which is clearly distinct from siblings like get_quote, get_history or get_financials. An agent can identify this as the derivatives-data tool without opening the schema.

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 branches usage: call without `expiration` to enumerate available expiration dates, call with one to retrieve calls/puts for that date. It also flags the case where a non-US symbol yields nothing and warns that this says nothing about the symbol itself, preventing a wrong inference.

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 openWorldHint=true, so the safety and external-data profile is covered. The description adds what data is returned ('current price and key intraday figures'), which is mild value, but says nothing about staleness, delays, rate limits, or errors.

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?

A single tight sentence with the payload description front-loaded and zero filler. Nothing is wasted or buried.

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?

An output schema exists, so return-value documentation is not required, and the one-param schema plus annotations cover the rest. The only real gap is that it never clarifies its relationship to the sibling 'get_quotes', which an agent selecting between them would want.

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?

With a single parameter and 100% schema description coverage, the schema already documents the symbol format (ticker/ISIN) and the search fallback. The description adds no syntax or format detail beyond that, so the baseline 3 for fully-covered schemas applies.

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?

States a specific verb ('Get') and resource ('current price and key intraday figures') for a Yahoo symbol, which is clear and concrete. However, it does not distinguish itself from the near-identical sibling 'get_quotes' (plural), leaving the agent to guess which one to call.

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

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

The description gives no when-to-use or when-not-to-use guidance and never names an alternative. The only routing hint ('For a company name, use search first') lives in the parameter schema, not the description, so the description itself contributes nothing here.

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 cover the read-only/open-world safety profile, and the description adds genuinely new behavior: per-symbol independent lookup, partial failure routed to `not_found` instead of aborting, and `truncated` being set past 50 symbols. The field list adds little because an output schema already exists, but the failure and truncation semantics are real added value.

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

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

Three tight sentences, front-loaded with the core capability, then usage, then return/failure semantics. No filler and no repetition of the schema.

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 one-parameter batch quote tool with an output schema, the description covers everything the agent needs: what is fetched, the cap, partial-failure handling, and the truncation flag. Return value details are correctly left to 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?

Schema description coverage is 100% for the single `symbols` parameter, so the schema already documents tickers/ISINs, the 50-item cap, and the no-company-names rule. The description restates the cap and ties it to the `truncated` output flag, which is a marginal addition rather than new parameter meaning.

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

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

States a specific verb and resource (get quotes) plus a clear scope qualifier ("several Yahoo symbols in one call"), which implicitly but unambiguously separates it from the singular get_quote sibling. An agent can pick the batch tool without opening either schema.

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?

"Use this to compare or fetch prices for multiple tickers at once" gives a concrete when-to-use condition. It never names the single-symbol alternative (get_quote) or states an exclusion, so it stops just short of full routing guidance.

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

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

Annotations already declare readOnlyHint and openWorldHint, so safety is covered. The description adds genuine context beyond them: it enumerates the returned data (buy/hold/sell trend, current/high/low/mean/median price targets) and flags the 'when available' caveat that these fields may be absent.

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

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

Two tight sentences, front-loaded with the core purpose and followed by the return contents. No filler or redundant phrasing.

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?

An output schema exists, so return values need not be spelled out, yet the description helpfully summarizes them. The single well-documented parameter and covered safety profile leave little missing, though a note on empty/absent data handling or sibling differentiation would make it complete.

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

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

Only one parameter and schema description coverage is 100%, with the schema itself clarifying ticker/ISIN format and the search-first fallback. The description adds no further parameter 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.

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

States a specific verb+resource ('Get analyst recommendation trends and price targets') plus the data shape it returns, so the agent knows exactly what it fetches. It does not explicitly distinguish itself from related siblings like get_upgrades_downgrades or get_estimates, leaving the agent to infer the boundary.

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?

Usage is only implied by the purpose; there is no explicit when-to-use, when-not, or named alternative. A hint to use 'search' for a company name lives in the schema, not the description, so the description itself adds no routing guidance.

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

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

Annotations declare readOnly and openWorld, so the safety profile is covered; the description adds real substance on top by listing the returned fields and warning that an empty result is uninformative. It does not mention rate limits or ordering guarantees, but that is minor given the read-only 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?

Front-loads purpose in the first sentence, then elaborates on entry contents and coverage limits without padding. The closing 'empty result says nothing about the symbol' slightly restates the prior coverage caveat but sharpens the interpretation, so it still earns its place.

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

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

An output schema exists, yet the description still summarizes the return shape and, more importantly, sets expectations for empty results - the main failure mode for this tool. Combined with a fully documented 2-parameter schema and read-only annotations, an agent has everything needed to call and interpret it.

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

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

Schema description coverage is 100% - the schema already documents 'symbol' format (ticker/ISIN, with search-first guidance) and 'limit' bounds. The description adds no syntax or interpretation beyond that, so the baseline of 3 applies.

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?

States a specific verb ('Get') and resource ('recent SEC filings') scoped to a 'Yahoo symbol', and enumerates what each entry contains (date, type, title, EDGAR URL, exhibit links). No sibling tool covers SEC filings, so the domain is unambiguous against get_news, get_company_info, or get_financials.

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

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

Gives clear applicability context: only U.S. SEC-registered issuers file there, so non-US symbols, ETFs, funds and crypto return nothing, and an empty result is not evidence about the symbol. It does not name a fallback sibling for non-US coverage, so it stops short of explicit alternative-routing.

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 openWorldHint=true, so the safety profile is covered. The description adds a genuinely useful behavioral constraint by repeating that the key is a sector key and not a ticker, preventing a common misuse. It does not mention limits or error behavior, but with annotations the bar is lower.

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?

Front-loads the core action and follows with return contents and routing guidance, all of which earn their place. The 'not a ticker' warning is stated twice (once parenthetically, once as a closing line), which is mild redundancy.

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

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

An output schema exists, so return values need not be explained, and the description still usefully previews them. It covers the drill-down path to get_industry and screen. Nothing essential is missing for a two-parameter, read-only browse tool.

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

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

Schema description coverage is 100%, and the schema already enumerates every valid sector key plus the limit bounds, so baseline is 3. The description's examples ('technology', 'healthcare') and the key-vs-ticker clarification add only marginal value beyond the schema.

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

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

States a specific verb+resource ('Browse a market sector') and disambiguates it from its siblings by explaining the key is a Yahoo sector key, not a ticker symbol. An agent can tell it apart from get_industry, get_market, and search without opening a schema.

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

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

Explicitly routes the agent onward: industry keys feed get_industry for drill-down or screen as an industry filter. This gives clear context and named alternatives. It does not state exclusions (e.g. when to prefer get_market instead), 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 and openWorldHint, so safety is covered. The description adds real behavioral context: the return shape (date + shares outstanding), that only the most recent `limit` points come back, and the 18-month default window. It doesn't mention pagination beyond limit or rate limits, so it stops short of a 5.

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

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

Three tight sentences with zero waste: purpose first, then return shape, then the limiting constraint and its remedy. The most actionable caveat (18-month window) is front-loaded enough to be caught before calling.

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 an output schema present, the description needn't explain return values in depth, and it covers purpose, windowing, and limit behavior adequately. The only gap is the absence of routing guidance relative to sibling history/fundamental tools, which is minor given the clear resource name.

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

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

Schema description coverage is 100%, so the schema already documents every parameter. The description's notes on limit being most-recent-only and start defaulting to 18 months largely restate what the schema says, adding little new meaning. Baseline 3 applies.

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?

States a specific verb and resource — 'Get the shares-outstanding history for a Yahoo symbol' — which is distinct from siblings like get_financials and get_holders. An agent can tell at a glance this returns a time series of share counts, not a snapshot.

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

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

The description gives conditional guidance for the start parameter ('pass one for anything older' than 18 months), which is useful. However, it never names an alternative tool or says when to prefer get_shares over get_financials/get_holders, so usage is implied rather than stated.

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 cover the safety profile (readOnlyHint, openWorldHint), and the description adds useful behavior: entries are the from/to grade and action, ordered most-recent-first, and non-equity symbols fail with an explicit error. It does not mention rate limits or the size/shape of the underlying response beyond the entry description.

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

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

Three short, front-loaded sentences: purpose, return content, and the equity-only constraint. No filler, and the most decision-relevant information comes first.

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 an output schema present, annotations covering safety, and full parameter docs, the description only needs to add what structured fields cannot; it does that via the equity-only error behavior and ordering. The lone gap is that 'recent' is never quantified, leaving the agent unsure of the time window.

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

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

Schema description coverage is 100%, so both 'symbol' and 'limit' are already fully documented (including the ISIN/ticker examples and the 'use search first' tip). The description adds no parameter-level syntax or constraints 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.

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

States a specific verb and resource ('Get recent analyst rating changes (upgrades/downgrades)') scoped to a Yahoo symbol, which an agent can distinguish from sibling tools like get_recommendations or get_estimates. It also declares the shape of each entry (firm, from/to grade, action), so the agent knows what it will get.

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

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

Gives a real when-not condition: 'Equity-only: an ETF, fund or crypto symbol answers with an error that says so,' which steers the agent away from misuse. It does not name an alternative when the symbol is not an equity or when analyst-recommendation summaries are wanted, so routing to siblings is left to inference.

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 and openWorldHint, so safety is covered. The description adds real behavioral nuance beyond that: results are the total match set with one row per listing, a row's dividend_yield can be missing or diverge from the filter, and preferred shares carry meaningless pe_ratio values. It does not discuss rate limits or latency, but the disclosure is 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?

Front-loads purpose, then organizes aliases by category, then records caveats. The alias enumeration is long but each entry is load-bearing reference material. Slightly dense, but no filler sentences.

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 an output schema present the description needn't detail return values, yet it still clarifies row contents and the one caveat that matters (dividend_yield mismatch). Combined with alias coverage, op restrictions, and sibling pointers, nothing an agent needs to invoke this correctly 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?

Although schema coverage is 100%, the schema only says field is 'an alias or a raw Yahoo screener field'. The description goes well beyond it by enumerating every valid alias grouped by category, and by documenting the op semantics (categories/region/exchange/sector/industry accept eq or is-in only), the percent convention, and the btwn value shape.

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?

States a specific verb and resource ('Find stocks by criteria') and immediately scopes it with concrete examples ('dividend payers in a region or cheap large caps'). An agent can distinguish this from the many sibling getters (get_quote, get_financials) because it is the only filter-driven discovery tool.

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

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

Gives clear context via examples and explicitly routes the agent to companions for data the rows lack ('get_company_info adds beta and forward P/E, get_holders the ownership shares'). It does not, however, state when to prefer the sibling 'search' tool over screening, so the alternative-selection guidance is incomplete.

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 cover safety (readOnlyHint, openWorldHint), so the bar is lower; the description adds the bounded result window (1-25), the default-capped count, and the exact fields returned, which the annotations do not convey.

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?

Front-loads the purpose, then the routing advice, then the return shape, in four short sentences with little waste, though the field list slightly overlaps the output schema.

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?

Covers purpose, routing, input types, result bounds, and returned fields; since an output schema exists, no further return-value detail is required for an agent to call it correctly.

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

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

Schema coverage is 100% and both params are described, including the limit's 1-25 range; the description restates rather than extends this, so baseline 3 applies.

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?

States a specific verb (Search) and resource (Yahoo Finance) plus accepted input types, and distinguishes itself from all sibling get_* tools by framing itself as the symbol-resolution entry point.

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

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

Explicitly states when to use it (turn a company name into a Yahoo symbol) and names an alternative path (other tools take an ISIN directly), giving the agent clear routing guidance.

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