FDIC BankFind MCP Server

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

Description goes beyond annotations by disclosing it's a public off-site proxy (not official CAMELS), Management component omitted, Sensitivity proxied via NIM trend and securities concentration, and output structure. No contradictions with annotations.

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

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

Description is moderately long but well-structured with a clear first sentence and bullet points for outputs. Some redundancy (e.g., 'output includes' list is detailed) but overall efficient.

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 (mentioned but not shown), the description adequately covers caveats (no M, proxy S), output components, and trend analysis. For a complex tool with good annotations and output schema, the description is complete.

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

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

Parameters are fully covered by the input schema (100% coverage). Description adds no new semantic information beyond what the schema already provides (cert, repdte, quarters descriptions in schema are thorough). 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?

Description clearly states it produces a CAMELS-style analytical assessment for a single FDIC-insured institution using public data, names the five components (C, A, E, L, S) and composite rating. This distinctly differentiates it from sibling tools like fdic_detect_risk_signals or fdic_show_bank_deep_dive.

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?

Description implies usage for analytical assessment but does not explicitly compare with alternative tools like fdic_detect_risk_signals or fdic_compare_peer_health. No when-to-use or when-not-to-use guidance is provided.

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 declare readOnlyHint=true, idempotentHint=true, etc., which the description supports. It adds behavioral context by stating it is analytical, non-destructive, and outputs structured JSON, without contradicting annotations.

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

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

The description is well-structured with a clear intro, a bullet list of outputs, and a note. It is appropriately sized but could be slightly more concise.

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

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

Given the presence of an output schema, the description covers all necessary context: what the tool does, what outputs it provides (listed in detail), and that it uses public data. No gaps for an analytical 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 has 100% coverage of parameters (cert and repdte), so the description adds minimal extra meaning. It mentions 'FDIC Certificate Number' and 'Report date' which are already in the schema, meeting 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 clearly states it analyzes loan portfolio composition and credit concentration risk for an FDIC-insured institution, distinguishing it from sibling tools like fdic_analyze_bank_health or fdic_analyze_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?

No explicit guidance on when to use this tool versus its siblings. The note 'based on public financial data' is generic and does not help in deciding between similar analytical 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. The description adds value by specifying that the tool outputs structured JSON, is analytical, and uses public data. It also details the output components (e.g., cash ratio, funding risk signals), exceeding what annotations provide.

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

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

The description is well-structured with a clear opening sentence followed by a bullet list of outputs. It is concise and front-loaded, avoiding unnecessary details. Minor improvement possible by integrating usage guidance.

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

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

Given the tool's analytical nature, low parameter count, and presence of an output schema, the description is complete. It covers all key aspects: purpose, inputs, outputs (listed), and data source. No gaps in context for an AI agent to use 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?

Input schema description coverage is 100% (both parameters described). The description only adds 'Defaults to most recent quarter' for repdte, which is already in the schema. No extra semantic meaning beyond schema, so 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's purpose: analyzing deposit composition, wholesale funding reliance, and funding risk. It provides a bullet list of specific outputs, making it distinct from sibling analytical tools like fdic_analyze_bank_health 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 note 'analytical tool based on public financial data' implies appropriate use, but there is no explicit guidance on when to prefer this tool over alternatives or when not to use it. Sibling tool names suggest related analyses, but the description does not differentiate usage contexts.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false. The description adds value by clarifying it is analytical, based on public financial data, and notes that AFS/HTM breakdown is not available. No contradictions.

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

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

Description is concise, front-loaded with purpose, and uses bullet points for outputs. Could be slightly more structured, but efficient overall.

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

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

Given output schema exists and annotations provide safety info, the description adequately covers outputs and notes data limitations. Complete for an analytical 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 coverage is 100%, so baseline is 3. The description does not add additional meaning beyond what the schema already provides for parameters (cert, repdte). No enrichment.

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 it analyzes securities portfolio with specific outputs (size, composition, concentration risk). It distinguishes from siblings like 'fdic_analyze_bank_health' by focusing on securities, but could be more explicit about when to choose this tool.

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

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

