Fintel Discovery — Financial Intelligence for AI Agents

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

Annotations already declare readOnlyHint and idempotentHint, and the description adds meaningful behavioral context: it parses SEC EDGAR Archives 13F infotable XML, requires no API key, returns one record per position, and exposes pagination via _has_more. No contradiction with the annotations exists.

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 a purpose statement, a return-field list, and a usage section. It front-loads the most important context and every paragraph adds practical value. Minor redundancy exists with schema parameter descriptions, but overall it earns its length.

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 supplies the critical selection context: where identifiers come from, how the parsed result is shaped, how to filter and paginate, and the data source. It is complete for a fetch/parse tool, though a few auxiliary parameters receive no contextual guidance beyond 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 reported as 0%, so the description must carry the parameter semantics burden. It does explain cik, accession_no, min_value_thousands, sort_by, limit, and offset with examples and thresholds, but it does not cover several auxiliary parameters such as source_resource_id, wholesaler_ids, exclude_fillers, or additional_display_fields, leaving those to the schema or external conventions.

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 and parse the complete equity holdings table from a specific SEC 13F-HR filing.' It also lists the exact output fields and frames the tool as Step 2 of an institutional holdings workflow, which clearly distinguishes it from search/discovery siblings like SearchEdgar13F and 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 explicitly says this is the primary Step 2 tool and directs the agent to obtain cik and accession_no from SearchEdgar13F or GetEdgarCompanyFilings before calling it. It also gives concrete guidance on filtering, sorting, and pagination. It does not explicitly state when not to use the tool versus alternatives, but the 'PRIMARY USE' framing makes the intended context clear.

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

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

The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable behavioral context beyond those annotations: the data is 'embedded as curated static reference', no API key is required, and the data source is the 2023–2024 Kitces Research survey. This meaningfully informs an agent that this is a deterministic, non-live dataset.

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 scannable, with a clear first sentence followed by a bulleted category list. Each sentence adds information: scope, categories, default behavior, source, and authentication requirement. There is minor redundancy with the title and the source repeating part of the schema description, but overall it is appropriately sized.

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 static-data tool, the description covers the essential invocation details: what data is returned, what categories exist, how to use the default, where the data comes from, and that no API key is needed. The output schema exists and the annotations cover safety-related traits, so return-value and mutation details do not need to be described. The only notable gap is the lack of guidance on whether the various generic filtering/tracking params are applicable.

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 add useful meaning for the primary category parameter by stating the default value and that category='all' retrieves all categories at once. However, schema description coverage is 0%, and the description does not address the several other parameters present in the schema, such as wholesaler_ids, exclude_fillers, source_resource_id, and additional_display_fields. An agent is left unsure whether those filter-style parameters apply to this static benchmark dataset.

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

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

The description opens with a specific verb and resource: 'Return Kitces Research advisor practice benchmark data for independent and RIA-affiliated financial advisors.' It then enumerates five concrete metric categories, which makes the tool's scope immediately clear. This also cleanly differentiates it from all sibling tools, which target holdings, filings, prices, and other market/firm data rather than advisor practice benchmarks.

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 about what data is available, lists the five categories, and explicitly explains the default behavior of category='all'. It does not explicitly name alternatives or state 'use X instead,' but the specificity of the benchmark domain makes the intended usage obvious relative to the sibling tools. This is clear context without exclusions.

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

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

Annotations already establish readOnlyHint, idempotentHint, and non-destructive behavior. The description adds useful context beyond those: the data source (Yahoo Finance via yfinance), the fact that no API key is required, and the specific data elements returned. This is transparent and helpful without contradicting any annotation.

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 capability, followed by scannable use-case bullets and a short source note. Every sentence earns its place; it is slightly longer than strictly necessary but remains efficient 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?

The description covers purpose, when to use, data source, authentication expectation, and the main output categories. An output schema exists, so return-value detail is not required. The main gap is that all params are optional and the description does not clarify what happens when symbol is omitted, but the schema's parameter descriptions largely fill that 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 should compensate by explaining key parameters like symbol and include_upgrades_downgrades. It does not: it mentions output fields such as fromGrade and toGrade but never tells the agent which parameter controls the history toggle or how to specify the target stock. The input schema documents parameters well, but the description itself adds no parameter-level 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 ('Fetch') and a precise resource: analyst buy/sell/hold consensus ratings, price target ranges, and the full upgrade/downgrade history with firm and grade details. This distinguishes it clearly from sibling market-data tools like GetPriceHistory or GetTickerInfo.

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

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

The description includes a dedicated 'Use this tool when' section with three concrete scenarios: current Wall Street consensus, price target upside/downside, and tracking rating changes. It does not explicitly name alternatives or exclusion cases, so it stops short of a 5.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds genuine behavioral context beyond that: the data source ('FINRA BrokerCheck public API') and 'No API key required,' which together set auth and provenance expectations. Rate-limit or latency behavior is not disclosed, but for a non-destructive, idempotent read that gap is minor.

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

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

The description is compact and front-loaded: purpose sentence, return-content sentence, bulleted usage triggers, then a source/auth footer. Every sentence earns its place — bullet 2 reuses return-content themes but reframes them as a decision trigger, so even the mild overlap is functional. The structure makes decision-relevant information immediately visible.

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

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

With an output schema present and safety annotations complete, the description covers the core invocation path fully and adds source and auth context. The main weaknesses are the absence of when-not-to-use guidance and a mild coherence issue: several schema parameters (wholesaler_ids, mcp_prompt_id) describe an internal 'fin' user-role system that sits oddly next to the 'public API, no API key required' framing. Still, none of these parameters are required, so correct invocation with just a CRD is fully supported.

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 identifies CRD as the key input and its provenance ('from SearchBrokerCheck'), and clarifies that it targets one individual, which helps invoke the tool correctly. However, the schema itself already documents crd with nearly identical guidance, so the description adds modest value; the remaining parameters (wholesaler_ids, exclude_fillers, etc.) are documented only in the schema, never in the description. Although the context signal reports 0% schema coverage at the top level, the nested properties are themselves richly described, so the schema carries most of the parameter-semantics burden.

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 enumerates returned content (employment history, exam qualifications, licenses, disclosures), and the 'one individual' scope plus 'FINRA BrokerCheck' qualifier separates it from firm-level and IAPD sibling tools. It also explicitly ties to SearchBrokerCheck, distinguishing detail-fetch from search.

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

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

