Fintel Discovery — Financial Intelligence for AI Agents

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

Annotations already mark it read-only/idempotent, and the description adds meaningful extra behavior: the data source (SEC EDGAR 13F infotable XML), no-API-key requirement, one-record-per-position shape, and pagination via limit/offset with '_has_more'. This goes beyond the annotations and gives the agent realistic expectations about scale.

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

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

The description is front-loaded with the core purpose, then uses a compact bullet list for output fields, then a brief usage sequence. Every sentence adds operational value without repeating the annotations or schema; it is long but proportional to 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?

Given output schema exists and annotations carry the safety profile, the description covers the remaining essentials: source, workflow dependency, optional filtering, pagination behavior, and the meaning of each returned field. Nothing needed to call the tool correctly appears missing.

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

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

Although schema coverage is signaled at 0%, the description compensates by explaining the important query parameters: min_value_thousands with a concrete example, sort_by='value_desc', and limit/offset with the 3,000+ position warning. It also tells the agent where to obtain cik and accession_no, tying the parameters directly to usage.

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

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

The description uses a specific verb and resource: 'Fetch and parse the complete equity holdings table from a specific SEC 13F-HR filing.' It also distinguishes itself by framing this as Step 2 after SearchEdgar13F/GetEdgarCompanyFilings and by listing exactly the return fields, so an agent can recognize it as the parsed-position tool rather than the filing-search 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?

It provides an explicit when-to-use directive: 'PRIMARY USE: Step 2 of institutional holdings workflow. Obtain cik and accession_no from SearchEdgar13F or GetEdgarCompanyFilings, then call this tool.' It also gives concrete tuning guidance for filtering, sorting, and pagination, which is more than enough to route the agent correctly.

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 beyond annotations: the data is embedded as curated static reference, no API key is required, and the source is the 2023–2024 Kitces Research survey. This helps the agent understand the tool's behavior (no live query, no auth needed) 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 compact and front-loaded: the first sentence states the core purpose, followed by a bulleted list of categories, then the default behavior, source, and auth requirement. Every sentence earns its place, and the structure makes the tool's scope immediately scannable.

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

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

The description is complete for the tool's primary use case: retrieving benchmark data by category. It covers the default, the source, and the auth requirement. The output schema exists, so return values are documented elsewhere. The only gap is that the description doesn't mention the filtering/tracking parameters (wholesaler_ids, question_asked, etc.), but those are secondary for this tool and are documented 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?

Schema description coverage is 0%, so the description must compensate. It does so by explaining the 'category' parameter's options and default ('all'), and by listing the five category values. However, the description does not explain the other parameters (mcp_prompt_id, question_asked, wholesaler_ids, etc.), which are documented in the schema but not in the description. Since the description covers the primary parameter well but ignores the rest, a 4 is appropriate.

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

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

The description states a specific verb ('Return'), a clear resource ('Kitces Research advisor practice benchmark data'), and the target audience ('independent and RIA-affiliated financial advisors'). It enumerates five concrete metric categories, which distinguishes it from sibling tools that focus on tickers, filings, or fund data. The tool's purpose is unmistakable even without opening the schema.

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

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

The description gives clear context on what data is included and how to retrieve all categories at once ('Set category='all' (default)'). It also notes the data source and that no API key is required. However, it does not explicitly state when to use this tool versus alternatives or when not to use it, so it falls just 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 indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows this is a safe read operation. The description adds that data comes from Yahoo Finance and no API key is required, plus the return includes ratings and price targets. However, it doesn't describe pagination or limits on the history length or clarify if the tool filters by wholesaler by default, though the schema covers wholesaler_ids. Given the annotations, a 3 is appropriate.

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

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

The description is well-structured with a clear summary followed by bulletized use cases and a source note. It is concise and front-loads the core output. The only minor inefficiency is the trailing 'Source: Yahoo Finance' line which, while useful, could be integrated. Still, it earns its place by explaining data provenance.

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 a complex schema with many parameters, but many are optional and have defaults. The description focuses on the primary use case of fetching ratings/price targets. However, it doesn't mention the wholesaler_ids filtering or source_resource_id caching, which are advanced but present in the schema. Given the existence of a rich schema and output schema, the description is adequate for most agents to call the tool correctly. Could add a note on typical output format, but not critical.

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 extensive descriptions for parameters like symbol and wholesaler_ids, covering a high degree of detail. However, the schema coverage is reported as 0%, meaning the schema's descriptions are not counted? Actually the context says coverage 0%, but the schema text clearly describes each parameter. The description itself only mentions the core symbol and the upgrades/downgrades flag, but it does not add much beyond what the schema already provides. Since the schema descriptions are detailed, the description adds little, but with 0% coverage baseline would be 3. The description does mention the return of fromGrade/toGrade which param 'include_upgrades_downgrades' controls, providing slight enhancement.

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 analyst ratings, price targets, and upgrade/downgrade history. It distinguishes itself from siblings by its focus on analyst consensus (buy/sell/hold) and price targets, which none of the sibling tools (e.g., GetPriceHistory, GetTickerInfo) cover.

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 lists three 'Use this tool when' scenarios, such as checking Wall Street consensus or needing price target range. It also notes the data source (Yahoo Finance) and that no API key is required, setting clear expectations. However, it does not explicitly state when not to use it or name an alternative tool, but given the clear use cases, this is sufficient.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful context by naming FINRA BrokerCheck as the public API source and stating that no API key is required, but it does not disclose rate limits, error behavior, or data freshness.

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 front-loaded: the core purpose appears in the first sentence, followed by concise bulleted use cases and a brief source note. Every sentence contributes useful information 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?