No explicit guidance on when or when not to use this tool versus alternatives like 'fdic_analyze_bank_health' or 'fdic_detect_risk_signals'. Only a note about AFS/HTM unavailability, which is data quality info, not usage context.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds value by explaining it batches calls, uses server-side processing, returns both concise text and structured data, and defaults for date parameters. No contradictions.

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 sections ('Good uses:', 'Inputs:', 'Returns:') and front-loads the main purpose. However, it is somewhat verbose; some minor details could be omitted without losing clarity.

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

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

Given the existence of an output schema, the description doesn't need to detail return values but still mentions 'comparison text plus structured deltas, derived metrics, and insight tags'. With 11 parameters and no required ones, the description provides complete guidance for tool usage.

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

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

Schema coverage is 100%, but the description adds meaningful context beyond schema, such as explaining why dates must be quarter-end and providing examples. It also lists all parameters with additional clarification like 'snapshot vs timeseries'.

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 it compares FDIC reporting snapshots and ranks results. It uses specific verbs ('Compare... and rank') and identifies the resource (FDIC reporting snapshots). It distinguishes itself from simpler sibling tools by noting it batches multiple operations for heavier analytical prompts.

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

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

The description explicitly states when to use the tool ('heavier analytical prompts that would otherwise require many separate MCP calls') and provides concrete use cases. It implies when not to use (simpler queries) and differentiates from alternatives by mentioning batching.

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 indicate read-only, idempotent, non-destructive behavior. The description adds that it is a public off-site analytical proxy, not official ratings, and details output structure and deprecations, providing good context beyond 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 bullet points for usage modes, but it is somewhat lengthy due to detailed output description and deprecation notes. It front-loads purpose effectively.

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

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

The description covers all operational aspects: modes, optional parameters, output structure, deprecations, and auto-peer selection logic. Given the tool's complexity and the presence of an output schema, this is thorough and complete.

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

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

With 100% schema coverage, the description still adds value by explaining the three usage modes and how parameters like certs, state, and asset_min/asset_max are used. This contextual guidance justifies a score above 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 clearly states the tool compares CAMELS-style health scores across FDIC-insured institutions, listing three distinct usage modes. This specificity and differentiation from siblings like fdic_peer_group_analysis earns a top score.

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

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

The description explicitly outlines three usage modes (explicit list, state-wide scan, asset-based) and optional subject highlighting. However, it does not direct when to avoid this tool or contrast it with similar sibling tools, slightly reducing clarity.

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

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

Annotations already indicate readOnly, openWorld, idempotent, and non-destructive behavior. The description adds context that the output is 'signal-shaped, not assessment-shaped' and notes it is not official supervisory ratings, which is valuable beyond 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 bullet points for severity levels and scan modes, making it easy to read. However, it is somewhat lengthy and could be slightly more concise without losing clarity.

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

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

Given 8 parameters, 100% schema coverage, and an existing output schema, the description provides comprehensive context: scan modes, severity levels, signal codes, and an explicit note about the proxy's nature. It leaves no major gaps for agent understanding.

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, baseline is 3. The description adds meaning by grouping parameters into scan modes (state, certs, asset_min/asset_max) and explaining the default and enum for min_severity, which helps in understanding how parameters interact.

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 scans FDIC-insured institutions for early warning risk signals using a specific proxy engine, and lists standardized signal codes with severity levels. However, it does not explicitly differentiate from sibling tools like 'fdic_analyze_bank_health' which may overlap in purpose.

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

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

The description explains three scan modes (state-wide, explicit list, asset-based) and constraints (max 50 certs), but does not provide guidance on when to use this tool versus alternative sibling tools for other analyses.

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

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

