Fintel Discovery — Financial Intelligence for AI Agents

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

Annotations already provide readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so safety is covered. The description adds valuable context: returns one record per position with a detailed field list, pagination behavior for large filers, source (SEC EDGAR infotable XML), and no-API-key requirement. It stops short of error/rate-limit details, but the annotations plus description provide strong transparency.

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 long but well-structured: opening purpose, field list, workflow placement, usage tips, and source. Every sentence adds useful information. Slightly verbose but justified given the tool's complexity.

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?

Despite many parameters, the description covers the essential workflow (prerequisites, filtering, sorting, pagination) and outlines the return fields. Since an output schema exists, detailed return documentation is unnecessary. The description is complete enough for an agent to select and invoke the tool correctly in most scenarios.

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

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

Although the context signal indicates low schema_description_coverage, the description compensates by explaining key parameters with practical examples: min_value_thousands ('filter noise... 1000 = positions ≥ $1M'), sort_by ('value_desc... largest positions first'), and limit/offset for pagination. It also mentions _has_more, which clarifies response semantics. It doesn't cover every parameter (e.g., wholesaler_ids, exclude_fillers), but the most important ones are well explained.

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+resource: 'Fetch and parse the complete equity holdings table from a specific SEC 13F-HR filing.' It clearly distinguishes this from siblings by focusing on parsing a filing's holdings, while sibling tools like SearchEdgar13F locate filings.

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 positions the tool as 'Step 2 of institutional holdings workflow' and names the exact sibling tools to obtain prerequisites: 'Obtain cik and accession_no from SearchEdgar13F or GetEdgarCompanyFilings.' It also provides concrete usage patterns for filtering (min_value_thousands), sorting (sort_by), and pagination (limit/offset, _has_more).

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, idempotent, and non-destructive behavior, but the description adds valuable context beyond that: 'No API key required' and 'data is embedded as curated static reference.' These disclosures inform the agent that no authentication is needed and that results are fixed unless the source dataset changes, which goes beyond what the annotations 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 a compact, bullet-style list that front-loads the primary purpose and then enumerates the five categories. Every line earns its place: purpose, category cover, default behavior, source, and authentication status. No fluff or repetition 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?

Despite an output schema and annotations, the tool's input is a complex nested object with eight parameters, yet the description only addresses 'category.' It doesn't mention that parameters like wholesaler_ids, additional_display_fields, or source_resource_id exist or hint at their use. For advanced use cases, an agent would be under-informed about filtering and follow-up behavior, despite a clear high-level purpose.

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

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

Schema description coverage is 0% per context signals, so the description must compensate for parameter explanations. It only covers the 'category' parameter (listing values and default), while ignoring seven other parameters embedded in the nested 'params' object (e.g., wholesaler_ids, source_resource_id, question_asked). This leaves the agent without semantic guidance for most 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 opens with a specific verb and resource: 'Return Kitces Research advisor practice benchmark data for independent and RIA-affiliated financial advisors.' It clearly distinguishes this tool from its financial-data siblings by focusing on advisor practice benchmarks, not holdings, ratings, or filings. The five categories are explicitly listed, leaving no ambiguity about what the tool provides.

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 a clear usage tip: 'Set category='all' (default) to retrieve all categories at once,' and implies this tool is for benchmark data. However, it does not explicitly discuss when to choose it over alternatives or provide exclusions. Sibling tools are all distinct data sources, so the when-not is not addressed, but the intended use is implied by the domain-specific content.

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, destructiveHint=false, and idempotentHint=true, covering the safety profile. The description adds meaningful context by naming the data source (Yahoo Finance via yfinance), noting no API key is required, and detailing the upgrade/downgrade fields returned. It does not address pagination or failure modes, but the annotation coverage lowers the burden.

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: a single lead sentence summarizes the tool's function, followed by a brief bulleted 'when to use' list and a source note. Every sentence earns its place with no 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?

The tool has rich annotations and an output schema, and the description clearly explains its core purpose and ideal use cases. Some generic parameters (e.g., wholesaler_ids, source_resource_id) are not mentioned, but they are system-wide and documented in the schema. For the analyst-ratings domain, the description provides sufficient context for an agent to select and invoke the 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 0%, meaning the description provides no guidance on any input parameters. It does not mention the symbol parameter or how to invoke the tool, instead focusing solely on the output. While the schema itself documents parameters well, the description fails to compensate for the low coverage, leaving the agent to infer that a ticker is needed.

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: 'Fetch analyst buy/sell/hold consensus ratings, current price targets (low, high, mean, median), and the full history of analyst upgrades and downgrades'. This clearly states what the tool does and distinguishes it from sibling data-retrieval tools like GetDividendsAndSplits or GetEarningsHistory.

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?

An explicit 'Use this tool when' section provides three concrete scenarios: wanting Wall Street consensus, needing price target range, and tracking rating changes. This gives clear context but does not name specific alternatives or exclusions, so it falls short of a 5.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the description's job is lighter. It adds useful context: fully lists return content (employment history, exam qualifications, licenses, disclosures) and states 'Source: FINRA BrokerCheck public API. No API key required,' which is behaviorally relevant. It does not mention rate limits or failure modes, but given the annotations, this is a strong showing.

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

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

The description is concise and well-structured: an opening purpose sentence, a bullet list of use cases, and a source note. No redundant content; every sentence adds value.

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 output schema (context confirms) and good annotations, so the description need not explain return formatting. It covers the main use cases, source, and API key requirement. Slightly missing guidance on what happens if CRD is invalid or not found, but for a read-only tool with rich schema/annotations this is 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?