For a read-only lookup tool with an output schema, the description covers the essential context: what the tool does, what data it returns, when to use it, and the data source. It does not mention limitations or error cases, but the output schema and annotations fill most remaining 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 clarifies that the CRD number is the key input and that it should come from SearchBrokerCheck, which adds meaning beyond the schema. However, the schema contains detailed descriptions for all parameters, and the tool description does not explain the additional generic parameters like wholesaler_ids or source_resource_id, so the description adds only modest value.

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: 'Retrieve the full FINRA BrokerCheck profile for one individual using their CRD number.' It also enumerates the returned content (employment history, exam qualifications, licenses, disclosures), making the tool's scope unambiguous and distinct from sibling search 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 provides an explicit 'Use this tool when' section with concrete scenarios and correctly points to SearchBrokerCheck as the source for the CRD. It does not explicitly state when not to use alternatives such as GetIAPDIndividualDetail, but the context is clear enough for an agent to route correctly.

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 useful behavioral context beyond annotations: the data source (Yahoo Finance via yfinance), that no API key is required, and that it returns date and amount/ratio for each event. 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: a clear first sentence, three focused use-case bullets, and a source note. Every sentence earns its place and the core purpose 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?

Given the output schema and annotations, the description covers the core usage well: what data is returned, when to use it, and the source. The main gap is that it does not clarify the period parameter or acknowledge the many unrelated-looking schema fields, though those are partially documented in the schema itself.

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 carries the burden of explaining parameters. It only mentions 'a ticker' and 'full history' and does not explain the period parameter, symbol format, or which of the many schema fields are actually relevant. The schema has nested descriptions, but the description itself 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?

The description opens with a specific verb and resource: 'Fetch the full history of cash dividends, stock splits, and combined corporate actions for a ticker.' This clearly distinguishes it from sibling tools like GetPriceHistory or GetEarningsHistory by naming the exact data domain.

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 covering dividend history, yield calculations, dividend growth research, and split verification. It does not name alternative tools or state when not to use it, but the context is clear enough for an agent to route correctly.

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 carry the safety profile (readOnlyHint=true, idempotentHint=true, destructiveHint=false), so the bar is lower; the description adds value beyond them by naming the data source (Yahoo Finance via yfinance), stating that no API key is required, and specifying the three output sections. Minor gaps like rate limits or data freshness are unaddressed, but nothing contradicts 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 core operation is front-loaded in the first sentence, followed by a compact bulleted usage list and a one-line output/source note. Every sentence earns its place; the three usage bullets are slightly redundant with one another but the overall structure is clean 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 the safety profile, the description provides what an agent needs: the returned sections, concrete use cases, and access requirements (no API key). It omits behavior like how limit defaults work, but the schema documents 'limit', so remaining gaps are minor for a straightforward read-only 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 adds no parameter-level guidance — it never mentions the symbol or limit fields. The nested EarningsParams schema does document symbol and limit well, which mitigates the low 0% coverage signal, and the usage bullets imply a ticker is the central input, but the description itself 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?

The opening sentence names a specific verb and resource — fetching earnings history (EPS actual vs estimate, surprise %) plus upcoming earnings dates with consensus estimates — which is concrete and actionable. It also mentions forward EPS estimates by quarter and fiscal year, making the scope precise enough to distinguish it from siblings like GetDividendsAndSplits, GetFinancials, or GetAnalystRatings.

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 (performance vs EPS expectations, next earnings date/consensus, surprise trends) that map directly to the tool's outputs. It does not name alternatives or state when not to use it, stopping short of the explicit exclusion guidance that would earn 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, and destructiveHint=false, so the safety profile is covered. The description adds value by stating 'Returns every filing on record' (comprehensive behavior) and 'No API key required' (auth requirement), which are useful disclosures beyond the structured metadata. It does not mention pagination or rate limits, but given annotation coverage, a 4 is appropriate.

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

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

The description is compact and front-loaded: the core action and return type come first, followed by bulleted use cases and a source note. No sentence is wasted, and the structure makes it easy for an agent to quickly grasp the tool's purpose and applicability.

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 has a single main parameter (CIK), an output schema exists, and annotations cover safety, the description is largely complete: it explains what is returned, how to find CIK, and that no API key is needed. The main omission is lack of detail on pagination or large result set handling, which could matter for 'every filing on record', but the output schema likely covers return structure. A 4 reflects this minor gap.

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

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

Schema description coverage is 0%, so the description must compensate for parameter details. The description only mentions CIK in passing, while the input schema contains several other parameters (wholesaler_ids, source_resource_id, etc.) that are entirely unaddressed. The CIK-specific detail in the schema (zero-padding, example) is not supplemented by the description. This is a clear 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 opens with a specific verb and resource: 'Retrieve all SEC filings for a company or institution using its CIK.' It explicitly names the returned fields (form type, date, accession number, description) and frames the scope as 'all filings', which distinguishes it from siblings like SearchEdgar13F. The title and description align perfectly.

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 gives concrete conditions: having a CIK, wanting full filing activity, tracking 13F/ADV/ownership history, and needing accession numbers. It provides clear context, but stops short of explicitly naming alternatives like SearchEdgar13F or stating when not to use this tool. Thus it earns a 4 rather than 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 mark the tool as read-only, idempotent, and non-destructive, so the description correctly focuses on extra behavioral detail: results are transposed with one row per reporting period, capped at 4 years/4 quarters, and the 'trailing' frequency is income-only. It also discloses the data source (Yahoo Finance) and that no API key is required, which covers authentication expectations.

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

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

The description is cleanly structured: purpose, output behavior, when-to-use bullets, compact option enums, then source attribution. Each block has a distinct job and there is no redundant filler, so the length is justified.

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 financial-data fetcher with an output schema, the description covers the essential surface: what statements can be retrieved, what frequencies and limits apply, the output orientation, and the source. The only minor gap is the lack of an explicit mention of the 'symbol' parameter, but that is easily inferred.

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, so the description must carry the parameter-semantics burden. It does a strong job for the two core knobs—'statement' and 'freq'—by listing their exact options and adding the TTM income-only constraint, but it never names 'symbol' explicitly, leaving that to be inferred from 'for a stock.'

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

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

Opens with a precise verb and resource: 'Fetch income statement, cash flow statement, or balance sheet for a stock,' which immediately distinguishes it from sibling tools such as GetPriceHistory or GetDividendsAndSplits. It also names the three statement types and the data scope, so an agent knows exactly what domain this tool covers.

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 dedicated 'Use this tool when' section gives concrete triggers (revenue, EPS, cash flow, CapEx, balance sheet ratios, fundamental analysis), which is strong explicit guidance. It does not state when not to use the tool or point to alternative sibling tools, so it stops short of a perfect 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, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds valuable behavioral context beyond annotations: the FRED_API_KEY requirement, the source attribution, and the fact that frequency aggregation is available via parameters.

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 front-loaded with the core purpose, followed by concise use-case bullets and parameter guidance. Every sentence earns its place, and there is no redundant restating of the tool name or title.

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

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