The description adds value beyond annotations by specifying the tool returns citation text, which is behavioral context. However, it doesn't disclose any potential issues or limitations. With strong annotations (readOnly, idempotent, non-destructive), the bar is lower, and the description provides adequate context for behavior.

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

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

The description is extremely concise, with no wasted words. It clearly states the tool's purpose and usage in one sentence.

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

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

The description is complete for a basic fetch tool: it tells when to use it and how to specify the id. However, it lacks details about the nature of the citation text (e.g., length, format) which could help the agent decide if it needs to call this tool. Given the output schema is present, the description is minimally adequate.

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?

While the schema already describes the parameter, the description reinforces the expected format with concrete examples (e.g., 'institution:3511', 'failure:1234'), making it easier for the agent to construct valid ids. This adds semantic value beyond the schema.

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

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

The description clearly states the tool's purpose: retrieving full citation text for search results. It uses a specific verb and resource, and distinguishes from sibling search tools by mentioning 'result returned by search.' However, it could be more specific about what constitutes 'full citation text.'

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 usage context ('when the model needs the full citation text for a result returned by search') but does not explicitly list when not to use it or mention alternative tools. It implies usage after search, which is adequate but not thorough.

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

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

Annotations already declare the tool as read-only and idempotent. The description adds value by detailing output structure (branch count, deposits, market-by-market breakdown, Non-MSA grouping) and mentioning structured JSON output. No contradictions with annotations.

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

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

Description is concise and well-structured: purpose first, then what it shows, followed by output list and a note about rural branches. Every sentence adds value, though it could potentially be slightly shorter.

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

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

Given the tool's simplicity (2 params, 1 required) and robust annotations (readOnly, idempotent, non-destructive) plus output schema existence, the description covers key behavioral aspects and output composition. It does not address error handling but is sufficient for context.

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

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

Input schema has 100% description coverage, with both params (cert, year) clearly described. The description does not add new meaning beyond the schema; it only restates the default year behavior. 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?

Description clearly states the tool analyzes geographic franchise footprint using SOD data, showing distribution across MSAs. Verb 'analyze' and specific resource 'franchise footprint' distinguish it from sibling tools like fdic_fetch or fdic_search, which are more general or search-oriented.

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?

No explicit guidance on when to use this tool versus alternatives. The description does not mention when to prefer it over siblings like fdic_market_share_analysis or fdic_search_locations, leaving the agent to infer from the tool's purpose.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the description doesn't need to repeat safety traits. The description adds that it returns a single institution profile, which is consistent but not adding significant behavioral context beyond the structured annotations.

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

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

Two sentences with no filler. Purpose and usage guidelines are front-loaded. Every word earns its place. Excellent conciseness.

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 lookup tool with full annotations, output schema, and 100% parameter coverage, the description provides all necessary context: purpose, when to use, and how to fulfill prerequisites. 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 coverage is 100% (cert and fields both have descriptions). The description adds context that cert is the unique identifier and that the tool should only be used when the cert is known. This adds marginal value but doesn't elaborate on the fields parameter. 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's purpose: retrieve an institution profile given an exact FDIC Certificate Number. It distinguishes from sibling tools (like fdic_search_institutions) by specifying that this is for known certs, not discovery.

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

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

Explicitly states when to use (user knows exact cert number) and when not to (use fdic_search_institutions or fdic_search for discovery). Provides clear context and alternatives, which is excellent for an AI 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 mark the tool as read-only and idempotent. The description adds the key behavioral detail that the tool returns 'found: false' if the institution did not fail. No contradictions with annotations.

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

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

The description is two sentences long, front-loaded with usage context, and every word adds value. No unnecessary information or repetition.

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

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

Given the presence of an output schema, the description appropriately focuses on usage and key behavior (found: false). It covers all necessary aspects for an agent to invoke the tool correctly, including a summary of return fields.

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 has 100% description coverage for both parameters (cert and fields). The description reiterates the importance of cert but adds no additional semantic meaning beyond the schema, so a baseline score of 3 is appropriate.

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

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

