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

Beyond the annotations (readOnlyHint, idempotentHint, destructiveHint=false), the description discloses that this is a public off-site proxy, not an official CAMELS rating, that Management (M) is omitted because it cannot be assessed from public data, and that Sensitivity uses proxy metrics. These caveats are crucial for setting expectations and are not present in annotations. No contradiction.

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

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

The description is long but well-structured with bullet points, front-loading the main purpose and then listing outputs and caveats. Every sentence adds value—there is no filler. It could be slightly trimmed, but the length is justified given the analytical complexity.

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

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

With an output schema present, the description appropriately lists the key outputs (composite ratings, risk signals, structured JSON) and clearly states limitations (proxy model, no M component). This is complete for an agent to decide whether to invoke the tool and to interpret the results.

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

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

The input schema already provides descriptions for all three parameters (cert, repdte, quarters) with 100% coverage, so the description adds minimal new meaning. It does mention that quarters is for 'trend analysis' and that repdte defaults to the most recent quarter, which slightly reinforces the schema. This meets the baseline for full schema coverage.

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

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

The description uses a specific verb ('Produce') and resource ('CAMELS-style analytical assessment') and details the five components (C, A, E, L, S) plus composite rating. This clearly distinguishes it from generic fetch tools and even from other analytic tools like fdic_detect_risk_signals or fdic_show_bank_deep_dive by naming the proprietary proxy model and scoring output.

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

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

The description clearly states it applies to a single FDIC-insured institution and specifies the analytical approach (CAMELS-style proxy). It implicitly signals that it is the right choice when a comprehensive, component-wise health assessment is needed, but it does not explicitly list alternatives or conditions when not to use it. Still, the context is strong enough for an agent to infer usage.

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, open-world, and non-destructive behavior, so the description only needs to add context beyond that. It adds value by noting that the tool is analytical, relies on public financial data, applies 2006 interagency guidance thresholds, and returns structured JSON plus computed risk signals. There is no contradiction with the annotations.

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

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

The description is front-loaded with the core purpose, followed by a well-structured bulleted list of outputs, and closes with a relevant data-source note. Every section earns its place and no unnecessary filler 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?

For an analysis tool of this complexity, the description covers the purpose, methodology, guidance basis, data source, and output contents. The input schema documents the required certificate and optional report date, and the output schema handles return-value details, so nothing essential is missing for an agent to invoke the tool correctly.

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

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

Schema description coverage is 100%, so the baseline is 3; the schema already documents 'cert' as the FDIC Certificate Number and 'repdte' as the report date with a default. The description does not meaningfully elaborate on either parameter beyond the schema, but it does reinforce the analytical context in which the institution certificate is used.

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 specific verbs—'Analyze', 'Computes', 'flags'—and names a precise resource: loan portfolio composition and credit concentration risk for an FDIC-insured institution. It is clearly distinct from sibling analytical tools because none of them is focused specifically on credit concentration, and the listed outputs make its 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 clearly establishes when to use it: when analyzing loan portfolio composition, CRE concentration relative to capital, or concentration risk signals. It does not explicitly name alternatives or state when not to use it, but the context is strong enough for an agent to select it appropriately.

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

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

Annotations already establish readOnlyHint, idempotentHint, and non-destructive behavior, lowering the burden on the description. The description adds useful context by stating this is an analytical tool based on public financial data and that it produces derived risk signals based on supervisory thresholds.

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 core purpose, followed by a scannable bulleted output list and a brief note about data provenance. Every line contributes useful information without redundancy.

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

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

Given the output schema, annotations, and complete parameter schema, the description covers the essential context: what the tool analyzes, what it returns, and that it uses public data. Minor gaps like explicit threshold caveats or data vintage are not critical for correct invocation.

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

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

Schema description coverage is 100%, so cert and repdte are already fully documented. The description does not add further parameter-level meaning, but it also does not need to; baseline 3 is appropriate.

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

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

The description uses a specific verb ('Analyze') with a clear resource ('funding profile') and enumerates concrete outputs such as deposit composition, wholesale funding reliance, and FHLB advances. This differentiates it from sibling analysis tools like fdic_analyze_securities_portfolio or fdic_analyze_credit_concentration.

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

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

The description implies the tool should be used when funding composition and funding risk are the focus, but it does not explicitly state when to choose this over sibling analytical tools. No exclusions or alternative routing are provided, so the usage context is only 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=true, idempotentHint=true, and destructiveHint=false. The description adds context by stating it is based on public financial data and explicitly noting that AFS/HTM breakdown is not currently available from the FDIC API. This limitation is useful beyond what annotations convey, enhancing transparency.

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

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

The description is well-structured with a clear lead sentence, a concise bullet list of outputs, and a NOTE for the limitation. It is front-loaded with purpose and avoids fluff. The bullet list is slightly lengthy but each item adds value.

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

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

Given the presence of an output schema (as indicated by context), the description need not detail return values. It covers the tool's purpose, scope, and a key limitation. It does not mention error cases or prerequisites, but for a read-only analytical tool with clear annotations, this is sufficient.

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?

