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

Annotations already declare readOnlyHint=true and openWorldHint=true, which the description does not contradict. It adds genuinely useful behavioral context beyond the annotations: 'Equity-only, empty for ETFs, funds, and crypto,' plus the specific data shape returned (estimate ranges, ex-dividend dates). This adds value without repeating 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?

Two compact paragraphs with the main purpose front-loaded and a clear behavioral caveat. Every sentence earns its place with zero filler or 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 single-parameter tool with a documented output schema and read-only annotations, the description covers what is returned and the equity-only limitation. It is nearly complete; only explicit sibling routing 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 documents the symbol parameter thoroughly (Yahoo ticker or ISIN, use search for company names). The description adds no parameter-level semantics beyond the schema, so the baseline of 3 applies.

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

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 upcoming corporate-calendar events for a Yahoo symbol,' then enumerates the exact contents (earnings dates with estimate ranges, dividend/ex-dividend dates). This is clear and distinct from a vague purpose, though it does not explicitly name overlapping siblings like get_earnings or 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?

Usage context is implied by describing the returned content and the equity-only scope, but there is no explicit when-to-use versus alternatives guidance. Given overlapping siblings such as get_earnings, get_dividends, and get_estimates, the description leaves the agent to infer which tool fits.

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 mark this as read-only and open-world, so the description does not need to disclose safety or mutation effects. It adds useful context by listing returned fields, but it does not address edge cases such as invalid symbols, data freshness, or symbol-resolution failures.

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 concise sentences, front-loads the action and resource, and then lists expected returns without redundant filler. Every sentence contributes useful selection information.

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

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

For a single-parameter read-only tool with a detailed input schema and output schema, the description covers the essential return categories and the symbol format. It could be slightly more explicit about what it does not provide (e.g., historical prices), but current detail is sufficient for correct tool selection.

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

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

The single parameter is fully documented in the schema with valid example formats and the 'search first' instruction. The description adds no additional parameter meaning beyond calling it a 'Yahoo symbol,' so the baseline score of 3 is appropriate.

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

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

The description uses a specific verb and resource: 'Get a company profile and key statistics for a Yahoo symbol.' It clearly names the return content (sector, valuation metrics, business summary), which distinguishes it from quote-only or financial-statement tools like get_quotes and 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?

The description makes the tool's scope clear: company profile and key statistics, not price history, dividends, or financial statements. The input schema adds practical guidance to use 'search' first for company names, but there is no explicit comparison with sibling tools.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety and world-openness are covered. The description adds that the tool returns dividend and stock-split history, but it does not disclose details like return format, adjustment behavior, or absence of data handling. This is adequate but not rich.

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

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

The description is a single sentence with no wasted words, front-loading the action and resource clearly. It is concise and immediately scannable.

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-only tool with a complete input schema, annotations, and an output schema, the description covers everything an agent needs to select and invoke the tool correctly. No critical operational details are 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 the symbol parameter already explaining Yahoo tickers, ISINs, examples, and the 'search' fallback. The description itself adds no parameter-level 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?

The description states a specific verb ('Get') and a clear resource ('dividend and stock-split history for a Yahoo symbol'), which distinguishes this tool from siblings like get_quotes, get_history, and get_financials. An agent can immediately understand what this tool returns.

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

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

The description implies when to use the tool — whenever dividend or stock-split history is needed — but it does not explicitly mention alternatives or exclusion criteria. The symbol parameter's note to use 'search' first is helpful but not tool-selection 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. The description adds meaningful behavioral context beyond those hints: it specifies that the tool is equity-only and returns empty results for ETFs, funds, and crypto, and it details the kinds of data returned. This is useful and non-contradictory.

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 with no filler. The primary purpose is front-loaded, and the additional details about return content and equity-only scope earn their place without redundancy.

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

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

Given the output schema is present, the description does not need to explain return structure in depth. It covers scope, return contents, and the key limitation (equity-only), while the schema handles parameter documentation. An agent has enough information to decide whether and how to call this tool.

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

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