A dedicated 'Use this tool when' section gives three concrete triggers: having a CRD from SearchBrokerCheck, needing employment/qualification data, and performing individual due diligence. It does not explicitly state when not to use it or name excludable alternatives (e.g., GetIAPDIndividualDetail for SEC profiles), but the when-to conditions are specific enough to route an 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 mark the tool readOnly, idempotent, and non-destructive. The description adds useful behavioral context beyond those flags: it identifies Yahoo Finance/yfinance as the source, states that no API key is required, and clarifies that the result is a full event history with date and amount/ratio. It does not discuss data freshness or rate limits, but for a read-only fetch the disclosure is adequate.

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

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

The description is front-loaded with the core action and return shape, followed by a compact three-bullet usage list and a source line. Every section earns its place, and there is no redundant restating of the title or schema.

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

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

Given the output schema exists and the annotations cover the safety profile, the description supplies the essential selection and invocation context: what data is returned, when to use it, the source, and auth requirements. It is not missing anything critical, though it could briefly mention limitations such as data being from Yahoo Finance rather than an official exchange source.

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 at 0%, so the description carries the burden of explaining parameters, but it only loosely hints at them with 'for a ticker' and 'full history.' It does not explain the period options, the symbol requirement, or the many nested fields inside the params object. The input schema itself has some property descriptions, but the description adds little independent 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 statement: 'Fetch the full history of cash dividends, stock splits, and combined corporate actions for a ticker.' It also names the returned fields (date, amount/ratio), so an agent can distinguish this from price, financial, or filing tools 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 provides a concrete 'Use this tool when' list covering dividend history, yield inputs, dividend growth research, and split verification. It does not explicitly state when not to use it or name alternative tools, but the guidance is clear enough for selection in most 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 and idempotentHint=true, so the read-only nature is covered. The description adds useful behavioral context beyond annotations: the Yahoo Finance/yfinance source, that no API key is required, and that the response is split into three named sections. No contradiction exists.

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: one clear functional sentence, a bulleted 'Use this tool when' list, a one-line output summary, and a source note. Every sentence earns its place 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?

The description is strong for tool selection and explains the source, output sections, and no-key requirement. However, it gives no guidance on how to populate the params object, and with a top-level schema coverage of 0% and many unrelated fields in the nested schema, an agent lacks enough invocation support.

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

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

The description mentions no parameter names, formats, or required inputs. Context reports 0% schema description coverage, so the description must compensate for the nested params schema, and it does not; the agent is left to infer that symbol and limit are the relevant fields among many unrelated ones like wholesaler_ids and exclude_fillers.

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 earnings history (EPS actual vs estimate, surprise %) and upcoming earnings dates with consensus estimates,' and adds forward EPS estimates. This clearly distinguishes it from sibling tools like GetFinancials or GetAnalystRatings, which do not target earnings estimates and dates.

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 performance vs EPS expectations, next earnings date/consensus, and surprise trend analysis. It does not name alternatives or state when not to use the tool, so it stops short of a 5.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds useful behavioral context beyond those annotations: it states the data source (SEC EDGAR API), that no API key is required, and that the tool returns every filing on record. It does not cover rate limits 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-structured and front-loaded with the core action, followed by concrete use cases, a CIK lookup link, and source/authentication notes. There is slight overlap between 'tracking all regulatory disclosures' and the later 13F/ADV bullet, but no significant waste.

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 API-backed tool, the description provides enough context to select and invoke it: it names the required domain identifier, shows where to find it, explains the returned data, and notes that no API key is needed. An output schema exists, so return-value documentation is not the description's burden. Minor gaps include no explicit mention of rate limits or pagination.

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 nested schema already documents the parameters in detail, including CIK formatting and zero-padding. The tool description adds some context around CIK usage and the return of accession numbers, but it does not meaningfully expand on the parameter semantics beyond what the schema provides. Baseline 3 is appropriate because the schema carries the parameter documentation burden.

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: 'Retrieve all SEC filings for a company or institution using its CIK.' It also clarifies the returned content (form type, date, accession number, description) and the all-filings scope, which distinguishes it from more targeted siblings like SearchEdgar13F or Get13FHoldings.

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 this tool when' scenarios: having a CIK, tracking 13F/ADV/ownership disclosure history, and needing accession numbers. This provides clear when-to-use guidance, though it does not explicitly name alternative tools or state 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 declare readOnlyHint, idempotentHint, and destructiveHint, so the description adds useful behavior beyond those: up to 4 years of annual data or 4 quarters of quarterly data, transpose orientation, TTM income-only restriction, and the Yahoo Finance/yfinance source with no API key. This is solid additional context, though edge cases like missing data or invalid symbols are not covered.

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

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

The description is well-structured, scannable, and front-loaded with purpose and return shape before usage guidance, options, and source. Every sentence provides value, there is no filler, and the bullet format makes the when-to-use cases easy to parse.

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 fetch tool, the description is largely complete: it states what data is returned, the available statement and frequency options, the output orientation, and the data source. Since an output schema exists, return-value details need not be in the description. It loses a point because it does not map the core inputs (especially symbol) explicitly or clarify which of the many unrelated-looking schema fields are meaningful, so an agent must infer some invocation details from the schema.

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

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

The description provides literal options for statement ('income', 'cashflow', 'balance') and freq ('yearly', 'quarterly', 'trailing') and notes that trailing is income-only, which is genuinely useful. However, with schema description coverage reported as 0%, it only partially compensates: 'symbol' is implied but not described, and the many financial-platform parameters in the schema (wholesaler_ids, source_resource_id, additional_display_fields, etc.) are left unexplained, which could confuse an agent inspecting the params object.

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 income statement, cash flow statement, or balance sheet for a stock.' It names the three statement types explicitly, which makes the tool's purpose unambiguous and helps distinguish it from siblings like GetPriceHistory, GetDividendsAndSplits, or GetEarningsHistory.

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

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