Input schema has 100% coverage—both parameters (cert and repdte) have descriptions. The description does not add any parameter-specific meaning beyond what the schema provides, such as format details or dependencies. Baseline 3 is appropriate since the schema carries the full 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 clearly states the tool analyzes securities portfolio size, composition, and concentration risk for FDIC-insured institutions. It enumerates specific outputs (relative to assets/capital, MBS concentration, AFS/HTM breakdown, risk signals), distinguishing it from sibling analysis tools like credit concentration or funding profile.

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

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

The description implies usage through its specific focus on securities portfolios, but it does not explicitly mention when to use this tool versus alternatives. There is no statement of 'use when...' or 'not for...' or mention of sibling tools. The NOTE about AFS/HTM unavailability provides a minor limitation, but no routing guidance.

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

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

Annotations clearly indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description does not need to re-state that this is a safe read operation. The description adds valuable context beyond annotations, such as the ability to batch multiple operations (roster lookup, financial snapshots, office-count snapshots, and time series) internally, the exact date format and quarter-end restriction for repdte, and the fact that it returns 'concise comparison text plus structured deltas, derived metrics, and insight tags.' It does not mention potential performance implications or detailed error scenarios, but given the annotations cover safety, a score of 4 is justified. There is no contradiction with the annotations.

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

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

The description is moderately lengthy but well-structured with clear sections: an overview, 'Good uses,' and 'Inputs' bullet list. The most distinguishing feature (batching and ranking) is front-loaded in the first sentence, and the examples are concise and illustrative. Each sentence serves a purpose, though the parameter list repeats some schema details (like sort_by options) that are already in the schema, which adds slight redundancy. Overall, it is efficient and easy to scan.

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

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

The description is complete given the complexity and available structured data. The output schema exists, so the description does not need to explain return values in detail, but it does mention 'concise comparison text plus structured deltas, derived metrics, and insight tags,' which gives a high-level preview. All parameters are described in the schema, and the description covers the high-level workflow, use cases, and parameter relationships. For an 11-parameter tool with an output schema and annotations, nothing critical for an agent 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?

Schema description coverage is 100% and all 11 parameters are documented with descriptions, defaults, and enums. The description adds significant value by grouping inputs (e.g., 'state or certs' as roster sources), explaining the date format and quarter-end requirement in more natural language, and listing all sort_by options with their defaults. It also clarifies the meaning of 'include_demographics' and 'analysis_mode' with examples. While the schema already covers the details, the description enhances comprehension by synthesizing the parameters into use-case logic, so a score of 4 is appropriate.

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

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

The description clearly states a specific verb ('compare' and 'rank') and a resource ('FDIC reporting snapshots'), and explicitly mentions multiple dimensions (growth, profitability, efficiency) and ranking functionality. It names sibling tools it is not, such as fdic_peer_group_analysis and fdic_analyze_bank_health, and differentiates itself by highlighting that it batches multiple operations into a single call. This makes it distinguishable from siblings without opening schemas.

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

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

The description provides explicit 'Good uses' with four concrete examples, clearly stating when to use this tool (e.g., 'Identify North Carolina banks with the strongest asset growth from 2021 to 2025') and contrasts it implicitly with alternatives by noting it is for 'heavier analytical prompts that would otherwise require many separate MCP calls.' It also gives parameter guidance (e.g., 'state or certs: choose a geographic roster or provide a direct comparison set') and clarifies that it batches operations that sibling search tools do individually. No negative usage cases are listed, but the examples and batching rationale provide very clear context.

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

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

Goes well beyond the readOnly/idempotent annotations by warning that the output is a 'Public off-site analytical proxy — not official supervisory ratings,' disclosing the deprecation of peer_context.subject_percentiles and its planned future removal, and explaining auto-peer cohort broadening when fewer than 10 peers match. 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?

Well-structured: purpose in the opening sentence, a clear 'Three usage modes' block, then output/deprecation notes, and finally the proxy caveat. The length is appropriate for the tool's complexity and every sentence contributes useful information.

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

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

Covers all usage modes, subject highlighting, output shape, deprecated fields, auto-peer behavior, and the non-official nature of the scores. It does not explicitly state that at least one of certs, state, or asset_min/asset_max is required, nor whether the modes are mutually exclusive, which is a notable gap given that the schema marks all parameters optional.

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 descriptions already cover all 8 parameters, so the baseline is 3; the description adds a useful mode-based organization tying certs, state, and asset_min/asset_max to distinct comparison strategies. Much of the cert/state wording overlaps the schema, but the mode framing and asset-size clarification add genuine meaning.

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

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

The description opens with a specific verb and resource: 'Compare CAMELS-style health scores across a group of FDIC-insured institutions,' and the three usage modes plus optional subject-cert add further scope. It does not explicitly name or exclude sibling tools like fdic_peer_group_analysis or fdic_analyze_bank_health, so differentiation is left partly to inference.

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

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

The description clearly defines when to use each parameter group: explicit cert list, state-wide scan, and asset-based selection, and explains the optional cert for highlighting a subject. It does not state when to prefer this tool over sibling comparison/analysis tools, nor does it say that at least one mode must be supplied.

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. The description adds valuable context about the output shape ('signal-shaped, not assessment-shaped') and the proxy nature ('Public off-site analytical proxy — not official supervisory ratings'), which informs the agent about the tool's limitations beyond what annotations capture.

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 lists and clear sections. It front-loads the purpose and then details signal codes and modes. The length is justified by the complexity of the tool, and each section 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 the presence of an output schema (as indicated), the description does not need to explain return values. It covers the tool's purpose, modes, signal codes, severity levels, and limitations. It is complete for an agent to call the tool correctly, though it could potentially add more explicit exclusions relative to siblings.

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

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

