fdic_searchUse this when the model needs citation-friendly FDIC BankFind search results for institutions, failed banks, branches, or schema documentation. Returns up to 8 results with id, title, and source URL.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Natural-language search query. |
| Name | Required | Description | Default |
|---|---|---|---|
| results | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, covering the safety profile. The description adds behavioral context by stating 'Returns up to 8 results with id, title, and source URL,' which is useful beyond annotations. 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, front-loaded with the usage instruction, and contains no redundant or irrelevant information. Every sentence contributes to understanding the tool's purpose, usage, and output.
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 tool with one parameter, rich annotations, and an output schema, the description is complete. It includes the result limit ('up to 8 results') and the fields returned, which are key behavioral details. No significant gaps exist.
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% coverage for the single 'query' parameter with description 'Natural-language search query.' The tool description adds potential search targets ('institutions, failed banks, branches, or schema documentation') but does not provide additional parameter syntax or format details. Baseline 3 applies due to high 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 clearly states the tool's purpose: 'Use this when the model needs citation-friendly FDIC BankFind search results for institutions, failed banks, branches, or schema documentation.' It uses a specific verb ('search') and resource ('FDIC BankFind'), and distinguishes itself from sibling tools by covering multiple entity types in a general search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly starts with 'Use this when...' providing a direct usage condition for when to invoke the tool. However, it does not mention alternatives or when not to use it, such as pointing to specialized sibling tools like fdic_search_institutions or fdic_search_failures. The clear usage context earns a 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Several tools have overlapping purposes, including exact duplicates: fdic_fetch/fetch and fdic_search/search. Analytical tools also overlap (analyze_bank_health, ubpr_analysis, detect_risk_signals), making it hard for an agent to distinguish them.
Most tools follow a fdic_verb_noun pattern, but two tools (fetch, search) lack the fdic_ prefix, breaking consistency. The verb style varies (get, search, analyze, compare, detect) but the prefix inconsistency is the main issue.
At 29 tools, the server is over the typical limit and includes redundant pairs that inflate the count. The broad FDIC domain justifies many tools, but the duplicates indicate poor scoping.
The server covers all major FDIC data resources: institutions, failures, financials, branches, history, demographics, SOD, and summary, plus analytical tools. No major gaps are evident for its read-only data and analysis purpose.