The description clearly states the tool retrieves a specific failure record for a known CERT, and lists the returned fields (date, resolution type, cost, acquirer). It distinguishes from sibling search tools by focusing on a single institution via its unique identifier.

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

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

The description explicitly states when to use the tool (when the user knows the CERT of a failed institution) and implies when not to (the institution did not fail, returning found: false). However, it does not mention alternative sibling tools like fdic_search_failures for listing failures.

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 clear. The description adds value by noting it uses 'public financial data' and detailing the output structure, including consolidated summary and list of subsidiaries.

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 paragraph with front-loaded main action. It contains a bit of redundancy (e.g., 'Structured JSON for programmatic consumption' might be inferred), but overall it is efficient and well-structured.

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

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

Given the tool has two parameters, full schema coverage, and an output schema, the description is complete. It explains both lookup methods, what the output includes, and notes the data source. No gaps.

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

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

Schema coverage is 100%, so parameters are documented. The description adds meaning by explaining that cert is 'of any subsidiary' and triggers holding company lookup, and that hc_name uses the NAMEHCR field. This goes beyond the schema's description.

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

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

The description uses a specific verb ('Profile') and clearly identifies the resource ('bank holding company'). It distinguishes from siblings by specifying it groups subsidiaries and aggregates financial metrics, unlike individual institution tools like fdic_get_institution.

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

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

The description explicitly states how to look up (by holding company name or subsidiary CERT number), which is clear guidance. It doesn't explicitly exclude alternative use cases, but the context of siblings implies it's not for individual institutions or peer analysis. A slight improvement would be to mention when not to use.

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. The description adds behavioral context: it computes HHI, ranks institutions, and returns structured JSON. No contradictions.

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, bullet points, and examples. Every sentence serves a purpose, and the length is appropriate for the complexity of the tool.

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

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

Given the tool has 5 optional parameters and a complex output (HHI, ranking), the description fully explains entry modes, required combinations, and output structure. An output schema exists, which further reduces ambiguity.

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

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

Schema coverage is 100%. The description adds value by providing concrete examples for msa (e.g., 19100) and explaining the cert parameter for highlighting. This enriches understanding beyond the schema descriptions.

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

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

The description clearly states it analyzes deposit market share and concentration using FDIC SOD data, computing HHI. It differentiates from sibling tools by specifying its focus on geographic market share analysis, and references a specific sibling for code lookups.

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

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

The description explains two entry modes (MSA vs city+state) with examples and required combinations. It does not explicitly contrast with other tools, but the context and detail provide sufficient guidance for correct 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 declare readOnlyHint, idempotentHint, and destructiveHint. The description adds rich behavioral details: competition ranking method (1,2,2,4), automatic subject ranking when cert is provided, that all matched peers are used for ranking regardless of limit, and override precedence. No contradictions.

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 and bullet points. It front-loads the core purpose and usage modes. While it is comprehensive, some sentences could be tightened, but overall every part contributes meaningfully.

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 (none required), an output schema, and multiple usage modes, the description covers all key aspects: three usage modes, ranking details, default dates, override precedence, and output components. It is self-contained and leaves no major gaps for an AI agent to infer.

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 every parameter has a baseline description. The tool description adds significant value by explaining default value derivation for asset_min/asset_max based on cert, the role of cert in auto-deriving peer criteria, and the advanced nature of raw_filter. This goes beyond the raw schema descriptions.

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

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

The description clearly states the tool builds a peer group and ranks an FDIC-insured institution against peers. It specifies three usage modes (subject-driven, explicit criteria, overrides) and distinguishes from siblings by noting that the peer list can be passed to fdic_compare_bank_snapshots for trend 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 description explicitly explains when to use each mode and how default values are derived. It provides guidance on overriding defaults and mentions passing output to another tool. However, it does not directly compare with other sibling tools like fdic_compare_peer_health, so usage context could be slightly sharper.

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

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