The description only mentions 'their CRD number' as the key input, which is already in the schema's crd property. With schema description coverage reported at 0%, the description does not compensate for the other optional parameters (e.g., mcp_prompt_id, source_resource_id) or explain their purpose. However, the schema itself provides detailed descriptions for all nested properties, so the tool description adds little beyond reinforcing the primary param.

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 ('Retrieve the full FINRA BrokerCheck profile') with a clear resource (individual by CRD number) and scope (full profile). It distinguishes from siblings by explicitly referencing SearchBrokerCheck as the source for obtaining the CRD, implying this tool is for detailed single-person lookups.

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 'Use this tool when' bullet list provides explicit conditions and scenarios (having a CRD, needing employment history/qualifications, due diligence). It implies the alternative (SearchBrokerCheck) by noting the CRD comes from there, giving a clear when-to-use versus avoid.

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, destructiveHint, and idempotentHint, so the description does not need to restate safety. It adds value by disclosing the data source ('Yahoo Finance via yfinance'), that no API key is required, and the return format (date, amount/ratio for each event). This goes beyond the annotation baseline.

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 well-structured, with the purpose front-loaded in the first sentence, followed by a brief return-format note, a tight bulleted usage list, and a source/API line. Every sentence earns its place with no 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 read-only annotations, the existence of an output schema, and the tool's relatively simple core use case (ticker + lookback), the description fully covers what the tool does, when to use it, and data provenance. No critical gaps remain for an agent to select and invoke it correctly.

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

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

The description provides no parameter-level guidance, and schema description coverage is 0% in the tool description. While the schema itself includes descriptions for nested properties like 'symbol' and 'period', the description does not compensate for the low coverage or clarify which of the many nested parameters are relevant for dividend/split queries.

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 begins with 'Fetch the full history of cash dividends, stock splits, and combined corporate actions for a ticker,' which is a specific verb+resource statement that clearly distinguishes this tool from sibling price/earnings/financial data tools. It also notes the return format (date, amount/ratio), leaving no ambiguity about its core function.

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?

A dedicated 'Use this tool when' section lists three concrete scenarios (dividend yield calculation, dividend growth research, stock split verification). This gives clear context for when to use the tool, though it does not explicitly name alternatives or state when not to use 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=true and destructiveHint=false. The description adds valuable context beyond annotations: data source ('Yahoo Finance via yfinance'), no API key required, and the three return sections (earnings_history, earnings_dates, earnings_estimate). It aligns with annotations without 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?

The description is compact and front-loaded: a clear opening sentence, a short bulleted use-case list, a brief return-structure line, and source/authentication note. Every sentence earns its place, with no redundant or vague 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?

Given the output schema exists and annotations are rich, the description covers purpose, usage scenarios, return sections, and source/auth. It lacks only a hint about required parameters (e.g., symbol), but overall it is sufficiently complete for a simple read-only financial data 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 description provides no parameter information, and schema description coverage is 0% at the top level. Although nested schema fields have detailed descriptions, the tool description does not compensate for the lack of parameter guidance—it never mentions the need for a ticker symbol or any other input.

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 fetches earnings history (EPS actual vs estimate, surprise %), upcoming earnings dates with consensus estimates, and forward EPS estimates—a specific verb ('fetch') plus detailed resource. It distinguishes itself from siblings like GetAnalystRatings or GetFinancials by focusing on earnings-specific 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?

Provides explicit 'Use this tool when' bullets with three concrete scenarios, giving clear usage context. However, it does not explicitly mention when not to use it or name alternative tools, so it lacks the full 'when-not/alternatives' guidance for a 5.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds useful context beyond these: it names the data source (SEC EDGAR API), states that no API key is required, and describes the return content (form type, date, accession number, description). It could mention pagination or rate limits, but the added context is valuable, so score 4.

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 well-structured and concise: a one-sentence purpose, a short output summary, a bulleted list of use cases, and a source/link line. No redundant information; every sentence contributes. Excellent front-loading of the main purpose.

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 the purpose, when to use it, the SEC EDGAR source, and how to locate a CIK. It does not mention pagination or the possibility of very large result sets, but that is a minor gap given the tool's simplicity and the existence of an output schema. Score 4.

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

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

The description explains the primary CIK parameter and provides a URL to find CIKs, which adds practical value. However, the description does not mention the other schema parameters (e.g., wholesaler_ids, source_resource_id) that appear in the input schema. The schema itself has detailed descriptions for all fields, but given the reported 0% schema_description_coverage, the description should compensate more. Score 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 clearly states the tool retrieves all SEC filings for a company/institution using its CIK, naming the specific resource (SEC EDGAR filings) and verb (retrieve). It also lists the exact output fields (form type, date, accession number, description), distinguishing it from sibling tools like Get13FHoldings or GetFinancials.

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

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

The description provides explicit 'Use this tool when' bullets, including tracking 13F/ADV/ownership history and accessing accession numbers. It does not explicitly mention when not to use the tool or alternative siblings, but the use cases are clear and this is a non-mutating lookup, so score 4.

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 indicate readOnlyHint=true and destructiveHint=false, so safety is established. The description adds meaningful behavior context: data limited to 4 annual periods or 4 quarters, transposed row-per-period format, Yahoo Finance via yfinance source, and no API key required. 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 compact and well-structured: opening action sentence, a sentence on data limits/format, bulleted use cases, options summary, and source note. Every sentence earns its place, with no redundancy or fluff.

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 description covers core outputs, data range, format, and source, and an output schema exists. However, the input schema contains many seemingly unrelated parameters (wholesaler_ids, exclude_fillers, etc.) that the description does not explain or clarify as irrelevant, and it never explicitly states that a symbol must be provided. These gaps prevent a perfect score.

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 describes parameters in detail (e.g., symbol example 'AAPL', statement and freq options with defaults, and lengthy descriptions for optional fields). The description only restates statement/freq options and adds no new meaning 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 clearly states 'Fetch income statement, cash flow statement, or balance sheet for a stock,' using a specific verb and resource. It distinguishes from sibling tools like GetPriceHistory and GetEarningsHistory by enumerating the exact financial statements and the fundamental-analysis 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?