The input schema already covers both parameters with 100% coverage, including the symbol description and limit constraints. The description does not add new semantic meaning for the parameters beyond the schema, so the baseline of 3 is appropriate.

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

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 upcoming and historical earnings for a Yahoo symbol.' It clearly describes what the tool returns (earnings calendar with EPS estimates, reported EPS, surprise %, and earnings history). It does not explicitly differentiate from siblings like get_estimates or get_calendar, so it misses the top score.

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

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

The description gives an important usage constraint: 'Equity-only, empty for ETFs, funds, and crypto.' This implies when the tool is appropriate but does not explicitly say when to prefer it over sibling tools or when to choose an alternative. Usage context is implied rather than explicitly routed.

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, and the description adds valuable behavioral context: it is equity-only, returns empty results for non-equities, and returns 'small tables keyed by period.' This goes beyond the annotations by describing expected output shape and edge-case behavior without contradicting them.

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 with no filler. The primary purpose is front-loaded, followed by a concise list of returned data and a key limitation. Every clause 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 single-parameter tool with an output schema, read-only and open-world annotations, and a clear equity-only constraint, the description covers what an agent needs to call it correctly. The return-value summary is sufficient given the output schema exists.

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 itself already explains that symbol can be a ticker or ISIN and advises using 'search' for company names. The description only repeats 'a Yahoo symbol,' adding no new meaning beyond the schema. 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 starts with a specific verb and resource: 'Get forward analyst estimates for a Yahoo symbol.' It clearly enumerates what is included (earnings and revenue estimates, EPS trend/revisions, growth estimates) and constrains applicability to equities. This differentiates it from siblings like get_earnings or get_financials by emphasizing 'forward' estimates.

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 states the tool returns forward estimates and is 'Equity-only, empty for ETFs, funds, and crypto,' which gives an important exclusion but does not name alternatives or specify when to prefer this over get_earnings or get_financials. Usage is implied by the return content rather than explicitly 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=true and openWorldHint=true, so the read-only nature is covered. The description adds behavioral context about the output format ('Each row is a line item and each column a reporting period, most recent first'), which is beyond the annotations and helps the agent interpret the response. No contradiction 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 two sentences with zero waste. The main purpose is front-loaded in the first sentence, and the second sentence adds a valuable format detail without redundancy. It is appropriately concise and well-structured.

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

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

The tool has an explicit output schema, so return values are already defined. Given the simple three-parameter interface with full schema descriptions and annotations covering the read-only and open-world aspects, the description is complete enough. The format note clarifies the orientation of the response. No missing essential information 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% – all three parameters (symbol, freq, statement) have descriptive text. The tool description does not add any extra meaning beyond what the schema already provides, so the baseline score of 3 applies. The description's format note relates to output, not parameters.

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

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

The description states a specific verb ('Get') and resource ('a financial statement for a Yahoo symbol'), which is clear and unambiguous. The resource uniquely identifies this tool among siblings (no other sibling mentions financial statements). The added format note ('Each row is a line item...') is extra but does not cloud the purpose.

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

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

The description implies usage by naming the resource explicitly ('financial statement'), but it does not explicitly state when to use this tool versus alternatives or mention exclusions. There is no guidance such as 'for real-time prices use get_quotes' or 'for earnings data use get_earnings'. The usage is inferred from the resource type, so it's 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 mark this as read-only and open-world, so the safety profile is covered. The description adds valuable behavioral context beyond annotations by disclosing an error condition: the tool raises for stocks and crypto because they lack fund data. That is a meaningful non-obvious behavior.

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 core purpose appears in the first sentence, followed by return details and an important exclusion. Every sentence earns its place with no redundant or filler 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?

For a simple two-parameter read-only tool with a full output schema and complete parameter descriptions, the description covers what it returns, when it should be used, and a key failure mode. Nothing an agent needs to invoke 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?

The input schema already provides 100% description coverage for both parameters, including examples and the 'use search first' hint for company names. The tool description adds no additional parameter-level meaning, so the baseline score of 3 is appropriate.

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

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

The description starts with a specific verb and resource: 'Get fund/ETF profile data for a Yahoo symbol.' It then lists concrete return contents (fund overview, weightings, top holdings) and explicitly scopes the tool to funds/ETFs, which clearly separates it from the many stock- and crypto-focused sibling 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?