Annotations already indicate read-only, idempotent, open-world, non-destructive behavior. The description adds context about output being chart-ready and exclusions for non-public items, enhancing transparency beyond 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 a single, well-structured sentence that front-loads the main purpose and includes all essential information without wasted words.

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

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

Given the presence of an output schema and the description's coverage of inputs and output summary, the description is fully complete for a data generation tool.

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

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

Schema description coverage is 100% with good parameter descriptions. The tool's description does not add further parameter details, so 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 states it builds chart-ready data for a QBP Lite report from public BankFind financials, listing included items and exclusions, clearly distinguishing from sibling search and 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 implies use for a concise QBP Lite report but does not explicitly state when to avoid this tool or mention alternative tools for different needs.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds valuable behavioral context: it uses FRED data, provides trend analysis and narrative context, returns structured JSON, and gracefully degrades if FRED API is unavailable. This goes beyond the annotations without contradicting them.

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

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

The description is well-structured with a clear opening sentence, bullet points for outputs, and a note about environment requirements. It is slightly longer than necessary but every sentence adds value. The main purpose is front-loaded.

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

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

Given that there are 3 parameters with full schema coverage and an output schema exists, the description is complete. It explains data sources, behavior when dependencies are missing, output structure, and usage context. No gaps remain for an agent to misuse the tool.

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

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