The description includes an explicit 'Use this tool when:' section listing four concrete scenarios (revenue/EPS/margins, cash flow, balance sheet, fundamental analysis). It does not mention alternatives or when-not-to-use, but the context is clear enough to guide selection among financial-data 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, idempotentHint=true, and destructiveHint=false, so the safety profile is established. The description adds meaningful context beyond annotations: it requires 'FRED_API_KEY environment variable' (an auth need) and identifies the data source ('Federal Reserve Bank of St. Louis FRED API'). While it doesn't discuss rate limits or error handling, the combination of annotations and these prerequisites gives adequate transparency.

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 well-structured multi-paragraph block: it starts with the core purpose, then gives a bulleted 'when to use' list, then mentions parameter usage, and ends with the API key requirement and source. It is somewhat verbose with the five bullets but each earns its place by clarifying use cases. It is front-loaded with the essential purpose, making it effective for quick scanning.

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 that an output schema exists and annotations cover safety/idempotency, the description is reasonably complete. It states return contents ('date + value pairs with series metadata'), provides usage guidance, and highlights the API key prerequisite. It does not mention pagination behavior or the default limit, but those are documented in the input schema. The main gap is the lack of guidance on ignoring unrelated schema parameters, but this does not prevent successful 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 description adds context for key parameters: 'Pass observation_start / observation_end to limit the date range' and 'Pass frequency to aggregate (e.g. 'm' for monthly, 'q' for quarterly).' However, with schema description coverage reported as 0%, the description does not compensate for all parameters; it omits series_id, limit, and many other fields defined in the schema. The schema itself has detailed descriptions, but the description's coverage is partial, and it does nothing to clarify the several irrelevant-looking parameters (wholesaler_ids, source_resource_id, etc.) that appear in the schema.

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

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

The description opens with a specific verb and resource: 'Fetch time-series observation data from FRED for a specific economic series.' It clearly states the return format ('date + value pairs with series metadata') and differentiates from the sibling tool by explicitly directing users to 'Use SearchFredSeries first if you don't know the series ID.' This is a strong, unambiguous purpose statement.

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 'Use this tool when' list covering typical macro-data scenarios (rates, inflation, GDP, unemployment, macro context, cross-period comparisons, current indicator values). It also names an alternative (SearchFredSeries) for series discovery. However, it does not explicitly state when NOT to use this tool or mention alternative tools for other data types, so it lacks exclusions.

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 readOnlyHint, idempotentHint, and destructiveHint false. The description adds substantial behavioral context: it discloses the data source (SEC EDGAR XBRL), the return fields and their percentage format, default behavior of include_all_classes, and the edge case that not all funds file XBRL rr: data. This goes well beyond the annotations and enriches the agent's understanding of what happens.

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 long but well-structured: it begins with the core purpose, lists return fields in a bulleted block, then provides usage and edge-case notes in labeled sections. Every sentence adds relevant information, and the layout improves scannability. It is not wasteful, but it is more detailed than strictly necessary, earning a 4 rather than a 5.

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

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

Given the tool's moderate complexity, the description is highly complete: it covers the data source, output format, usage workflow, behavior variations (include_all_classes), failure modes, and fallback option. The presence of an output schema means return values are already defined externally, so the description doesn't need to redundantly explain them. It fully prepares the agent to select and invoke the 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 stated as 0%, so the description must compensate. It explains the key parameter cik (obtain from SearchFundsByCategory, zero-padding handled) and the include_all_classes toggle with its behavior. However, it does not mention several other parameters (e.g., wholesaler_ids, source_resource_id, optional_additional_filters) that are present in the schema. The description partially compensates but leaves gaps for less critical 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 opens with a specific verb+resource: 'Retrieve expense ratios and fee breakdown for a mutual fund or ETF using its SEC CIK.' It clearly distinguishes from siblings by naming GetFundProfile as a fallback and SearchFundsByCategory as the source of CIKs, making its role in the fee-comparison workflow explicit.

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

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

Explicitly states 'PRIMARY USE: Step 2 of fee comparison. Accepts CIKs returned by SearchFundsByCategory...' and provides guidance on when to use include_all_classes true vs false. It also gives a specific fallback instruction ('use GetFundProfile (yfinance) as a fallback') when XBRL data is unavailable, offering clear alternatives and context.

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, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds useful behavioral context: it sources data from Yahoo Finance via yfinance, requires no API key, and only works for funds. This goes beyond the structured 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 front-loaded with a clear purpose statement, followed by bulleted use cases and a compact list of section options. It is well structured and easy to scan, though there is minor redundancy between the opening list and the bullet points.

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 description provides enough context to select and invoke the tool correctly: purpose, use cases, section options, scope limitation, data source, and authentication requirement (none). An output schema exists, so return-value details are unnecessary. Some advanced nested parameters remain undocumented in the description, but the schema fills those gaps.

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 description explicitly enumerates section options and maps them to data categories, which helps with the primary parameter. However, it does not explain several nested parameters (wholesaler_ids, source_resource_id, mcp_prompt_id, etc.) or the required 'params' wrapper. Given that schema description coverage is 0%, the description only partially compensates for the gap.

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 fetches ETF or mutual fund specific data and lists concrete data types (top holdings, sector allocations, expense ratio, bond ratings, equity style). It also distinguishes from siblings by explicitly noting 'For stocks, use GetTickerInfo', which removes 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 'Use this tool when' section provides explicit use cases, and the description clearly states it only works for ETFs/mutual funds, directing stock queries to GetTickerInfo. This gives the agent both positive and negative guidance for tool selection.

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, idempotentHint=true, and destructiveHint=false. The description adds valuable behavioral context beyond these annotations by specifying the data source ('Yahoo Finance via yfinance') and the lack of an API key requirement, which informs the agent about external dependencies and authentication. It does not detail rate limits or failure modes, but the safety profile is already covered by annotations.

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

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

The description is concise and well-structured. It opens with a clear purpose, followed by bullet-pointed usage scenarios and a terse listing of holder_type options, then closes with source/auth notes. Every sentence earns its place, and the description is front-loaded with the most actionable 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?

Given the tool's moderate complexity and the presence of annotations (readOnlyHint, idempotentHint) and an output schema, the description covers the essential context: what data it returns, common use cases, holder_type options, and data source. It does not mention potential limitations or required fields (though symbol is optional), but it is largely complete for a read-only data-fetch 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 description mentions 'holder_type options: institutional, mutualfund, insider, all', which aligns with the schema's parameter description, but it does not add significant meaning beyond what the schema already provides. The schema itself contains rich descriptions for symbol, holder_type, and other parameters. While the context signal indicates 0% schema description coverage, the description only partially compensates by enumerating holder_type values; other parameters (e.g., symbol, wholesaler_ids) are not addressed in the tool description.

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 what the tool does: 'Fetch ownership data for a stock: top institutional holders, mutual fund holders, and recent insider transactions.' This is a specific verb+resource construction that distinguishes it from sibling tools like Get13FHoldings or GetFundProfile. The scope is explicit and the mention of holder types further clarifies the tool's unique 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 provides a clear 'Use this tool when' section with three concrete scenarios, giving the agent strong cues for when to invoke this tool. However, it does not explicitly name alternative sibling tools or state when NOT to use this tool, so it stops short of full exclusionary 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, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful context beyond that: 'Source: SEC IAPD public API. No API key required' and explicitly lists the return contents (office locations, custodians, affiliated entities), giving the agent a better sense of what to expect. It does not mention rate limits or error behavior, but with the annotations and output schema, this is sufficient.

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 well-structured: a concise opening sentence stating the core action, a brief list of return contents, three clear bullet points for usage scenarios, and a final note on the source and API key. Every sentence is informative and there is 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?