The description includes a dedicated 'Use this tool when' section with concrete fundamental-analysis scenarios such as needing revenue, net income, EPS, operating margins, cash flow from operations, CapEx, and liquidity ratios. It gives clear context but does not explicitly name when-not-to-use conditions or alternative sibling tools, so it stops short of a 5.

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

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

Annotations already declare readOnly, idempotent, and non-destructive hints, so the description does not need to re-litigate safety. It adds meaningful context beyond those hints by stating the required FRED_API_KEY environment variable, the data source, and the response format of date/value pairs plus series metadata. Rate limits and error behavior are not mentioned, but this is a read-only data fetch with solid annotation coverage.

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 lead sentence, a bulleted use-case list, parameter hints, and an environment requirement. It is slightly longer than necessary because the four bullets overlap in meaning, but every section adds useful operational context.

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 gives the important operational details: what data to expect, when to use the tool, which parameters matter most, and the API key requirement. However, it does not address the limit default, the max observation count, the odd mix of unrelated schema parameters, or possible failure modes. Since an output schema is available, the return-value gap is reduced, but the schema's confusing parameter surface leaves some ambiguity.

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 carry the burden of explaining parameters, but it only mentions observation_start, observation_nd, and frequency. It does not clarify the limit parameter, date-format expectations, or the large set of fin-specific fields present in the schema such as wholesaler_ids, exclude_filers, source_resource_id, and optional_additional_filters. The description covers the core FRED parameters but leaves many schema fields unexplained.

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

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

The description clearly states a specific action and resource: 'Fetch time-series observation data from FRED for a specific economic series.' It distinguishes itself from the sibling tool SearchFredSeries by explicitly instructing agents to use SearchFredSeries first when the series ID is unknown. The return shape is also previewed, which makes the tool's purpose immediately 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 an explicit 'Use this tool when' list covering macro data, advisor/fund context, time-period comparisons, and current indicator values. It also gives a clear conditional routing instruction: use SearchFredSeries first if the series ID is unknown. This is sufficient guidance for an agent to decide when to invoke this tool versus the main sibling.

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

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

Annotations already carry readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered and the bar is lower. The description adds genuinely useful behavior beyond annotations: the data comes from SEC EDGAR XBRL company facts with no API key, all values are expressed as percentages (including the 0.03 = 0.03% example), include_all_classes changes row cardinality, and the rr: taxonomy coverage caveat is disclosed. Minor gap: no rate-limit or error-shape detail, but this is modest for a read-only 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 long but deliberately structured: a field bullet list, a 'PRIMARY USE' block, an include_all_classes explanation, a fallback note, and a source line. It is front-loaded with the verb+resource in the first sentence, and each section adds information an agent needs. It is slightly longer than the minimum, but the length is justified by the tool's nuance rather than padding.

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 tool with rich annotations and an output schema, the description covers everything needed to select and invoke it correctly: return fields with units, workflow position, input provenance, share-class behavior, data-availability caveat, fallback path, source, and authentication requirement ('No API key required'). There is no material gap for an agent to trip on.

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 at 0%, so the description must compensate for parameter meaning. It does for the two tool-specific parameters: CIK is contextualized as the output of SearchFundsByCategory, and include_all_classes is explained with concrete behavioral consequences (one row per share class per period vs. single most recent value). The generic plumbing parameters (wholesaler_ids, source_resource_id, exclude_fillers, etc.) are not covered in the description, though they carry detailed schema descriptions of their own.

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 expense ratios and fee breakdown for a mutual fund or ETF using its SEC CIK,' and identifies the data source (SEC XBRL rr: taxonomy). It differentiates from the 30+ siblings by naming its workflow partners explicitly — SearchFundsByCategory produces the CIKs it consumes, and GetFundProfile is the fallback — so an agent can disambiguate 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?

Explicitly positions the tool in a workflow: 'PRIMARY USE: Step 2 of fee comparison. Accepts CIKs returned by SearchFundsByCategory,' with a concrete ranking instruction (rank by net_expense_ratio ascending). It also gives an explicit when-not and alternative: 'Not all funds file XBRL rr: data. If this tool returns an error, use GetFundProfile (yfinance) as a fallback.' This is the gold standard for 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=true, idempotentHint=true, and destructiveHint=false, so the safety profile is established and the description adds beyond it: the data source ('Yahoo Finance via yfinance'), the auth requirement ('No API key required'), and the ETF/mutual-fund-only scope. 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?

Every sentence earns its place: a scoped purpose sentence, four actionable usage bullets, a compact section-options list, an exclusion with a named alternative, and a source/auth note. Information is front-loaded and scannable for an agent.

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

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

An output schema exists so return values need not be spelled out, and annotations cover the safety profile. The description supplies scope, when-to-use triggers, section semantics, data source, and auth requirements. Minor gaps: no behavior specified for invalid symbols, and the fixed-income-only nature of bond_ratings is only implied rather than stated.

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% per context signals, the description carries the documentation burden and does compensate for the most important parameter: it lists all section options with their meanings and maps them to use cases in the bullets. However, it leaves symbol formatting to the schema and does not clarify the purpose of the auxiliary wrapper params (source_resource_id, wholesaler_ids, etc.), which appear irrelevant to a Yahoo Finance-backed fetch.

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 ETF or mutual fund specific data' — and enumerates the exact data areas returned (top holdings with weight %, sector allocations, expense ratio, bond credit quality ratings, equity style characteristics). It differentiates from siblings by naming the alternative: 'For stocks, use GetTickerInfo,' and its content list distinguishes it from overlapping tools like GetFundFees and GetHolders.

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 four concrete trigger scenarios, from needing top-10 holdings with weights to comparing fund profiles for advisor recommendations. It also states a clear exclusion and routes to the alternative: 'Only works for ETFs and mutual funds. For stocks, use GetTickerInfo.'

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds useful behavioral context: the data source is Yahoo Finance via yfinance, no API key is required, holders are 'top' holders, and insider data is 'recent'. It does not contradict 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: a purpose sentence, three usage bullets, a holder_type line, and a source line. Every sentence earns its place and there is no filler or redundancy.

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

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

