Skip to main content
Glama
jflamb

FDIC BankFind MCP Server

by jflamb

Search Summary of Deposits (SOD)

fdic_search_sod
Read-onlyIdempotent

Search annual branch-level deposit data from FDIC-insured institutions using filters like year, location, or deposit amounts to analyze banking trends and branch performance.

Instructions

Search annual Summary of Deposits (SOD) data for individual bank branches.

The SOD report provides annual deposit data at the branch level, showing deposit balances for each office of every FDIC-insured institution as of June 30 each year.

Common filter examples:

  • All branches for a bank: CERT:3511

  • SOD for specific year: YEAR:2022

  • Branches in a state: STALPBR:CA

  • Branches in a city: CITYBR:"Austin"

  • High-deposit branches: DEPSUMBR:[1000000 TO *]

  • By metro area: MSANAMEBR:"Dallas-Fort Worth-Arlington"

Key returned fields:

  • YEAR: Report year (as of June 30)

  • CERT: FDIC Certificate Number

  • BRNUM: Branch number (0 = main office)

  • UNINAME: Institution name

  • NAMEFULL: Full branch name

  • ADDRESBR, CITYBR, STALPBR, ZIPBR: Branch address

  • CNTYBR: County

  • DEPSUMBR: Total deposits at branch ($thousands)

  • MSABR: Metropolitan Statistical Area code

  • MSANAMEBR: MSA name

  • LATITUDE, LONGITUDE: Coordinates

Args:

  • cert (number, optional): Filter by institution CERT number

  • year (number, optional): SOD report year (1994-present)

  • filters (string, optional): Additional ElasticSearch query filters

  • fields (string, optional): Comma-separated field names

  • limit (number): Records to return (default: 20)

  • offset (number): Pagination offset (default: 0)

  • sort_by (string, optional): Field to sort by (e.g., DEPSUMBR, YEAR)

  • sort_order ('ASC'|'DESC'): Sort direction (default: 'ASC')

Prefer concise human-readable summaries or tables when answering users. Structured fields are available for totals, pagination, and deposit records.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
filtersNoFDIC API filter using ElasticSearch query string syntax. Combine conditions with AND/OR, use quotes for multi-word values, and [min TO max] for ranges (* = unbounded). Common fields: NAME (institution name), STNAME (state name), STALP (two-letter state code), CERT (certificate number), ASSET (total assets in $thousands), ACTIVE (1=active, 0=inactive). Examples: STNAME:"California", ACTIVE:1 AND ASSET:[1000000 TO *], NAME:"Chase"
fieldsNoComma-separated list of FDIC field names to return. Leave empty to return all fields. Field names are ALL_CAPS (e.g., NAME, CERT, ASSET, DEP, STALP). Example: NAME,CERT,ASSET,DEP,STALP
limitNoMaximum number of records to return (1-10000, default: 20)
offsetNoNumber of records to skip for pagination (default: 0)
sort_byNoField name to sort results by. Example: ASSET, NAME, FAILDATE
sort_orderNoSort direction: ASC (ascending) or DESC (descending)ASC
certNoFilter by FDIC Certificate Number
yearNoFilter by specific year (1994-present). SOD data is annual.

