fdic-banks-mcp-server

Get institution quarterly financials

fdic_get_institution_financials

Read-onlyIdempotent

Get one institution's quarterly Call Report financials by CERT — balance sheet, income, returns, credit quality, and capital ratios — most recent quarter first, with its name, status, and holding company. Unsuffixed income and return metrics are single-quarter figures; _ytd metrics accumulate from January 1. Dollar amounts are in thousands. Quarterly data lands about seven weeks after quarter end; history reaches back to 1984.

Input Schema

Name	Required	Description
`cert`	Yes	FDIC certificate number, from fdic_search_institutions.
`metrics`	No	At most 1000 raw metric names (fdic_list_reference topic metrics). Deduplicated before querying the first 25; deferred_metrics holds the rest. Omit or pass [] for the default health set.
`to_date`	No	Latest quarter to include, in the same forms as from_date. Omit for the latest published quarter.
`quarters`	No	Most recent quarters to return; accepts 1–10000, executes at most 200 within from_date/to_date. effective_quarters reports the applied count. Continue with to_date before the oldest returned quarter.
`from_date`	No	Earliest quarter to include: a quarter-end date (2025-03-31), the same without dashes (20250331), or a quarter label (2025Q1).

Output Schema

Name	Required	Description
`cap`	No	The quarters cap applied.
`rows`	No	Quarterly rows, most recent first.
`error`	No	Present when the call failed. Absent on success.
`shown`	No	Quarters returned.
`notice`	No	Guidance for an empty window, an inactive institution, or quarters left out by the cap.
`truncated`	No	True when more quarters were available than the quarters cap returned.
`data_as_of`	No	When FDIC last rebuilt the financials index (ISO timestamp).
`institution`	No	Institution identity, status, holding company, and succession; fdic_search_institutions with certs returns the full record (charter class, regulator, county, dates, latest assets).
`deferred_metrics`	No	Metrics not queried; pass these as metrics in a new call.
`selection_notice`	No	Execution caps and how to retrieve deferred selections.
`processed_metrics`	No	Metrics actually queried, including automatic panel sort/filter metrics.
`effective_quarters`	No	Quarters execution cap applied, at most 200.
`metric_definitions`	No	Field, unit, and basis of each metric in rows.
`quarters_available`	No	Reported quarters in the requested window, before the quarters cap.

Schema Changelog

Changes observed during successful MCP inspections.

Changed8 schema fields changedOct 16, 2026

changedInput schema / properties / metrics / description

Previous value: -"Up to 25 metric names (fdic_list_reference topic metrics). Omit for the default health set: assets, deposits, uninsured deposits, equity, net income, ROA, ROE, net interest margin, efficiency, noncurrent-loan and charge-off rates, loans to deposits, and capital ratios."New value: +"At most 1000 raw metric names (fdic_list_reference topic metrics). Deduplicated before querying the first 25; deferred_metrics holds the rest. Omit or pass [] for the default health set."

changedInput schema / properties / metrics / maxItems
```
Previous value: -25New value: +1000
```

changedInput schema / properties / quarters / description

Previous value: -"Most recent quarters to return (1–200; 200 covers the whole history back to 1984). Within from_date/to_date it caps the count."New value: +"Most recent quarters to return; accepts 1–10000, executes at most 200 within from_date/to_date. effective_quarters reports the applied count. Continue with to_date before the oldest returned quarter."

changedInput schema / properties / quarters / maximum
```
Previous value: -200New value: +10000
```

addedOutput schema / properties / deferred_metrics

Added value: +{
+  "description": "Metrics not queried; pass these as metrics in a new call.",
+  "items": {
+    "description": "Deferred metric.",
+    "type": "string"
+  },
+  "type": "array"
+}

addedOutput schema / properties / effective_quarters

Added value: +{
+  "description": "Quarters execution cap applied, at most 200.",
+  "maximum": 9007199254740991,
+  "minimum": -9007199254740991,
+  "type": "integer"
+}

addedOutput schema / properties / processed_metrics

Added value: +{
+  "description": "Metrics actually queried, including automatic panel sort/filter metrics.",
+  "items": {
+    "description": "Processed metric.",
+    "type": "string"
+  },
+  "type": "array"
+}

addedOutput schema / properties / selection_notice

Added value: +{
+  "description": "Execution caps and how to retrieve deferred selections.",
+  "type": "string"
+}

First observedOct 9, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, openWorld), yet the description adds genuinely new behavioral context: a ~7-week publication lag after quarter end, history back to 1984, most-recent-quarter-first ordering, dollar amounts in thousands, and the unsuffixed vs _ytd accumulation rule. That is strong value-add; only paging/continuation mechanics are absent from the description.

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?

A single dense paragraph that front-loads the core purpose (what is returned, keyed by CERT) before units, timing, and history caveats. Every clause carries information, though the packing of four distinct facts into one block is slightly heavy for parsing.

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 (5 params, 49-value metric enum, large history), but the description supplies the non-obvious facts an agent needs — units, YTD vs quarterly semantics, sort order, data latency, and history depth — while an output schema exists to cover return values and annotations cover safety. Nothing material is missing.

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?

With 100% schema description coverage the baseline is 3, but the description adds real meaning beyond the schema: it explains that unsuffixed income/return metrics are single-quarter while _ytd metrics accumulate from January 1, and that dollar figures are in thousands. These semantics are not conveyed by the bare enum list, which only names metrics.

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?

States a specific verb and resource ('Get one institution's quarterly Call Report financials by CERT') and enumerates the content domains (balance sheet, income, returns, credit quality, capital ratios). The 'one institution' scope distinguishes it from multi-institution siblings like fdic_query_financials and fdic_compare_peers without needing to open their schemas.

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 phrase 'one institution's ... by CERT' implies the single-institution use case, and the schema points at fdic_search_institutions for obtaining the CERT. However, the description never explicitly says when to prefer this over fdic_query_financials or fdic_compare_peers, nor states prerequisites or exclusions, so usage is inferred rather than declared.

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

All fdic-banks-mcp-server tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.