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

Annotations cover the safety profile (readOnlyHint, openWorldHint), so the description's added value is the error behavior for non-equity symbols and the shape of the returned data. It does not mention rate limits or symbol-normalization quirks, but for a read-only lookup it is adequately transparent.

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

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

Three short sentences, front-loaded with the core action and return contents, with the equity-only caveat placed last. 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?

For a single-parameter read tool with an output schema and covering annotations, the description supplies everything an agent needs: what is returned, the equity scope, and the failure mode. Nothing essential 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 schema already explains the symbol format (ticker or ISIN) plus the advice to use 'search' for company names. The description adds only the equity-only constraint on the symbol, 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?

States a specific verb and resource (get upcoming corporate-calendar events) and enumerates exactly what comes back: next earnings date(s) with estimate ranges plus dividend/ex-dividend dates. This clearly separates it from narrower siblings like get_earnings and get_dividends.

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

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

Provides an explicit when-not: non-equity symbols (ETF, fund, crypto) return an error. It does not, however, route the agent to specific alternatives such as get_dividends or get_earnings when only one piece of the calendar is wanted, so alternative-selection guidance is partial.

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 and there is no contradiction. The description adds only the content inventory of the result, which is thin behavioral context and partly redundant given an output schema exists; nothing about failures, rate limits, or data freshness is disclosed.

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 verb and purpose, followed by a compact enumeration of return fields. Two sentences with no filler, though the field list is somewhat list-heavy rather than value-adding.

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 need not explain return values, and the annotations cover the safety profile. It adequately conveys purpose and scope; the only real gap is missing usage routing among the many overlapping 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 the schema fully documents the single 'symbol' parameter, including ISIN/ticker examples and the 'use search first' rule. The description adds no syntax or format detail beyond what the schema already provides, making the baseline 3 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 clear verb ('Get') and resource ('company profile and key statistics') and enumerates the returned fields, so the agent knows this is a profile/valuation lookup rather than a raw price quote. It does not, however, name or distinguish itself from siblings like get_quote, get_financials, or get_industry, which overlap on 'statistics'.

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 when-to-use or when-not guidance appears in the description. The helpful hint 'For a company name, use search first' lives in the schema parameter description, not the tool description, and no alternative for quote/financial data is suggested despite many overlapping siblings.

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 that both dividends and splits are returned, but says nothing about the time range covered, default period, or pagination, which matters for a history-style call.

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, no filler, resource named before the qualifier. Front-loaded and exactly as long as it needs to be.

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

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

Output schema exists, so return values need no explanation, and the single required parameter is fully documented with annotations covering the safety profile. The definition is nearly self-sufficient; only the absence of any time-range or routing guidance keeps it from a 5.

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 coverage is 100%, so the schema already documents the symbol format, the ISIN example, and the maxLength. The description's 'for a Yahoo symbol' adds consistency but no new syntax or constraints, 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 a precisely scoped resource (dividend and stock-split history) qualified by the symbol type. This cleanly separates it from siblings like get_history (price history) and get_shares, so an agent can pick it 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?

Usage is implied by the name and by the resource named, but the description offers no when-to-use/when-not guidance or alternatives (e.g. get_history for prices). The only routing hint in the whole definition lives in the schema ('For a company name, use search first'), 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 cover the safety profile (readOnlyHint, openWorldHint), so the description only needs added context — and it delivers: the exact return payload shape (calendar plus recent history) and a failure-mode disclosure (non-equity symbols error out). It does not cover pagination or error shapes beyond the equity case, keeping 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?

Front-loaded verb+resource, then a compact sentence enumerating returned fields, then the equity-only caveat. Three tight sentences with no filler; only minor room to trim the field enumeration.

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-only lookup with a full output schema and annotation coverage, the description supplies purpose, payload contents, and the key failure mode. The only gap is sibling differentiation, which is not strictly required for correct invocation.

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%, including the limit bound (1-50, default 12) and the symbol format guidance (ticker or ISIN, 'use search first'), so the schema carries the parameter burden. The description adds nothing about either parameter, which is the expected baseline 3 when coverage is complete.

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: 'Get upcoming and historical earnings for a Yahoo symbol', with the returned content spelled out (EPS estimate, reported EPS, surprise %). It is clear what the tool does, but it never distinguishes itself from overlapping siblings such as 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 only implied — the agent can infer this is for earnings data on equities, and the description adds a real constraint ('Equity-only: an ETF, fund or crypto symbol answers with an error'). However there is no explicit when-to-use-vs-alternative routing against get_estimates/get_calendar/get_financials, which an agent would need.

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 the safety profile is covered. The description adds genuinely useful behavior beyond that: the equity-only failure mode and the shape of the payload (small tables keyed by period).

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, followed by two short sentences of return details and the equity constraint. No filler; slightly loose line-wrapping but every sentence earns its place.

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

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

