fdic-banks-mcp-server

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

Annotations already declare this a read-only, idempotent, open-world operation, so the safety profile is covered. The description adds genuinely non-structured context: the default cohort is every institution in the same asset-size band that reported that quarter, and the output units (dollar amounts in thousands, ratios as percentages), which an agent cannot infer from annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, each earning its place: what is computed, how the peer group is configured, and the units of the returned numbers. Front-loaded with the core action and free of restatement of the tool name or title.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a six-parameter tool with an output schema, full schema descriptions, and read-only annotations, the description supplies the remaining decision-relevant context: what gets returned, how the default cohort is chosen, and the units. Deferred-metric and small-cohort behaviors are handled in the schema, so nothing an agent needs to call it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning beyond the schema: it explains the default and the narrowing/widening/naming semantics of peer_asset_band, peer_state and peer_certs as a family of mutually exclusive alternatives, which the schema states only piecewise. It does not add syntax or value-level detail for metrics or report_date beyond what the schema already documents.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource ('Compare one institution with a peer group for one quarter') and enumerates exactly what the comparison yields: the institution's value alongside peer median, quartiles, min/max, percentile and rank. This is clearly distinguishable from siblings like fdic_get_institution_financials (single institution) or fdic_query_financials without opening either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives clear context on how the peer group resolves by default and the three ways to change it (narrow to a state, widen to all sizes, name by CERT), which tells the agent when each peer-selection parameter applies. It stops short of explicitly naming a sibling alternative for the single-institution case, so it is context-rich but lacks exclusions.

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

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

Annotations already declare a read-only, idempotent, closed-world read, so this description clears the lower bar easily by adding substantial context: exactly what the detailed response contains (source tool, call parameters, row count, creation and expiry times, column schema, and unit/basis for amount/ratio/count columns), what the list-mode response contains, ordering (newest first), and page size (50). It also discloses the expiry behavior and the unauthenticated-canvas listing limitation, none of which is in the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Information is front-loaded: the source and identity of the dataframes come first, then the two modes, then the SQL-prep guidance, then the deployment caveat. The prose is dense and runs as one long paragraph, which slightly hurts scanability, but nearly every clause carries operational information rather than filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, yet the description still tells the agent what each mode returns and when to prefer which, and covers the unusual deployment case. For a two-mode read tool with defined lifecycle semantics (expiry), nothing needed to call it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema already documents both parameters, but the description adds operational meaning: the name comes from a dataset field and unlocks the full detail view, while offset is passed as next_offset from the prior page and is ignored when name is set. That cross-parameter interaction is a genuine addition beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource (describe df_<id> dataframes) and precisely names where they come from: staged by fdic_query_financials/fdic_get_deposits on oversized offset-0 results, or saved via fdic_dataframe_query's register_as. It also distinguishes the two modes (named describe vs. unnamed list), so an agent can tell it apart from the sibling query tools 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.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit when-to-use (read a table's columns this way before writing SQL for fdic_dataframe_query), how to choose between the two modes (pass name vs. omit name), and a concrete deployment exclusion: on unauthenticated HTTP where all callers share one canvas, listing is unavailable, so pass the name from a dataset field. Nothing is left to inference.

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

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

Goes well beyond the readOnly/idempotent annotations: it discloses type coercion quirks (DOUBLE as JSON numbers, dollar columns in thousands of USD, BIGINT returned as strings requiring CAST), rejected statement classes, the 1,000,000-row staging budget with oldest-dataframe eviction, and the register_as_clash and register_as_too_large failure modes. The clash-on-repeat behavior even qualifies the idempotent annotation, which is honest disclosure rather than a contradiction.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the core action, then the prerequisite, then the gotchas, in a tight six-sentence block. Some material (row budget, name-clash repeat behavior) partly duplicates the rich schema, but almost every sentence gives the agent something actionable.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a four-parameter SQL tool with an output schema, the description covers everything an agent needs: where tables come from, the describe-first step, type-mapping pitfalls, rejected SQL, and register_as lifecycle/limits. Return-value shape is correctly left to the output schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema already carries the parameter documentation and a 3 would be the floor. The description adds genuine semantics on top: register_as produces a materialized dataframe with a fresh TTL and unique-name requirement, and the CAST guidance shapes how the sql parameter must be written.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource — running one read-only SELECT (DuckDB SQL) across df_<id> dataframes — and names the exact sibling tools that stage those dataframes (fdic_query_financials, fdic_get_deposits) plus fdic_dataframe_describe. An agent can distinguish this from the sibling query tools 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.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives a clear prerequisite workflow ('Before writing SQL, pass each table name to fdic_dataframe_describe') and states the exclusion boundary (writes, DDL, file-reading functions and system catalogs rejected). It is clear about context and sequence but never explicitly contrasts when to query a staged dataframe versus calling fdic_query_financials directly.

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

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

