FDIC BankFind MCP Server

Analyze Bank Health (CAMELS-Style)

fdic_analyze_bank_health

Read-onlyIdempotent

Produce a CAMELS-style analytical assessment for a single FDIC-insured institution using the public off-site proxy model.

Scores five components — Capital (C), Asset Quality (A), Earnings (E), Liquidity (L), Sensitivity (S) — using published FDIC financial data and derives a weighted composite rating (1=Strong to 5=Unsatisfactory), plus a proxy model overall band (1.0–4.0 scale).

Output includes:

Composite and component ratings with individual metric scores
Proxy model overall assessment band with capital classification
Management overlay assessment (inferred from public data patterns)
Trend analysis across prior quarters for key metrics
Risk signals flagging critical and warning-level concerns
Structured JSON for programmatic consumption (legacy + proxy fields)

NOTE: Management (M) is omitted from component scoring — cannot be assessed from public data. Sensitivity (S) uses proxy metrics (NIM trend, securities concentration). This is a public off-site analytical proxy, not an official CAMELS rating.

Input Schema

TableJSON Schema

Name	Required	Description
`cert`	Yes	FDIC Certificate Number of the institution to analyze.
`repdte`	No	Report Date (YYYYMMDD). Defaults to the most recent quarter likely to have published data.
`quarters`	No	Number of prior quarters to fetch for trend analysis (default 8).

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

TDQS

A4.3/5.0

Behavior5/5

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

The description goes beyond the readOnly/idempotent annotations by explaining the proxy model nature, the omission of Management (M), the proxy metrics for Sensitivity (S), and the fact that this is not an official CAMELS rating. It also details the output structure, making the behavior fully transparent.

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, front-loaded with a clear summary, and uses bullets to organize output details. Every sentence adds value, and the note about limitations is essential. 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?

The tool is complex with a rich output schema, and the description covers the score scales, output components, and limitations comprehensively. The presence of an output schema reduces the need to explain return values, and the description effectively fills the remaining gaps.

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 the parameters. The description adds no additional parameter-specific semantics beyond mentioning trend analysis over prior quarters, which is already captured by the 'quarters' parameter description. 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's function: 'Produce a CAMELS-style analytical assessment for a single FDIC-insured institution using the public off-site proxy model.' It identifies the specific verb, resource, and scope, and distinguishes it from siblings like fdic_analyze_credit_concentration by focusing on composite 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?

The description implies this tool is for holistic CAMELS-style assessment but does not explicitly compare it to alternative sibling tools or state when to prefer this one. Sibling tools like fdic_analyze_funding_profile are more specialized. This is implied rather than explicit, so a score of 3 reflects the lack of direct usage guidance.

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

All FDIC BankFind MCP Server tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.6/5.0

Disambiguation1/5

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.

Naming Consistency2/5

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.

Tool Count2/5

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.

Completeness4/5

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.

Resources

Need Help?