Skip to main content
Glama
jflamb

FDIC BankFind MCP Server

by jflamb

Search Institution History / Structure Changes

fdic_search_history
Read-onlyIdempotent

Search for structural change events in FDIC-insured financial institutions, including mergers, acquisitions, name changes, charter conversions, and failures. Filter by certificate number, event type, date range, or location to analyze institutional history.

Instructions

Search for structural change events for FDIC-insured financial institutions.

Returns records on mergers, acquisitions, name changes, charter conversions, failures, and other significant structural events.

Common filter examples:

  • History for a specific bank: CERT:3511

  • Mergers: TYPE:merger

  • Failures: TYPE:failure

  • Name changes: CHANGECODE:CO

  • By date range: PROCDATE:[2008-01-01 TO 2009-12-31]

  • By state: PSTALP:CA (two-letter state code)

Event types (TYPE): merger = institution was merged into another failure = institution failed assistance = received FDIC assistance transaction insurance = insurance-related event (new coverage, termination)

Common change codes (CHANGECODE): CO = name change CR = charter conversion DC = deposit assumption change MA = merger/acquisition (absorbed by another institution) NI = new institution insured TC = trust company conversion

Key returned fields:

  • CERT: FDIC Certificate Number

  • INSTNAME: Institution name

  • CLASS: Charter class at time of change

  • PCITY, PSTALP: Location (city, two-letter state code)

  • PROCDATE: Processing date of the change (YYYY-MM-DD)

  • EFFDATE: Effective date of the change (YYYY-MM-DD)

  • ENDEFYMD: End effective date

  • PCERT: Predecessor/successor CERT (for mergers)

  • TYPE: Type of structural change (see above)

  • CHANGECODE: Code for type of change (see above)

  • CHANGECODE_DESC: Human-readable description of the change code

  • INSDATE: Insurance date

Args:

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

  • filters (string, optional): 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., PROCDATE)

  • 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 event 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 to get history for a specific institution

Implementation Reference

  • The handler function for 'fdic_search_history', which queries the FDIC history endpoint and processes the results.
    async ({ cert, ...params }) => {
      try {
        const response = await queryEndpoint(ENDPOINTS.HISTORY, {
          ...params,
          filters: buildFilterString({
            cert,
            rawFilters: params.filters,
            rawFiltersPosition: "last",
          }),
        });
        const records = extractRecords(response);
        const pagination = buildPaginationInfo(
          response.meta.total,
          params.offset ?? 0,
          records.length,
        );
        const output = { ...pagination, events: records };
        const text = truncateIfNeeded(
          formatSearchResultText("events", records, pagination, [
            "CERT",
            "INSTNAME",
            "TYPE",
            "PROCDATE",
            "PCITY",
            "PSTALP",
          ]),
          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 input schema (zod) defining the arguments for 'fdic_search_history'.
    const HistoryQuerySchema = CommonQuerySchema.extend({
      cert: z
        .number()
        .int()
        .positive()
        .optional()
        .describe(
          "Filter by FDIC Certificate Number to get history for a specific institution",
        ),
    });
  • The registration of 'fdic_search_history' tool using the McpServer instance.
      server.registerTool(
        "fdic_search_history",
        {
          title: "Search Institution History / Structure Changes",
          description: `Search for structural change events for FDIC-insured financial institutions.
    
    Returns records on mergers, acquisitions, name changes, charter conversions, failures, and other significant structural events.
    
    Common filter examples:
      - History for a specific bank: CERT:3511
      - Mergers: TYPE:merger
      - Failures: TYPE:failure
      - Name changes: CHANGECODE:CO
      - By date range: PROCDATE:[2008-01-01 TO 2009-12-31]
      - By state: PSTALP:CA (two-letter state code)
    
    Event types (TYPE):
      merger = institution was merged into another
      failure = institution failed
      assistance = received FDIC assistance transaction
      insurance = insurance-related event (new coverage, termination)
    
    Common change codes (CHANGECODE):
      CO = name change
      CR = charter conversion
      DC = deposit assumption change
      MA = merger/acquisition (absorbed by another institution)
      NI = new institution insured
      TC = trust company conversion
    
    Key returned fields:
      - CERT: FDIC Certificate Number
      - INSTNAME: Institution name
      - CLASS: Charter class at time of change
      - PCITY, PSTALP: Location (city, two-letter state code)
      - PROCDATE: Processing date of the change (YYYY-MM-DD)
      - EFFDATE: Effective date of the change (YYYY-MM-DD)
      - ENDEFYMD: End effective date
      - PCERT: Predecessor/successor CERT (for mergers)
      - TYPE: Type of structural change (see above)
      - CHANGECODE: Code for type of change (see above)
      - CHANGECODE_DESC: Human-readable description of the change code
      - INSDATE: Insurance date
    
    Args:
      - cert (number, optional): Filter by institution CERT number
      - filters (string, optional): 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., PROCDATE)
      - 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 event records.`,
          inputSchema: HistoryQuerySchema,
          annotations: {
            readOnlyHint: true,
            destructiveHint: false,
            idempotentHint: true,
            openWorldHint: true,
          },
        },
        async ({ cert, ...params }) => {
          try {
            const response = await queryEndpoint(ENDPOINTS.HISTORY, {
              ...params,
              filters: buildFilterString({
                cert,
                rawFilters: params.filters,
                rawFiltersPosition: "last",
              }),
            });
            const records = extractRecords(response);
            const pagination = buildPaginationInfo(
              response.meta.total,
              params.offset ?? 0,
              records.length,
            );
            const output = { ...pagination, events: records };
            const text = truncateIfNeeded(
              formatSearchResultText("events", records, pagination, [
                "CERT",
                "INSTNAME",
                "TYPE",
                "PROCDATE",
                "PCITY",
                "PSTALP",
              ]),
              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 provide readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds valuable behavioral context beyond annotations: it explains what types of events are returned, provides extensive examples of filter syntax and event types, describes key returned fields, and gives guidance on output format preferences ('Prefer concise human-readable summaries or tables'). This significantly enhances the agent's understanding of how to use the tool effectively.

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?

The description is well-structured and front-loaded with the core purpose, followed by useful examples and explanations. While comprehensive, it maintains good information density with minimal waste. The only minor improvement would be slightly tighter editing of the examples section, but overall it's highly efficient.

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?

Given the tool's complexity (7 parameters, no output schema), the description provides exceptional completeness. It explains what the tool returns (event types, key fields), how to filter effectively with detailed examples, parameter usage guidance, and output format preferences. This fully compensates for the lack of output schema and gives the agent everything needed to use the tool correctly.

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 substantial value by providing extensive examples of how to use the filters parameter (with specific field names like CERT, TYPE, CHANGECODE, PROCDATE, PSTALP), explaining event types and change codes, and showing how these map to the filters parameter. This gives the agent much deeper understanding of parameter semantics than the schema alone.

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 for structural change events for FDIC-insured financial institutions.' It specifies the exact resource (structural change events) and distinguishes from siblings by focusing on history/structure changes rather than current snapshots, failures only, or financial data.

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 what types of events are returned (mergers, acquisitions, name changes, etc.) and includes common filter examples that help users understand when to apply this tool. However, it doesn't explicitly state when to use this tool versus alternatives like fdic_search_failures or fdic_search_institutions, which would be needed for a perfect score.

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