FDIC BankFind MCP Server

Compare Peer Health (CAMELS Rankings)

fdic_compare_peer_health

Read-onlyIdempotent

Compare CAMELS-style health scores across FDIC-insured institutions using explicit list, state, or asset range. Highlight a subject bank's ranking among peers.

Instructions

Compare CAMELS-style health scores across a group of FDIC-insured institutions.

Three usage modes:

Explicit list: provide certs (up to 50) for a specific comparison set
State-wide scan: provide state to compare all active institutions in that state
Asset-based: provide asset_min/asset_max to compare institutions by size

Optionally provide cert to highlight a subject institution's position in the ranking.

Output: structuredContent includes {model, official_status, report_date, institutions, metrics, peer_context, proxy_summary, proxy, deprecations}. Institutions include proxy scores and name_source. When a subject cert is provided, metrics[] is the preferred subject-vs-peer array for new UI bindings and proxy_summary is a flattened subject proxy. peer_context.subject_percentiles is deprecated, remains for backward compatibility, and is targeted for removal only in a future coordinated major release. Auto-peer selection derives asset bands from report-date financials and broadens the cohort if fewer than 10 peers match.

NOTE: Public off-site analytical proxy — not official supervisory ratings.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`cert`	No	Subject institution CERT to highlight in the ranking. Optional.
`certs`	No	Explicit list of CERTs to compare (max 50).
`state`	No	Two-letter state code to select all active institutions (e.g., "WY").
`asset_min`	No	Minimum total assets ($thousands) for peer selection.
`asset_max`	No	Maximum total assets ($thousands) for peer selection.
`repdte`	No	Report Date (YYYYMMDD). Defaults to the most recent quarter.
`sort_by`	No	Sort results by composite or a specific CAMELS component rating.	composite
`limit`	No	Max institutions to return in the response.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`model`	Yes
`official_status`	Yes
`proxy`	No
`proxy_summary`	Yes
`report_date`	Yes
`sort_by`	Yes
`total_institutions`	Yes
`returned_count`	Yes
`subject_cert`	Yes
`subject_rank`	Yes
`metrics`	Yes
`institutions`	Yes
`deprecations`	Yes
`peer_context`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Addedv1.26.0May 1, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations already establish read-only/idempotent safety, and the description adds substantial behavioral context: auto-peer selection broadens the cohort when fewer than 10 peers match, peer_context.subject_percentiles is deprecated, and the output is an analytical proxy rather than official supervisory ratings.

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?

Well-structured with clear sections for purpose, usage modes, and output details. Although detailed, every sentence earns its place, including the deprecation warning and proxy disclaimer.

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 description covers usage modes, output fields, auto-peer fallback, deprecation, and the non-official caveat. Since an output schema exists, it doesn't need to repeat return types, and the extra guidance on metrics vs proxy_summary is valuable for correct UI bindings.

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?

Input schema already covers 100% of parameters, providing baseline 3. The description goes beyond by grouping parameters into usage modes (certs, state, asset range) and clarifying that cert highlights a subject institution, which adds semantic meaning beyond individual field 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 compares CAMELS-style health scores across FDIC-insured institutions. The three usage modes (explicit certs, state-wide, asset-based) define the exact scope and distinguish it from sibling tools like fdic_peer_group_analysis.

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?

Provides explicit context for when to use the tool by naming three concrete usage modes and an optional subject-cert parameter. It does not explicitly name alternatives or state when not to use it, so it stops short of full when-not guidance.

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