The tool has an output schema (available to the agent), the annotations declare it read-only and idempotent, and the description adds key contextual details: source, no API key, expected fields, and specific use cases. For a read-only retrieval tool with rich schema and annotations, this description is complete and sufficient for an agent to know when and how to invoke it.

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

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

The description only mentions the main parameter CRD ('by its CRD number' and references SearchIAPDFirm as the source), but the input schema already provides detailed descriptions for all parameters, including CRD. Since schema_description_coverage is 0% (the tool description does not explain the other 7 parameters), the description should compensate, but it does not address optional filters or internal fields. However, the schema's own descriptions are rich, so this is a minor gap.

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

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

The description clearly states the tool's purpose: 'Retrieve the full Form ADV filing detail for one RIA firm by its CRD number.' It uses a specific verb, identifies the resource ('full Form ADV filing detail'), and lists key returned fields (client types, advisory activities, fee arrangements, etc.), which distinguishes it from sibling tools like GetIAPDIndividualDetail or SearchIAPDFirm.

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 includes a 'Use this tool when' section with three concrete scenarios, such as 'You have a firm CRD (from SearchIAPDFirm) and want complete ADV detail' and 'You need office locations, custodians, or affiliated BD information.' It gives clear context for when to use the tool but does not explicitly name alternatives or state when not to use it, so it misses the top score.

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 idempotentHint, lowering the bar. The description adds useful context: SEC IAPD public API source, no API key required, and what data sections will be returned. It doesn't mention rate limits, errors, or pagination, but the read-only nature is already captured by 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?

Description is three short paragraphs: purpose, use-case bullets, and source/auth note. It is front-loaded with the main verb and resource, uses bullets effectively, and contains no filler or repeated schema content. Every sentence adds value.

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 an output schema exists and annotations cover read-only/idempotent behavior, the description provides enough operational context: source, no auth, main use cases, and return contents. It lacks limitations or guidance on the optional platform parameters, but for an individual-detail lookup it is sufficiently 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 reported as 0%, and the description does not compensate. It only mentions 'CRD number' and that the CRD comes from SearchIAPDIndividual, but does not explain the many other schema parameters (mcp_prompt_id, source_resource_id, wholesaler_ids, etc.) or how to pass them. The schema itself has rich descriptions, but the tool description adds little 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?

Description states a specific verb-resource pair: 'Retrieve the full SEC IAPD profile for one individual investment advisor representative using their CRD number.' It lists concrete contents (registration history, exam qualifications, employment history, disclosures) and clearly distinguishes from siblings like SearchIAPDIndividual ('full profile') and GetIAPDFirmDetail ('individual').

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?

Explicit 'Use this tool when' bullets provide clear context: having a CRD from SearchIAPDIndividual, needing full profile/Form ADV Part 2B equivalent, and performing deep due diligence. It does not explicitly name alternatives or when-not conditions (e.g., firm lookups should use GetIAPDFirmDetail), so it falls short of a 5.

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

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

Annotations already declare readOnly, idempotent, and non-destructive. Description adds valuable context: source is the GLEIF API, no API key required, and it returns a single record. It does not mention error cases or rate limits, but for a simple read operation 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 compact: two introductory sentences plus a three-item bullet list. Every sentence adds value, including the source and no-API-key note. Front-loaded with the primary purpose.

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 simple scope, the description covers purpose, usage, source, and return fields. Output schema exists, so return values need not be described. However, the schema contains many extraneous parameters that the description does not address, which might confuse an agent despite the clear focus on the LEI code.

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

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

Schema description coverage is 0% at the tool level (top-level 'params' lacks description), and the description does not compensate by explaining the input structure. The description mentions the LEI code but ignores the other seven nested parameters (mcp_prompt_id, wholesaler_ids, etc.), many of which seem irrelevant; an agent gets no help distinguishing relevant from irrelevant 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?

Description clearly states the tool retrieves a full GLEIF LEI record for one legal entity using its 20-character LEI code, listing specific return fields (legal name, registration status, addresses, LOU, renewal dates). This specific verb+resource distinguishes it from search tools like SearchLEI.

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 'Use this tool when' section provides explicit conditions (have LEI from SearchLEI, verify registration status, need legal address). It does not explicitly state when not to use or mention alternative tools by name, but the reference to SearchLEI as the source of the LEI implies a workflow.

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, destructiveHint=false, and idempotentHint=true, so the safety profile is covered. The description adds useful context by explaining the flattened table output (e.g., 'AAPL_Close', 'SPY_Volume') and the data source (Yahoo Finance via yfinance, no API key required). However, it does not mention potential limits on the number of tickers, request rate constraints, or how date ranges interact with the 'period' parameter.

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 well-structured: purpose first, then return format, usage scenarios, and source. It is not overly verbose; the bullet list is scannable. Every sentence adds value. It could be slightly tighter by merging the symbol-passing note into the purpose, but overall it is efficient and 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?

Despite having an output schema (which covers return values), the tool's input schema is large and includes many parameters unrelated to price history (wholesaler_ids, exclude_fillers, etc.). The description does not clarify which of these are relevant or how to use the core date/interval parameters. It also lacks information on symbol-count limits or error behavior, making it insufficient for an agent to correctly fill the params object in many scenarios.

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

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