For a one-parameter read tool with annotations and an output schema, the description covers purpose, payload contents, and the key error condition. Return-value formatting is left to the output schema, which is appropriate.

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 single 'symbol' parameter is fully documented in the schema (ticker/ISIN formats, redirect to 'search' for company names). The description adds no parameter detail, 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 forward analyst estimates for a Yahoo symbol') and enumerates the returned content (earnings/revenue estimates, EPS trend and revisions, growth estimates). It is clearly distinct from get_quote/get_financials, though it never explicitly contrasts itself with the closest sibling, get_earnings.

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 usage constraint: 'Equity-only: an ETF, fund or crypto symbol answers with an error that says so.' That is an explicit when-not condition. It stops short of naming an alternative tool (e.g. get_fund_data) for non-equity symbols.

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 usefully adds the result orientation (rows are line items, columns are periods, most recent first), but says nothing about pagination, statement availability limits, or error behavior 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?

Two short sentences, front-loaded with the purpose before the result-shape note, and no filler. Slightly terse at the cost of routing information, but every sentence earns its place.

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

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

With an output schema present and annotations covering read-only/open-world behavior, the description only needs to frame purpose and result orientation, which it does. Missing guidance on choosing between this and the many sibling financial-data tools is the only real gap.

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 each fully documented in the schema, including the 'ttm is income and cashflow only' caveat. The description adds no parameter-level detail beyond that, which is the expected baseline when the schema does the work.

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 (a financial statement) scoped to a Yahoo symbol, which distinguishes it from siblings like get_earnings or get_estimates. It does not explicitly name those alternatives, so it stops 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?

There is no when-to-use guidance in the description: no mention of when to prefer this over get_earnings, get_estimates, or get_fund_data, and no stated prerequisites. The only routing hint ('For a company name, use search first') lives in the symbol parameter 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 safety and network scope are covered. The description adds genuinely new behavior: the tool raises an error for non-fund symbols. It stops short of noting rate limits, symbol-resolution behavior (ISIN), or whether missing data yields empty sections.

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 sentences, front-loaded with the purpose and then the returned fields, followed by the negative case. No filler and nothing repeated from structured fields verbatim.

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 explanation is unnecessary, and the description covers purpose, scope, and the error condition. The only gap is the absence of a redirect for non-fund symbols to a sibling tool, which an agent would have to infer from the sibling list.

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% – both `symbol` (ticker/ISIN) and `limit` (max holdings, default 25, max 100) are fully documented in the schema. The description's mention of 'top holdings' only loosely gestures at `limit` and adds no syntax or default info beyond the schema, 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 fund/ETF profile data for a Yahoo symbol') and enumerates the returned content: overview, asset-class and sector weightings, top holdings. The 'Fund/ETF-only' scope plus the explicit failure for stocks/crypto cleanly separates it from siblings like get_company_info, get_holders, and get_quote without naming them.

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?

Tells the agent exactly which inputs are valid (funds/ETFs) and which are not (stocks, crypto, which raise), which is a real routing signal. It does not name the alternative tool to use for a stock symbol (e.g. get_company_info), so the when-not case is covered but the redirect 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 declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds a valuable behavioral detail: results are capped at 250 rows and a `truncated` flag is set when cut. It does not explain rate limits, data freshness, or intraday constraints, leaving some gaps.

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 sentences plus a brief clause, front-loaded with the core purpose and then the query modes and truncation behavior. No wasted words, though the truncation clause could be slightly more prominent.

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 5 parameters with full schema descriptions, annotations, and an output schema, the description covers the essential purpose and adds the non-obvious 250-row cap/truncation behavior. It is nearly complete for an agent to call correctly, though it could mention symbol lookup alternatives more explicitly (though the schema already does).

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 all parameters (period precedence, start/end exclusivity, interval enums, symbol format). The description adds no parameter-level meaning beyond what the schema provides; 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 (get) and resource (historical OHLCV data for a symbol). It is clearly distinct from get_quote (current price) and get_financials, but it does not explicitly name a sibling to reinforce the distinction—it relies on the resource semantics.

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 mentions querying by period or start/end, which implies usage, but it does not provide explicit when-to-use vs. when-to-choose-another-tool guidance or exclusions. The schema already documents period vs start precedence, so the description adds little routing value.

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 safety (readOnlyHint=true, openWorldHint=true), so the bar is lower. The description adds genuine behavioral context: the failure mode for non-equity symbols and the shape of the returned data. It does not mention pagination or limits on the summary section, which would be the 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?