For a read-only fetch tool with an output schema and safety annotations, the description is largely complete: it covers purpose, usage context, key parameters, API key requirements, and source. It does not explain every schema field, but the core FRED workflow is sufficiently specified.

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

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

With schema description coverage reported at 0%, the description must compensate for parameter meaning. It does explain observation_start/observation_end and frequency, and implies series_id by referencing 'a specific economic series' and SearchFredSeries. However, it leaves limit, series_id as an explicit parameter name, and the many generic fin params (wholesaler_ids, source_resource_id, etc.) unexplained in the description itself.

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 also states the return shape ('date + value pairs with series metadata'), and explicitly routes users to SearchFredSeries when the series ID is unknown, distinguishing it from the sibling search tool.

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

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

The description provides a clear 'Use this tool when' list covering macro data needs, macro context, cross-period comparisons, and current indicator values. It also names SearchFredSeries as the alternative for unknown series IDs, though it does not explicitly list when-not-to-use cases against other 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 mark the tool read-only and idempotent; the description adds that it reads SEC EDGAR XBRL company facts, requires no API key, returns percentages, and may fail for funds that do not file rr: data. 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 front-loaded with purpose and workflow, uses a scannable bullet list for return fields, and ends with source and fallback. It is longer than minimal but every section earns its place; minor redundancy with the output schema 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?

For a read-only lookup tool with an output schema, the description covers the full invocation workflow: where CIKs come from, what the fields mean, how include_all_classes changes results, and what to do on failure. Nothing essential is missing.

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

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

The description explains the two behaviorally important inputs: CIK (source it from SearchFundsByCategory) and include_all_classes (share-class vs single-value behavior). It does not mention the generic plumbing params like wholesaler_ids or source_resource_id, but those are ancillary and the schema itself documents them.

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 ('Retrieve') and resource ('expense ratios and fee breakdown for a mutual fund or ETF using its SEC CIK'), then names the data source (SEC Risk/Return rr: taxonomy). This clearly separates it from siblings like GetFundProfile and SearchFundsByCategory.

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 fee comparison', tells the agent to feed it CIKs from SearchFundsByCategory, and prescribes ranking by net_expense_ratio. It also provides a fallback rule: if XBRL data is unavailable, use GetFundProfile. This is textbook when-to-use 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, covering the safety profile. The description adds meaningful context beyond these: 'Source: Yahoo Finance via yfinance. No API key required.' This informs the agent about external dependencies and setup requirements. It doesn't mention rate limits or error behavior, but given the annotations cover the main behavioral traits, a 4 is appropriate.

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

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

The description is longer than average but well-structured with clear bullet points and a logical flow: core purpose, use cases, section options, sibling differentiation, source. Every sentence adds information; there's no filler or tautology. It could be slightly more concise, but the structure earns a 4.

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 moderately complex with many optional parameters and an output schema defined. The description covers the primary scenarios, the distinction from stocks, and the data source. It doesn't explain every parameter, but the schema provides those details. The output schema covers return values. Everything an agent needs to decide whether and how to invoke the tool correctly is present, so a 4 is justified.

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 reports 0% schema description coverage (likely referring to the outer params object), each nested property in the schema has detailed descriptions (e.g., symbol examples, section options, wholesaler role explanations). The description text itself adds little beyond restating the section options ('overview', 'holdings', etc.), which are already in the schema. It does reinforce the ETF/mutual fund restriction, but that's also implied by the tool purpose. With such comprehensive schema descriptions, the description's value is marginal, hence a baseline 3.

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

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

The description states a specific verb ('Fetch') and resource ('ETF or mutual fund specific data') and outlines concrete data elements: top holdings with weight %, sector allocations, expense ratio, bond credit quality ratings, and equity style characteristics. It also distinguishes from sibling GetTickerInfo by explicitly saying 'For stocks, use GetTickerInfo,' so an agent can immediately tell them apart.

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:' block with four concrete scenarios (top holdings, sector breakdown, bond ratings, comparing fund profiles), and gives an explicit exclusion: 'Only works for ETFs and mutual funds. For stocks, use GetTickerInfo.' This is clear, actionable guidance on when to call it and what alternative to use instead.

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 useful context such as Yahoo Finance as the source, no API key required, and holder_type options, but it does not disclose return shape, data latency, or limits. This is acceptable given the annotations, but not rich.

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

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

The description is compact and front-loaded: purpose, use-case bullets, holder_type options, and source are covered in about five short lines. The bullets slightly restate the opening purpose, but there is no real fluff and the structure is 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?

For a read-only, idempotent fetch with an output schema present, the core use cases and source are covered. However, it does not differentiate from overlapping ownership-related siblings like Get13FHoldings or GetFundProfile, and it relies on the schema for symbol and filter details; with 0% reported schema coverage, that reliance makes it only partially 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?

Reported schema description coverage is 0%, so the description must compensate. It explicitly documents holder_type values ('institutional', 'mutualfund', 'insider', 'all') and the data source, but it never mentions the symbol parameter or the filtering/context parameters. This is partial compensation, not complete 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 opens with a specific verb-resource pairing: 'Fetch ownership data for a stock' and then lists concrete categories: top institutional holders, mutual fund holders, and insider transactions. This clearly distinguishes it from unrelated siblings like GetAnalystRatings or GetPriceHistory, and the mention of insider buys/sells makes the tool's unique scope explicit.

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

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

The 'Use this tool when' bullets provide clear trigger conditions: institutional ownership questions, insider activity checks, and ownership concentration analysis. However, it does not name sibling alternatives or say when not to use this tool, so it falls short of 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 establish idempotence and read-only safety. The description adds useful behavioral context beyond that: it is sourced from the SEC IAPD public API, requires no API key, and returns all Form ADV Part 1 fields. It does not discuss rate limits or error behavior, but the disclosures made are meaningful.

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 direct first sentence stating what the tool does, a concise list of use cases, and a short source/auth note. Every sentence earns its place, and the most important scoping 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?