Annotations already cover read-only/idempotent/open-world, so the description's real contribution is pagination mechanics (page-at-a-time, continue with offset, only offset 0 stages a dataframe), the June 30 annual cadence, and units in thousands. It stops short of describing empty-market behavior or error conditions, which keeps it off a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Four sentences, front-loaded with the dataset and scope, then the mode matrix, then pagination and defaults. Dense but nearly waste-free; the long 'With both' sentence is slightly overpacked but still parseable.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 9-parameter, no-required-parameter tool with an output schema and full schema coverage, this covers what remains: mode selection, defaulting, pagination protocol, unit conventions, and a pointer to the dataframe handoff. Nothing an agent needs to call it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3; the description earns a bump by explaining the interaction semantics the schema only states per-field — which geography types are accepted and what cert adds when combined. It does not restate syntax details already in the schema, which is correct.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States the specific dataset (FDIC Summary of Deposits, branch-level domestic deposits, annual as of June 30 from 1994) and then enumerates the three result shapes by parameter combination. An agent can tell exactly what comes back for cert-only, geography-only, and combined calls 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.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly maps each parameter combination to its output mode, states the default (latest survey year) and that branches/rankings are paged via offset. It names fdic_dataframe_query as the consumer of staged dataframes, but does not point to a sibling for nearby questions (e.g. drill-down on an institution identified here).

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

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

Annotations already cover the safety profile (readOnly, idempotent, openWorld), yet the description adds genuinely new behavioral context: a ~7-week publication lag after quarter end, history back to 1984, most-recent-quarter-first ordering, dollar amounts in thousands, and the unsuffixed vs _ytd accumulation rule. That is strong value-add; only paging/continuation mechanics are absent from the description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single dense paragraph that front-loads the core purpose (what is returned, keyed by CERT) before units, timing, and history caveats. Every clause carries information, though the packing of four distinct facts into one block is slightly heavy for parsing.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is complex (5 params, 49-value metric enum, large history), but the description supplies the non-obvious facts an agent needs — units, YTD vs quarterly semantics, sort order, data latency, and history depth — while an output schema exists to cover return values and annotations cover safety. Nothing material is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 100% schema description coverage the baseline is 3, but the description adds real meaning beyond the schema: it explains that unsuffixed income/return metrics are single-quarter while _ytd metrics accumulate from January 1, and that dollar figures are in thousands. These semantics are not conveyed by the bare enum list, which only names metrics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Get one institution's quarterly Call Report financials by CERT') and enumerates the content domains (balance sheet, income, returns, credit quality, capital ratios). The 'one institution' scope distinguishes it from multi-institution siblings like fdic_query_financials and fdic_compare_peers without needing to open their schemas.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The phrase 'one institution's ... by CERT' implies the single-institution use case, and the schema points at fdic_search_institutions for obtaining the CERT. However, the description never explicitly says when to prefer this over fdic_query_financials or fdic_compare_peers, nor states prerequisites or exclusions, so usage is inferred rather than declared.

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

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

Annotations already cover the safe/read-only, idempotent, open-world profile, and the description adds substantive behavior on top: newest-first ordering, the de-duplication rule that a merger or failure appears once from whichever side the CERT was on, branch-level suppression, and historical coverage start dates. These are exactly the semantics an agent cannot infer from structured fields.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with verb, key, and ordering, and every subsequent clause carries non-redundant information (dedup rule, branch exclusion, historical limits). The first sentence is dense and long, but no sentence is disposable.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Output schema exists, so return shape need not be described; the description instead covers ordering, de-duplication, event-type filtering effects, and temporal coverage. Nothing an agent needs in order to call this correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3; the description earns an extra point by explaining that event_types controls the otherwise-hidden branch-level records and by clarifying the from/to scope as coverage windows rather than mere filters. It doesn't add format detail, but here the schema already fully documents the parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The first clause names a specific verb (get), a scoped resource (one institution's structure-change history, keyed by CERT) and an ordering (newest first). It then enumerates the event families covered, so the agent can tell this apart from fdic_search_failures or fdic_search_institutions 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.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives clear usage context: branch-level events are excluded unless event_types includes branch, and merger/failure coverage windows (1969/1970) are stated. It never explicitly routes to a sibling (e.g., when to use fdic_search_failures instead), so it stops short of the exclusion-and-alternatives bar.

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

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

Annotations already declare readOnly, idempotent, and closed-world, so the safety profile is covered. The description adds real context beyond them: 'Served from built-in tables; no request to FDIC' tells the agent the call is offline, instant, and cannot fail on network or auth. Return content is covered by the output schema, so nothing further is required.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