Three tight sentences: the core purpose first, the return contents second, the equity-only restriction last. No filler, no restatement of the name.

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, yet it still gives a useful preview of the payload. Combined with the equity-only constraint, an agent has enough to decide and call correctly; only the alternative routing for non-equity symbols is unstated.

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% – both 'symbol' and 'limit' are fully documented in the schema, including ticker/ISIN formats and the 1–100 range. The description adds no parameter-level 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 and resource ('Get the ownership breakdown for a Yahoo symbol') and enumerates the payload ('insider/institutional percentages plus the top institutional and mutual-fund holders'). This clearly separates it from siblings like get_insider_activity, get_shares, and get_fund_data.

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

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

Explicitly scopes applicability: 'Equity-only: an ETF, fund or crypto symbol answers with an error that says so.' That is a real when-not condition an agent can act on. It stops short of naming which sibling to call instead (e.g. get_fund_data for funds), so it is not a full 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 provide readOnlyHint=true and openWorldHint=true, so the read-only safety profile is covered. The description aligns with that by saying 'Browse' and describes what is returned, but it does not add much behavioral context beyond the annotations—no ordering, pagination, or edge-case behavior is disclosed.

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

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

The description is front-loaded with the core purpose and return contents. It is concise, though the final sentence repeats 'not a ticker symbol' from the opening, making the wording slightly redundant without harming clarity.

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

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

Given the output schema exists and the input schema covers all parameters, the description supplies the essential extra context: where keys come from, what the output covers, and what kind of input is expected. Nothing important is missing for an agent to call this tool 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%, with both 'key' and 'limit' fully documented including types, defaults, and constraints. The description reinforces the key-discovery instruction and the non-ticker warning, but adds no meaning beyond what the schema already provides.

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: browse an industry by its Yahoo key. It enumerates concrete return contents (industry overview, parent sector, top companies, top performers/growth), which clearly distinguishes it from sibling tools like get_company_info or get_sector. The repeated 'not a ticker symbol' further pins down the resource type.

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?

It gives explicit guidance on how to obtain valid keys: from the 'industries' list returned by get_sector, with 'semiconductors' as an example. It also warns not to pass a ticker symbol. However, it does not explicitly compare this tool to alternatives or state when to prefer it over a sibling such as get_sector, so it falls just short of a perfect usage guide.

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 safety profile (readOnlyHint, openWorldHint), and the description adds value beyond them: the three-part return shape and the equity-only failure mode. It does not mention pagination or rate limits, but the output schema handles return structure, so the remaining gap is minor.

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: purpose, then return contents, then the constraint. Front-loaded and every sentence carries distinct information 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?

With an output schema and full parameter coverage, the description only needs to supply the routing constraint, which it does via the equity-only caveat. Only the sibling differentiation (vs. get_holders) 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 both parameters (symbol formats, ISIN, limit bounds) are already fully documented in the schema. The description adds no syntax or format detail beyond it, which is the baseline-3 case.

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 ('Get insider trading activity for a Yahoo symbol') plus an enumeration of the three outputs (individual transactions, 6-month summary, roster). Clear enough to distinguish from get_quote/get_holders by content, though it never names the institutional-holder sibling it is most likely to be confused with.

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 usage constraint: equity-only, with an explicit error for ETF/fund/crypto symbols, and the schema points company-name lookups to 'search' first. No explicit when-to-prefer-this-over-alternatives statement, so it stops just short of 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 and openWorldHint=true, so the safety profile is covered. The description adds valuable behavioral context: the 'status' field is null for non-US keys due to an upstream limitation, not an error. This prevents an agent from misinterpreting null results as failures. It also clarifies that the index summary works for all keys, which is useful behavioral information beyond 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 compact and front-loaded: the first sentence states the core purpose, the second gives example questions and the key-vs-ticker distinction, and the third covers the US-only status limitation. Every sentence earns its place, and there is no redundant 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?