Given an output schema, read-only annotations, and sibling context, the description provides enough to select and invoke the tool correctly. It covers purpose, expected return content, source, authorization requirements, and the prerequisite relationship to SearchIAPDFirm.

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 highlights the key parameter, crd, and tells the agent where to obtain it (from SearchIAPDFirm). However, it does not compensate for the remaining parameters such as wholesaler_ids, source_resource_id, exclude_fillers, or additional_display_fields, despite the reported low schema description coverage of the top-level 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 names a specific verb and resource: 'Retrieve the full Form ADV filing detail for one RIA firm by its CRD number.' It also enumerates the fields returned, such as client types, custody information, and affiliated entities, which clearly distinguishes it from sibling lookup/search tools like 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 contains explicit 'Use this tool when' bullets covering the main scenarios and names SearchIAPDFirm as the source of the required CRD. It does not explicitly say when NOT to use it versus alternatives such as GetIAPDIndividualDetail, so it stops just short of a full 5.

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

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

Annotations already carry the safety profile (readOnlyHint=true, idempotentHint=true, destructiveHint=false), so the bar is lower. The description adds value beyond this by disclosing what data is returned and the authentication reality ('No API key required', public SEC API). No contradiction with annotations exists—'Retrieve' and 'disclosures' align with read-only/idempotent semantics.

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?

Purpose is front-loaded, and every sentence earns its place: what it returns, three concrete usage triggers, and source/auth details. The when-to-use bullets are scannable and there is zero filler or repetition of schema content. Efficient and well-structured.

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

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

For a single-primary-input retrieval tool with a rich output schema and safety annotations, the description covers everything needed to call it correctly: the input requirement, the expected data, when to use it, and the data source plus auth. An output schema exists, so return value documentation is present, and the description complements rather than duplicates it.

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

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

Schema description coverage is 0% at the top level, but the nested $defs carry detailed property descriptions, mitigating the gap. The description adds real meaning for the primary parameter—it names the CRD, states it comes from SearchIAPDIndividual, and implies format via the example. However, auxiliary parameters (mcp_prompt_id, wholesaler_ids, source_resource_id, etc.) are not mentioned in the description at all, so the burden is not fully compensated for 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?

States a specific verb ('Retrieve'), a precise resource ('full SEC IAPD profile for one individual IAR'), and the key discriminator ('using their CRD number'). It also enumerates the return content (registration history, exam qualifications, employment history, disclosures). Unlike siblings, it is clearly individualized for a single IAR rather than a firm or a search, so an agent can distinguish it from GetIAPDFirmDetail and SearchIAPDIndividual with no schema inspection.

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 three explicit use-this-when bullets, including the crucial precondition ('You have a CRD from SearchIAPDIndividual') that routes the agent to the correct source tool. It stops short of naming when-not-to-use or pointing to the alternatives (e.g., SearchIAPDIndividual for name-based lookup), so exclusions are left implicit, but the guidance 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, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds valuable context beyond annotations by stating the source is the GLEIF API and that no API key is required, which are operational details an agent needs to know. It does not contradict 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 front-loads the core purpose, lists the returned data, then provides clear 'Use this tool when' bullets, and ends with source and authentication info. Every sentence adds value 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?

While the tool has an output schema (so return values need not be described), the description does not adequately address the parameter landscape. It provides clear usage scenarios and source info, but leaves the many optional parameters unexplained, which could confuse an agent about whether to include them. Given the schema complexity (multiple optional params), the description is not fully complete for correct invocation.

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

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

Schema description coverage is 0% per context signals, so the description must compensate for parameter guidance. It mentions the primary parameter (lei) with an example but completely ignores the other six parameters in the schema (mcp_prompt_id, question_asked, wholesaler_ids, exclude_fillers, source_resource_id, additional_display_fields, optional_additional_filters), many of which appear generic and irrelevant to this LEI lookup. The description does not clarify that only lei is needed and the rest are optional and likely unnecessary, leaving the agent unsure about what to pass.

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 the full GLEIF LEI record for one legal entity using a 20-character LEI code, and lists the specific data returned (legal name, status, addresses, LOU, renewal dates). It also distinguishes itself from sibling SearchLEI by explicitly referencing obtaining the LEI from SearchLEI, making its purpose unambiguous.

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

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

The description provides explicit 'Use this tool when:' conditions, such as having a LEI from SearchLEI, verifying registration status, or needing legal address/jurisdiction. This clearly guides when to use this tool versus searching or other alternatives, and it implies SearchLEI is the preceding search tool.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds useful behavioral context beyond those: it returns a flattened table, accepts multiple symbol formats, and identifies the data source as Yahoo Finance via yfinance with no API key required.

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 front-loaded: a crisp one-sentence summary, clear use-case bullets, a concrete symbols example, and a source note. Every sentence adds value without unnecessary repetition.

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

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

Given the annotations and output schema, the description covers the essential invocation details: purpose, symbol format, returned data shape, and data source. It could be more complete by explicitly steering single-ticker requests to GetPriceHistory, but it is still adequate for correct multi-ticker usage.

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 symbols parameter format and hints at OHLCV output, but the schema's parameter descriptions already cover symbols, dates, period, and interval. The nested schema contains many unrelated parameters (e.g., wholesaler_ids, exclude_fillers) that the description does not clarify or warn against, which could confuse an agent.

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

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

The description states a specific verb and resource: 'Fetch OHLCV price history for multiple tickers in a single call.' It also clarifies the output shape with example columns like 'AAPL_Close' and 'SPY_Volume', which helps distinguish it from single-ticker tools like GetPriceHistory.

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 lists use cases: comparing multiple securities, correlated price data, and correlation matrices. It does not explicitly mention when not to use it or name the single-ticker alternative, but the context is clear enough for an agent to choose this tool for multi-ticker needs.

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 by naming the data source (Yahoo Finance via yfinance), noting that no API key is required, and explaining the default behavior when expiry_date is omitted. It does not cover rate limits or error behavior, but those are less critical for a read-only, idempotent tool.

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, well-organized, and front-loaded with the core purpose before the usage bullets. Every sentence adds value: the first sentence defines the action, the second lists outputs, the bullets give when-to-use guidance, and the final lines provide prerequisite and data-source context without filler.

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

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

