FDIC BankFind MCP Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.30.2
Disambiguation5/5
Every tool has a clearly distinct purpose with no ambiguity. The tools are organized by data domain (institutions, financials, failures, demographics, locations, SOD, history, summary) and analysis type (search, get, compare, peer analysis), making it easy for an agent to select the right tool for each task. For example, fdic_search_institutions is for finding institutions, fdic_get_institution is for retrieving details of a known institution, and fdic_compare_bank_snapshots is for multi-institution trend analysis.
Naming Consistency5/5
All tools follow a consistent 'fdic_verb_noun' pattern with snake_case throughout. The verbs are descriptive and appropriate (search, get, compare, peer_group_analysis), and the nouns clearly indicate the data domain (institutions, financials, failures, demographics, etc.). This predictability makes the tool set easy to navigate and understand.
Tool Count5/5
With 12 tools, the count is well-scoped for the FDIC BankFind domain. Each tool serves a distinct and necessary function, covering institution lookup, detailed retrieval, financial analysis, failure data, demographics, locations, SOD data, historical events, and summary data. The set is comprehensive without being overwhelming, supporting a wide range of analytical workflows.
Completeness5/5
The tool set provides complete coverage for FDIC bank data analysis. It includes search and retrieval for all key data types (institutions, financials, failures, demographics, locations, SOD, history, summary), plus advanced analytical tools like comparison and peer analysis. There are no obvious gaps—agents can perform institution discovery, detailed profiling, trend analysis, benchmarking, and historical research seamlessly.
Average 4.3/5 across 12 of 12 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 2 community issues answered or closed in the last 6 months
- 2 commits in the last 12 weeks
- Last stable release on June 21, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate read-only and idempotent. Description adds context: public off-site proxy, not official ratings, engine type, and output format. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with bullet points and sections, but slightly verbose. Front-loaded with main verb and purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all key aspects: signal codes, severity, scan modes, and notes on proxy nature. Output schema handles return values. Adequate for complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All parameters have schema descriptions. The description adds high-level context (modes) but does not significantly enhance per-parameter meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it scans FDIC-insured institutions for early warning risk signals using a specific engine, lists signal codes and scan modes. It is specific but does not explicitly differentiate from sibling tools like fdic_analyze_bank_health.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Describes three scan modes (state-wide, explicit list, asset-based) and provides context for when to use each. However, it lacks explicit 'when not to use' guidance or comparison with alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool as read-only, non-destructive, idempotent, and open-world. The description adds value by specifying the result structure (up to 8 results with id, title, and source URL), which is not inferable from annotations. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exceptionally concise—two sentences that deliver the essential purpose, usage context, and result format with no superfluous words. Every sentence serves a clear function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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 does not need to detail return values, but it usefully highlights the result fields. It lacks details on query syntax or pagination, but for a straightforward search tool with one parameter, it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage for the single 'query' parameter, the burden on the description is minimal. The description does not elaborate on the parameter beyond the schema's 'Natural-language search query,' but adds no meaningful new semantics. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it provides 'citation-friendly FDIC BankFind search results' for specific categories like institutions, failed banks, branches, or schema documentation. It effectively communicates the tool's scope, though it does not explicitly differentiate from sibling tools that target narrower sub-types (e.g., 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.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises when to use the tool ('when the model needs citation-friendly FDIC BankFind search results') but lacks explicit guidance on when not to use it or suggestions for alternatives among the many sibling search tools. This forces the agent to infer context from other tool descriptions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, non-destructive behavior. The description adds context: data source (public financial data), specific disclosures (AFS/HTM not available), and output contents (risk signals). This enriches 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise (about 6 lines) with clear bullet points and front-loaded purpose. Every sentence is informative and to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has only 2 parameters, full schema coverage, and an output schema (as indicated), the description adequately covers the analytical purpose, output details, and a notable limitation (AFS/HTM breakdown). No gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters. The description does not add further details about parameter usage or constraints, 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it analyzes securities portfolio size, composition, and concentration risk. Lists specific output items. However, it does not differentiate from sibling analytical tools (e.g., fdic_analyze_credit_concentration) explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance. The note about AFS/HTM unavailability is useful but does not cover usage context relative to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, destructiveHint, idempotentHint. Description adds pagination behavior and reference to field catalog, but adds minimal extra value 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, no wasted words. Very concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Rich schema, annotations, and output schema (referenced) cover most needs. Mentions pagination and field catalog. Missing notes on rate limits or error handling, but not critical for a search tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%; descriptions are detailed. The tool description does not add extra meaning to parameters beyond the schema, 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool is for searching failed FDIC-insured institutions with specific filters, and distinguishes from siblings like fdic_search_institutions which searches active institutions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use this when the user wants details on failed FDIC-insured institutions', providing clear context. No explicit exclusions or alternative names, but the context is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a safe read operation (readOnlyHint, destructiveHint false). The description adds that it returns history events and references a field catalog, but lacks details on pagination, rate limits, or data freshness.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no fluff. Purpose and filtering are front-loaded, and the second sentence directs to a schema catalog for details. Efficient and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Has output schema, so return values are covered. The description covers purpose and filtering. The reference to the field catalog adds completeness. However, it could briefly explain the history nature more.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already describes all parameters well. The description mentions filtering by 'CERT, type, change code, date range, or state' but does not add substantial new meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is for structural-change events like mergers and acquisitions, and specifies the resource (FDIC-insured institutions) and filtering options. This distinguishes it from sibling tools like fdic_search_institutions 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.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use this when the user wants structural-change events' and lists filtering dimensions. However, it does not explicitly state when not to use it or name alternative tools, though it can be inferred from sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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, so the bar is lower. The description adds context about pagination and a schema reference for the full field catalog, but does not disclose additional behavioral traits 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the use case, and no wasted words. The first sentence tells when to use it, the second describes what it returns and references the field catalog. Highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the comprehensive schema with detailed parameter descriptions and annotations, the description adequately covers the tool's functionality. It mentions pagination and a field catalog reference, and lists the searchable criteria. Could potentially mention error handling or rate limits, but overall complete for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 itself does not elaborate on parameters beyond the schema; it only sets the overall use context. The schema already provides detailed descriptions for all 6 parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: searching FDIC-insured institutions by various criteria like name, state, CERT, asset size, charter class, or regulatory status. It distinguishes itself from over 20 sibling tools by explicitly specifying use case and return type (institution profile rows with pagination).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
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 needs...', providing clear context for when to use this tool. However, it does not explicitly mention when not to use it or suggest alternative sibling tools (e.g., fdic_get_institution for a single institution), lacking explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, destructiveHint, idempotentHint, openWorldHint. The description adds that it returns annual financial-summary snapshots, but does not elaborate on rate limits, pagination details beyond the schema, or other behavioral nuances. It provides moderate extra value 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two concise sentences. The first clearly states purpose and filtering, the second directs to a full schema. No unnecessary words, front-loaded with key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the comprehensive schema (100% parameter coverage) and clear annotations, the description is mostly complete. It explains the tool's purpose and key filters. Minor gap: no mention of output structure, but the reference to an external schema covers that. Adequate for a search tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 parameters. The description highlights cert and year filters, which adds context, but does not add meaning beyond what the schema provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides annual financial-summary snapshots with examples like assets, deposits, ROA, ROE, offices. It specifies filtering by CERT and/or year, and references a separate schema for full field catalog. This distinguishes it from sibling tools like fdic_search_financials or 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.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use the tool (for annual summary snapshots filtered by CERT/year), but does not explicitly state when not to use it or mention alternatives. Given the many sibling tools, explicit exclusions would help, 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds value by clarifying that ratios are UBPR-equivalent (not official FFIEC UBPR), computed from Call Report data, and based on public financial data. It also lists the output structure. This goes 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a main sentence followed by bullet points listing ratio categories. It is front-loaded and every sentence adds value. Could be slightly more concise but overall effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the tool, the presence of an output schema, and the detailed list of output categories in the description, the description is complete. It covers the main use case and return structure adequately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and both parameters have clear descriptions. The description adds the default behavior for repdte ('defaults to most recent quarter'), which is helpful. This justifies a baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Compute UBPR-equivalent ratio analysis for an FDIC-insured institution' and enumerates specific ratio categories (summary, loan mix, capital adequacy, liquidity, growth). This distinguishes it from sibling tools that focus on individual aspects 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.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance is provided. The description implies the tool is for a comprehensive ratio analysis, but does not compare to siblings like fdic_analyze_bank_health or fdic_peer_group_analysis. The context of UBPR-equivalency helps somewhat.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive. Description adds context by stating it's analytical and based on public financial data, and notes output format (structured JSON). This exceeds minimal value expected from annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise, well-structured with bullet points, and front-loaded with the main purpose. Every sentence adds value with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity, annotations, and output schema, the description provides sufficient context: what it analyzes, output components, data source, and usage note. No gaps identified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear parameter descriptions. The description does not add additional meaning beyond what the input schema provides, so baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool analyzes deposit composition, wholesale funding reliance, and funding risk for FDIC-insured institutions. It distinguishes from siblings by specifying these unique analytical focuses.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
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 siblings. The context is implied by the name and description, but no alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations show readOnlyHint=true, destructiveHint=false, idempotentHint=true. Description adds that it computes HHI and ranks, provides optional highlight, and output structure. No contradictions. Adds 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is well-structured with bullet points and clear sections. It's fairly long but every sentence adds value. Some redundancy (repeats that at least one of msa or city+state required). Still, concise for the complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is an output schema (not shown but context says has output schema), description covers entry modes, output overview, and requirements. For a complex tool with 5 params, the description is complete enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 5 parameters with 100% coverage, each parameter has a description. The description adds context about how parameters relate (e.g., city requires state, msa can be looked up via fdic_search_sod). So schema already describes them, description adds usage context. Baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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. It specifies two entry modes (MSA or city+state) and mentions output includes HHI, ranked institutions, etc. It distinguishes from siblings like fdic_search_sod (which is for looking up codes).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use MSA vs city mode, and directs to use fdic_search_sod for looking up MSABR codes. It also states requirements (at least one of msa or city+state). No explicit when-not-to-use, but clear guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true. The description adds value by detailing the exact output components, the proxy nature, limitations (M omitted, S proxies), and that it uses published FDIC data. It fully discloses behavioral traits 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with bullet points and clear sections. It is somewhat lengthy but each part adds valuable information. It is appropriately detailed without being excessively verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema, the description does not need to explain return values. It covers all necessary aspects: input parameters, output structure, limitations, and analytical scope. It is complete for its complexity level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% description coverage for its 3 parameters. The overall tool description does not add new meaning to the parameters beyond what the schema already provides. Baseline score 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it produces a CAMELS-style analytical assessment for a single FDIC-insured institution using a public off-site proxy model. It lists components and output, distinguishing it from sibling tools that focus on specific aspects 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.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains what the tool does and notes that Management component is omitted and that it's a proxy model. However, it does not provide explicit guidance on when to use this tool versus alternatives like fdic_compare_peer_health or fdic_detect_risk_signals.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint, destructiveHint, idempotentHint) already convey safety. Description adds value by referencing the full field catalog and mentioning ElasticSearch filter syntax, but does not detail rate limits or pagination beyond schema 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with clear use case and a reference to the full field catalog. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 8 parameters, no required ones, and full schema coverage, the description is fairly complete. It hints at the data complexity via the catalog reference. Minor gap: no mention of response structure, but output schema exists to fill that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description reiterates common filters but does not add significant meaning beyond what the schema already provides for each parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description specifies 'quarterly Call Report data (balance sheet, income, capital, performance ratios) for FDIC-insured institutions.' This clearly identifies the tool's purpose and distinguishes it from sibling tools like fdic_search_institutions 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.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description clearly states when to use ('when the user wants quarterly Call Report data') and implies exclusivity for financial data. However, it does not explicitly mention when not to use or list alternative tools, which would be helpful given the many search siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only and idempotent behavior. The description adds that it returns specific fields (address, coordinates, branch number, service-type rows) and references a schema, providing 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences cover purpose, filtering options, and output, making it concise and front-loaded with no unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the parameter count, rich annotations, and output schema reference, the description is sufficiently complete. It mentions output types and references a full field catalog, covering most needs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed descriptions for each parameter. The description adds some context about what the tool returns but doesn't significantly enhance parameter understanding beyond what's in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns branch/office locations for FDIC-insured institutions, specifying filtering options and output types. It distinguishes itself from sibling tools that deal with institutions or financial data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says when to use ('when the user wants branch/office locations') and lists filters. While it doesn't provide explicit when-not-to-use, the context and sibling tools imply alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly and idempotent hints. The description adds client-specific rendering behavior (interactive widget vs. Markdown table), which is beyond what annotations provide. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with key information, no fluff. Efficiently conveys purpose, usage, and rendering behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has only 2 parameters, annotations cover safety, and an output schema exists (not shown but indicated), the description provides a good overview of the dashboard content. It is complete enough for an agent to understand what to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% coverage with descriptions for both parameters. The description does not add additional meaning beyond what is already in the schema, 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it shows a 'scannable single-institution dashboard' with specific content (identity, financial metrics, risk signals, source links), distinguishing it from sibling tools like fdic_get_institution or fdic_search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
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 a scannable single-institution dashboard', providing clear usage context. It does not explicitly mention when not to use, but the positive guidance is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and openWorldHint. The description adds value by stating it returns up to 8 results with id, title, and source URL, plus the 'citation-friendly' aspect. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two sentences, front-loaded with the when-to-use information, and every word adds value. No wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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 noted), the description covers return format, result limit, and use case. It could mention that it's a general search vs. specific siblings, but is sufficiently complete for most agents.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the description of 'query' is already in the schema. The description adds that it accepts a 'natural-language query', but this matches the schema. It provides no additional parameter details beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as a general search for FDIC BankFind, covering institutions, failed banks, branches, and schema documentation. It distinguishes from sibling tools which are more specific (e.g., fdic_search_institutions, fdic_search_failures), making it easy to choose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
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 ('citation-friendly FDIC BankFind search results') and mentions the return format. However, it does not provide explicit when-not-to-use guidance or compare with siblings, though the context of many specialized siblings implies this is the broad option.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint, destructiveHint, and idempotentHint, which the description reinforces by labeling it as analytical and based on public data. The description adds behavioral specifics: it computes metrics per 2006 interagency guidance and flags concentration risks, which go 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured. The first sentence states the core purpose, followed by a bulleted list of outputs, and a final note on data source. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and the presence of an output schema, the description covers all essential aspects: purpose, key metrics, regulatory guidance, and data source. It is sufficient for an agent to understand the tool's functionality and output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with both parameters documented (FDIC Certificate Number and report date). The description does not add parameter-level details beyond the schema, 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.
Purpose5/5
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 loan portfolio composition and credit concentration risk for an FDIC-insured institution. It lists specific outputs like CRE concentration relative to capital and loan-type breakdown, and distinguishes it from siblings focusing on health, funding, or securities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when credit concentration analysis is needed) by detailing the analytical outputs. It does not explicitly exclude alternatives, but the context and sibling tool names (e.g., fdic_analyze_bank_health) make the use case clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds valuable behavioral context: it explains that branches outside MSAs are grouped under 'Non-MSA / Rural', and it lists exact output fields (total branch count, deposits, market count, market-by-market breakdown). This goes 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, well-structured with bullet points, and front-loaded with the core purpose. Every sentence adds value: the opening sentence states the tool's function, the bullet points detail outputs, and the final point handles edge cases (non-MSA). No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists (as indicated in context signals), the description does not need to detail return values. It adequately explains inputs (cert, year), the analysis process (SOD data, MSA breakdown), and the edge case (rural branches). This is sufficient for an agent to understand and correctly invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds meaning beyond the schema: it explains that 'year' defaults to the most recent, and it clarifies the data source (Summary of Deposits). The description also notes how non-MSA branches are handled, which is not in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it analyzes the geographic franchise footprint using Summary of Deposits data, providing a market-by-market breakdown of branch count and deposits. It distinguishes itself from similar tools like fdic_market_share_analysis (comparative) and fdic_search_sod (raw data) by focusing on a single institution's footprint with structured output.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives, nor does it provide exclusion criteria or prerequisites. Usage is implied by the tool's purpose, but no guidance is given for choosing among sibling tools like fdic_market_share_analysis.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnly and idempotent, so no destructive actions. The description adds valuable context: that it aggregates data across subsidiaries, provides consolidated metrics and a list of subsidiaries, and outputs structured JSON. It also notes it's based on public financial data, reinforcing safe usage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, well-structured with bullet points, and front-loads the core purpose. Every sentence adds value without unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 optional params, full schema coverage, output schema presence), the description provides all necessary information: purpose, lookup options, and output contents. It is complete for agent decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema coverage is 100% and already describes both parameters (hc_name and cert). The description restates the lookup methods but does not add significant new semantic details beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it profiles a bank holding company by grouping its FDIC-insured subsidiaries and aggregating financial metrics. It specifies lookup methods (by name or subsidiary CERT) and distinguishes itself from sibling tools that focus on individual banks or other analyses.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains what the tool does and how to use it (by HC name or subsidiary CERT), but does not explicitly state when not to use it or direct to alternatives. The unique purpose is clear, but guidance on exclusion could be stronger.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent behavior. The description adds that it returns demographic data, which is useful 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with purpose, no wasted words. Efficiently conveys the tool's role.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the rich schema (8 parameters fully described) and existing annotations, the description adequately covers the tool's purpose and usage. The reference to an external field catalog is helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 adds value by specifying that filtering is commonly done by CERT and REPDTE, and references a separate schema for full fields, which helps understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool is for quarterly demographic and market-structure attributes, listing specific data types (office counts, metro classification, etc.). It distinguishes from sibling tools by its focus on demographics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use this when the user wants quarterly demographic... attributes' and suggests filtering by CERT and/or REPDTE. Does not explicitly exclude alternative tools, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, non-destructive, idempotent, and openWorld hints. The description adds value by explaining it batches operations, returns structured deltas and insight tags, and describes behavior across modes. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized into clear sections: purpose, use cases, inputs, returns. Every sentence adds value with no fluff. Concise yet comprehensive.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool complexity (11 parameters, optional output schema), the description covers inputs, outputs, and use cases thoroughly. It explains both snapshot and timeseries modes, and the return format. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with good descriptions for each parameter. The description adds context by explaining which parameters are used for roster building, filtering, and sorting, and by listing sort_by options again. Minor redundancy but overall helpful.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool compares FDIC snapshots and ranks by growth/profitability/efficiency. It distinguishes from siblings by noting it batches multiple MCP calls and includes optional office-count features.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Good uses are clearly listed with examples (e.g., identifying banks with strongest asset growth). It explains when to use, but does not explicitly state when not to use or name alternatives, though the sibling list implies specialization.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a safe, read-only, idempotent operation. The description adds critical context: it's a public off-site analytical proxy, not official supervisory ratings. It also details output structure and deprecation warnings.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is informative but quite lengthy, with detailed output and deprecation notes. While well-structured, it could be more concise without losing essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (8 optional parameters, multiple modes, detailed output schema), the description covers all key aspects: usage, output fields, peer selection logic, and disclaimers. It is complete for effective tool use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with each parameter described. The description adds value by explaining how parameters relate to the three usage modes and the optional subject cert, enriching the context beyond individual parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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, with three specific usage modes. This distinguishes it from sibling tools like fdic_peer_group_analysis or fdic_compare_bank_snapshots.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Three explicit usage modes (explicit list, state-wide, asset-based) provide clear guidance on when to use each. While it doesn't directly mention alternatives, the modes effectively partition use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, destructiveHint, idempotentHint, openWorldHint. The description adds value by explaining the id parameter format and that it retrieves full citation text, which is behavioral context beyond the 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence followed by examples. No wasted words; every part is essential for understanding the tool's purpose and usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, the description does not need to explain return values. It covers purpose, usage, and parameter semantics fully. With 1 parameter, 100% schema coverage, and strong annotations, the description is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds meaning to the 'id' parameter by explaining it is a 'retrieval item id' with specific formats (e.g., 'institution:3511'), which is more informative than the schema's generic description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves full citation text for search results. It specifies the verb 'fetch' and resource 'full citation text', and the examples of id formats differentiate it 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.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use the tool ('when the model needs the full citation text for a result returned by search') and provides example id formats. It lacks explicit 'when not to use' but the context implies it is only for items from search results.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds practical context (needs exact cert, returns one profile) but does not detail error states or rate limits. With good annotation coverage, the description's additional context 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core use case, and contains no unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
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 comprehensive annotations, the description covers all essential context: when to use, what it returns, and key prerequisite. No gaps are evident.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with both parameters described (cert as unique identifier, fields as comma-separated list). The description does not add new parameter information, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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 an institution profile given an exact FDIC Certificate Number. It explicitly distinguishes from sibling tools (fdic_search_institutions, fdic_search) that are meant for discovery.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use (knows exact certificate) and when-to-use-alternatives (for discovery, use search tools). This leaves no 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, destructiveHint=false, idempotentHint=true, openWorldHint=true. The description adds valuable context beyond these, such as including 'explicit exclusions for non-public or non-BankFind QBP items' and describing the output components. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that efficiently communicates the tool's purpose, output contents, and constraints (exclusions). No redundant information; every phrase earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the three well-documented parameters (100% schema coverage) and the presence of an output schema (as per context signals), the description adequately covers what the tool does and produces. It mentions key output categories and exclusions, providing sufficient context for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 the parameters (repdte, trend_quarters, include_community_banks). The description does not add further detail about their semantics or usage, meeting the baseline expectation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Build chart-ready data for a concise QBP Lite report from reproducible public BankFind quarterly financials.' It lists specific outputs (executive snapshot metrics, trend series, community-bank comparison data, source notes) and exclusions, distinguishing it from sibling tools like fdic_fetch or fdic_search_financials that deal with raw data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context (chart-ready data for QBP Lite reports from public BankFind data) but does not explicitly specify when to use this tool over alternatives or when not to use it. Sibling tools such as fdic_analyze_* indicate different analytical use cases, but no direct comparison is made.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds important behavioral context beyond annotations: data is annual as of June 30, covers branch deposits, and references a field catalog. Annotations already declare read-only, non-destructive, and idempotent. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: the first defines purpose and data type, the second mentions filters and a reference. Efficient and front-loaded with essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complex schema (8 params) with full descriptions, output schema present, and clear annotations, the description is complete enough. It specifies the data source, timing, and available filters, allowing an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed parameter descriptions. The tool description only mentions filtering by CERT and/or year, which is already covered by the schema. No additional semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves annual branch-level deposit data (SOD) as of June 30 each year, specifying branch deposits, MSAs, and geographic distribution. This distinguishes it from siblings like fdic_search (general institution search) and 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.
Usage Guidelines4/5
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 annual branch-level deposit data (SOD…)' providing clear context. It does not mention when not to use or alternative tools, but the instruction is sufficient given the sibling context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds key behavioral details: ranking uses competition rank (1,2,2,4), all peers are used for ranking regardless of limit, and output includes metric definitions with directionality. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured into clear sections (intro, modes, metrics, ranking, output, overrides) with no wasted sentences. It is front-loaded with purpose and each part adds distinct value, earning its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (10 parameters, multiple usage modes, and output schema), the description is remarkably complete. It covers ranking method, metric details, output structure, and parameter override logic, leaving no significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds substantial meaning: defaults for asset_min/asset_max (50%/200% of subject), charter_classes default to subject's, repdte defaults to most recent quarter, and explains how parameters interact across modes. This goes well beyond the schema's baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Build' and resource 'peer group for an FDIC-insured institution', clearly distinguishing the tool's focus on peer construction and ranking. It explicitly lists three usage modes and fixed-ranked metrics, setting it apart from siblings like fdic_compare_bank_snapshots.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description details three usage modes (subject-driven, explicit criteria, subject with overrides) and override precedence, guiding the AI on when to use each. It also references fdic_compare_bank_snapshots for trend analysis, indicating an alternative. However, it does not explicitly state scenarios where this tool should be avoided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds significant behavioral context beyond annotations: explains graceful degradation when FRED API is unavailable, requirement for FRED_API_KEY, and what outputs are included (trend analysis, narrative, structured JSON). Annotations already indicate read-only and idempotent, so 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is well-structured with a concise opening statement followed by bullet points listing outputs and notes. It front-loads the core purpose. Slightly longer than necessary but still efficient. Could trim redundant phrasing like 'Gracefully degrades' appearing twice.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (external API, multiple output types, graceful degradation), the description covers all critical aspects: inputs, outputs, dependencies, and failure behavior. An output schema exists to detail return values, so the description appropriately focuses on usage and behavioral nuances.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all 3 parameters. Description adds value by explaining that cert auto-detects state from institution record, and that repdte sets the date range for FRED data. This enriches the schema's basic parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool's purpose: overlay macro/regional economic data on a bank's geographic context. Specifies data sources (FRED) and outputs (unemployment rates, federal funds rate, narrative). Distinct from sibling tools which focus on bank-specific financial analysis, making it clear when to use this tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description implies when to use: when needing macroeconomic context for a bank. Does not explicitly state when not to use or provide alternatives, but the context of sibling tools makes the differentiation clear. Could be improved by noting that for bank-specific financials, use other tools like fdic_analyze_bank_health.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. Description adds that it returns 'full citation text', which is a behavioral detail beyond 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose and usage, no redundant information. Every sentence is essential.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a simple tool with one parameter, good annotations, and existence of output schema, the description is complete enough. It covers when to use and id formatting, though the output is only implied as 'full citation text'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema already describes the id parameter. Description adds value by providing examples (e.g., 'institution:3511', 'failure:1234') and clarifying the format, which helps the agent construct correct inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool fetches 'full citation text for a result returned by search', with specific verb and resource. This distinguishes it from sibling search tools and other fdic_* tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use ('when the model needs the full citation text for a result returned by search') and provides concrete examples of id format, effectively contrasting with search tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and idempotent behavior. The description adds value by specifying the returned fields (date, resolution type, cost, acquirer) and the 'found: false' response for non-failed institutions, which is 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, two sentences, with no redundant information. It front-loads the key purpose and usage, 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.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists, the description does not need to detail return structure. It covers essential aspects: what the tool returns (key failure fields), the 'found: false' edge case, and the required input. This is complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 both parameters well. The description does not add significant additional meaning beyond what is in the schema, meeting the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The title and description clearly specify that the tool retrieves failure details for a failed institution using a certificate number (CERT). It distinguishes itself from sibling tools like fdic_search_failures by focusing on a specific record rather than a list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: when the user knows the CERT and needs the specific failure record. It also notes that if the institution did not fail, the response includes 'found: false', guiding the agent on handling non-failure cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![fdic-mcp-server MCP server](https://glama.ai/mcp/servers/jflamb/fdic-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/jflamb/fdic-mcp-server)

Score Badge

Copy to your README.md:

[![fdic-mcp-server MCP server](https://glama.ai/mcp/servers/jflamb/fdic-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/jflamb/fdic-mcp-server)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/jflamb/fdic-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server