Confidently covers core use cases, data source, and auth requirements, and an output schema exists to define return values. Advanced optional parameters like source_resource_id and wholesaler_ids are documented in the schema, so the description is sufficient for typical calls even though it does not explain those internal fin features.

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 nested schema already provides thorough documentation for symbol and holder_type, including examples and allowed values. The description only restates the holder_type options and adds minor context about insider transactions, so it adds little beyond what the schema already conveys.

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 ('Fetch') and resource ('ownership data for a stock') and enumerates the exact data subtypes: institutional holders, mutual fund holders, and insider transactions. This clearly scopes the tool relative to siblings like GetFundProfile or GetAnalystRatings, though it does not explicitly name any sibling as a point of contrast.

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

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

Provides an explicit 'Use this tool when' list covering institutions/funds, insider buying/selling activity, and ownership concentration data. This is clear context for when the tool is appropriate, but it does not mention exclusions or alternative sibling tools such as Get13FHoldings or GetFundProfile.

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. The description adds useful behavioral context: the source (SEC IAPD public API) and that no API key is required. It also lists the fields returned, giving the agent a preview of the output. 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 front-loaded with the operation, followed by a cleanereturn-fields list, a 'Use this tool when' bullet section, and a source note. There is minor redundancy (CRD mentioned twice) but every sentence serves a purpose.

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

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

The description covers what data is returned, the source, auth requirements, and common use cases. However, the schema marks crd as optional with default null, while the description implies the CRD is required, creating potential ambiguity. It also does not say what happens if the CRD is invalid or not found. Output schema and annotations fill some gaps but not this one.

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

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

Schema description coverage is 0%, meaning the description provides almost no parameter-level detail. The schema itself already documents CRD and the other nested parameters thoroughly, so the description's 'byits CRD number' is redundant and adds no new meaning. The description does not compensate for the low coverage level.

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 ('Retrieve') and resource ('ull Form ADV filing detail') with a clear scope ('one RIA firm by its CRD number'). It also lists the key fields returned, making the purpose unambiguous. It does not explicitly name a sibling tool to differentiate from, though the title 'Detail by CRD' implies contrast with 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 'Use this tool when' section provides three specific conditions, including the prerequisite of having a CRD from SearchIAPDFirm and the use cases of needing offices, custodians, or affiliate BD info. It does notexplicitly state when not to use it or name alternatives, but the guidance is clear enough for an 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 indicate readOnly, idempotent, and non-destructive behavior. The description adds meaningful behavioral context by specifying the returned content: complete registration history, exam qualifications, employment history, and disclosures, plus the external SEC API source and lack of API key requirement.

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 concise opening line, scannable use-case bullets, and a short source note. Every sentence serves a purpose and no filler or repetition is present.

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, the presence of an output schema, and annotations covering safety, the description provides sufficient context: the input source, what data will be returned, when to use it, and the external API source. No critical calling information 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 emphasizes the essential CRD parameter and where to obtain it, which adds modest semantic value. However, with schema description coverage reported as 0% at the top level, the description does not compensate for the many optional parameters like filters, resumability, or display fields, leaving that burden to the nested schema descriptions.

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 identifies the action ('Retrieve the full SEC IAPD profile'), the specific resource ('one individual investment advisor representative'), and the key identifier ('CRD number'). It also distinguishes itself from sibling tools like GetIAPDFirmDetail and SearchIAPDIndividual by targeting full individual-level detail.

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

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

The tool provides explicit use-case bullets, such as having a CRD from SearchIAPDIndividual, needing Form ADV Part 2B-equivalent data, and performing deep due diligence. It does not explicitly state when not to use this tool or mention alternatives like GetIAPDFirmDetail, but the stated conditions are 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, and the description does not contradict them. The description adds useful context beyond annotations: it names the external GLEIF API as the source, states that no API key is required, and enumerates the returned data fields. This is sufficient for a simple read-only 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 compact and well-structured: purpose comes first, followed by concrete use cases and source/authentication note. Every sentence adds value, and there is no fluff or repetition of the tool name.

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

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

For a simple single-entity lookup, the description covers purpose, use cases, and return fields well. However, given the unusual number of irrelevant-looking schema parameters and 0% schema coverage, it should have explicitly stated that only the LEI is required for normal use. That omission creates a meaningful completeness gap for an AI agent deciding how to invoke the tool.

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

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

The description only explains the meaning of the LEI code itself, which is the primary parameter, but the input schema contains several additional parameters (wholesaler_ids, source_resource_id, question_asked, etc.) with zero schema description coverage according to the context signals. An agent could easily be confused about whether those parameters are relevant to this GLEIF lookup. The description does not clarify that only lei is needed and the rest are internal or optional plumbing.

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: 'Retrieve the full GLEIF LEI record for one legal entity using its 20-character LEI code.' It clearly separates this from sibling search tools like SearchLEI by focusing on single-record detail retrieval. The listed return fields make the tool's scope 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 states when to use the tool: when a LEI is already available from SearchLEI, when verifying registration status/renewal date, and when needing exact legal address/jurisdiction. It does not explicitly say 'do not use this to search by name,' but the reference to SearchLEI as the source of the LEI implies the boundary.

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, and non-destructive behavior, and the description adds useful context: Yahoo Finance/yfinance as data source, no API key required, and a flattened per-ticker column format. It doesn't disclose rate limits or data-quality caveats, but those are minor for a read-only fetch.

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-loaded with the core behavior, and organized with a use-case list plus a concrete input example. Every sentence adds information; the source note is the final, low-cost detail.

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 output schema handles return-value documentation, and the description covers the essential call pattern, use cases, and data source. It is slightly incomplete in not signaling how period/start/interval are expected to be used, but defaults and schema fill most of that 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 carry parameter guidance; it only explains the symbols format and does not cover the date range, period, or interval parameters. It repeats the symbol examples from the schema rather than adding semantics for the other nested params.

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

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

