ifsc-mcp

Validate IFSC format offline

ifsc_validate

Read-onlyIdempotent

Validate IFSC codes offline against RBI structure rules without network calls. Reject malformed codes early and explain why a code is invalid.

Instructions

Check whether a string is structurally a valid IFSC, without any network call.

Applies the RBI/NEFC layout rules offline: exactly 11 characters, 4 leading letters for the bank code, a literal '0' as the 5th character, and 6 trailing alphanumeric branch characters.

Choose this over ifsc_lookup when you want to reject junk before spending a request, or to explain why a user-entered code is wrong. It does NOT confirm the branch exists - only ifsc_lookup does that.

Returns ok: true with: input, normalized, is_valid, bank_code, branch_code, reason and message. reason is a stable code: VALID, EMPTY, WRONG_LENGTH, INVALID_CHARACTERS, BAD_BANK_CODE, MISSING_BANK_SUBLET or BAD_BRANCH_CODE.

Args: ifsc: The candidate string to validate.

Returns: A validation report, always with ok: true - an invalid IFSC is a successful report, not an error.

Example: Ask "is HFDCC00001 a valid IFSC?" -> call ifsc_validate("HFDCC00001") and read reason == "MISSING_BANK_SUBLET".

Input Schema

TableJSON Schema

Name	Required	Description	Default
`ifsc`	Yes	The candidate IFSC string to check, e.g. 'HDFC0000001' or a messy user-typed value like ' hdfc 0000001 '. Case and whitespace are normalised before checking. May be empty - an empty value is a reportable result (reason EMPTY), not an error.

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.6/5.0

Behavior5/5

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

Annotations already cover readOnly/idempotent/closed-world, but the description adds genuinely useful behavior beyond them: no network call, normalization of case/whitespace, the always-`ok: true` contract ('an invalid IFSC is a successful report, not an error'), and the enumerated stable `reason` codes. That is real operational context an agent cannot get from the annotations alone.

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 core purpose and the sibling tradeoff, then laid out in readable blocks. The Returns section partially restates what the declared output schema already provides, which is mild redundancy, but the Example is compact and instructive.

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, offline, idempotent validator, everything an agent needs is present: the layout rules, normalization behavior, empty-input handling, the success-vs-error contract, and the reason codes. An output schema exists, so return-value detail is a bonus rather than a gap.

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% and the schema already documents normalization, emptiness, and maxLength, so the Args line ('The candidate string to validate') adds little. Baseline 3 applies since the schema does the heavy lifting; the description does not add format or syntax beyond it.

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+resource ('Check whether a string is structurally a valid IFSC') and immediately scopes it as offline/no-network. It explicitly distinguishes itself from the sibling `ifsc_lookup` by naming it and stating the boundary (validation vs. branch existence).

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?

Gives an explicit routing rule: 'Choose this over `ifsc_lookup` when you want to reject junk before spending a request', plus the when-not clause 'It does NOT confirm the branch exists - only `ifsc_lookup` does that.' Both the use case and the exclusion are stated, not implied.

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

Deploy Server