Schema coverage is 100%, so parameters are already described. The description adds meaningful usage patterns by mapping modes to parameters (e.g., state for state-wide, certs for explicit list, asset_min/asset_max for asset-based) and clarifies the min_severity enum levels. This goes beyond the schema's field-level 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 states the tool's function: scanning FDIC-insured institutions for early warning risk signals using a specific engine. It differentiates from siblings by focusing on 'risk signals' and mentions the proxy engine, which distinguishes it from other analysis 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 guidance on how to use the three scan modes (state-wide, explicit list, asset-based) and which parameters to provide for each. It also implies a distinction from full assessments via 'signal-shaped, not assessment-shaped', though it does not name specific sibling alternatives.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, covering safety. The description adds that it returns the full citation text and specifies the id format, giving useful behavioral context beyond annotations without contradiction.

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

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

The description is a single sentence that front-loads the purpose and provides concrete examples. It is concise, with no fluff or redundancy.

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

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

For a single-parameter tool with an output schema, the description covers when to use it, what it does, and the input format. It adequately sets expectations without missing critical details.

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

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

Schema description coverage is 100%, and the schema already describes the 'id' parameter with examples. The description repeats these examples, adding minimal value beyond the schema. Baseline of 3 is appropriate.

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

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

The description clearly states the tool fetches the full citation text for a search result, with specific examples of id formats (e.g., 'institution:3511'). It distinguishes itself from the search sibling tools by focusing on retrieval of existing results.

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

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

The description explicitly says 'Use this when the model needs the full citation text for a result returned by search', providing a clear trigger condition. It doesn't mention alternatives or exclusions, but the context implies it complements the search tools rather than replacing them.

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

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

Annotations already establish read-only, idempotent, non-destructive behavior. The description adds useful behavioral details beyond annotations: results are sorted by deposits, totals are included, and branches outside MSAs are grouped under 'Non-MSA / Rural'. No contradiction with 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 well-structured and front-loaded: a clear lead sentence, focused output bullets, and a useful non-MSA caveat. The bullet about 'Structured JSON for programmatic consumption' is slightly redundant given the output schema, but the overall length is appropriate.

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, strong annotations, and only two parameters, the description is nearly complete for invocation. It covers scope, grouping behavior, and outputs. The main gap—explicit alternative routing—is already penalized under usage guidelines.

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

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

The input schema already provides 100% parameter coverage, including the meaning of cert and the year default, so the baseline is 3. The description adds contextual framing ('FDIC-insured institution', SOD data) but no new parameter-level semantics beyond the schema.

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

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

The description opens with a specific action ('Analyze the geographic franchise footprint') and a named data source (Summary of Deposits). It defines a unique deliverable—market-by-market branch and deposit breakdown across MSAs—that distinguishes it from sibling financial-analysis tools like fdic_market_share_analysis.

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 intended use is implied: given an FDIC-insured institution, analyze its footprint. However, there is no explicit when-to-use or when-not-to-use guidance, and it does not name alternatives or conditions that would route an agent to a different sibling tool.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds that it returns a single institution profile, which is a useful behavioral trait beyond annotations, but it does not detail error handling or response specifics. Given annotations cover the main behaviors, a 3 is appropriate.

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

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

Two concise sentences with no redundancy. The primary use case is stated first, and the alternative routing is added efficiently. Every word earns its place.

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

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

For a single-record getter, the description covers when to use it, how to discover the needed identifier, and the expected result type (one profile). With an output schema present and annotations covering safety, nothing essential is missing.

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

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

Schema description coverage is 100% for both parameters (cert and fields), so the schema already provides full meaning. The description does not add parameter-specific details beyond what the schema states, so the baseline of 3 applies.

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

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

The description clearly states the tool's purpose: retrieve one institution profile when the user knows an exact FDIC Certificate Number. It names the resource (institution profile) and the key identifier (cert), and distinguishes it from search tools by directing users to discovery tools first.

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

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

It explicitly states when to use this tool (when the user knows an exact CERT) and when not to (to discover a CERT first, call fdic_search_institutions or fdic_search). This provides clear routing and alternative tool names.

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

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

Annotations already declare readOnlyHint and idempotentHint, so the safety profile is covered. The description adds useful behavioral details beyond those annotations: the specific returned failure fields (date, resolution type, DIF cost in COST field, acquirer) and the `found: false` response for non-failed institutions.

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

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

Two compact sentences with no filler. The usage trigger is front-loaded, followed by a concise list of returned data and the not-found behavior.

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-ID lookup with a rich output schema and safety annotations, the description covers the essential usage trigger, key return fields, and no-result behavior. Nothing critical is missing for an agent to invoke it correctly.

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

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