The opening sentence names the action (Fetch), the resource (OHLCV price history), and the distinguishing scope (multiple tickers in a single call). It also tells what the response looks like (flattened table with per-ticker columns), so it cannot be confused with GetPriceHistory or other quote 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 'Use this tool when' list gives concrete scenarios: cross-security comparison, portfolio/basket correlation, and relative performance. It doesn't explicitly state when not to use it or name alternatives such as GetPriceHistory, so it falls one step short of fully explicit 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, idempotentHint, and non-destructive behavior. The description adds relevant context by stating the data source (Yahoo Finance via yfinance), that no API key is required, and how missing expiry_date resolves. It does not address latency or data limitations, but those are secondary 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 compact, front-loaded with the core behavior, and uses short bullets for usage conditions. Every sentence adds useful information, and the source/API-key note is placed last without bloating the text.

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, the description covers what the tool returns, how to get valid expiry dates, and external source requirements. It could be slightly more explicit about symbol being required despite the schema marking it optional, which would make an agent less likely to call it without required context.

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

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

The description clarifies the behavior of expiry_date (nearest available expiry when omitted) and identifies symbol examples, which adds some semantic guidance. However, schema description coverage is 0% and the description does not explicitly state that symbol must be supplied, nor does it discuss the other schema fields (e.g., mcp_prompt_id, question_asked, source_resource_id). The nested schema is rich, but the description itself leaves a notable 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?

States a specific action ('Fetch the full options chain') with a clear resource (calls and puts for one expiry), and enumerates the returned fields. The phrase 'one expiry date' and the mention of a companion tool help distinguish it from GetOptionsExpirations and other market-data 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?

Provides explicit 'Use this tool when' conditions and a concrete prerequisite ('Call GetOptionsExpirations first to get valid expiry dates'). It also gives a fallback behavior for omitted expiry_date, giving an agent clear decision rules for invocation.

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

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

Annotations already carry the safety profile (readOnlyHint=true, idempotentHint=true, destructiveHint=false), so the description needs only additive context. It adds valuable provenance and auth information: 'Source: Yahoo Finance via yfinance. No API key required.' No contradiction with annotations.

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

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

The core purpose is front-loaded in the first sentence, and the whole text is compact. Minor redundancy: the second bullet ('You need a specific expiry date to pass into GetOptionsChain') largely restates the preceding sentence, so not every sentence earns its place.

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

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

An output schema exists and annotations are rich, so return-value and safety explanations are not required. The description covers purpose, usage, source, and auth adequately for a simple read-only listing tool. However, it never reconciles the oddly generic internal parameters (wholesaler_ids, exclude_fillers, source_resource_id) with the Yahoo Finance data source, which may confuse an agent deciding what to populate.

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, but it only loosely implies the symbol parameter via 'for a ticker'. None of the other schema fields (mcp_prompt_id, question_asked, wholesaler_ids, exclude_fillers, source_resource_id) are addressed, leaving the agent with no guidance about which parameters matter for a Yahoo Finance options-listing call. The description does not bridge the gap left by the low-coverage 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 states a specific verb and resource — 'List all available options expiry dates for a ticker' — and immediately differentiates itself from the sibling GetOptionsChain by establishing that this tool is the prerequisite step for finding a valid expiry date. An agent can distinguish it from GetOptionsChain without inspecting either schema.

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

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

Explicit 'Use this tool when' bullets give concrete trigger conditions (know which contracts exist for a stock/ETF; need an expiry to pass into GetOptionsChain) and name the downstream sibling. It lacks an explicit when-not-to-use clause, so it stops just short of fully explicit 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 communicate read-only/idempotent/non-destructive behavior. The description adds useful context beyond annotations by naming Yahoo Finance via yfinance as the source, stating no API key is required, and documenting intraday max lookback limits (730 days for 1h, 60 days for shorter intraday bars).

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-loaded with the core purpose, and uses short bullets and option lists. Every sentence adds useful information, and it avoids restating unrelated schema details.

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

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

Given the output schema exists and annotations cover safety, the description provides enough context about source, interval limits, and use cases. It could be slightly stronger by explicitly routing multi-ticker requests to GetMultiTickerHistory, but nothing critical is missing for standard single-ticker history calls.

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 summarizes interval and period options and adds max-day constraints, which is helpful. However, the input schema already documents these values, and the description does not cover important parameters such as start/end precedence, actions, auto_adjust, or source_resource_id, so it only partially compensates for the low schema coverage signal.

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 ('Fetch') and names the exact resource: OHLCV price history for one ticker. It also distinguishes this tool from sibling tools like GetMultiTickerHistory by explicitly narrowing scope to a single ticker.

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 gives clear, concrete scenarios such as analyzing performance over a time range and computing returns/volatility/trends. It does not explicitly name an alternative tool to use for multi-ticker history, so it stops short of full when-not 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 readOnly, idempotent, and non-destructive behavior, so the description mainly adds useful context: the dependency on cenpy, the optional Census API key, the ACS 5-Year source, and that income/share metrics are derived. 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 organized and front-loaded: purpose, key metrics, use cases, then requirements/source. The metric bullet list is useful and not padded. The only minor redundancy is mentioning the free/optional API key twice, which keeps it from a perfect score.

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, why it is useful, when to use it, the external dependency, and the data source. Since an output schema exists, it does not need to fully document return structure. It is slightly incomplete about edge cases such as missing or conflicting zip_code/state arguments and how the generic fin parameters interact with the territory profile.

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

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

The schema description coverage is reported as 0%, so the description carries some burden. It does identify the core selectors ('ZIP code or state') and mentions the optional census_api_key, but it does not clarify whether one selector is required, what happens when both are provided, or how the fin-specific parameters such as wholesaler_ids and source_resource_id affect invocation. The nested input schema fills part of this 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 US Census American Community Survey (ACS) income and wealth proxy data for a ZIP code or state.' It also names the exact returned metrics, making the tool's purpose unmistakable, especially against sibling tools focused on tickers, funds, and broker data.

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

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