For a read-only, idempotent tool with an output schema and clear annotations, the description covers the main practical needs: what it returns, when to use it, how to get valid expiry dates, and what happens if expiry_date is omitted. The only notable omission is explicit guidance on how symbol is required or resolved, and the unrelated generic params are not clarified in the description.

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%, so the description must compensate. It does add meaningful behavior for expiry_date by explaining omitting it returns the nearest expiry, and it implies symbol through 'stock or ETF.' However, it does not explicitly describe the symbol parameter or explain the generic params object and its many fields, leaving a noticeable gap for an agent deciding what to pass.

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 immediately states the exact operation: fetch the full options chain (calls and puts) for one expiry date, and enumerates the returned fields. This clearly distinguishes it from sibling tools like GetOptionsExpirations, which only provides expiry dates, and from other market-data tools. The repeated phrase 'full options chain' plus the specific field list leaves no ambiguity about what the tool does.

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 use cases with a 'Use this tool when' bullet list and names GetOptionsExpirations as a prerequisite, which is strong contextual routing. It does not explicitly state when not to use this tool or name alternative tools for related tasks, so it falls just 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, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds useful context beyond annotations by naming the data source ('Yahoo Finance via yfinance') and stating 'No API key required,' which helps the agent understand access and operational expectations.

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

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

The description is compact, front-loads the core purpose in the first sentence, and uses short bullets for usage conditions. Every sentence earns its place, and there is no redundant restating of the tool name or title.

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

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

For a simple read-only expiry-date listing tool, the description covers the key context: what it does, when to use it, how it relates to GetOptionsChain, and the data source. An output schema exists, so the missing return-format details are not the description's burden; the only minor gap is that it doesn't warn that most parameters in the schema are irrelevant for this call.

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 0%, so the description must compensate for parameter semantics, but it only mentions 'a ticker' generically. It does not name the `symbol` parameter, clarify that most of the other schema fields are irrelevant to this tool, or explain expected formats. The schema itself contains some descriptions, but the description fails to bridge 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 opens with a specific verb and resource: 'List all available options expiry dates for a ticker.' It also distinguishes itself from the sibling tool GetOptionsChain by positioning itself as the step to run before requesting an options chain, so an agent can tell them apart immediately.

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

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

The description explicitly says 'Use this before calling GetOptionsChain' and provides a 'Use this tool when' section with concrete conditions: knowing which options contracts exist and needing an expiry date to pass into GetOptionsChain. This gives clear selection guidance without relying on inference.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful context: the source (Yahoo Finance via yfinance), no API key requirement, and specific interval limits (max 730 days for 1h, max 60 days for intraday). However, it does not describe error behavior, rate limits, or what happens on invalid tickers. Given the annotations cover safety, the description contributes some behavioral detail but not rich context, so a 3 is warranted.

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 efficient, starting with the core purpose and then listing usage conditions and key options. It is structured with a bullet-like 'Use this tool when' section and a clear list of interval/period options. There is minimal redundancy, and the most important information (what it does) is front-loaded. It earns a 4 for being concise and well-organized.

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 (many parameters, nested objects, output schema), the description covers the essential usage context: what it returns, when to use it, key interval/period limits, and source/authentication details. The output schema is present, so return format need not be described. The description does not mention error handling or rate limits, but these are not critical for an agent to invoke the tool correctly. It is complete enough for correct invocation, so a 4 is appropriate.

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

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

Schema description coverage is 0%, meaning the description text does not describe most parameters. The description does mention interval and period options, which maps to two of the many parameters, but it does not cover symbol, start, end, auto_adjust, actions, or the many filtering params. The schema itself provides descriptions for each parameter, so the agent still has structured guidance, but with low coverage the description should compensate more. It provides some value for interval/period but leaves others to the schema, so a 3 is fair.

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 ('Fetch') and resource ('OHLCV price history for one ticker'), which is clear and unambiguous. It does not explicitly name or differentiate from sibling tools like GetMultiTickerHistory, but the phrase 'for one ticker' implies the single-ticker scope, distinguishing it from multi-ticker alternatives. It is specific enough for an agent to understand the 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 includes a 'Use this tool when' section with three concrete conditions (historical price/volume data, performance analysis, returns/volatility/trend analysis). This provides clear context on when to invoke the tool, though it does not explicitly state when not to use it or name alternatives. It gives actionable guidance without exclusions, so a 4 is appropriate.

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

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the description does not need to restate safety. It adds useful behavioral context: the data source, required cenpy package, optional Census API key with rate-limited fallback, and the specific metrics returned. 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-organized into a lead sentence, a bulleted list of key metrics, a 'Use this tool when' section, and a brief requirements/source note. Every section earns its place and the most important scoping information is front-loaded. There is no filler or redundant explanation.

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 the core behavior, use cases, returned metrics, and external dependencies, and an output schema exists to define return values. It does not explicitly state that at least one of state or zip_code should be provided despite no required parameters, and it omits mention of internal parameters like wholesaler_ids and source_resource_id, but those are documented in the nested schema.

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

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

Schema description coverage is 0% at the top level, so the description must compensate. It names the two most important inputs conceptually ('ZIP code' and 'state') and discusses the API key, but it never maps these to the actual parameter names (zip_code, state, census_api_key) and does not mention the filter/cache/internal parameters at all. The nested schema has detailed property descriptions, so this is a partial rather than total 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 starts 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 clearly distinguishes this tool from sibling tools focused on ticker, fund, broker, or EDGAR data by naming the exact domain (Census territory wealth) and the intended use case (scoring territory opportunity for financial advisors).

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 with three concrete scenarios: scoring territory wealth by ZIP, comparing household income across territories, and overlaying wealth proxies with advisor AUM data. It does not explicitly state when not to use it or name alternatives, but the context is clear enough for an agent to select it 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=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds useful context beyond this: the data source (Yahoo Finance via yfinance), that no API key is required (auth requirement), and the breadth of returned metadata (60+ fields). This goes beyond what annotations provide, earning a 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 moderately long but well-structured: a clear front-loaded purpose sentence, a bulleted 'Use this tool when' section, a list of supported assets, and a source note. Every sentence adds value — no filler. It could be slightly tighter, but the organization 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 the tool's purpose, typical usage scenarios, supported asset classes, data source, and authentication requirements. It does not discuss return format, but an output schema exists (which is not shown here) and would cover that. It also doesn't mention limitations or when to prefer a sibling, but for a read-only metadata lookup, the provided context is sufficient for an agent to call it correctly.

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

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

