Zovo Bank Insurance Check

Estimate FDIC deposit coverage

estimate_deposit_coverage

Read-onlyIdempotent

Use this when the user wants to know how much of their bank deposits are FDIC insured. Takes up to 30 accounts (FDIC cert, ownership category, balance, owners, trust beneficiaries), checks each bank in live FDIC records, and applies $250,000 per owner per bank per ownership category, joint shares, and the 2024 trust rule ($250,000 per beneficiary, up to 5). Returns insured and uninsured totals per bank and category, a PDF worksheet and a CSV. The result is an estimate; it does not replace FDIC EDIE and does not cover credit unions.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "accounts": "<accounts>"
    },
    "name": "estimate_deposit_coverage"
  }
}

Input Schema

Name	Required	Description	Default
`accounts`	Yes	Accounts to estimate, e.g. [{"cert":3511,"category":"single","balance":300000}]. Up to 30.

Output Schema

Name	Required	Description	Default
`kind`	Yes
`banks`	Yes
`errors`	Yes
`source`	Yes
`totals`	Yes
`edie_url`	Yes
`downloads`	Yes
`rules_url`	Yes
`bank_check`	Yes
`banks_count`	No
`errors_count`	No
`accounts_used`	Yes
`estimate_note`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 8, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds genuinely new context: it hits live FDIC records (consistent with openWorldHint), caps input at 30 accounts, spells out the coverage rules applied, and discloses that it produces PDF and CSV artifacts alongside totals. It also sets expectations that the result is an estimate with explicit scope limits.

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?

Front-loaded with the trigger condition and the scope limit, then the mechanism, then the output and caveats. It is dense but nearly every clause carries information; the long compound sentences could be split for faster scanning.

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?

For a single-parameter, nested-account estimation tool with an output schema present, the description supplies the rules, limits, artifacts, and caveats an agent needs to call it correctly and to explain results. 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?

Schema coverage is 100% and nested account fields are well documented, so the baseline is 3. The description goes further by explaining what the account fields are used for — per-owner, per-bank, per-category aggregation, joint share splitting, and the 2024 trust rule of $250,000 per beneficiary up to 5 — which clarifies how balances and beneficiaries affect the computation.

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 (estimate FDIC deposit coverage for a user's bank deposits) in the very first sentence, framed as a triggering condition. It is immediately distinguishable from find_bank (certificate lookup) and bank_history (transaction history).

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 a clear when-to-use trigger ('when the user wants to know how much of their bank deposits are FDIC insured') and boundary conditions (not a replacement for FDIC EDIE, does not cover credit unions). It does not explicitly route to a sibling tool, though the schema points at find_bank for certificate numbers.

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

All Zovo Bank Insurance Check 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.

Resources

Need Help?