The description gives an explicit when-to-use ('Fund/ETF-only') and a clear when-not-to-use condition ('raises for stocks and crypto'), preventing an agent from misrouting equity or crypto requests to this tool. This is actionable exclusion guidance even though it does not name a specific replacement sibling.

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 mark the tool read-only and open-world. The description adds a meaningful behavioral constraint: results are capped at 250 rows and 'truncated' is set when cut. This goes beyond the schema and helps set expectations.

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 with no filler: purpose, query modes, and row-cap behavior. The most decision-relevant information is front-loaded.

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

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

With full schema coverage, an output schema, and read-only annotations, the description covers the remaining operational detail (250-row cap and truncation flag). Nothing needed 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 schema already documents all five parameters. The description reinforces the period vs start/end relationship but does not add meaning beyond what the parameter descriptions already provide.

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

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

The description opens with a specific verb and resource: 'Get historical OHLCV ... data for a symbol.' This clearly differentiates it from sibling quote/news/fund tools, and the period/start-end modes further specify its scope.

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

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

It gives clear context for use: historical OHLCV retrieval with either a look-back period or an explicit date range. It does not explicitly name alternatives or exclusions, but the purpose is specific enough that an agent can infer when to select it.

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

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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds behavioral context beyond annotations: it specifies the return content (summary plus top holders) and the empty-result behavior for non-equities. This is useful for setting expectations and avoids surprises.

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-loaded with the core purpose ('ownership breakdown'), and includes the key limitation without any fluff. Every sentence earns its place, and the structure is clear and scannable for an agent.

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 (indicated by has_output_schema=true), the description need not detail return fields. It covers the essential scope (equity-only, empty for non-equities) and the general output shape. Combined with annotations and schema, nothing critical is missing for correct invocation and interpretation.

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%, with both 'symbol' and 'limit' already documented in the input schema. The description doesn't add parameter-specific meaning beyond what the schema provides. It mentions return content but not parameter constraints or usage details, so it doesn't exceed the baseline for fully covered schemas.

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

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

The description clearly states the tool gets an ownership breakdown for a Yahoo symbol, specifying the exact output (insider/institutional percentages, top holders). It distinguishes itself from siblings by explicitly noting it's equity-only and empty for non-equities, which differentiates it from get_fund_data or get_shares without ambiguity.

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 the tool (for equity ownership) and explicitly excludes ETFs, funds, and crypto. While it doesn't name alternative tools for those cases, the exclusion itself guides the agent away from misuse. It could have explicitly pointed to get_fund_data for funds, but the limitation is clear enough.

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 already provide readOnlyHint and openWorldHint. The description adds value by detailing the exact return components and the empty response for ETFs/funds/crypto, which is beyond the annotation scope. No contradiction.

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 concise sentences front-load the purpose, then provide details and a caveat. Zero redundant wording.

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 both parameters fully described in the schema, the description covers the key behavioral constraints (return components, equity-only). An agent has all necessary information to select and invoke the tool.

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

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

Schema description coverage is 100%, with clear descriptions for both symbol and limit. The description does not add parameter-specific information, 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 clearly states the verb 'Get' and the resource 'insider trading activity', and enumerates the specific data returned (transactions, 6-month summary, roster). The equity-only caveat distinguishes it from other financial data tools in the sibling set.

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 specifies when not to use (non-equities) but doesn't explicitly name alternatives. The purpose and sibling context make the intended use obvious, but a direct reference to alternatives would have been stronger.

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 establish read-only and open-world behavior, lowering the bar. The description adds that results are limited to 1-10 items and include specific article fields. It does not disclose the news timeframe or possible variation in article availability, but this is not a serious gap given the readOnlyHint and 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 concise, information-dense sentences. The main purpose and limit behavior are front-loaded, and the article field list earns its place by setting return expectations without redundancy.

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

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

