ifsc-mcp

List or search Indian bank codes and names

bank_directory

Read-onlyIdempotent

Look up the official 4-letter bank code for a bank by name, or list banks. Use before IFSC lookup when only a bank name is given.

Instructions

Look up the official 4-letter bank code for a bank, or list banks by name.

Every IFSC begins with a 4-letter bank code, and this is the tool that maps "HDFC Bank" -> "HDFC". Use it before ifsc_lookup or search_branches when the user gave a bank name rather than a code.

Returns ok: true with: banks (list of {"code", "name"}), count (total matches) and source (the upstream dataset URL).

Data comes from the published razorpay/ifsc dataset and is cached, so repeated calls are cheap. This returns banks, not branches - use search_branches or ifsc_lookup for a specific branch.

Args: query: Substring filter over code and name; omit for the full list. limit: Max rows, 1-500 (default 50, or 500 with no query).

Returns: Matching bank codes and names, or a structured error payload.

Example: Ask "what is the code for Kotak Mahindra?" -> call bank_directory(query="kotak") and read banks[0]["code"].

Input Schema

TableJSON Schema

Name	Required	Description	Default
`limit`	No	Max banks to return, 1-500. Defaults to 50, or 500 with no query.
`query`	No	Optional case-insensitive fragment matched against both the 4-letter code and the full bank name, e.g. 'hdfc', 'kotak', 'state bank', 'cooperative'. Omit to list every bank (1511+).

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 2, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare readOnly, idempotent and open-world behavior, so the safety profile is covered. The description adds real context beyond that: the upstream razorpay/ifsc dataset, caching that makes repeated calls cheap, and the shape of the success and error payloads. It stops short of richer disclosure such as refresh cadence or staleness of the cached data.

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?

Opening sentence is front-loaded and the routing guidance comes early, which is the right priority order. There is mild redundancy: return values are described twice (a detailed 'Returns ok: true with...' block and a second 'Returns:' line), which costs a little tightness.

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?

With an output schema present the description need not enumerate return fields, yet it still covers routing, data source, caching, error shape, and a worked example. Nothing an agent needs to select or invoke this correctly is missing.

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%, so both parameters are already fully documented in the schema, which sets the baseline at 3. The description's Args section largely restates the schema (substring filter, omit for full list, 1-500 range) and adds little beyond the default-scaling note already present in the schema.

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 ('look up the official 4-letter bank code ... or list banks by name') and immediately scopes what it is not ('this returns banks, not branches'). The HDFC -> HDFC mapping example makes the transform concrete and distinguishable from branch-oriented siblings.

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

Usage Guidelines5/5

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

Explicitly states when to use it ('before ifsc_lookup or search_branches when the user gave a bank name rather than a code') and names the alternatives for the opposite case ('use search_branches or ifsc_lookup for a specific branch'). Both the selection condition and the exclusions are spelled out.

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

Deploy Server