One long but well-structured sentence that front-loads the purpose, then walks the topics in the same order as the enum, ending with the operational reassurance. Dense and informative rather than padded, though the section of the sentence duplicated by the enum description could be trimmed.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With a single enum parameter, full schema coverage, an output schema, and complete annotations, the description supplies everything an agent still needs: what each topic yields, which sibling tools the tables feed, and that no FDIC request is made. Nothing material is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the enum is fully described, so baseline is 3; the description goes further by spelling out the payload of each topic (e.g., change_codes carry the FDIC code, its event type, and level; coverage gives years and cadence). It is slightly redundant with the schema's enum description, which limits it to a 4.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb plus resource ('list the vocabulary') and enumerates exactly what is returned: metric names with FDIC field/unit/basis, bank charter classes, failure methods, structure-change codes, insurance funds, peer asset bands, and dataset coverage. This clearly distinguishes it from every sibling, which are data-query tools that consume this vocabulary rather than expose it.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Frames the tool as the reference for 'the other fdic_ tools' and names the siblings that depend on specific tables (fdic_get_institution_history for change codes, fdic_compare_peers for asset bands), which implies calling it when you need valid field names or enum values. It stops short of an explicit 'use this before querying / do not use for financial data' statement.

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

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

Annotations cover read-only/idempotent/open-world, but the description adds non-obvious behavior: default date scope is latest quarter only, offset 0 stages a full dataframe, and results are paged. It doesn't detail truncation/deduplication of certs/metrics (that lives in the schema) or error behavior, so not a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three tight sentences front-loaded with the core action, then use cases, then pagination/defaults. Every clause carries distinct information; no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 12 params, an output schema, and rich annotations, the description covers scope, defaults, pagination, and the dataframe-staging side effect. It leaves some detail (deferred_certs/metrics truncation, sort tie-breaking) to the schema, which is acceptable given the output schema exists.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3; the description adds value by recasting params in terms of intent — CERTs, HQ state, asset range, metric thresholds — and explaining the date default. The schema still carries the unit and format detail, so a 4 rather than 5.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Pull a multi-institution, multi-quarter Call Report panel'), defines the row grain (one row per institution per quarter), and enumerates the filters. This clearly distinguishes it from fdic_get_institution_financials (single bank) and fdic_compare_peers.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives two concrete use cases ('screen every bank in a state with a noncurrent-loan rate above 3%' vs 'build a trend panel for SQL') and describes pagination continuation. It also names fdic_dataframe_query as the downstream consumer of the staged dataframe, which routes the agent beyond this tool.

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

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

Annotations already declare readOnly, idempotent, and openWorld, so the safety profile is covered. The description adds real value beyond that: what is returned (failure date, acquirer, assets, deposits, estimated loss), that totals are included over every match, what group_by aggregates, and that dollar amounts are in thousands. It omits pagination/limit behavior and the CERT-less pre-1977 caveat, which live only in the schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, front-loaded with scope and filters before return shape and the resolution caveat. It is dense but not padded; the long opening sentence could be split for readability, and "plus totals over every matching event" is slightly redundant with the group_by sentence.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema covering return shape and annotations covering safety, the description supplies the remaining essentials: time scope, default resolution behavior, aggregation semantics, and unit convention. The only material gap is paging behavior and the pre-1977 CERT limitation, both of which are documented in the schema instead.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all 12 parameters thoroughly, including units, enums, and defaults. The description restates the filter dimensions and the thousands unit but adds no syntax or edge-case detail beyond the schema, which is the expected baseline for fully documented parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ("Search FDIC-insured bank failures and assistance transactions") and names the exact filter dimensions available. The scope phrase "since 1934" and the failures-vs-assistance distinction separate it cleanly from siblings like fdic_search_institutions.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit behavioral routing: "Searches failures only unless resolution is set to assistance or all," which tells the agent how to widen scope. It does not name an alternative sibling tool for the institution-search case, so the when-to-use-this-vs-that guidance is implied rather than spelled out.

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

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

Annotations only cover read-only/idempotent/open-world; the description adds substantial behavior the agent could not infer: fuzzy, case-insensitive, word-required name matching, matching against former and trade names with the result indicating which matched, and successor CERT for merged/failed institutions. That is exactly the kind of disclosure that prevents wrong calls.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Four sentences, front-loaded with purpose, then matching semantics, then return shape, then the exclusion caveat. No filler, and each sentence carries distinct information an agent needs.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, the description need not enumerate return fields, yet it briefly orients the agent (CERT key, status, successor CERT, assets/deposits). Combined with annotations covering the safety profile and a fully documented schema, nothing required to select or invoke this tool is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3, but the description adds cross-tool semantics — that records are keyed by CERT and that this CERT is the identifier every other fdic_ tool accepts — plus reinforces the name-matching semantics that govern the name parameter. The remaining parameters (sort, limit, offset, asset bounds) are left entirely to the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (Find) and resource (FDIC-insured banks and savings institutions) plus the searchable facets — name, CERT, location, size, charter class, holding company. It also explicitly scopes what is excluded (credit unions under NCUA), which cleanly separates it from siblings like fdic_search_failures and fdic_get_institution_financials.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives clear context for when this is the right tool — broad institution lookup across active and closed/merged/failed entities — and notes that CERT is the join key every other fdic_ tool consumes, which helps chaining. It stops short of naming an explicit alternative (e.g., use fdic_search_failures for failure-event data), so routing is inferred rather than stated.

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