Schema description coverage is 0%, so the description must carry the burden of explaining parameters. It does explain the symbols format (space- or comma-separated) with examples, which is helpful. But it completely ignores the other key parameters (start, end, period, interval) that are part of the params object, and it does not mention the several unrelated-looking fields (wholesaler_ids, source_resource_id, etc.) that appear in the schema, leaving an agent without guidance on those.

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 clear, specific action: 'Fetch OHLCV price history for multiple tickers in a single call.' It distinguishes the tool from its sibling GetPriceHistory by emphasizing multi-ticker support and the flattened table output format. The source and key output shape are also stated, leaving no ambiguity about the tool's core function.

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 explicit when-to-use guidance through a bulleted list of scenarios (comparing performance, correlated data, correlation matrices). It implies that for single-ticker data one would use a different tool, but it does not explicitly name GetPriceHistory as the alternative. This is clear context but lacks an explicit exclusion statement.

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 indicate readOnlyHint, idempotentHint, and destructiveHint=false, so the description adds value by disclosing the return fields, the data source (Yahoo Finance via yfinance), no API key requirement, and default-expiry behavior. It does not mention potential large payloads or rate limits, but the additional context is strong.

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

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

The description is concise, front-loaded with the main action, and uses a clean bullet list for usage guidance. Every sentence contributes: what it returns, when to use, prerequisite, default behavior, and source. No fluff or 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 robust output schema and annotations, the description covers purpose, usage conditions, source, and key behavior. It could go further by noting the potentially large size of the full chain or pagination characteristics, but it already states 'full options chain' and lists fields, making it sufficiently complete for selection and 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 description explains the expiry_date default behavior and the prerequisite to use GetOptionsExpirations, which adds semantics beyond the schema. However, it does not explain the symbol parameter or the many fin-specific parameters (wholesaler_ids, exclude_fillers, etc.), and schema description coverage is 0% per context. The description only partially compensates for the low 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 clearly states the tool fetches 'the full options chain (calls and puts) for one expiry date' and lists the specific data fields returned (strike, bid, ask, last price, IV, open interest, volume). This specific verb+resource distinguishes it from siblings like GetOptionsExpirations, which is about expiry dates rather than the chain.

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

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

The description provides explicit 'Use this tool when' bullet points covering options strategy research, IV needs, and open interest analysis. It also names the prerequisite sibling tool, 'Call GetOptionsExpirations first to get valid expiry dates,' and explains the fallback behavior when expiry_date is omitted. This gives clear context for when to use this tool versus alternatives.

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, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds valuable context: it states the data source (Yahoo Finance via yfinance) and that no API key is required. This goes beyond the annotations and helps the agent understand external dependencies and authentication needs.

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

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

The description is concise and front-loaded with the main purpose. The 'Use this tool when' bullet list is clear and directly relevant, and the source note is useful. It is appropriately sized for a simple read-only tool, though the bullet section could be slightly tightened without losing meaning.

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 and read-only, and an output schema exists, so the description does not need to detail return values. It covers when to use the tool, the source, and authentication. It lacks mention of rate limits or data freshness, but given the simplicity and existing annotations/output schema, the description is sufficiently complete for an agent to invoke the tool correctly.

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

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

Although the tool description mentions 'for a ticker,' it does not name the 'symbol' parameter or explain the other parameters. However, the input schema provides robust descriptions for every property, including examples (e.g., 'AAPL', 'SPY') and detailed explanations for fields like wholesaler_ids and source_resource_id. Since the schema itself carries the semantic burden, the description's lack of parameter detail is acceptable, but it adds no extra meaning beyond the schema.

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

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

The description opens with a specific verb and resource: 'List all available options expiry dates for a ticker.' This clearly states what the tool does and distinguishes it from sibling tools like GetOptionsChain, which retrieves the full option chain once an expiry is chosen. The title also reinforces 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 provides explicit 'Use this tool when' conditions and names the related sibling tool GetOptionsChain as the intended next step. It says to use this tool before GetOptionsChain to find a valid expiry date, which gives the agent clear guidance on when to select it over alternatives.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds useful context beyond annotations: the data source (Yahoo Finance via yfinance), no API key requirement, and specific intraday limits (1h max 730 days, 5m/15m/30m max 60 days), which inform agent expectations about data availability.

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

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

The description is concise and well-structured with a clear opening, bullet-pointed use cases, and a compact list of interval/period options. Every sentence adds value, and the formatting improves scannability 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 an output schema present and annotations covering safety, the description sufficiently covers the tool's purpose, use cases, and key parameter options. It does not explain the generic parameters (e.g., wholesaler_ids) but these are likely irrelevant to price history and are documented in the schema. The description could mention that start/end override period, but that is already in 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?

The input schema already provides detailed descriptions for interval and period options, including max durations. The description repeats a subset of these options but does not add meaning beyond the schema. Given high schema coverage, the baseline of 3 is appropriate; the description does not compensate for the many other parameters (e.g., wholesaler_ids, source_resource_id) but those are likely generic and not central to this tool.

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 fetches OHLCV price history for one ticker, with a specific verb ('Fetch') and resource ('OHLCV price history'). It distinguishes from sibling tools by explicitly noting 'one ticker', which contrasts with GetMultiTickerHistory.

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

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

The description provides explicit 'Use this tool when' bullet points covering historical data needs, performance analysis, and returns/volatility/trend computation. It does not name alternatives or explicitly state when not to use, but the 'one ticker' constraint implicitly rules out multi-ticker use cases.

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, destructiveHint=false, and idempotentHint=true, establishing it as a safe read operation. The description adds meaningful behavioral context: dependence on the cenpy Python package, optional API key with rate-limited fallback (further detailed in the schema), and data source (ACS 5-Year estimates). This goes beyond the annotations 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 well-structured with clear sections ('Key metrics returned', 'Use this tool when') and front-loads the core purpose. At ~150 words, it carries some redundancy (e.g., repeating 'free' and API key info) but remains focused and 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?

Given that an output schema exists and annotations cover safety, the description is comprehensive enough: it explains what the tool returns, when to use it, and its external dependencies. It does not explicitly state the mutual exclusivity of state and zip_code, but the schema covers that. Overall, it provides sufficient context 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 description coverage is reported as 0%, and the description only superficially references 'ZIP code or state' without detailing the many other parameters (wholesaler_ids, exclude_fillers, etc.). However, the input schema itself contains rich descriptions for every property, so the agent can get full parameter semantics from the schema. The description adds minimal value for parameter understanding beyond the primary selection fields.

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

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