The description provides explicit 'Use this tool when' bullets that give clear invocation context for territory wealth scoring and demographic comparison. It does not name a specific alternative tool or give explicit 'when not to use' guidance, but the use cases are concrete enough to route an agent 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 cover the safety profile with readOnlyHint=true, idempotentHint=true, and destructiveHint=false, reducing the burden on the description. The description adds useful behavioral context by naming the data source (Yahoo Finance via yfinance), noting that no API key is required, and clarifying that the tool accepts multiple instrument types. It does not discuss rate limits or data freshness, but those are less 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 and front-loaded with a scoping first sentence, followed by a useful when-to-use bullet list and a compact supported-assets line. Every sentence adds information without filler or redundancy.

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

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

Since an output schema exists, the description does not need to explain return values, and it already covers purpose, use cases, supported instrument types, and data source/auth expectations. The main gaps are that it does not explicitly explain how to provide the symbol parameter or when to prefer a sibling tool like LookupTicker or GetFundProfile. Overall, it is sufficiently complete for most correct invocations.

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

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

Context signals indicate 0% schema description coverage and only one top-level parameter, so the description must compensate for parameter explanation. It only implies the symbol parameter through asset-type examples like AAPL, SPY, and BTC-USD, and never explicitly states that a symbol must be provided or how the top-level 'params' object is used. Several schema fields such as mcp_prompt_id, wholesaler_ids, and exclude_fillers are not tied to this tool's purpose.

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 Yahoo Finance profile' and enumerates concrete return fields such as market cap, P/E ratio, 52-week range, and dividend yield. It clearly distinguishes this metadata/profile tool from price-history, ratings, or filings siblings by emphasizing the profile focus and 60+ metadata fields. The asset-type list makes the tool's scope 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 includes an explicit 'Use this tool when' section with three concrete scenarios: quick company/fund summary, sector/industry classification, and price metadata needs. It does not explicitly say when not to use it or name sibling alternatives such as LookupTicker or GetFundProfile, so it stops short of a 5.

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

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

Annotations already convey read-only, idempotent, non-destructive behavior. The description adds meaningful context beyond that: it is backed by Yahoo Finance/yfinance, requires no API key, and returns exchange/asset type information. This gives the agent useful expectations about data source and result shape.

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: opening purpose, then use cases, then an options list, then source/auth note. Every sentence adds useful information without unnecessary 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 lookup tool with an output schema, the description covers purpose, use cases, key parameter options, and authentication requirements. It could additionally clarify result limiting/pagination or mention that only symbol metadata is returned, but nothing critical is missing for correct invocation.

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

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

The description explains the core query behavior and enumerates valid asset_type options, which helps selection. However, it does not address max_results or the various framework parameters present in the schema, and the context signal indicates low schema_description_coverage, so the description only partially compensates for parameter documentation.

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

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

The description opens with a specific verb and resource: 'Search for a Yahoo Finance ticker symbol by company name, fund name, or keyword.' It also states what is returned ('matching symbols with exchange and asset type'), and the use cases clearly distinguish it from the many sibling search/data 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 explicit when-to-use scenarios: finding a ticker from a name, locating ETF/mutual fund tickers, and disambiguating similarly named securities. It does not name alternative sibling tools or give when-not-to-use guidance, so it stops short of a 5.

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

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

Annotations already mark the tool as readOnly, idempotent, and non-destructive, and the description adds meaningful behavioral context beyond that: it depends on Bloomberg's OpenFIGI API, requires no API key, and mentions optional keys affect rate limits. This gives an agent useful operational expectations that structured annotations alone do not provide.

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

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

The description is well-structured with a clear intro, a bulleted 'Use this tool when' list, a compact table of supported idTypes, a targeted usage tip, and a source/authentication note. Every sentence serves a purpose and the most important information is front-loaded.

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

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

For a tool with an output schema, the description does not need to explain return values, and it adequately covers the core mapping use cases, supported identifiers, exchange targeting, and API source. It loses a point because it does not fully align with the schema's wider set of idType values and leaves the several non-OpenFIGI params unaddressed, which could confuse an agent trying to decide whether they matter.

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 reported 0% schema description coverage, the description needed to compensate, and it does explain the main idType values and exchCode usage with examples. However, it lists only four of the six idType options that appear in the schema (omitting ID_COMMON and ID_WERTPAPIER) and does not explain other mapping fields like micCode, currency, or securityType, nor the generic extra params such as wholesaler_ids and source_resource_id.

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... using Bloomberg's OpenFIGI service' and explicitly says it converts between ticker symbols, ISINs, CUSIPs, and FIGIs. This distinguishes it from sibling search tools like SearchFigiInstruments and LookupTicker, which focus on lookup rather than cross-system ID conversion.

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

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

The description provides a dedicated 'Use this tool when' section with concrete scenarios: converting ticker to ISIN/CUSIP, normalizing IDs across data sources, and identifying exchanges. It gives actionable guidance like including 'exchCode': 'US' for ticker lookups, but it does not explicitly name sibling tools or describe when not to use it, 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=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds genuine context beyond that: the data source (FINRA BrokerCheck public API), that no API key is required, and the specific return fields. 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 longer than average but every section earns its place: core function, use cases, workflow routing, state hint, follow-up tool pointer, and source/no-auth note. It is front-loaded with the what-it-does sentence and uses bullet structure for scannability.

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

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

For a read-only search tool with an output schema and a large sibling family, the description is complete: it explains what it returns, how it fits into the multi-step geographic workflow, when to use alternatives, and the authentication state. Nothing an agent needs to call it correctly is missing.

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

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

The description adds meaning for the two primary search params — name (search by name) and state ('Narrow results with the optional state parameter'). However, the tool exposes 12 nested parameters and the description is silent on most of them; it relies on the schema's per-parameter descriptions for the rest. Acceptable but not compensating beyond baseline.

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 pair ('Search FINRA BrokerCheck for registered individual brokers... by name') and states what the tool returns (CRD number, current firm, registration status, disclosures). The title adds 'Individuals' to distinguish from SearchBrokerCheckFirm, and the workflow section explicitly names the siblings it is not.

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

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