Schema description coverage is 0% — the tool description does not mention any of the parameters (symbol, mcp_prompt_id, etc.). However, the description indirectly conveys the core parameter by listing supported symbols and asset classes (e.g., 'AAPL', 'BTC-USD'), which helps an agent infer what to pass for the 'symbol' field. The schema itself already documents each parameter, so the description's marginal addition is the asset-class guidance, not parameter syntax. This partially compensates for the low coverage, but not fully.

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 ('Fetch') and resource ('full Yahoo Finance profile'), enumerates the data returned (name, sector, industry, market cap, P/E ratio, 52-week range, beta, dividend yield, description, and 60+ other metadata fields), and distinguishes it from siblings by focusing on the profile/metadata aspect rather than history, ratings, or filings. It also lists supported asset classes, making the scope unmistakable.

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

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

The description provides explicit usage scenarios ('Use this tool when:') covering quick summaries, sector/industry classification, and price metadata needs. It also lists asset classes with examples. It does not explicitly state when NOT to use it or name alternatives (e.g., GetPriceHistory for historical prices), so it lacks exclusions, but the context is clear enough for an agent to route correctly.

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, covering safety. The description adds useful context: 'Source: Yahoo Finance via yfinance. No API key required.' It also implies return fields ('exchange and asset type'). However, it does not disclose rate limits, caching behavior, or potential external API availability issues, which are relevant for a network-backed lookup.

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 (purpose, usage, asset types, source) and uses bullet points effectively. Every sentence carries information, and the most important details are front-loaded. It is slightly verbose, but the 'Use when' list earns its place by guiding agent decision-making.

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 low-risk read-only lookup, the description covers purpose, usage scenarios, asset types, and authentication. It does not mention the optional caching/follow-up parameter (source_resource_id) or the tracking parameters (mcp_prompt_id, question_asked), but these are advanced and mostly irrelevant for the core lookup. The presence of an output schema also offloads return-value details, so the description is sufficiently complete for typical agent use.

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

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

The single top-level parameter 'params' has no description in the schema (0% coverage), so the description must compensate. It lists asset_type options and implies the query string, but does not explain the params structure or other schema fields like max_results, source_resource_id, or wholesaler_ids. This is minimal compensation for a parameter that is an object with many nested properties.

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 ('Search'), names the resource ('Yahoo Finance ticker symbol'), and states the input type ('by company name, fund name, or keyword'). It clearly distinguishes from siblings like GetTickerInfo (which assumes a known ticker) and other search tools by focusing on name-to-symbol resolution.

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 when' section with three concrete scenarios and the general rule 'you have a name but need the ticker symbol.' It provides clear context but does not state when not to use the tool or name a preferred alternative, so it stops short of a full 5.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds useful operational context beyond annotations: it names the external OpenFIGI service, states that no API key is required, and notes that an optional key raises rate limits. This is meaningful behavioral disclosure.

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

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

The description is well-structured with a clear opening, bulleted use cases, a supported-values list, and a source note. It is slightly longer than necessary and repeats some schema content, but every section contributes useful guidance and the main purpose 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?

Given the output schema and annotations, the description covers the core use cases, supported ID types, exchange targeting, and API key/rate-limit context. It relies on the schema for optional mapping fields and generic parameters, which is acceptable, but it does not mention alternative sibling tools or when not to use this tool.

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

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

The schema already documents the mappings structure, idType options, and examples, so the description's idType list is partially redundant. The description does add the exchCode 'US' targeting hint and clarifies the no-API-key requirement, but it omits ID_COMMON and ID_WERTPAPIER, which the schema lists as supported values.

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

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

The description clearly states a specific verb and resource: 'Map financial instrument identifiers between different ID systems using Bloomberg's OpenFIGI service' and lists the concrete conversions (ticker, ISIN, CUSIP, FIGI). It is clear and specific, though it does not explicitly differentiate itself from sibling tools like SearchFigiInstruments or 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 description provides an explicit 'Use this tool when' section with three concrete scenarios, including normalizing IDs across EDGAR/Yahoo Finance and identifying exchanges. It gives clear context but does not mention exclusions or when a sibling tool would be preferable.

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?

With readOnlyHint, idempotentHint, and destructiveHint all set, the safety profile is already established by annotations. The description adds valuable context beyond that: it states the data source is the 'FINRA BrokerCheck public API' and that 'No API key required,' plus the return fields include CRD and disclosure status, which are useful behavioral details not present in 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 longer than the minimal ideal, but every section earns its place: use-case bullets, a geographic workflow, and a source note. It is well-structured and front-loaded with the core action and returned fields before the workflow details, with only minor redundancy around the word 'registered.'

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 what the tool returns, when to use it, the sequential workflow with sibling tools, the narrow-by-state option, and the follow-up GetBrokerCheckDetail route. With an output schema present and annotations covering safety, nothing essential is missing for an agent to select and invoke this tool correctly.

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

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

The description only adds meaning for the optional 'state' parameter ('2-letter code') and implies name-based search, while the schema itself carries detailed descriptions with examples for name, rows, start, state, filters, and more. Given the context signal reports 0% schema description coverage at the top level, the description does not fully compensate for the nested 'params' wrapper, but the nested schema fills most gaps, so a baseline 3 is appropriate.

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

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

The description's first sentence states a specific verb and resource: 'Search FINRA BrokerCheck for registered individual brokers and financial representatives by name.' It also lists the exact returned data (CRD number, current firm, registration status, disclosures) and explicitly distinguishes itself from SearchBrokerCheckFirm and GetBrokerCheckDetail, so an agent can tell it apart from siblings.

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

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