For a single-parameter, read-only tool with a rich schema and an output schema, the description is complete. It covers what the tool does, how to use it, the key limitation (US-only status), and what to expect for other keys. An agent has everything needed to invoke it correctly without further investigation.

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 the 'key' parameter thoroughly, including the allowed values and the US-only status behavior. The description reinforces this by giving examples ('US', 'EUROPE') and restating the key distinction (market key vs ticker). This adds a small amount of clarity beyond the schema, but the schema does most of the work, so a 4 is appropriate rather than a 5.

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 ('Get'), a clear resource ('trading status and headline index summary for a market'), and explicitly distinguishes itself from ticker-based tools by saying it takes a market key, not a ticker symbol. It also names the sibling 'get_quotes' implicitly by contrast, making it easy for an agent to select this tool for market-level status rather than individual securities.

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 says when to use this tool: to answer whether a market is open, when it opens/closes next, and how major indices are doing. It also gives an exclusion: it is not for ticker symbols, and it notes that 'status' is only available for 'US'. This is clear guidance that prevents misuse.

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 the headline-count bound (1-10) and the article field list, but the latter simply restates what the existing output schema already provides. No permission, rate-limit, or recency behavior is disclosed.

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 that front-load the core action; nothing is bloated. The second sentence largely duplicates the output schema, which slightly reduces its value but costs little space.

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 clear annotations, the description is nearly sufficient — the agent knows what it returns and the count bound. The only substantive gap is any guidance on choosing this over sibling news-adjacent 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 (symbol and limit, including the 1-10 range and ISIN/company-name guidance) are fully documented in the schema. The description repeats the limit range but adds no format or syntax detail beyond it, 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?

The description states a specific verb and resource ('Get recent news headlines for a Yahoo symbol'), which is clear and distinguishes it from sibling quote/financial tools by subject matter. It does not explicitly name a sibling or contrast scope against them, so it stops 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?

There is no guidance on when to use this tool versus alternatives such as get_company_info or search; the 'use search first for a company name' hint lives in the symbol parameter schema, not the description. The agent must infer usage purely from the tool name.

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 only cover readOnlyHint and openWorldHint; the description adds real behavioral context: chains are capped at 60 strikes centred on the current price, a 'truncated' flag signals a cut chain, and coverage is restricted to US-listed instruments. These are non-obvious traits the agent could not infer from the schema.

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

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

Three short sentences, front-loaded with the primary action, then the two calling modes, then the coverage caveat. No filler and no repetition of schema mechanics.

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 documented, but the description still supplies the key interpretive detail (60-strike cap, truncated flag). Combined with the parameter routing and the US-only caveat, an agent has everything needed to call and interpret results.

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, and the description earns an increment by specifying that 'expiration' must be a value taken from the list returned by the no-argument call, tying the two parameters together as a workflow.

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?

Opens with a specific verb and resource ('Get the option chain for a Yahoo symbol'), which clearly differentiates it from get_quote, get_history and the other sibling tools. The dual-mode behavior is stated up front so an agent knows exactly what resource it is retrieving.

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

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

Gives explicit when-to-use routing for both modes: call without 'expiration' to list dates, call with it to get the chain for a date drawn from that list. It also states a when-not condition ('a non-US symbol has none and that says nothing about the symbol'), preventing a false negative interpretation.

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 'current' with intraday figures, implying a live snapshot rather than historical data, but says nothing about staleness, market-hours behavior, or error handling 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?

A single front-loaded sentence with no filler; the verb, resource and scope arrive immediately and nothing is wasted.

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 a fully documented one-parameter schema and an output schema present, the description need not explain return values. It is nearly complete, though it omits any routing cue versus the sibling get_quotes, which is the one thing an agent choosing between them might need.

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 single parameter's schema already documents accepted forms (ticker, ISIN) plus the 'search first' fallback. The description contributes no additional parameter meaning, 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 (Get) and resource (current price and key intraday figures) scoped to a Yahoo symbol, which is clearer than a bare name restatement. However, it does not distinguish itself from the near-identical sibling get_quotes, leaving the plural/singular split 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?

No when-to-use or when-not-to-use guidance is given. The description never mentions the sibling get_quotes for batch retrieval, nor does it carry over the schema's hint to run 'search' first for company names — that guidance lives only in the parameter 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 and openWorldHint, so safety is covered by structured data. The description adds real behavioral value beyond that: per-symbol independent lookup and the partial-failure semantics that symbols with no data land in 'not_found' instead of aborting the whole call. It does not mention rate limits or the 50-symbol truncation behavior (that lives in the schema), but the error-handling disclosure is genuinely useful.

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?