Given a simple read-only tool, a 100% schema-covered parameter set, and an existing output schema, the description is nearly complete. It clearly states the result contents and count constraints; the only minor gap is that 'recent' is not time-bound, but this is acceptable for a headline-news 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%, so the schema already documents both parameters well. The description's reference to 'up to limit, 1-10' mirrors the schema's min/max/default and adds no new semantic meaning. 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 ('recent news headlines for a Yahoo symbol') and clarifies the output includes title, summary, publisher, publish time, and URL. It is clearly distinct from the financial-data siblings and can be selected 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 tool description frames the intended use case: retrieving recent news for a Yahoo symbol. The symbol parameter additionally provides guidance to use 'search' first for company names, which routes around a common misuse. No news-specific sibling exists, so explicit exclusions are not required.

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?

Even with readOnlyHint and openWorldHint annotations, the description adds substantial non-obvious behavior: the 60-strike cap on each side, the truncation flag, and the important caveat that non-US symbols have no option chains. These details go well beyond the annotations and prevent misinterpretation.

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

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

The description is front-loaded with a one-line purpose, then logically structured into two concise usage paragraphs. Every sentence earns its place, and the edge-case caveat is included without bloat.

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, the description covers all necessary operational context: how to discover expirations, how to request a chain, result limits, truncation behavior, and market coverage limitations. Nothing critical is missing 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?

The schema already covers both parameters at 100% with clear descriptions (symbol formats and expiration behavior). The tool description mostly restates the expiration flow already in the schema, so it adds limited parameter-level meaning beyond what structured data 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 opens with a specific verb and resource ('Get the option chain for a Yahoo symbol') and clearly distinguishes the tool's unique function from the many sibling data-fetching tools. It also explains the two operational modes, making it immediately recognizable.

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 clear, actionable guidance on when to call without expiration versus with expiration, forming a two-step workflow. It does not explicitly contrast this tool with sibling alternatives, but the usage pattern is explicit enough for correct invocation.

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 convey read-only and open-world behavior, and the description does not contradict them. The description only adds the intraday/current scope; it does not disclose latency, rate limits, or behavior for invalid symbols, though that is a minor gap given 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?

One short, front-loaded sentence with no filler. Every word carries meaning, and the description is appropriately sized for a single-parameter read-only tool.

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

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

Given one required parameter, a rich schema, output schema, and read-only annotations, this is nearly complete for correct invocation. It omits explicit sibling differentiation and data-freshness caveats, but neither is essential for a basic quote lookup.

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

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

The single parameter is fully documented in the schema with type, examples, ISIN support, and a search fallback. The description adds no param-level meaning beyond the schema, so with 100% schema coverage 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 exactly what the tool returns—current price and key intraday figures—for a Yahoo symbol. The phrase 'current' and 'intraday' differentiates it from historical and fundamental data tools, and 'a Yahoo symbol' signals the singular quote use case.

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 mostly implied: it is for a current snapshot of a symbol, not historical or fundamental data. The schema adds a 'use search first for company names' hint, but the tool description itself does not name alternatives like get_quotes for multiple symbols or state when not to use this tool.

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

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

Annotations already mark the tool as read-only and open-world. The description adds useful behavior beyond that: each symbol is looked up individually, failed symbols appear under not_found rather than failing the whole call, and the quoted fields are named. No contradiction 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?

Three concise sentences, each earning its place: the action, the use case, and the failure behavior. The core verb and resource are front-loaded, and there is no redundant restatement of schema details.

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 an output schema available, the description fully covers what the tool does, when to use it, and what happens with missing data. The not_found behavior is especially valuable for agents deciding whether partial results are acceptable.

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 parameter description already documents that symbols are Yahoo tickers/ISINs, not company names, and that up to 50 are accepted with extras dropped. The description only restates the multi-symbol idea, adding no new parameter-level 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 and resource: 'Get compact current quotes for several Yahoo symbols in one call.' It emphasizes multiple tickers and comparison, which distinguishes it from the singular get_quote sibling. The listed return fields further clarify the resource scope.

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

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

'Use this to compare or fetch prices for multiple tickers at once' is a clear, direct instruction for when to choose this tool. It provides context but does not explicitly name alternatives or state when not to use it, such as when a single quote would suffice.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds behavioral nuance by noting 'when available' for price targets and 'over recent months' for the trend, signaling potential data variability without contradicting 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?

Two sentences with zero waste: the first states the purpose and the second details the output. The most important info is front-loaded, and no filler exists.

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

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