The input schema covers 100% of parameters with descriptions. The description adds meaningful nuance for the repdte parameter ('FRED data fetched for 2 years before this date') which is not in the schema description. It also clarifies that cert auto-detects state, enhancing understanding 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 uses a specific verb 'overlay' and clearly identifies the resource ('macro/regional economic data on a bank's geographic context'). It lists distinct outputs (unemployment rates, federal funds rate, narrative assessment) that differentiate it from sibling analysis tools like fdic_analyze_bank_health or fdic_detect_risk_signals.

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

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

The description states the tool provides 'trend analysis and narrative context for bank performance assessment,' implying usage context. However, it does not explicitly specify when to use this tool versus other FDIC analysis tools, nor does it provide when-not-to-use guidance. The note about FRED_API_KEY and graceful degradation offers some conditional 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?

The description adds behavioral detail beyond the annotations, specifying that results include id, title, source URL, and a limit of up to 8 results. This complements the readOnly, idempotent, and open-world hints from annotations. No contradictions.

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 usage context, and every sentence provides essential information. There is no unnecessary text, making it efficient for an AI agent to parse.

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

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

The tool has an output schema (not shown but indicated) and the description explains the return structure (id, title, source URL) and result limit. This is fairly complete for a search tool, though additional context about citation-friendly nature is provided. Some users might want pagination details, but overall it 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?

Schema description coverage is 100% (the single 'query' parameter is described as 'Natural-language search query'). The description does not add further detail about the parameter's expected format or examples. Given high coverage, a baseline score of 3 is appropriate.

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

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

The description clearly specifies the verb 'search' and resource 'FDIC BankFind' with a comprehensive list of result types (institutions, failed banks, branches, schema documentation). It differentiates from sibling tools like fdic_search_failures and fdic_search_institutions by being a general search. This provides high purpose clarity.

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

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

The description explicitly states when to use the tool ('when the model needs citation-friendly FDIC BankFind search results'), which is helpful. However, it does not provide explicit guidance on when not to use it or suggest alternatives, missing an opportunity to distinguish from the many sibling 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=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, covering safety aspects. The description adds valuable context: the tool returns quarterly data and references a schema for the full field catalog, which helps the agent understand what to expect beyond the schema.

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

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

The description is concise at three sentences, with the most important information (when to use, what data, how to filter) front-loaded. Every sentence contributes value without any 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?

Given the presence of an output schema (referenced separately), the description does not need to detail return values. It covers the key aspects: quarterly demographic attributes, filtering options, and a pointer to the full field catalog. This is complete for a search tool with good annotations and schema support.

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

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

The input schema has 100% description coverage, so the baseline is 3. The description adds minimal additional meaning by mentioning 'Filter by CERT and/or REPDTE', which reinforces two key parameters but does not elaborate on their syntax beyond what the schema 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 tool's purpose: returning quarterly demographic and market-structure attributes for FDIC-insured institutions. It specifies the types of data (office counts, metro classification, codes, geographic reference) and mentions filtering by CERT and/or REPDTE. This differentiates it from sibling tools like fdic_search_institutions or fdic_search_financials.

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

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

The description provides explicit guidance on when to use the tool: 'when the user wants quarterly demographic and market-structure attributes'. It also indicates filtering options. While it does not explicitly state when not to use it or list alternatives, the context of multiple FDIC sibling tools and the specific domain (demographics vs financials) makes the usage 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. Description adds that it returns paginated records and references a full field catalog, providing useful behavioral context beyond 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, front-loaded with purpose, no unnecessary words. Efficient and clear.

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 existing and annotations covering safety, the description provides essential info on filters, pagination, and field catalog. It sufficiently covers the tool's behavior without being overly detailed.

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

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

Schema coverage is 100% with descriptions for all 6 parameters. The description mentions filter types but doesn't add significant meaning beyond the schema definitions.

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 it searches failed FDIC-insured institutions with filters on name, state, date range, etc. It distinguishes from sibling tools like fdic_search_institutions which likely cover active 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?

Explicitly says to use when details on failed institutions are needed. Though it doesn't list when not to use or alternatives, the context with sibling tools implies appropriate use cases.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, etc., so the safety profile is clear. The description adds context about quarterly data and filtering options but does not reveal additional behavioral traits (e.g., rate limits, data freshness). With strong annotation coverage, a score of 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, front-loading the purpose and key filters, then referencing an external schema for details. Every word earns its place; no redundancy or fluff.

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

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

Given 8 parameters, a rich output schema (referenced), and a complex data domain, the description is largely complete. It mentions the full field catalog (1,100+ fields) via a link, which compensates for not detailing return values. Minor omission: no explanation of pagination or error handling, but still adequate.

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 has 100% description coverage, so the schema already explains all parameters thoroughly. The description highlights CERT and REPDTE but adds no new meaning beyond the schema; the baseline score of 3 is correct.

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 quarterly Call Report data for FDIC-insured institutions, with specific filters (CERT, REPDTE, ElasticSearch). This distinguishes it from sibling tools like 'fdic_search_institutions' or 'fdic_get_institution' by focusing on financial performance data.

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

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

The description explicitly says 'Use this when the user wants quarterly Call Report data', providing clear context for when to use the tool. However, it does not mention when NOT to use it or explicitly compare to sibling tools, which slightly reduces the score.

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

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

Annotations already declare the tool as read-only, idempotent, and non-destructive. The description adds that it returns structural-change events, providing some context beyond the annotations, but does not disclose additional behavioral traits like pagination limits or field full 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 only two sentences, front-loading the purpose and filtering capabilities. Every word adds value, with no redundancy or fluff.

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

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

Given the comprehensive schema (7 parameters, all described), annotations, and reference to an external schema for field catalog, the description is complete enough for the agent to understand usage without missing critical information.

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 has 100% description coverage, so the description does not need to add much parameter meaning. It briefly mentions filter options, but the schema already fully documents each parameter.

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 returns structural-change events (mergers, acquisitions, etc.) for FDIC-insured institutions, with specific filtering options. This distinguishes it from sibling tools like fdic_search_institutions or fdic_get_institution.

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 specifies when to use the tool (for structural-change events) and lists filterable dimensions (CERT, type, change code, date range, state). It does not explicitly state when not to use it, but the context 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 indicate readOnly, idempotent, and non-destructive behavior. The description adds value by noting that results return institution profile rows with pagination and referencing a field catalog, providing context beyond the annotations.

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

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

The description is two sentences: the first clearly states the purpose and scope, the second adds details on pagination and field catalog. No unnecessary words, every sentence adds value.

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

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

Given the presence of an output schema (referenced in description), the tool description covers search criteria, pagination, and field catalog. It is reasonably complete but could briefly mention sorting options, though those are 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% (all 6 parameters have descriptions). The description adds minimal parameter-specific details beyond mentioning searchable criteria (e.g., name, state). It does not significantly enhance understanding of the parameters.

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

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

The description clearly states the tool searches for FDIC-insured institutions by various criteria like name, state, CERT, asset size, etc. It uses a specific verb-resource combination but does not explicitly differentiate from sibling tools such as fdic_get_institution or fdic_search_summary.

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 starts with 'Use this when...' providing clear context for when to use the tool. It mentions pagination and a field catalog for reference. However, it does not specify when not to use it (e.g., for single institution lookups) or mention alternative 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 readOnly, openWorld, idempotent, and non-destructive hints, so the description adds value by stating the tool returns address, coordinates, branch number, and service-type rows. No contradictions with annotations.

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

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

Single, front-loaded sentence that directly states purpose and output. No unnecessary words; every part is informative.

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?

Description references the output schema (see fdic://schemas/locations) and lists key return fields, compensating for the missing inline output schema. For a search tool with well-documented parameters, this is complete.

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

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

All parameters have schema descriptions covering 100%, so the description adds little beyond mentioning filterable fields (CERT, state, city, etc.) which are already in the schema. 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 branch/office locations for FDIC-insured institutions with various filters. It is specific but does not explicitly distinguish from sibling tools like fdic_search_institutions or fdic_search, though the tool name and context make the purpose clear.

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

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

The description begins with 'Use this when...' which provides direct usage context. It lists common filters (CERT, state, city, etc.) but does not mention when not to use it or alternatives, which would be helpful given the many sibling 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 confirm read-only, non-destructive behavior. The description adds useful context: annual data snapshot, branch-level granularity, and filter options (CERT/year). No contradictions.

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 fluff. Front-loaded with purpose and data specifics. Reference to full field catalog is efficient.

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 core use case and references detailed schema. Output schema exists, so return format description is unnecessary. Lacks explicit mention of pagination parameters but schema covers them.

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 provides 100% coverage with detailed descriptions for all 8 parameters. The description adds marginal value by mentioning CERT and year filters, but does not elaborate beyond 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 explicitly states the tool retrieves annual branch-level deposit data (SOD), specifies the date (June 30 each year), and lists included data types (branch deposits, MSAs, geographic distribution). This is distinct from sibling tools focused on financial analysis, risk signals, etc.

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?

Clear instruction 'Use this when the user wants...' sets appropriate context. Does not explicitly state when not to use or name alternatives among many siblings, but the specificity of SOD data provides implicit 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, openWorldHint, and no destructive behavior. The description adds no behavioral traits beyond the annotations, but does not contradict them. No additional transparency provided.

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

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

The description is two concise sentences, front-loaded with the purpose and usage, and includes a pointer to a schema. No unnecessary words.

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 8 parameters fully described in schema and the presence of output schema, the description provides adequate context about data returned and filtering. However, it does not mention pagination or sorting, which are covered by 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% with detailed parameter descriptions. The description does not add new meaning beyond what the schema already provides, only mentioning filtering by CERT and year.

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 annual financial-summary snapshots with specific metrics (assets, deposits, ROA, ROE, offices) and filtering options (CERT, year). It distinguishes from sibling tools by specifying 'summary' data.

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

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

The description says 'use this when the user wants annual financial-summary snapshots', providing clear context. It does not explicitly mention when not to use it or alternatives, but the context is sufficient for differentiation.

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). The description adds valuable cross-client behavioral context: ChatGPT renders an interactive widget, while Claude and others get a Markdown table. No contradictions with annotations.

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

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

Two sentences, zero waste. The first sentence states the purpose and content; the second explains cross-client rendering. Front-loaded and efficient.

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 (not shown but indicated), the description appropriately focuses on input semantics and usage. It covers the key data categories (identity, financial metrics, risk signals, source links). Slight gap: no mention of data freshness or update frequency, but acceptable for a dashboard 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 coverage is 100%, so the schema already describes both parameters. The description adds only one detail: the default behavior for repdte ('defaults to the most recent likely published quarter'). This provides minor additional insight 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 uses specific verbs ('scannable', 'renders') and identifies the resource ('single-institution dashboard') with clear content (identity, metrics, risk signals, source links). It distinguishes from sibling tools by specifying its scope (single-institution) and output format differences (widget vs Markdown).

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

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

The description explicitly states 'Use this when the user wants...' but does not provide when-not-to-use or name alternative tools. It implies usage context for a quick overview, but lacks explicit exclusions or comparisons with sibling tools.

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

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

Annotations already indicate read-only, idempotent, and non-destructive behavior. The description adds context by noting ratios are computed from Call Report data and are UBPR-equivalent, not official FFIEC output. No contradictions with annotations.

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

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

The description is well-structured with bullet points for output categories and front-loaded with the main purpose. It is slightly lengthy but every sentence earns its place. Could be more concise but still effective.

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 only two parameters, rich annotations (all hints provided), and an output schema, the description is complete. It explains the output categories, data source, and clarifies the UBPR-equivalent nature, leaving no significant gaps.

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

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

Schema coverage is 100% with descriptions for both parameters (cert and repdte). The description does not add additional semantic meaning beyond what the schema provides, so 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 computes UBPR-equivalent ratio analysis for FDIC-insured institutions, listing specific financial metrics like ROA, ROE, NIM, loan mix, capital adequacy, etc. It distinguishes from siblings by specifying a comprehensive set of ratios, not just a single health score.

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

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

The description implies use for comprehensive ratio analysis but does not explicitly state when to use this tool versus alternatives like fdic_analyze_bank_health or other specific ratio tools. No when-not or alternative suggestions are provided.

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, idempotent, non-destructive behavior. The description adds example ID formats but no further behavioral context beyond what annotations provide.

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

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

Single sentence, front-loaded with use case, no wasted words.

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 one-parameter tool with an output schema, the description fully covers when to use it and the parameter format. No gaps.

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

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

Schema description coverage is 100%, so baseline 3. The tool description repeats examples already in the schema, adding minimal value.

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

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

The description clearly states the tool fetches full citation text for a search result, using a specific verb and resource. It distinguishes from sibling search tools by focusing on retrieval of individual 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 when to use it ('when the model needs the full citation text for a result returned by search'), providing clear context. However, it does not explicitly state when not to use it or name alternatives, though siblings imply the 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 indicate read-only, open-world, idempotent, and non-destructive behavior. The description adds that it returns up to 8 results with id, title, and source URL, and mentions 'citation-friendly', which provides useful context beyond the annotations.

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

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

The description is two sentences long, front-loaded with the action and purpose, and contains no unnecessary words. Every sentence adds value.

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

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

Given the complexity of a search tool and the presence of an output schema, the description adequately covers the return structure. It could mention error handling or pagination, but the core functionality is well-described.

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

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

The schema has 100% coverage with a single parameter 'query' described as 'Natural-language search query.' The description does not add further detail about query syntax or formatting, so it does not significantly enhance the schema information.

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 performs search on FDIC BankFind for institutions, failed banks, branches, or schema documentation. It distinguishes from siblings by mentioning specific result types, though sibling list includes both 'search' and 'fdic_search' which could cause confusion, but the title and description make the scope clear.

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

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

The description says 'Use this when the model needs citation-friendly FDIC BankFind search results', providing a clear use case. However, it does not explicitly mention when not to use it or alternative tools for more specific searches, such as fdic_get_institution for detailed institution data.

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