There is an explicit 'Use this tool when' list (find CRD number, verify registration status, enrich a rep record) plus a geographic workflow that tells the agent to use SearchBrokersByPlace and SearchBrokerCheckFirm first when the name is unknown, and GetBrokerCheckDetail after. This is clear when/when-not guidance with named alternatives.

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

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

The annotations already declare readOnly, idempotent, and non-destructive behavior. The description adds useful context by identifying the public FINRA BrokerCheck API and stating that no API key is required. It does not discuss rate limits or pagination, but that is minor given the annotation coverage.

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: action, output, use cases, and source line in that order. There is no filler, and each bullet earns its place.

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

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

For a read-only lookup tool with a rich schema and output schema, the description covers purpose, use cases, and access model. It could be slightly more complete by explicitly routing to sibling tools for individual rep searches or detail retrieval, but that omission is 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 input schema shown contains detailed descriptions for the nested parameters, so the prose description is not required to repeat them. The description adds only light emphasis on name and location-related parameters. The schema carries the parameter-semantics burden, which warrants the baseline 3.

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

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

The description states a specific verb-resource pair ('Search FINRA BrokerCheck for broker-dealer firms by name') and lists the exact return fields: CRD, registration status, city, state, and disclosure flag. This clearly distinguishes it from the individual-focused and IAPD sibling tools.

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

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

Three explicit 'Use this tool when' bullets provide concrete decision contexts: needing a CRD, disambiguating similarly named firms by location, and building a territory map of BD firms. It stops short of naming alternative sibling tools or stating when not to use it.

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

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

Beyond the readOnly/idempotent/non-destructive annotations, the description discloses the data source (SEC EDGAR full-text search API), the return fields, and that no API key is required. It does not cover pagination or rate limits, so it is not a 5.

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

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

The description is well organized: purpose, return fields, business context, bulleted use cases, and a closing source/requirement note. It is slightly longer than necessary and the use-case list overlaps somewhat with the opening sentence, but it remains readable 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?

For a search tool with output schema and safety annotations, the description covers source, key requirement, filters, and return fields. It is incomplete around sibling differentiation—especially that Get13FHoldings is the right follow-up for actual holdings—and omits any pagination or result-limit caveats.

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 prose adds semantic framing for the central parameters—institution name and start/end date filters, including the date format. The nested schema already documents all fields comprehensively, so the description's contribution beyond the schema is modest, and the 0% top-level coverage signal is offset by the rich $defs descriptions.

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 line states a specific action and scope: search SEC EDGAR for 13F-HR filings by institution name, and enumerates the returned fields. It stops short of a 5 because it does not explicitly distinguish itself from siblings like GetEdgarCompanyFilings or Get13FHoldings.

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 has an explicit 'Use this tool when' block with concrete scenarios, which is better than most tools. However, the first bullet ('see what funds or ETFs a firm holds') overstates what this tool returns—it returns filing metadata, not holdings—and no alternative (Get13FHoldings) is suggested for the holdings use case.

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 description only needs to add context beyond those. It adds the external API source, states that no API key is required, and mentions that an optional key raises rate limits. This is useful behavioral context, though it does not go into failure modes or rate-limit edge cases.

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-loaded with the core action, and uses bullet points for usage scenarios. Every sentence serves a purpose, and there is no filler or repetition of schema content.

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

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

For a search tool with a rich schema and an output schema, the description covers the necessary context: what it searches, what it returns, when to use it, which sibling to prefer instead, and external API constraints. No critical information for selecting or invoking the tool is missing.

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

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

The description only paraphrases the main search concept ('by name or keyword') and references instrument categories like ETFs, options, and futures. The nested input schema already documents query, exchange_code, security_type, limit, and other filters with examples, so the description does not need to repeat them. It adds some high-level context but does not substantially extend the schema's parameter documentation.

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

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

The description opens with a specific verb and resource: 'Search Bloomberg OpenFIGI for financial instruments by name or keyword.' It also lists the returned fields (FIGI, ticker, exchange, security type, composite FIGI) and names the sibling tool MapInstrumentIds, making the tool's identity and scope immediately clear.

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' bullet list covering common lookup scenarios and provides a clear exclusion: 'Use MapInstrumentIds instead if you already have a specific ID to convert.' This tells the agent exactly when to choose this tool versus an alternative.

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

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

Annotations already cover the safety profile (readOnlyHint, idempotentHint, non-destructive). The description adds the FRED_API_KEY requirement and the exact fields returned, which are meaningful beyond annotations. It does not discuss rate limits or error behavior, but this is a low-risk read-only search 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 front-loaded with a crisp purpose statement and uses clear bullet sections for usage, common IDs, and prerequisites. It is slightly longer than strictly necessary—the source line adds little—but it remains scannable 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?

For a read-only search tool with an output schema and strong annotations, the description covers purpose, return fields, prerequisites, and the correct follow-up tool. Minor omissions such as error handling or explicit pagination behavior are low risk and partly covered by the schema.

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

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

The description clarifies that search is by keyword and suggests useful search topics (interest rates, inflation, GDP, unemployment, money supply). However, it does not explain limit, order_by, or the params wrapper; the nested schema documents those details, so the description adds only moderate value beyond the schema.

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

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

The description opens with a specific verb and resource: search the FRED database by keyword, and it enumerates return fields (series ID, title, frequency, units, seasonal adjustment, date range). It also distinguishes itself from the sibling GetFredSeriesData by framing this as the discovery step before fetching data.

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

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

The 'Use this tool when' list gives concrete decision criteria: finding the right series ID, discovering available macro data, and obtaining context for financial analysis. It explicitly names GetFredSeriesData as the next step and even lists common series IDs to make the search-to-fetch workflow unambiguous.

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

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