Opens with the core action, then usage, then per-symbol behavior and failure handling. Every sentence carries distinct information with no filler, and the most important scoping detail 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?

An output schema exists, so return values need only summary treatment, yet the description still names the key fields and explains the not_found edge case. Combined with the fully covered parameter schema and read-only/open-world annotations, nothing an agent needs to invoke and interpret this 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% and the single 'symbols' parameter already documents tickers/ISINs, the exclusion of company names, and the 50-item cap. The description adds no parameter-level detail beyond the schema, so baseline 3 is appropriate; the sentences about return fields are output, not 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?

States a specific verb and resource ('Get compact current quotes') plus an explicit scope ('for several Yahoo symbols in one call'), which cleanly distinguishes it from the singular sibling get_quote. An agent can tell what it returns and that it is the batch variant 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?

The sentence 'Use this to compare or fetch prices for multiple tickers at once' gives clear usage context that implicitly separates it from get_quote for a single ticker. It stops short of naming the alternative tool or stating an explicit when-not condition, so it falls just below the top band.

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 and world-access behavior are covered. The description adds a small amount of context by noting the trend is over recent months and price targets are returned 'when available,' but does not disclose auth, rate limits, or freshness details. With annotations covering the core behavior, 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 two sentences and front-loads what the tool does. The second sentence largely restates return values that are also captured by the output schema, but it remains brief and is not overly repetitive.

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 a simple, read-only getter with one well-documented parameter and an output schema, so extensive description is not required. It covers purpose and output content sufficiently, though adding a pointer to sibling alternatives would make the context more complete.

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

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

Schema description coverage is 100% for the single symbol parameter, and the schema already documents valid formats including tickers, ISINs, and the need to use 'search' for company names. The description adds no parameter-level detail beyond saying it is for a Yahoo symbol, 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?

The description states a specific verb and resource: getting analyst recommendation trends and price targets for a Yahoo symbol. It identifies the exact data domain (buy/hold/sell trends and price targets), which distinguishes it from siblings like get_estimates and get_upgrades_downgrades.

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 what the tool returns but gives no guidance on when to use it versus alternatives such as get_upgrades_downgrades or get_estimates. It does not mention prerequisites or conditions that select this tool over its siblings.

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 the safety profile is covered; the description adds genuinely useful behavior beyond that: the exact shape of each entry (date, type, title, EDGAR URL, exhibit links) and the important negative-result semantics ('An empty result says nothing about the symbol'). It does not state pagination or how many filings are typically returned, but the coverage of empty-result meaning is a real value-add.

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 the return shape, then the caveats — a sensible ordering with no filler sentences. Slight length is justified by the enumeration of fields and issuer caveats, though the field list overlaps with what the output schema already conveys.

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-only tool with a full output schema and complete parameter descriptions, this covers the remaining unknowns well: what an empty result means and which instrument classes will never return filings. Return-value detail is technically redundant given the output schema, and pagination behavior is unmentioned, keeping it just short of full completeness.

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%: both 'symbol' (accepts ticker or ISIN, with the 'use search first' hint) and 'limit' (max results, default 25) are fully documented in the schema. The description adds only the notion of 'recent' filings, which loosely frames the limit parameter but supplies no new syntax or format detail — 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?

The description opens with a specific verb+resource ('Get recent SEC filings for a Yahoo symbol') and enumerates the fields each entry contains, so the tool's scope is unambiguous. It does not explicitly name or contrast against any of the 20 sibling get_* tools, though the SEC-filings resource is distinctive enough to separate it in practice.

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 context is implied through the caveats ('Only issuers registered with the U.S. SEC file there, so a non-US symbol has none, and neither do ETFs, funds or crypto'), which tells the agent when to expect empty results. However, it never states when to reach for this tool over get_financials, get_company_info, or get_insider_activity, nor does it name any alternative, leaving the routing decision 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 cover readOnlyHint and openWorldHint, so the description does not need to restate them. It adds behavioral context by detailing the composition of the returned data (companies, ETFs, funds, industries) and clarifying the key format, which is useful for an agent planning subsequent calls. No contradictions 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 three compact sentences with zero filler. The main action and key distinction (not a ticker) are front-loaded, follow-up detail is organized logically, and every sentence adds value. This is a model of concise technical writing.

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

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