The tool is simple (one parameter) and an output schema exists. The description explains what data will be returned, including the caveat about availability, which is sufficient for correct invocation without needing to inspect the 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 coverage is 100% and the symbol parameter is thoroughly documented in the schema with examples and a routing hint. The description does not need to add more, so a baseline of 3 is appropriate—the schema carries the full semantic load.

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 uses a specific verb ('Get') and resource ('analyst recommendation trends and price targets'), and explicitly states the returned data: buy/hold/sell trend and price target statistics. This clearly distinguishes it from siblings like get_estimates or get_upgrades_downgrades by naming the exact output.

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 context by specifying the input format (Yahoo ticker or ISIN) and routes users to 'search' for company names. However, it does not name alternative tools or explicitly state when not to use this tool, leaving some ambiguity among the many recommendation-related 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 read-only and open-world behavior. The description adds useful behavioral context: exact entry fields, the scope limitation to SEC-registered issuers, and the interpretation of empty results. This goes beyond what annotations alone convey, without any contradiction.

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 compact sentences front-load the action and then add only high-value details about result contents, symbol eligibility, and empty-result interpretation. 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 read-only retrieval tool with an output schema, the description covers what is returned and how to interpret edge cases (empty results for non-SEC issuers). Combined with the annotations and schema, nothing necessary for correct invocation 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 both parameters have clear descriptions (symbol formats and limit bounds/default). The tool description adds no new parameter semantics, so the baseline of 3 is appropriate.

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

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') for a Yahoo symbol. The mention of filing types and caveats distinguishes it from financial/news siblings, so an agent can select it appropriately.

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 clear context on when results will be present or empty (non-US symbols, ETFs, funds, crypto) and warns that an empty result says nothing about the symbol. It does not explicitly name alternative tools for cases where SEC filings do not apply, but the guidance is otherwise sufficient.

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

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

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, and the description adds meaningful behavioral detail: each point is a date with reported shares outstanding, limit truncates to the most recent points, and the default window is 18 months. This goes beyond what annotations alone 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?

Three sentences, front-loaded with the core purpose and followed by precise behavioral details. Every sentence contributes useful information with no filler or repetition.

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 does not need to explain return fields. It covers the input semantics, default window, limit behavior, and symbol scope, leaving no obvious gap 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%, so the baseline is 3. The description mostly restates the start and limit semantics already present in the schema, adding only the practical phrasing 'pass one for anything older' without introducing new parameter-level 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?

The description states a specific verb and resource: 'Get the shares-outstanding history for a Yahoo symbol.' This clearly distinguishes it from sibling tools like get_history or get_financials by naming the exact data being retrieved.

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 clear operational guidance: the default 18-month window means callers should pass a start date for older data, and only the most recent limit points are returned. It does not explicitly compare against sibling tools, but the usage context is unambiguous.

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 and openWorldHint annotations, the description discloses meaningful behavioral traits: results are ordered 'most recent first', each entry includes 'from/to grade and action', and non-equity instruments return empty results. This gives the agent important expectations that annotations alone 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?

The description is compact and front-loaded: the first sentence states the core purpose, and the second adds the key details about entry structure, ordering, and scope. Every sentence earns its place without redundancy.

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

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

With a full input schema, an output schema, and readOnly/openWorld annotations, the description completes the picture by covering sort order and equity-only behavior. It does not mention limit semantics or alternatives to sibling tools, but those are not critical gaps given the existing structured context.

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 input schema already documents symbol and limit well. The description adds little parameter-level detail beyond restating that the subject is a Yahoo symbol, so the baseline score of 3 is appropriate.

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

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

The description clearly states a specific verb and resource: 'Get recent analyst rating changes (upgrades/downgrades) for a Yahoo symbol.' It also explains what each entry contains. However, it does not explicitly differentiate itself from similar siblings like get_recommendations, so it falls short of full sibling-level distinction.

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 a clear usage boundary: 'Equity-only, empty for ETFs, funds, and crypto.' This tells the agent when not to expect results, but it does not name alternative tools for those cases, so it is one step below explicit when-to-use/alternative 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=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.