Schema description coverage is 100%, so parameters are already well documented. The description adds modest semantic context by linking CERT to a failed institution and noting the COST output field, but it doesn't add meaning beyond the schema for the parameters themselves.

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 ('get'), a specific resource ('failure record'), and the key required identifier (CERT). It clearly distinguishes this from general institution or search tools by limiting scope to failed institutions' specific failure records.

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

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

It explicitly states when to use the tool: when the user knows the CERT and needs a specific failure record. It does not explicitly name an alternative like 'use fdic_search_failures when the CERT is unknown,' so it falls just short of full exclusion guidance.

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

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior; the description adds that this is an analytical tool based on public financial data and that it produces consolidated subsidiary metrics. It is consistent and mildly useful, but it does not disclose edge cases such as no-match or missing-parameter behavior.

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

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

The purpose is front-loaded and the output bullets make the structure readable. The 'Structured JSON' bullet and the public-data note add only modest value, so it is concise enough but not maximally tight.

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 covers return shape and the annotations cover safety, so the description does not need to repeat those. It lacks an explicit statement that at least one lookup parameter should be supplied and what happens if both or neither are provided, which is a real invocation 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 coverage is 100%, so the schema already carries the cert and hc_name descriptions. The description restates the two lookup modes and the NAMEHCR field detail already present in the schema, adding no new semantic meaning beyond emphasizing the lookup paths.

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 action and resource: profile a bank holding company by grouping its FDIC-insured subsidiaries and aggregating financial metrics. This clearly distinguishes it from institution-level FDIC tools, though it never names a sibling explicitly.

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

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

It describes how to look up a holding company (by hc_name or by subsidiary CERT) and what output to expect, so the basic use context is evident. It does not state when to prefer this over sibling tools like fdic_get_institution or fdic_peer_group_analysis, nor any 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 declare read-only, idempotent, non-destructive behavior, so the description only needs to add context. It does so well by disclosing the two entry modes, the output contents (overview, HHI classification, optional highlighted institution, top rankings, structured JSON), and the requirement for at least one valid market identifier.

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

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

The description is well-structured with clear sections for entry modes, output, and requirements. It is slightly longer than strictly necessary because much of the content restates schema descriptions, but the bulleted format and front-loaded purpose keep it readable and scannable.

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

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

For a read-only analytical tool with an output schema and complete annotations, the description covers the necessary invocation requirements, data source, market entry modes, and output highlights. An agent has enough information to call the tool correctly without needing return-value details that are already available in the output 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 100%, so the baseline is 3. The description reinforces parameter relationships (city requires state, msa is a numeric MSABR code, cert highlights an institution) but does not add substantial new meaning beyond the schema. It is adequate but not exceptional.

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

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

The description names a specific verb and resource: analyze deposit market share and concentration using FDIC Summary of Deposits data. It clearly differentiates itself from sibling search-focused tools by describing the analytical output (market share, rankings, HHI) rather than just retrieval.

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

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

The description provides clear entry-mode guidance (MSA vs. city+state), states the required parameter combinations, and cross-references fdic_search_sod for MSABR code lookup. It does not explicitly contrast with every sibling, but the usage context is sufficiently clear for an agent to choose this tool over plain search tools.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, and the description does not contradict any of these. Beyond that, it adds rich behavioral context: ranking uses competition rank (1, 2, 2, 4), the comparison set is 'matched peers plus the subject institution,' and the limit parameter affects only returned peer count while all matched peers are used for ranking. This transparency exceeds what annotations alone 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 long but meticulously structured with clear sections: purpose, usage modes, metrics, ranking methodology, output contents, and override precedence. Every sentence contributes new information—there is no fluff. It is front-loaded with the primary purpose, and technical details are logically organized for easy scanning.

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

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

Given the complexity of 10 parameters, three usage modes, and a ranking algorithm, the description is exceptionally complete. It covers all parameter defaults, the ranking method, the output schema (subject rankings, peer medians, peer list, metric definitions), and even explains the relationship to a sibling tool. An agent has all the information needed to invoke the tool correctly in any mode.

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 100% schema coverage, the baseline is 3, but the description adds significant value by explaining parameter interdependencies. It specifies that asset_min/asset_max default to 50%/200% of the subject's report-date assets when cert is provided, that charter_classes defaults to the subject's charter class, and that the three usage modes map to different parameter combinations. This goes far beyond the schema's isolated field 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 opens with a clear, specific statement: 'Build a peer group for an FDIC-insured institution and rank it against peers on financial and efficiency metrics at a single report date.' It immediately distinguishes itself from sibling tools like fdic_compare_bank_snapshots and fdic_analyze_bank_health by focusing on peer group construction and ranking. The purpose is precise and 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 enumerates three usage modes (subject-driven, explicit criteria, subject with overrides) and explains when each is appropriate. It also provides routing guidance by stating that the peer list with CERTs can be 'pass[ed] to fdic_compare_bank_snapshots for trend analysis,' which directly addresses alternatives. The override precedence is clearly documented.

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

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

Annotations already declare read-only, open-world, and idempotent behavior, so the description need not repeat safety. It adds meaningful behavioral context: it builds chart-ready data, includes explicit exclusions, and implies a specific structure. It could disclose more about how it aggregates or formats data, but given strong annotations, this is sufficient.

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

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