Given the presence of an output schema and the annotations covering safety/volatility, the description provides complete guidance: it lists the return categories, the drill-down path to get_industry, and the key semantics. An agent has everything needed to call this tool correctly without additional inference.

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%, giving a strong baseline. The description adds meaningful nuance by explicitly stating the key is not a ticker and providing examples (technology, healthcare), which helps prevent misuse beyond the schema's enum list. The limit parameter is already well-documented in the schema, so the description does not need to repeat it.

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 ('Browse') and resource ('market sector'), explicitly distinguishes it from ticker-based tools, and enumerates exactly what is returned (overview, top companies, ETFs, funds, industries). It clearly differentiates from the sibling get_industry, making its role unambiguous.

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

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

The description provides clear context on when to use it: for sector-level browsing, and explicitly points to get_industry for drilling down into industries. It also warns 'not a ticker,' which implies not for individual securities. However, it does not systematically contrast with all other sibling tools beyond the industry drill-down, so a 4 is appropriate.

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 the safety profile is covered. The description adds genuinely useful behavior beyond them: the default 18-month coverage window, the truncation rule ('only the most recent limit points are returned'), and how to widen the window. It does not mention update cadence, auth, or whether values can be null.

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 result shape, then the windowing caveat. Nothing is filler and the most important constraint (18-month default) is placed where it will be read.

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 unnecessary, and annotations cover the safety profile. The description closes the main gap an agent would hit (date-window defaults and truncation). Minor omissions remain, such as units/currency-agnostic nature of the count and staleness of the series.

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 schema already documents all four parameters, including the 18-month default and the YYYY-MM-DD format. The description restates the start/limit behavior rather than adding syntax, ordering, or edge-case detail, 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 the shares-outstanding history for a Yahoo symbol') and describes the shape of the result (date + reported shares outstanding). No sibling tool covers shares-outstanding history, so an agent can distinguish it from get_holders, get_financials or get_company_info 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?

The description implies the use case (retrieving historical shares-outstanding series) and gives one actionable condition ('pass a start for anything older' than 18 months). It never names an alternative tool or states when a different sibling should be chosen instead, so guidance stays implicit.

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 genuine behavioral context on top: entries are firm-level rating changes with from/to grade and action, ordered most recent first, and non-equity symbols return an explicit error. It does not mention rate limits or data staleness, but the added context is substantive.

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: purpose first, entry structure second, failure mode last. No filler and nothing redundant.

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 re-explained, and the description still sketches the entry shape. With annotations covering the safety profile and a fully documented schema, the definition is nearly complete; only the sibling boundary with get_recommendations is left unaddressed.

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' (including ISIN and suffix formats, plus the search fallback) and 'limit' (bounds and default) are fully documented in the schema. The description adds nothing beyond that, 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+resource: 'recent analyst rating changes (upgrades/downgrades) for a Yahoo symbol', and clarifies the entry shape and ordering. The equity-only constraint is useful, but it never distinguishes itself from the close sibling get_recommendations, 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?

The 'Equity-only' note implies when the tool fails, but there is no explicit when-to-use guidance or pointer to get_recommendations/search for adjacent cases. Usage is only implied by the phrasing 'recent analyst rating changes'.

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 known. The description adds that it returns up to limit matches and describes the result fields, which goes beyond the annotations and clarifies the expected output. It doesn't mention edge cases or rate limits, but for a simple read-only search this is adequate.

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

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

The description is two sentences, front-loads the core purpose, and includes the critical usage instruction in the second sentence. Every sentence earns its place, with no redundancy or 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?

For a simple search tool with fully documented parameters, an output schema (implied by 'has output schema: true'), and read-only annotations, the description covers everything an agent needs: what it does, when to use it, and what it returns. There are no missing details that would hinder correct invocation.

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 both parameters, so the schema already documents query and limit thoroughly. The description reiterates that query accepts company name, ticker, or ISIN and that limit caps matches, which adds little new semantic value beyond what the schema provides. The baseline of 3 is appropriate given full schema coverage.

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

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

The description states a specific verb ('Search') and a clear resource ('Yahoo Finance by company name, ticker symbol, or ISIN'), and explains what it returns (matches with symbol, name, exchange, instrument type). This clearly distinguishes it from the sibling get_* tools, which retrieve specific data types rather than resolving entities.

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 instructs to use this tool first to resolve a name or ISIN into a Yahoo symbol that other tools accept, establishing a clear workflow and entry-point role. It gives an explicit 'when to use' without ambiguity, and the instruction 'Use this first' makes it obvious.

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