The description clearly states the tool's function with a specific verb and resource: 'Retrieve US Census American Community Survey (ACS) income and wealth proxy data for a ZIP code or state.' It lists concrete metrics (median income, home value, household count) and explicitly positions it for territory scoring, distinguishing it from the financial-data-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 includes a dedicated 'Use this tool when:' section with three explicit scenarios (scoring territory wealth potential, comparing income distribution, needing wealth proxy before overlaying advisor AUM data). This provides clear, actionable guidance on when to select this tool over alternatives.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds valuable context beyond annotations: it names the data source (Yahoo Finance via yfinance), states no API key is required, and discloses the breadth of return fields (60+ metadata fields). It does not cover rate limits or latency, but the added source and authentication context go beyond what annotations provide.

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 well-structured with a clear lead sentence, a bulleted 'Use this tool when' list, a supported-assets section, and a source note. Every sentence serves a purpose; there is no redundant filler. It is longer than the ideal example but remains efficient and scannable for an AI 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?

The description covers the tool's purpose, usage scenarios, supported asset types, data source, authentication requirements, and return fields. An agent can confidently select and invoke this tool without needing additional context. The presence of an output schema means the return format need not be detailed further. It is complete for a read-only profile fetch 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 schema provides extensive descriptions for all parameters, but the context signal reports schema description coverage as 0%, suggesting the tool description must compensate. The description gives concrete symbol examples for various asset classes (AAPL, SPY, VFINX, BTC-USD, ^GSPC) but does not explain other parameters like mcp_prompt_id, wholesaler_ids, or source_resource_id. This partially compensates for the core symbol parameter but leaves other parameters unexplained.

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 'Fetch the full Yahoo Finance profile for a stock, ETF, mutual fund, crypto, or index' with a specific verb and resource. It lists exact output fields (name, sector, industry, market cap, P/E ratio, etc.) and distinguishes itself from sibling tools like GetPriceHistory or LookupTicker by focusing on the full profile metadata.

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 an explicit 'Use this tool when' list with three concrete scenarios (quick summary, sector/industry classification, current price metadata). It also lists supported asset types with symbols. It does not mention when NOT to use it or name alternative sibling tools, but the use cases are clear enough for an agent to select this tool appropriately.

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, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds useful context beyond annotations: it identifies Yahoo Finance/yfinance as the source, states no API key is required, and notes the return includes exchange and asset type. This enriches the behavioral understanding without contradicting 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 well-structured with a clear introductory sentence, a 'Use this when' list, and a source note. It is slightly verbose because the asset_type options are repeated almost verbatim from the schema, but each section serves a purpose and the content is not wasteful.

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 that an output schema exists and the tool is a simple read-only lookup, the description adequately states what is returned (matching symbols with exchange and asset type) and the source. It does not explain every parameter, but relies on the schema for that. The description is complete enough for an agent to select and invoke the 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?

Context signals indicate 0% schema description coverage, so the description must compensate. It explains the query parameter implicitly ('by company name, fund name, or keyword') and explicitly lists asset_type options, but does not address other parameters like max_results, mcp_prompt_id, or wholesaler_ids. While the schema itself contains detailed descriptions for these, the given coverage signal lowers the baseline, and the description only partially fills the gap.

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 searches for a Yahoo Finance ticker symbol by company name, fund name, or keyword, returning matching symbols with exchange and asset type. It uses a specific verb ('Search') and resource ('ticker symbol'), and is distinct from sibling tools like SearchBrokerCheck or SearchFigiInstruments.

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

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

The description provides explicit when-to-use scenarios: knowing a name but needing the ticker, finding ETF/mutual fund tickers, and disambiguating similar securities. It does not explicitly mention alternatives or when not to use the tool, but the context provided is clear and actionable.

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 idempotentHint=true. The description adds context about the API source (Bloomberg OpenFIGI), no API key requirement, and rate limit behavior. It does not describe edge cases or error handling, but the added info is valuable.

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 well-structured with clear sections: a summary, 'Use this tool when' list, supported idType values, and a source/rate-limit note. Every sentence adds value, and the formatting makes it easy to scan.

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, the description does not need to detail return values. It covers the tool's purpose, usage scenarios, supported ID types, and operational details like rate limits and API source, making it complete for an agent to decide when and how to use it.

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

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

The tool description explains idType values and exchCode usage, which complements the schema. However, the schema has extensive descriptions for the 'mappings' object and other fields, and the description does not cover the full parameter structure (e.g., mcp_prompt_id, wholesaler_ids). Since schema coverage is 0%, more compensation was expected.

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 that it maps financial instrument identifiers between ID systems using OpenFIGI, listing conversions between ticker, ISIN, CUSIP, and FIGI. This is specific and distinguishes it from sibling tools like LookupTicker or GetTickerInfo.

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 provides a 'Use this tool when' section with concrete scenarios, such as converting IDs or combining data from EDGAR and Yahoo Finance. It does not mention alternative tools or when to avoid using it, but the use cases are clear.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, so safety is covered. The description adds meaningful context: source (FINRA public API), no API key required, and that results are a summary (full profile via GetBrokerCheckDetail). It does not mention pagination limits or rate limits, but those are in the schema, so this is a solid 4.

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 well-structured: front-loaded purpose, then usage cases, workflow, parameter note, sibling reference, and source. It is longer than the best examples but every section earns its place; no fluff. Minor redundancy (e.g., 'narrow results' repeats schema wording) keeps it from a 5.

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

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

Given the tool's complexity (multiple parameters, related tools, pagination), the description covers purpose, return fields, use cases, alternatives, a workflow, parameter hint, and source/auth. Output schema exists, so return details are not needed. This is complete enough for an agent to use 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 effectively 100% for individual params (e.g., name, state, rows, start all have descriptions). The description adds minimal extra semantics—it highlights 'state' as a narrowing filter and implies name usage. Since schema already covers parameter details, baseline 3 is appropriate and the description does not compensate for any undocumented params.

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: 'Search FINRA BrokerCheck for registered individual brokers and financial representatives by name.' It explicitly lists return fields (CRD number, current firm, registration status, disclosures), distinguishing it from sibling SearchBrokerCheckFirm and GetBrokerCheckDetail.

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 'Use this tool when' list with three concrete scenarios, names alternative tools (SearchBrokersByPlace, SearchBrokerCheckFirm, GetBrokerCheckDetail), and describes a step-by-step geographic workflow. This fully addresses when to use vs alternatives.

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 state readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the bar is lower. The description adds useful non-obvious context: 'Source: FINRA BrokerCheck public API. No API key required.' This clarifies the data source and authentication requirements beyond what annotations provide. It doesn't discuss rate limits or pagination behavior, but the annotations cover the safety profile adequately.

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 well-structured and concise. It opens with the primary purpose, lists specific use cases in a bulleted section, and ends with a note on the data source and API key requirement. No sentence is wasted, and 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?

