Skip to main content
Glama

fdic-ncua-health-rollup

Screen US banks for financial stress using FDIC capital ratios, CRE concentration, deposit runoff and ROA, with quarter-over-quarter deltas and peer-percentile health flags.

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. Call describe-gov-data-tool (free) for a verified example input. 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

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?

Annotations only declare readOnlyHint=false / openWorldHint=true / idempotentHint=false; the description goes far beyond that, disclosing that it never writes to the government source, that each call starts a metered Apify run billed $0.008 per result ($2.40–$8 per 1,000 depending on plan), that failed runs are free, that benchmark costs exactly one extra request, and that credit_union currently fails fast at no charge.

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?

Long but well-structured: purpose first, then a clearly labeled 'COST AND SIDE EFFECTS' block and a store link. Almost every sentence earns its place, though a few phrases (e.g. the repeated 'reads live from the official government source' claim) overlap with content already implied elsewhere.

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, no-output-schema tool, the description is close to complete: it names the metrics returned, flags that every mode returns the same field set, and discloses cost and failure behavior. The only gap is that it never characterizes the response envelope (single JSON run output vs. dataset), which an agent would have to infer.

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 the per-parameter docs are extremely rich (mode ordering, peerBasis fallback threshold, cost-cap semantics of maxResults), so the schema carries the load. The top-level description adds only the cost-per-result framing that ties into maxResults and does not enrich the other nine parameters, meriting the 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?

States a specific verb+resource with scope: a bank/credit-union financial-health screen over FDIC data, enumerating the concrete metrics (capital ratios, CRE concentration, deposit runoff, ROA/ROE/NIM) and QoQ deltas. An agent can tell this apart from siblings like epa-drinking-water-quality-screener or fema-nri-county-risk-profile without opening a 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?

Gives clear routing and prerequisite guidance — call describe-gov-data-tool for a verified example input — and reinforces it via parameter docs (state is 'strongly recommended', inspect priorItems for delta mode). It does not state explicit when-not-to-use conditions against the other sibling tools, so it stops short of the top band.

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