The description is a single, front-loaded sentence that lists key outputs and exclusions without padding. Every element serves a purpose, and the structure leads with the primary action and outcome.

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 there is an output schema (though not shown), the description need not detail return values. It covers the purpose, key inclusions, and exclusions, and the parameter info is in the schema. A minor gap is lack of examples or notes on data lag, but overall it is complete for a report-builder tool.

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

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

Schema description coverage is 100%, so the schema fully documents repdte, trend_quarters, and include_community_banks. The description adds context, like the default trend_quarters and the community-bank flag use, but does not add new meaning beyond the schema. Baseline 3 is appropriate.

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

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

The description clearly states the tool builds chart-ready data for a QBP Lite report from public BankFind quarterly financials. It enumerates the output components (executive snapshot metrics, trend series, community-bank comparison, source notes) and explicitly excludes non-public or non-BankFind items. This distinguishes it from sibling tools that handle raw searches or deep dives.

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

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

The description implies it is for generating a concise QBP Lite report from public data, and the exclusion of non-public items hints it is not for proprietary metrics. However, it does not explicitly contrast with sibling tools like fdic_analyze_bank_health or fdic_ubpr_analysis, nor does it state when to use this vs a raw fdic_fetch. The context is clear enough for a similar-use case, but lacks explicit 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 cover readOnly, idempotent, and non-destructive behavior. The description adds valuable behavioral context beyond annotations: it depends on the FRED API, requires FRED_API_KEY for reliable data, degrades gracefully without it, and returns narrative plus structured JSON. 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 well-structured with a clear opening sentence, bulleted output list, and a separate note about environment requirements. Minor redundancy exists: 'gracefully degrades' appears twice, once in the first paragraph and again in the NOTE, but overall it is organized and front-loaded with the core 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?

With output schema present and safety annotations covering side-effect behavior, the description covers the main outputs, external dependency, and degradation behavior. A minor gap is that it does not explain what happens when neither cert nor state is provided, or which input should be preferred for a bank-level look-up versus a state-level analysis.

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

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

Schema description coverage is 100%, so the schema already documents cert, state, and repdte thoroughly, including the auto-detection from cert and the 2-year lookback. The description does not add parameter-specific meaning beyond what the schema provides; it mostly describes output content rather than parameter behavior.

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 action ('Overlay macro/regional economic data') and a clear resource (FRED data for unemployment and federal funds rate). It is clear what the tool produces, though it does not explicitly differentiate itself from sibling analytical tools like fdic_peer_group_analysis or fdic_market_share_analysis.

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

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

Usage context is implied through 'for bank performance assessment' and the focus on geographic/economic context, but there is no explicit when-to-use/when-not-to-use guidance or reference to alternatives. An agent must infer that this tool is for macro overlay rather than institution-level financial analysis.

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

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

Annotations already declare the tool read-only, idempotent, and non-destructive Introducing the 8-result cap and returned fields is useful, but the description does not add caveats such as external data variability, pagination limits, or source reliability beyond what annotations and the output schema already imply.

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

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

The description is two sentences with no wasted words. It front-loads the when-to-use guidance, then gives the result shape, making it easy to scan and act on.

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 single parameter, rich annotations, and presence of an output schema, the description is almost complete for correct invocation. The only notable gap is that it does not explain how fdic_search relates to the many specialized sibling search tools, which could lead to suboptimal tool selection.

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

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

There is only one parameter, query, and the schema already describes it as a natural-language search query with 100% coverage. The description adds no additional meaning that the schema does not already provide, so the baseline score of 3 is appropriate.

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

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

The description clearly states the tool searches FDIC BankFind for specified categories (institutions, failed banks, branches, or schema documentation) and emphasizes citation-friendly results with id, title, and source URL. This distinguishes it from data-heavy siblings like fdic_search_financials, though it does not explicitly contrast it with specialized searches such as fdic_search_institutions.

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 trigger: use this when citation-friendly BankFind search results are needed. It does not, however, list exclusions or recommend alternatives among the many specialized sibling tools, so it stops short of top marks.

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 that this is read-only, idempotent, non-destructive, and open-world. The description adds that the data is quarterly demographics/market-structure, which is useful, but it does not disclose pagination behavior, result limits, or other operational traits; with annotations covering the safety profile, this is adequate but not rich.

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

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

Three sentences with no filler: the when-to-use trigger, filter guidance, and schema pointer are all front-loaded and purposeful. Every sentence earns its place.

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

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

For a read-only search tool with a full parameter schema and output schema, the description gives the domain context and filter entry points needed to call it correctly. It could be more explicit about how this differs from location-adjacent siblings, but overall nothing critical is missing.

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

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

Schema description coverage is 100%, so all eight parameters are already documented in the input schema. The description only reinforces 'Filter by CERT and/or REPDTE' and points to a field catalog, adding no need for compensation beyond the 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 names a specific purpose—'quarterly demographic and market-structure attributes'—with concrete examples (office counts, metro classification, county/territory codes) and the target resource (FDIC-insured institutions). This makes it easy to distinguish from siblings like fdic_search_financials or fdic_search_failures.

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

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

It opens with an explicit 'Use this when' trigger and tells the agent which filters to use (CERT and/or REPDTE). It does not name sibling alternatives or state when not to use it, so it misses the 'when-not/alternatives' bar.

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

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