The description covers the core purpose, usage scenarios, and source context, which is sufficient for an agent to decide when to invoke the tool. An output schema exists, so the lack of return value explanation is acceptable. It does not mention pagination or the full set of optional parameters, but the schema and annotations fill many gaps. Overall it is fairly complete but not exhaustive.

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

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

Schema description coverage is 0% for the top-level 'params' parameter, so the description must compensate for parameter meaning. It only hints at 'name' and 'location' (state) implicitly through usage bullets, but does not explicitly explain parameters like rows, start, state, or the required input structure. The schema's nested property descriptions do provide detail, but the tool description itself adds minimal parameter semantics.

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

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

The description clearly states the tool's function: 'Search FINRA BrokerCheck for broker-dealer firms by name.' It also lists the specific output fields (firm CRD, registration status, city, state, disclosure flag), distinguishing it from sibling tools like SearchBrokerCheck which likely covers both firms and individuals. The title reinforces the firm-specific 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?

The description includes a dedicated 'Use this tool when:' section with three concrete scenarios (needing CRD numbers, distinguishing similarly named firms, building territory maps), which provides clear context for when to use it. It does not explicitly mention when not to use it or name alternative tools, so it stops short of a 5.

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

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

Annotations already declare the tool as read-only, idempotent, and non-destructive, so the safety profile is well covered. The description adds valuable context: it identifies the data source (SEC EDGAR full-text search API), states 'No API key required,' and mentions date-range filtering. This goes beyond the annotations and provides a clear picture of the tool's behavior, though it doesn't discuss potential rate limits or pagination.

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 well-structured and efficient. It opens with the core function, then uses a bulleted list for use cases, and ends with a concise note on date filtering and source. Every sentence serves a purpose, and the key information is front-loaded. It is neither overly verbose nor under-specified.

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 description provides context about the data source, the purpose of 13F filings, and what the tool returns. However, it is incomplete in some respects: it doesn't mention that only filing metadata is returned (not actual holdings), which makes the first use-case bullet misleading. It also doesn't address the internal parameters or any limitations like pagination. While an output schema exists, the description leaves gaps in understanding the tool's full scope.

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

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

The schema has very low description coverage (0% per context signals). The description only partially compensates by mentioning 'institution name' (mapping to query) and 'start_date and end_date' with format. However, it does not mention the many other parameters in the schema (wholesaler_ids, exclude_fillers, source_resource_id, etc.) or provide any guidance on them. The schema itself has detailed descriptions for each parameter, but the tool description fails to bridge the gap for a tool with many 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 clearly states the tool's function: 'Search SEC EDGAR for 13F-HR institutional holdings filings by institution name.' It specifies the resource (SEC EDGAR 13F filings), the action (search), and the key differentiator (by institution name), and lists the returned fields. This makes it distinct from sibling tools like Get13FHoldings or GetEdgarCompanyFilings, even without an explicit comparison.

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 includes a 'Use this tool when' section with three specific scenarios, providing clear context for when this tool is appropriate. However, it does not explicitly mention alternatives or when not to use the tool, and one bullet ('see what funds or ETFs a firm holds in their portfolios') may overstate the tool's capabilities since it returns filing metadata, not actual holdings. Still, the guidance is largely clear and useful.

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 readOnly, idempotent, and non-destructive behavior. The description adds valuable context about the data source (Bloomberg OpenFIGI API) and authentication ('No API key required (optional key raises rate limits)'). It doesn't contradict annotations, and the extra source/auth detail goes beyond what annotations indicate.

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 well-structured with a clear first sentence, a concise output list, and bullet points for use cases. It front-loads the essential purpose, uses whitespace effectively, and every sentence contributes to understanding the tool. No fluff or 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?

The description covers purpose, output, use cases, an alternative, and source/auth. With an output schema present and annotations covering safety, it is largely complete for a search tool. The only minor gap is not detailing rate limit specifics or error behavior, but those are peripheral.

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

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

Schema description coverage is 0% at the top level (the 'params' object has no description). The description does not mention any parameters (query, limit, exchange_code, etc.), so it fails to compensate for the low coverage. Although the nested schema contains rich property descriptions, the tool description itself adds no 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 opens with a specific verb and resource: 'Search Bloomberg OpenFIGI for financial instruments by name or keyword.' It clearly states the output fields and differentiates from siblings by explicitly directing users to MapInstrumentIds when they already have a specific ID. This distinguishes it well from other search tools like LookupTicker.

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 'Use this tool when' section lists three concrete scenarios, and it explicitly names an alternative (MapInstrumentIds) for a different use case. This provides clear when-to-use and when-not-to-use guidance, which is rare and highly useful.

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 readOnly, idempotent, and non-destructive hints. The description adds the FRED_API_KEY requirement and the data source, which are not in annotations. This is meaningful beyond the structured metadata, though it doesn't discuss rate limits or error behavior.

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

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

The description is well-structured with a clear opening sentence, a bulleted use-case list, and a helpful list of common series IDs. It is a bit longer than strictly necessary, but every section earns its place and the front-loaded purpose sentence makes it easy to scan.

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 description covers purpose, use cases, auth requirement, and points to a companion tool. The output schema and annotations cover return values and safety, so the description is sufficiently complete for a search tool, though it omits potential limitations like result count defaults.

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 coverage is 0% at the tool level, and the description does not compensate. It mentions 'by keyword' but doesn't explain the 'params' wrapper or the key parameters like query, limit, and order_by. The nested schema has descriptions, but the tool description itself offers little parameter guidance.

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 searches the FRED database by keyword and lists the specific return fields (series ID, title, frequency, etc.). It distinguishes itself from sibling tool GetFredSeriesData by explicitly framing this as the discovery step before fetching data.

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

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