The 'Use this tool when' section lists concrete conditions (find CRD number, verify registration, enrich missing CRD) and the geographic workflow maps the sequence of sibling tools, ending with 'use this tool to find individuals at that firm.' It also directs users to GetBrokerCheckDetail for the full profile, giving clear when-to-use and alternative routing.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds useful context beyond annotations: it names the data source (FINRA BrokerCheck public API), states that no API key is required, and specifies the return fields. It doesn't describe pagination or rate limits, but those are covered by schema parameters. The description complements rather than contradicts 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 first sentence stating the core function, followed by a concise 'Use this tool when' list. It includes the source and API key note at the end. No redundant sentences; every part earns its place. The format is scannable 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?

The description specifies the return fields (CRD, status, city, state, disclosure flag) and the source. An output schema exists (though not shown), which likely details the return structure. The tool has many parameters, but they are documented in the schema. The description does not mention rate limits or error handling, but for a read-only search tool with an output schema, the provided information is sufficient for an agent to call it correctly.

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

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

The tool's own description does not mention any parameters, but the schema's nested properties (name, rows, start, state, etc.) have rich descriptions with examples. The top-level 'params' property lacks a description, and the signal reports 0% schema description coverage for the top-level wrapper. However, the inner schema descriptions are comprehensive, so the description adds little beyond what the schema already documents. Baseline 3 applies because schema covers the parameters.

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

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

The description states a specific verb ('Search'), resource ('FINRA BrokerCheck'), and target ('broker-dealer firms by name'). It clearly distinguishes from siblings like SearchBrokerCheck (likely broader) and GetBrokerCheckDetail by specifying firm-level search. The phrase 'Returns firm CRD, registration status, city, state, and disclosure flag' reinforces 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 'Use this tool when' section with three concrete scenarios (needing CRD, distinguishing similar firms, building territory maps). It provides clear context but does not explicitly state exclusions (e.g., 'for individuals, use SearchBrokerCheck'). Still, the guidance is actionable and well-aligned with the tool's purpose.

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

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

Annotations already cover read-only/idempotent/non-destructive behavior, and the description adds useful context: the source is the SEC EDGAR full-text search API, no API key is required, and searches are by institution name with date-range filtering. It doesn't disclose possible search-result limitations or pagination, but the annotation coverage lowers the bar.

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-organized and front-loaded: purpose, return fields, regulatory context, usage bullets, date format, and source/auth are each given one short section. Every sentence adds information and there is no filler.

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

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

For the core use case the description is complete: it explains what the tool does, what it returns, when to use it, the input format for dates, and the data source. An output schema exists, so return values don't need to be enumerated. It doesn't address advanced cached-result or internal-filter behavior, but those are documented in the schema and are not essential to primary usage.

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

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

With schema description coverage reported at 0%, the description must compensate. It adds meaning for the core parameters by explaining the query is an institution name and that start_date/end_date use YYYY-MM-DD. However, it leaves the many fin-specific parameters (wholesaler_ids, source_resource_id, exclude_fillers, additional_display_fields, etc.) entirely to the schema, so the compensation is only partial.

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: 'Search SEC EDGAR for 13F-HR institutional holdings filings by institution name.' It also names the exact return fields (filing date, entity name, period of report, accession number), which sharply distinguishes it from siblings like Get13FHoldings or GetEdgarCompanyFilings.

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 concrete scenarios such as researching an institution's investment strategy or getting a list of 13F filings for a manager over a date range. It does not name sibling alternatives or give when-not-to-use guidance, so it stops just 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 read-only, idempotent, and non-destructive behavior. The description adds context beyond those annotations: it identifies the external source, states that no API key is required, and notes the optional-key rate-limit effect. There is no contradiction with 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 front-loaded with the core statement, uses scannable bullets for usage guidance, and closes with a concise source/auth note. Every sentence adds distinct value and nothing feels redundant.

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

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

For a search tool with an output schema and safety annotations, the description covers selection cues, result contents, the relevant sibling, and auth considerations, so return values need no restatement. It does not discuss optional filters or empty-result behavior, but the schema and annotations cover much of that residual need.

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

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

Given the 0% schema description coverage, the description should compensate, but it only contextualizes the search query concept ('by name or keyword') and says nothing about the wrapper `params` object or meaningful options such as `limit`, `exchange_code`, `security_type`, or `source_resource_id`. The nested schema definitions contain details, but the tool description itself adds minimal 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?

States a clear verb ('Search'), resource ('Bloomberg OpenFIGI'), subject ('financial instruments'), and explicit scope ('by name or keyword'), then lists returned identifiers. It also names MapInstrumentIds as the sibling to distinguish from, so an agent can tell them apart.

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 concrete conditions, and an explicit when-not with the alternative: 'Use MapInstrumentIds instead if you already have a specific ID to convert.' This is direct routing guidance.

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

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

Annotations already cover readOnlyHint and idempotentHint, so the safety profile is known. The description adds context about the data source (FRED), the exact return fields (series ID, title, frequency, units, seasonal adjustment, date range), and the API key requirement, providing value beyond 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 well-structured with a clear opening sentence, bullet points for usage, and a list of common series IDs. It is somewhat verbose but each section adds value, and it front-loads the core purpose effectively.

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, and the description also lists the return fields. It covers the API key requirement, provides usage guidance, and gives examples. For a search tool with a rich schema, the description is sufficiently complete for an agent to call it correctly.

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

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

The input schema provides detailed descriptions for all parameters (limit, query, order_by, etc.), so the baseline is 3. The description adds example queries and common series IDs but does not significantly extend parameter semantics 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 clearly states the verb (Search) and resource (FRED database) and lists the return fields. It differentiates from the sibling GetFredSeriesData by framing its purpose as finding series IDs before fetching data, making it unambiguous.

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

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

The description explicitly lists when to use the tool (finding series IDs, discovering macro data) and points to the alternative GetFredSeriesData for fetching data after a series is found. It also gives concrete topic examples, leaving no ambiguity about 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, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds non-obvious behavioral context on top: results are 'de-duplicated by CIK (one record per fund filer)', 'No API key required', and the data source is 'SEC EDGAR full-text search API'. These are traits an agent cannot infer from annotations or the tool name, and there is no contradiction with the read-only hints.

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 front-loaded: a purpose sentence, a bolded PRIMARY USE callout, a compact indented example block, then behavior notes and source attribution. It is longer than the minimal two-sentence style, but the length is justified by the domain complexity and the 12-parameter surface; each section earns its place with minimal 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?