Annotations already establish read-only, idempotent, and non-destructive behavior; the description adds value beyond those by disclosing pagination and by flagging the COST-vs-ESTIMATED_LOSS naming trap. This is meaningful behavioral context the annotations and schema 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?

Four sentences, all informative and front-loaded with the use case. The field caveat is compact, the 'do not use ESTIMATED_LOSS' warning is explicit, and the closing schema pointer avoids unnecessary verbosity.

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

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

With full schema parameter coverage, annotations, and an output schema, the description fills the remaining gaps: pagination behavior, the loss-field naming caveat, and a pointer to the full field catalog. No critical information needed for correct invocation is missing.

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

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

Schema coverage is 100%, so the baseline is 3. The description earns a 4 by adding a critical field-alias clarification (COST for DIF cost) and by explaining how to request highest-cost failures with sort_by and sort_order, which the schema does not fully convey.

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 (search) on a specific resource (failed FDIC-insured institutions) and enumerates the main filter dimensions. The word 'failed' distinguishes it from sibling tools like fdic_search_institutions without needing to name them.

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

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

Opens with an explicit 'Use this when...' for the target case. It does not mention when-not-to-use or name alternative tools, but the usage context is clear 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 declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds context about the data type and points to the field catalog (fdic://schemas/financials), which is useful. It does not add details about rate limits, pagination behavior beyond schema, or response format, but since annotations carry the main behavioral burden, a 3 is appropriate.

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

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

The description is two sentences with no filler. The first sentence front-loads the purpose (quarterly Call Report data), and the second gives filtering guidance and a pointer to the full field catalog. Every word earns its place; it is concise and well-structured.

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

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

Given that an output schema exists (so return values are defined) and the input schema covers all 8 parameters with descriptions, the description adds enough context: the data type, primary filters, and a reference to the extensive field catalog. It does not mention default sorting or pagination, but those are covered in the parameter descriptions. The tool is relatively complex, yet the description, combined with schema, provides adequate guidance.

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

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

Schema description coverage is 100%, meaning every parameter has a description in the input schema. The tool description mentions CERT and REPDTE as filters, but this merely restates what the schema already documents. It does not add syntax details, relationships between parameters, or compensate for any gaps because there are none. Thus baseline 3 applies.

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

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

The description explicitly states the tool provides quarterly Call Report data (balance sheet, income, capital, performance ratios) for FDIC-insured institutions, which clearly distinguishes it from sibling tools like fdic_search_summary (summary data), fdic_search_demographics (demographics), and fdic_search_institutions (institution info). It also names the primary filters (CERT and REPDTE), making the purpose unambiguous.

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

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

The description begins with 'Use this when the user wants quarterly Call Report data', which gives clear context for when to invoke it. However, it does not explicitly mention alternatives or exclusions, even though many sibling tools exist. It could say 'for summary data use fdic_search_summary' etc., but the absence of explicit when-not guidance keeps it at a 4 rather than a 5.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, covering safety. The description adds domain context (event types) but no behavioral details like pagination behavior, rate limits, or result format. Since annotations cover safety, the description's additional value is limited, though it does mention filtering options.

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

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

Two sentences: the first states when to use and what it does; the second points to a schema reference. No redundancy, front-loaded, and every word 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 the presence of an output schema and annotations, the description covers purpose and usage adequately. It references a full field catalog, which is helpful. It does not explain pagination or error handling, but those are in schema. Missing a note that this is historical data only, but that is implied by 'history'.

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

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

Schema description coverage is 100%, so parameters are fully documented. The description adds a high-level summary of filterable dimensions but does not explain parameter syntax or semantics beyond what the schema already provides. Baseline 3 applies.

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

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

The description clearly states the tool retrieves structural-change events (mergers, acquisitions, name changes, etc.) for FDIC-insured institutions, which distinguishes it from sibling tools like fdic_search_institutions (general search) or fdic_search_financials (financial data). The verb 'search' and resource 'history' are specific.

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

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

It explicitly states 'Use this when the user wants structural-change events' and lists filtering dimensions (CERT, type, change code, date range, state). While it does not mention alternatives or exclusions, the purpose is clear enough to route correctly. A slight gap: no direct statement about when not to use it.

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

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

Annotations already cover safety (readOnly, openWorld, idempotent, non-destructive). The description adds useful behavioral context: returns 'institution profile rows with pagination' and directs to the field catalog. It doesn't disclose response envelope details or any subtle API behaviors, but the annotations lower the burden.

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

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

Two sentences, no filler. The primary use case is front-loaded, and the pointer to the field catalog replaces a long list of fields. Every phrase earns its place.

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

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

With an output schema, rich annotations, and 100% parameter schema coverage, the description only needs to add the searchable dimension and pagination behavior—both are present. Nothing essential is missing for an agent to invoke this correctly.

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

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

Schema description coverage is 100%, so the schema documents all 6 parameters. The description's mentions of search dimensions (name, state, CERT, asset size) largely repeat the schema's examples (NAME, STNAME, CERT, ASSET) without adding new meaning. Baseline 3 is appropriate.

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

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

The description starts with a specific verb+resource ('FDIC-insured institution search results') and enumerates the search dimensions (name, state, CERT, asset size, charter class, regulatory status). It clearly distinguishes this from sibling search tools focused on financials, failures, or locations.

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

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

It states a clear when-to-use condition ('Use this when the user needs FDIC-insured institution search results...'). However, given the large sibling family (fdic_search_financials, fdic_search_failures, fdic_search_locations), it doesn't explicitly name alternatives or exclusion conditions, leaving some routing ambiguity for the agent.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context beyond annotations by naming the returned content categories: address, coordinates, branch number, and service-type rows, plus a pointer to the full field catalog.

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

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

The description is two sentences, front-loaded with the key usage condition, and contains no filler. Every clause either refines the tool's scope, describes the output, or points to authoritative schema documentation.

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 detailed input schemas, rich annotations, and an output schema, the description is complete. It covers when to use the tool, what it returns, and how to get full field details, so an agent has enough to select and invoke it correctly.

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

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

Schema description coverage is 100%, so the bar for adding value is moderate. The description still adds meaning by naming additional filter dimensions such as city, county, metro area, and branch type that are not explicitly listed in the filters parameter examples, helping the agent understand the breadth of the filters string.

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

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

The description clearly states the tool searches for branch/office locations of FDIC-insured institutions and lists filter dimensions. It is specific about the resource type, but it does not explicitly distinguish itself from sibling tools like fdic_search_sod or fdic_search_institutions, so it stops short of full differentiation.

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 opening 'Use this when the user wants branch/office locations...' gives clear, actionable guidance for when to select this tool. It does not mention alternatives or when-not-to-use scenarios, but the when condition is explicit and direct.

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, openWorld, and non-destructive behavior, so the bar for additional disclosure is lower. The description adds the annual June 30 as-of context but does not disclose rate limits, pagination, or output behavior beyond what schema/annotations provide.

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

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

Two terse sentences with no filler. The use-case trigger and core data characteristics lead, followed by a useful pointer to the full field catalog.

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 complex 8-parameter tool, the combination of rich schema descriptions, annotations, output schema, and the field-catalog pointer covers what an agent needs. The description additionally orients the agent to data vintage and branch-level granularity.

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?

Input schema coverage is 100% and every parameter has a meaningful description, so the baseline is 3. The description's 'Filter by CERT and/or year' mostly restates schema information, though it points to fdic://schemas/sod for the field catalog.

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 clear use-case trigger ('Use this when the user wants...') and identifies the exact resource: annual branch-level Summary of Deposits data as of June 30. It further specifies content (branch deposits, MSAs, geographic distribution), which distinguishes it from FDIC financials, institutions, and failures 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?

It states an explicit condition for when to use the tool (SOD/branch-deposit requests) and how to narrow it (CERT and/or year). It does not explicitly list when-not-to-use or point to alternative sibling tools, but the trigger is clear.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so safety is covered. The description adds useful context about the data scope and points to a full field catalog (fdic://schemas/summary), but does not disclose behaviors like pagination defaults or result limits beyond what the schema already provides. With annotations in place, this is adequate but not exceptional.

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

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

The description is two sentences, front-loaded with the tool's use case, and ends with a useful pointer to the full field schema. Every word earns its place; there is no redundancy or filler.

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

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

With an output schema, 100% parameter coverage, and strong annotations, the description covers the core purpose and main filter dimensions. It does not disambiguate from the similarly named fdic_search_financials, which is the main gap for an otherwise complete tool definition.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds a hint that results are 'filtered by CERT and/or year', which aligns with the schema, but it provides no additional meaning for limit, offset, fields, filters, sort_by, or sort_order beyond their already-detailed 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 identifies a specific verb ('search'), a specific resource ('annual financial-summary snapshots'), and the key data fields (assets, deposits, ROA, ROE, offices). It does not explicitly contrast itself with the sibling fdic_search_financials, which could be confused, so it falls just short of full sibling differentiation.

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 opens with 'Use this when...' and clearly specifies the conditions (annual financial-summary snapshots, filtered by CERT/year). It provides solid when-to-use context but gives no when-not-to-use guidance or explicit alternative tools, such as pointing to fdic_search_financials for quarterly data.

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, non-destructive, and open-world hints. The description adds useful behavioral context by explaining that ChatGPT renders an interactive widget while Claude and other clients render Markdown, and it clarifies the dashboard's content categories. It does not go deeper into data freshness, error behavior, or source-specific caveats, so it provides moderate but not rich transparency.

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

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

The description is two tight sentences with no filler. The primary usage guidance is front-loaded, followed by the client-specific rendering caveat that an agent needs to set expectations correctly.

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

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

For a low-complexity tool with two parameters, an output schema, and safety-relevant annotations, the description provides enough context to invoke it correctly and describe the result. It could be slightly stronger by noting how this dashboard differs from sibling institution-level tools, but nothing critical is missing for basic correct use.

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

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

The input schema already fully describes both parameters: cert as the FDIC Certificate Number and repdte as an optional YYYYMMDD report date with a default. The description adds no additional parameter meaning beyond implying a single-institution scope, so the baseline of 3 is appropriate.

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

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

The description states a specific use case: rendering a scannable single-institution dashboard with identity, financial metrics, risk signals, and source links. It clearly names the resource and output format, but does not explicitly distinguish this from siblings like fdic_get_institution or fdic_search_institutions, leaving some differentiation to inference.

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

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

The opening phrase 'Use this when the user wants...' gives clear context for when the tool is appropriate, and the content list (identity, metrics, risk signals, source links) helps an agent select it. However, it does not state when not to use it or name alternatives, so it stops short of full routing guidance.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds genuine behavioral value beyond that: the caveat that ratios are 'UBPR-equivalent, not official FFIEC UBPR output' and the disclosure that it is an analytical tool based on public financial data. It also previews the output categories. No contradiction with annotations — 'Compute...analysis' aligns with read-only, non-destructive semantics.

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

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

Front-loaded with the core purpose, followed by a structured bulleted list of outputs and a one-line note. Efficient overall, though there is some redundancy: the opening 'Includes summary ratios (ROA, ROE, NIM, efficiency), loan mix, capital adequacy, liquidity metrics, and year-over-year growth rates' partially repeats the more detailed bullet list below it. Minor waste but the added specificity justifies most of the 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?

The tool has an output schema, so return-value structure is covered there; the description still usefully enumerates the output categories. Both parameters are documented in the schema. The main missing element is usage guidance relative to siblings (also reflected in the usage_guidelines score), but for the analytical scope, data-source caveats, and output preview, the description is largely complete. The default repdte behavior is already in the schema.

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

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

Schema description coverage is 100% — both 'cert' (FDIC Certificate Number) and 'repdte' (Report date YYYYMMDD, defaults to most recent quarter) are documented in the schema. Per baseline, when the schema carries full weight, a 3 is appropriate. The description adds nothing about parameter formats or the default behavior beyond what the schema already states.

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?

Uses a specific verb ('Compute') and a well-defined resource ('UBPR-equivalent ratio analysis for an FDIC-insured institution'). The description enumerates exact ratio categories (ROA, ROE, NIM, loan mix, capital adequacy, liquidity, growth), making it clearly distinguishable from sibling tools like fdic_analyze_bank_health or fdic_peer_group_analysis. The explicit 'UBPR-equivalent, not official FFIEC UBPR output' qualifier sharpens the scope.

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

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

The description states what the tool produces but gives no guidance on when to choose it over the ~26 sibling analytical tools (e.g., fdic_analyze_bank_health, fdic_analyze_funding_profile, fdic_analyze_credit_concentration). The note that it's 'analytical' and based on 'public financial data' implies context but provides no explicit when-to-use or when-not-to-use direction, nor names any alternative. Given the crowded sibling space, this is a real gap.

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, openWorldHint, idempotentHint, and non-destructive behavior. The description adds no additional behavioral context such as rate limits, authentication needs, or edge cases. It is not contradictory, but it does not enrich beyond the annotations.

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

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

Two sentences with a clear when-to-use directive and concrete id examples. Every word earns its place, and the key guidance 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 single-parameter, read-only, idempotent tool with an output schema, this is nearly complete. It explains what to pass and when to call it. The only gap is the lack of explicit differentiation from the similarly named sibling 'fdic_fetch'.

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

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

Schema description coverage is 100% and includes the same id format examples as the description. The description reinforces the expected id syntax but does not add meaning beyond what the schema already provides.

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

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

The description clearly states the resource ('full citation text for a result returned by search') and distinguishes this from search tools. It does not explicitly distinguish itself from the sibling 'fdic_fetch', which creates minor ambiguity.

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

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

It provides an explicit trigger condition: use when the model needs the full citation text from a search result. It does not list exclusions or alternatives, but the condition is specific enough for an agent to route correctly.

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

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

Annotations already provide readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, which cover safety and side-effect behavior. The description adds value by specifying the result count limit ('up to 8 results') and the fields returned ('id, title, and source URL'), which is behavioral context not in annotations. No contradiction with annotations; the description emphasizes it is a read-only search, consistent with annotations.

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

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

The description is two sentences, front-loads the purpose and context, and every sentence adds useful information. No fluff or repetition of schema details. It is concise and well-structured.

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

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

Given the tool has only one parameter, a simple safety profile (annotations), and an output schema that likely describes the result structure, the description is sufficient. It specifies the output format (id, title, URL) and result limit, which is complete for an agent to call it correctly. No additional complexity requires more detail.

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

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

Schema description coverage is 100%, as the 'query' parameter is well-described in the schema with 'Natural-language search query.' The description adds minimal value beyond that, only implying the search is natural-language. Since coverage is high, the baseline is 3, and the description doesn't need to add more.

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 ('FDIC BankFind'), and the types of results ('institutions, failed banks, branches, or schema documentation'). It also mentions the purpose ('citation-friendly') which distinguishes it from generic search tools. This clearly differentiates it from siblings like 'fetch' or the many analysis 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 says 'Use this when the model needs citation-friendly FDIC BankFind search results', which gives a clear context for use. However, it does not explicitly state when not to use it or mention alternatives like 'fetch' or the specific search siblings (e.g., fdic_search_institutions). The guidance is decent but lacks explicit exclusions or comparisons to alternatives.

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