The description provides a dedicated 'Use this tool when' section with concrete scenarios, and explicitly names the alternative GetFredSeriesData as the follow-up after finding a series ID. It also notes the API key requirement, giving clear operational 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 destructiveHint=false, so the safety profile is known. The description adds valuable behavioral context: it queries specific form types, de-duplicates by CIK, supports date filtering, and requires no API key. This goes beyond what annotations provide.

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?

Description is front-loaded with the core purpose, then a clear PRIMARY USE statement, followed by useful example queries. Every sentence earns its place; no filler or redundancy. Well-organized and easy to scan.

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

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

Given the tool's complexity (nested schema with many fields) and the presence of an output schema, the description covers the main workflow context, source, de-duplication behavior, and date filtering. It does not mention pagination or rate limits, but these are less critical for a read-only search tool with good annotations.

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 top-level 'params' parameter has no description (0% coverage), and the tool description does not explain that the agent must pass an object with sub-fields. Example queries hint at 'keywords' and 'fund_type' but omit other parameters like start_date, max_results, and filters. The nested schema has detailed descriptions, but the description does not compensate for the coverage gap.

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?

Description clearly states it searches SEC EDGAR for mutual fund and ETF filers by category or keyword, names the specific forms queried (N-1A, 485BPOS, N-2), and lists return fields (entity name, CIK, form type, filing date). This is a specific verb+resource pairing that distinguishes it from sibling tools like GetFundFees.

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 frames the tool as Step 1 of a fee-comparison workflow and directs the agent to feed returned CIKs into GetFundFees. Provides concrete example query scenarios. However, it does not explicitly state when NOT to use this tool or compare it to alternative search tools like SearchEdgar13F.

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, idempotent, and non-destructive. The description adds useful context: it covers only SEC-registered RIAs, returns specific fields, uses a public API with no API key, and notes the source. It doesn't mention pagination or error cases, but the safety profile is already covered by 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 longer than necessary but well-structured with clear sections, bullet points, and a source note. Every sentence adds value, including workflow and alternatives, though it could be slightly more concise.

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 description covers the tool's scope, output fields, source, authentication, limitations, and relationship to sibling tools. Given the presence of an output schema and rich sibling context, this description is complete and leaves no critical gaps.

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

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

Schema description coverage is 0%, but the description clearly indicates the core parameter is the firm name and what the search does with it. The schema itself provides more detailed parameter descriptions for the nested properties, so the description adds some meaning without fully compensating for all 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 clearly states the tool searches the SEC IAPD database for RIA firms by name and lists the exact return fields. It also distinguishes from sibling tools by explicitly contrasting with BrokerCheck and mentioning GetIAPDFirmDetail as a follow-up.

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

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

The description provides explicit 'Use this tool when' bullets, names alternative tools for broker-dealers (SearchBrokerCheckFirm), and describes a workflow from SearchBrokersByPlace to GetIAPDFirmDetail. This gives clear guidance on when to use this tool versus 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, idempotentHint=true, and destructiveHint=false, so the agent knows this is a safe read operation. The description adds useful context beyond annotations: it names the public source (api.adviserinfo.sec.gov), states that no API key is required, and lists return fields (CRD number, current employer, registration states, exam history). This gives additional behavioral context 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?

The description is appropriately sized and front-loaded. The first sentence states the purpose and output, followed by concise bullet-point usage guidance, sibling alternatives, and a source note. No wasted words; 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 search tool with many optional internal parameters, the description provides a solid high-level context: what it returns, when to use it, and its source. The output schema exists, so return-value details are not needed. It does not mention the internal filtering parameters (wholesaler_ids, source_resource_id, etc.) or caching behavior, but those are well-documented in the schema. Given the schema richness, the description captures the essential 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 0% and the description does not compensate. It only mentions searching 'by name' and returns 'registration states,' which loosely maps to the 'name' and 'state' parameters, but it ignores the many other params (rows, wholesaler_ids, source_resource_id, etc.). However, the input schema itself provides detailed descriptions for each parameter, which mitigates the lack of description-level guidance, so it is not a 1.

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?

Description uses a specific verb+resource ('Search SEC IAPD... for individual investment advisor representatives') and clearly distinguishes from siblings by explicitly naming SearchIAPDFirm and SearchBrokerCheck as alternatives for firm and broker/dealer lookups. It also states the tool is for individuals, not firms.

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 explicit 'Use this tool when' scenarios (individual advisor lookup, verify IA registration, due diligence) and explicitly states when NOT to use it ('For firm lookups, use SearchIAPDFirm instead; For broker/dealer individuals, use SearchBrokerCheck instead'). This is exactly the kind of when/when-not/alternatives guidance expected.

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 readOnly, idempotent, and non-destructive behavior. The description adds useful context: no API key required, source (GLEIF API), and global coverage (2M+ entities, 200+ jurisdictions). This goes beyond annotations without contradicting them, though it omits rate limits or pagination details.

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 well-structured with a clear lead sentence, a 'Use this tool when' list, and a source note. It is somewhat verbose (e.g., 'Cover 2M+ legal entities globally' is promotional), but generally every sentence earns its place and the key information is front-loaded.

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

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

For a read-only search tool with rich annotations and an output schema, the description covers the main purpose, return fields, use cases, and alternative tool. It lacks some operational details like pagination or error handling, but those are not critical given the schema and source note. Overall it is complete enough for an agent to select and invoke 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 0% — the tool description does not mention any parameter names or semantics. While the input schema has detailed descriptions for each field, the description itself fails to compensate for the low coverage, offering no guidance on using 'name', 'country', 'limit', or other params.

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: 'Search the Global Legal Entity Identifier Foundation (GLEIF) database for Legal Entity Identifiers (LEIs) by entity name.' It clearly states what the tool returns (LEI code, legal name, registration status, legal address, jurisdiction) and explicitly distinguishes from sibling GetLEIDetail by noting parent/subsidiary lookups belong there.

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 'Use this tool when' list covering four scenarios, including cross-referencing SEC EDGAR entities. It also names the alternative for parent/subsidiary relationships ('use GetLEIDetail'), giving clear when-to-use and when-not-to-use guidance.

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