For a tool that has an output schema and rich annotations, the description covers everything needed for selection and correct invocation: purpose, workflow position, return fields, de-duplication behavior, date filtering, source, and authentication requirements. Minor gaps keep it from a 5 — the params wrapper object is implied rather than stated, and max_results sizing guidance lives only in the nested schema rather than in the description.

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

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

With schema_description_coverage at 0% at the top level, the description must compensate, and it does partially: the example block teaches the two most important parameters with concrete value→outcome mappings ('keywords='commodity', fund_type='etf'' → 'commodity ETF universe'), and it mentions date filtering. However, start_date/end_date syntax, max_results behavior, and the internal parameters (wholesaler_ids, source_resource_id, mcp_prompt_id) are left entirely to the nested $defs descriptions, which carry most of the semantic load.

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

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

The description leads with a specific verb+resource scope: 'Search SEC EDGAR for mutual fund and ETF filers by investment category or keyword', names the exact filing forms queried (N-1A, 485BPOS, N-2), and states the return fields (entity name, CIK, form type, filing date). It also positions the tool within a workflow relative to sibling tools like GetFundFees, so an agent can distinguish it from the other search siblings without opening schemas.

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

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

The 'PRIMARY USE' section explicitly says when to invoke this tool — 'Step 1 of fee comparison' — and names the downstream step: 'Feed the returned CIKs directly into GetFundFees to retrieve expense ratios'. This is clear workflow guidance with a named sibling. It stops short of explicit exclusions (e.g., use LookupTicker for a known symbol, or go straight to GetFundFees when CIKs are already in hand), which keeps it at a 4 rather than 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, and destructiveHint=false, so the safety profile is covered. The description adds valuable context: it notes the source is the SEC IAPD public API, no API key is required, and it covers RIAs registered with the SEC. It also clarifies the scope (registered with SEC) and the workflow relationship to other tools. It doesn't describe pagination or rate limits, but the annotations plus source/scope context make this a strong 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 with a clear opening sentence, bullet-point usage guidance, a workflow note, and a source note. Every sentence earns its place, and the most important information (what it does, what it returns) is front-loaded. It's appropriately sized for 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?

The tool has an output schema, so return values don't need to be described. The description covers the source, authentication (no API key), scope (SEC-registered RIAs), and workflow relationships. It doesn't mention pagination or result limits, but for a search tool with an output schema and clear annotations, this is nearly complete. A 4 is warranted rather than 5 because the description doesn't address what happens with partial matches or how many results are returned.

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 compensate. The description explains the primary parameter (name) by stating the tool searches 'by name' and gives examples in the schema ('Vanguard', 'Fidelity Investments'). However, the description doesn't explain the other parameters (mcp_prompt_id, question_asked, wholesaler_ids, exclude_fillers, source_resource_id, additional_display_fields, optional_additional_filters), which are documented only in the schema. Since the schema itself provides detailed descriptions for those, and the description covers the core search parameter, a 4 is appropriate.

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

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

The description clearly states the tool searches the SEC IAPD database for RIA firms by name, and lists the specific return fields (CRD, registration status, AUM, employee count, state, office city). It also distinguishes itself from sibling tools like SearchBrokerCheckFirm and GetIAPDFirmDetail, making its purpose unambiguous.

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

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

The description provides explicit when-to-use guidance: when you need CRD or AUM for a named RIA firm, when looking up Form ADV data, and when distinguishing RIA firms vs BD firms. It also names alternatives (SearchBrokerCheckFirm for broker-dealers, GetIAPDFirmDetail for full ADV data) and describes a geographic workflow with SearchBrokersByPlace. This is exemplary usage 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, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds valuable context: it identifies the data source as a public API and states that no API key is required, which is behaviorally relevant for an agent deciding on authentication. Minor omissions like rate limits are not critical given the annotations.

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

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

The description is well-structured with a clear opening, bullet-point usage guidelines, and explicit alternative routing. It is concise, front-loads the core purpose, and every sentence serves a purpose 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, the description need not explain return formats. It covers the core functionality, usage scenarios, and alternatives. The schema documents parameters thoroughly. The only minor gap is the lack of mention of pagination or rate limits, but these are not essential for correct invocation given the annotations and 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 description does not discuss parameters at all, but the input schema contains detailed descriptions for every property (name, rows, state, etc.), including examples and notes. Since schema description coverage is effectively high, the description need not compensate; the schema carries the load, so a baseline score of 3 is appropriate.

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

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

The description clearly states the tool searches SEC IAPD for individual investment advisor representatives by name, listing specific return fields (CRD number, employer, registration states, exam history). It explicitly differentiates from sibling tools (SearchIAPDFirm, SearchBrokerCheck), making the purpose unambiguous.

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

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

The description provides explicit when-to-use conditions (look up individual advisor, verify IA registration, due diligence) and names the alternative tools for firm lookups and broker/dealer individuals. This directly addresses selection criteria without leaving inference to the agent.

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 behavioral context: it names the upstream source (GLEIF API), states that no API key is required, and lists the returned fields. It does not mention rate limits or pagination, but the annotations lower the bar and the added context is meaningful.

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 source line. Some background details (MiFID II, EMIR, Dodd-Frank, 2M+ entities) are not strictly necessary for invocation, but they are brief and do not obscure the actionable guidance.

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, when to use, the alternative tool, source, and authentication requirements. An output schema exists, so return-value details are not required. It does not mention the limit/country parameters or pagination, but the core search workflow is fully described and the annotations cover safety.

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 compensate for parameter meaning, but it only mentions searching 'by entity name.' It does not explain the limit, country filter, or the many nested tracking/filtering parameters inside the params object. The description adds minimal parameter semantics beyond what the schema already provides.

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

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

The description uses a specific verb ('Search') and resource ('GLEIF database') and clearly states the input (entity name) and output fields (LEI code, legal name, registration status, legal address, jurisdiction). It also distinguishes itself from GetLEIDetail by explicitly naming that sibling for parent/subsidiary lookups, so an agent can tell them apart.

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 covering common scenarios and names GetLEIDetail as the alternative for parent/subsidiary relationships. This gives clear selection guidance beyond what the schema or annotations convey.

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