Skip to main content
Glama

fdic-ncua-health-rollup

Screen banks and credit unions for financial stress using FDIC/NCUA data, including capital ratios, CRE concentration, deposit runoff, and QoQ deltas to flag at-risk institutions.

Instructions

Bank & Credit-Union Financial Health API — FDIC/NCUA QoQ. Bank financial-stress screen on keyless FDIC data: capital ratios, CRE concentration (2006 guidance two-prong test), deposit runoff, ROA/ROE/NIM and asset quality per institution, with quarter-over-quarter deltas, peer-percentile scoring and health flags (deposit outflow, low ROA, rising NPL). Reads live from the official government source. COST AND SIDE EFFECTS: read-only with respect to the government source — it never writes to any external system — but each call starts a metered run on YOUR Apify account, billed $0.008 per result ($8 per 1,000). Lower on paid Apify plans, down to $2.40 per 1,000. Nothing is charged when a run fails. Store page: https://apify.com/malonestar/fdic-ncua-health-rollup

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
modeNoEvery mode returns the SAME full field set — capital ratios, uninsured deposits, unrealized losses, CRE concentration, credit quality and quarter-over-quarter deltas. Mode changes the ordering only. snapshot = largest institutions first. delta = biggest quarter-over-quarter deposit move first (the headline run-risk signal). score = highest peer asset percentile first. stress = most health flags first, the triage view. Example: "stress". Applied by default if omitted: "snapshot".
stateNoUS state to scope the cohort, e.g. CA, TX, NY. Strongly recommended: it focuses the run and makes peer percentiles state-level. Empty = the entire country (slower; national peer scoring). Example: "TX".
benchmarkNoAdds asset-weighted benchmark ratios and this bank's distance from them, in percentage points: benchmark_uninsured_deposit_ratio, benchmark_cre_to_tier1_pct, benchmark_unrealized_loss_to_equity_pct plus uninsured_vs_benchmark_pts, cre_vs_benchmark_pts, unrealized_vs_benchmark_pts. 'national' compares against all ~4,350 FDIC-insured banks; 'state' against the banks in your state. Costs exactly ONE extra request thanks to server-side aggregation — not a second full download. 'none' skips it. Example: "national".
creGrowthNoThe 2006 interagency CRE guidance is TWO tests: construction >= 100% of capital, OR (CRE >= 300% of capital AND CRE grew >= 50% over 36 months). Leaving this on fetches the quarter from 12 quarters ago — one extra request — and fills cre_growth_36m_pct, cre_total_loans_36m_ago, cre_baseline_date and cre_guidance_prong, plus the cre_guidance_both_prongs flag. Turn it off to skip that request; the level tests still run. Example: true.
maxAssetsNoOnly include institutions with at most this many total assets, in thousands of dollars. 0 = no ceiling. Combine with minAssets to score within an asset-size peer band (e.g. community banks $250M–$1B). Applied by default if omitted: 0.
minAssetsNoOnly include institutions with at least this many total assets, in thousands of dollars (FDIC reports assets in $000s, so 1000000 = $1B). Use with maxAssets to build a peer band. 0 = no floor. Applied by default if omitted: 0.
peerBasisNoWhat counts as a 'peer' when computing peer_asset_percentile, peer_roa_percentile, peer_cre_percentile and peer_uninsured_percentile. 'cohort' scores against everything you pulled (a state cohort mixes a $27M agricultural bank with a $200B trust bank, so the percentile means little). 'business_line' uses the FDIC SPECGRP business-model peer group — the cut a bank examiner uses. 'asset_band' uses FFIEC-style size bands. 'community_bank' splits on the FDIC community-bank research flag. Groups with fewer than 5 institutions fall back to the full cohort rather than ranking a bank against two neighbours. Example: "business_line". Applied by default if omitted: "cohort".
maxResultsNoMaximum number of institution-health records to return after filtering, scoring, and ranking. This is your cost cap: one record = one billable result. 500 covers a full mid-size state; TX has ~380 banks, CA ~180. Example: 500. Applied by default if omitted: 1000.
priorItemsNoOptional. In delta mode, an array of institution rows from a previous run (each needs id, total_assets, total_deposits) to diff the current quarter against, instead of auto-fetching the prior quarter. Lets you compare two arbitrary runs. Applied by default if omitted: [].
institutionTypeNoWhich institutions to include. 'bank' = FDIC-insured banks, fully supported, the only option that returns data today. 'credit_union' = NCUA — NOT AVAILABLE YET (ships in v1.3); selecting it alone fails the run immediately and bills nothing, rather than quietly handing back bank data. 'all' = runs the bank half now and picks up credit unions automatically the moment v1.3 lands. Example: "bank".

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.2

TDQS

A4.3/5.0
Behavior5/5

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

Well beyond the annotations, it discloses the metered-run billing model ($0.008/result, down to $2.40 per 1,000 on paid plans), that failed runs are not charged, that it is read-only with respect to the government source, and that credit_union selection fails immediately without billing. This is exactly the kind of side-effect and cost context annotations cannot express.

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?

Purpose is front-loaded, then a clearly labeled COST AND SIDE EFFECTS block, so the most decision-relevant facts come first. It is somewhat long and ends with a store-page URL, but every sentence carries actionable 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?

For a 10-parameter tool with no output schema, the description covers cost, side effects, feature availability and the returned metric families, which is what an agent needs to decide and invoke correctly. Return field shapes are left to the schema, which is acceptable given there is no output schema to lean on.

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 all ten parameters are already fully documented in the schema, including enum semantics, defaults and worked examples. The top-level description adds little parameter detail beyond the schema; 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 opening sentence names a specific resource and domain (bank/credit-union financial health from FDIC/NCUA data) and enumerates the exact outputs: capital ratios, CRE concentration, deposit runoff, ROA/ROE/NIM, asset quality, QoQ deltas, peer percentiles and health flags. No sibling tool shares this domain, and an agent can tell precisely what it gets without opening the schema.

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 supplies clear operating context: mode meanings with use-cases ('delta = the headline run-risk signal', 'stress = the triage view'), a recommendation to scope by state, and a cost-cap rationale for maxResults. It stops short of an explicit when-to-use/when-not statement versus other tools, but no near-alternative exists among the siblings.

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