Annotations already cover readOnlyHint=true and idempotentHint=true, so the safety profile is established. The description adds genuine behavioral context beyond that: results are de-duplicated by CIK (one record per fund filer), specific form types are queried, the underlying source is the SEC EDGAR full-text API, and no API key is required. No pagination or rate-limit behavior is disclosed, but 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 front-loaded with its main function and organized into labeled sections (PRIMARY USE, examples, de-dup, date filtering, source/authentication). The four example queries add length but demonstrate realistic usage patterns that help an agent form queries correctly. Nothing is redundant; every block carries information, though it runs slightly long.

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 primary fee-comparison workflow, the description is complete: search semantics, query examples, downstream chaining, de-duplication behavior, date-filtering support, and authentication status are all covered. Minor gaps remain — no pagination/rate-limit guidance and no mention that max_results can be increased for broader scans — but the output schema and annotations cover the rest.

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, and it partially does: example queries map keywords and fund_type values, and a line covers date filtering for start/end dates. However, core params like max_results, plus wholesaler_ids, source_resource_id, and others, get no mention in the description, leaving a coverage gap for non-obvious 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 first sentence names a specific verb ('Search'), resource ('SEC EDGAR'), target ('mutual fund and ETF filers'), and selection dimension ('by investment category or keyword'), and states the return fields (entity name, CIK, form type, filing date). The form-type scope (N-1A, 485BPOS, N-2) plus the stated downstream link to GetFundFees clearly differentiates it from siblings like SearchEdgar13F and 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?

'PRIMARY USE: Step 1 of fee comparison. Feed the returned CIKs directly into GetFundFees' is an explicit workflow position with concrete downstream chaining, and the four example queries show realistic keyword/fund_type usage. It does not explicitly name alternative tools to prefer in other scenarios, so exclusions from siblings like SearchFredSeries or SearchEdgar13F are left implicit.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, so the safety profile is covered. The description adds useful behavioral context: the source is the public SEC IAPD API, no API key is required, and the search covers SEC-registered RIAs only. It also discloses the returned data fields.

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

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

The description is front-loaded with a clear one-sentence summary, then uses bullets and explicit workflow guidance. It is mildly redundant, repeating the RIA-vs-BrokerCheck distinction twice, and the geographic-workflow paragraph is slightly tangential, but overall every section still earns its place.

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

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

Given output schema presence and annotations covering read-only safety, the description supplies enough context for an agent to select and call the tool confidently. It explains scope, inputs, outputs, source, and related-tool flow. Minor gaps: it doesn't mention whether the name is required or behavior when omitted, and it doesn't address pagination or result limits.

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 clarify the core parameter—searching by firm name—but it does not explain the wrapper `params` structure or the optional parameters such as wholesaler_ids, source_resource_id, exclude_fillers. The main invocation path is clear, but advanced parameter usage is left entirely to 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 names a specific verb, resource, and subject: 'Search the SEC Investment Adviser Public Disclosure (IAPD) database for registered investment advisor (RIA) firms by name.' It also states the returned fields and clearly differentiates this tool from BrokerCheck and individual-IAPD searches.

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

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

Explicit 'Use this tool when' bullets define the intended scenarios, and the description gives a clear alternative: 'For broker-dealers, use SearchBrokerCheckFirm instead.' It also provides a concrete workflow connecting SearchBrokersByPlace to this tool and then to GetIAPDFirmDetail.

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 safety profile is clear. The description adds useful context beyond this: it identifies the public SEC API source, notes that no API key is required, and summarizes what data is returned. It does not mention rate limits or pagination, but those are minor given the non-destructive read-only nature.

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 when-to-use bullets and explicit alternatives. Every section adds value, and the source/authentication note is brief and relevant. 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?

For a read-only lookup tool, the description covers the key context: what it searches, when to use it, when not to use it, the data source, and authentication requirements. The output schema and annotations cover return structure and safety. Minor gaps remain around pagination, rate limits, and optional state-based narrowing, but the definition is complete enough for an agent to select and invoke the tool correctly.

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

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

The description calls out the primary input ('by name') but does not mention other useful parameters like state, rows, or additional filters. Although the nested input schema provides detailed property descriptions, the contextual signal shows 0% schema description coverage, so the description should compensate more than it does. It is adequate for selecting and making a basic call, but not for fully understanding available filtering options.

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-resource pair: 'Search SEC IAPD' for 'individual investment advisor representatives,' and explicitly lists the return fields (CRD number, current employer, registration states, exam history). It also distinguishes itself from firm lookups by stating 'not a firm,' so an agent can immediately tell this is the individual-advisor 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 explicit when-to-use conditions in three bullets and names two concrete alternatives: SearchIAPDFirm for firms and SearchBrokerCheck for broker/dealer individuals. This gives an agent clear selection criteria and prevents confusion with sibling tools.

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

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

Annotations already provide readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is known. The description adds operational context by naming the GLEIF API source, stating that no API key is required, and listing the fields returned. It does not mention rate limits or pagination, but those are secondary for a read-only search with an output schema.

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

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

The description is front-loaded with purpose and return fields, and the use-case bullets keep selection logic scannable. The sentences about regulatory reporting and 2M+ entities provide useful domain background but are not strictly necessary for invocation, so the description is concise without being maximal.

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 tool with an output schema and annotations, the description covers the source, authentication needs, scope, use cases, and a sibling alternative. It leaves some ambiguity around the many generic schema parameters that seem unrelated to a public LEI search, but that does not prevent an agent from invoking the tool correctly.

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

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

Schema description coverage is reported as 0% for the top-level params parameter, so the description must compensate. It identifies 'entity name' as the primary search criterion, which is useful, but it does not explain how to structure the params object, nor does it mention optional parameters like limit or country, or the fin-specific fields such as wholesaler_ids and source_resource_id. This is only partial compensation for the missing parameter documentation.

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'), a specific resource ('Global Legal Entity Identifier Foundation (GLEIF) database'), and a clear object ('Legal Entity Identifiers by entity name'). It also lists concrete return fields (LEI code, legal name, registration status, legal address, jurisdiction), which seperates it from generic search tools and points to its exact sibling GetLEIDetail.

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 concrete use cases and explicitly directs parent/subsidary lookups to GetLEIDetail. This gives an agent actionable selection criteria and an alternative, leaving little to inference.

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