Implementation Reference

  • The handler function for the fdic_search_sod tool, which queries the SOD endpoint and processes the results.
      async ({ cert, year, ...params }) => {
        try {
          const response = await queryEndpoint(ENDPOINTS.SOD, {
            ...params,
            filters: buildFilterString({
              cert,
              dateField: "YEAR",
              dateValue: year,
              rawFilters: params.filters,
            }),
          });
          const records = extractRecords(response);
          const pagination = buildPaginationInfo(
            response.meta.total,
            params.offset ?? 0,
            records.length,
          );
          const output = { ...pagination, deposits: records };
          const text = truncateIfNeeded(
            formatSearchResultText("deposit records", records, pagination, [
              "CERT",
              "YEAR",
              "UNINAME",
              "NAMEFULL",
              "CITYBR",
              "DEPSUMBR",
            ]),
            CHARACTER_LIMIT,
            "Request fewer fields, narrow your filters, or paginate with limit/offset.",
          );
          return {
            content: [{ type: "text", text }],
            structuredContent: output,
          };
        } catch (err) {
          return formatToolError(err);
        }
      },
    );
  • The Zod schema defining the input parameters for the fdic_search_sod tool.
    const SodQuerySchema = CommonQuerySchema.extend({
      cert: z
        .number()
        .int()
        .positive()
        .optional()
        .describe("Filter by FDIC Certificate Number"),
      year: z
        .number()
        .int()
        .min(1994)
        .optional()
        .describe(
          "Filter by specific year (1994-present). SOD data is annual.",
        ),
    });
  • Registration of the fdic_search_sod tool within the McpServer.
    export function registerSodTools(server: McpServer): void {
      server.registerTool(
        "fdic_search_sod",
        {
          title: "Search Summary of Deposits (SOD)",
          description: `Search annual Summary of Deposits (SOD) data for individual bank branches.
    
    The SOD report provides annual deposit data at the branch level, showing deposit balances for each office of every FDIC-insured institution as of June 30 each year.
    
    Common filter examples:
      - All branches for a bank: CERT:3511
      - SOD for specific year: YEAR:2022
      - Branches in a state: STALPBR:CA
      - Branches in a city: CITYBR:"Austin"
      - High-deposit branches: DEPSUMBR:[1000000 TO *]
      - By metro area: MSANAMEBR:"Dallas-Fort Worth-Arlington"
    
    Key returned fields:
      - YEAR: Report year (as of June 30)
      - CERT: FDIC Certificate Number
      - BRNUM: Branch number (0 = main office)
      - UNINAME: Institution name
      - NAMEFULL: Full branch name
      - ADDRESBR, CITYBR, STALPBR, ZIPBR: Branch address
      - CNTYBR: County
      - DEPSUMBR: Total deposits at branch ($thousands)
      - MSABR: Metropolitan Statistical Area code
      - MSANAMEBR: MSA name
      - LATITUDE, LONGITUDE: Coordinates
    
    Args:
      - cert (number, optional): Filter by institution CERT number
      - year (number, optional): SOD report year (1994-present)
      - filters (string, optional): Additional ElasticSearch query filters
      - fields (string, optional): Comma-separated field names
      - limit (number): Records to return (default: 20)
      - offset (number): Pagination offset (default: 0)
      - sort_by (string, optional): Field to sort by (e.g., DEPSUMBR, YEAR)
      - sort_order ('ASC'|'DESC'): Sort direction (default: 'ASC')
    
    Prefer concise human-readable summaries or tables when answering users. Structured fields are available for totals, pagination, and deposit records.`,
          inputSchema: SodQuerySchema,
          annotations: {
            readOnlyHint: true,
            destructiveHint: false,
            idempotentHint: true,
            openWorldHint: true,
          },
        },
        async ({ cert, year, ...params }) => {
          try {
            const response = await queryEndpoint(ENDPOINTS.SOD, {
              ...params,
              filters: buildFilterString({
                cert,
                dateField: "YEAR",
                dateValue: year,
                rawFilters: params.filters,
              }),
            });
            const records = extractRecords(response);
            const pagination = buildPaginationInfo(
              response.meta.total,
              params.offset ?? 0,
              records.length,
            );
            const output = { ...pagination, deposits: records };
            const text = truncateIfNeeded(
              formatSearchResultText("deposit records", records, pagination, [
                "CERT",
                "YEAR",
                "UNINAME",
                "NAMEFULL",
                "CITYBR",
                "DEPSUMBR",
              ]),
              CHARACTER_LIMIT,
              "Request fewer fields, narrow your filters, or paginate with limit/offset.",
            );
            return {
              content: [{ type: "text", text }],
              structuredContent: output,
            };
          } catch (err) {
            return formatToolError(err);
          }
        },
      );
    }
Behavior4/5

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable context beyond annotations: it explains the annual nature of SOD data (as of June 30), provides extensive filter examples, lists key returned fields, and includes output formatting guidance ('Prefer concise human-readable summaries or tables').

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?

The description is well-structured and efficiently organized: purpose statement, data context, filter examples, returned fields, parameter summary, and output guidance. Every section serves a clear purpose with zero wasted text, making it easy to scan and understand.

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 search tool with comprehensive annotations (read-only, open-world, idempotent) and full schema coverage, the description provides excellent context: it explains the data source (annual SOD reports), gives practical usage examples, lists key output fields, and includes formatting guidance. The absence of an output schema is compensated by the detailed field descriptions.

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. The description adds meaningful value by providing common filter examples that illustrate practical usage of the 'filters' parameter, listing key returned fields that help users understand what data they'll receive, and offering output formatting guidance that complements the parameter definitions.

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 description clearly states the tool's purpose: 'Search annual Summary of Deposits (SOD) data for individual bank branches.' It specifies the exact resource (SOD data), scope (annual, branch-level), and distinguishes it from siblings by focusing on deposit data rather than institution details, failures, or financials.

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 provides clear context about when to use this tool (for branch-level deposit data as of June 30 each year) and includes practical filter examples. However, it doesn't explicitly state when NOT to use it or name specific alternatives among the sibling tools for different data needs.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/jflamb/fdic-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server