Provides IFSC code lookup via the Razorpay IFSC API, returning bank, branch, address, MICR, and support for UPI/NEFT/IMPS/RTGS.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@India Essentials MCP Which bank branch is IFSC SBIN0000001 and does it support UPI?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP server that gives AI assistants everyday Indian lookups: bank IFSC codes, PIN codes and air quality. No API keys needed.
Tool | What it does | Data source |
| Bank, branch, address, MICR and UPI/NEFT/IMPS/RTGS support for an IFSC code | Razorpay IFSC API |
| Post offices, district and state for a 6-digit PIN code | India Post (postalpincode.in) |
| Current AQI and pollutants for an Indian city | Open-Meteo |
| Current AQI for the area of a PIN code (PIN → district → AQI) | India Post + Open-Meteo |
Try asking your assistant:
"Which bank and branch is IFSC SBIN0000001, and does it support UPI?"
"What area is PIN code 560001?"
"Is it safe to go for a run in Delhi right now?"
"How is the air quality at PIN code 400001?"
# easiest (no install step)
uvx india-essentials-mcp
# or with pip
pip install india-essentials-mcpRelated MCP server: india-business-mcp-server
Add this to claude_desktop_config.json:
{
"mcpServers": {
"india-essentials": {
"command": "uvx",
"args": ["india-essentials-mcp"]
}
}
}Restart Claude Desktop and the tools will appear.
pip install -e ".[dev]"
pytest
npx @modelcontextprotocol/inspector india-essentials-mcp # try tools in a browser UIAir quality is modelled data on the US AQI scale, not an official CPCB ground-station reading.
aqi_by_pincode is district-level, not street-level.
Data comes from free third-party services, which may rate-limit or change.
aqi_by_pincode (combine PIN lookup with air quality)
GSTIN format validation
Caching to be kind to the free APIs (24h for IFSC/PIN, 15 min for AQI)
CPCB station-level AQI
MIT
Get current air quality for the area covered by a 6-digit Indian PIN code (for example '110001' for central Delhi). Uses the PIN's district to locate it, so the result is district-level, not street-level.
| Name | Required | Description | Default |
|---|---|---|---|
| pincode | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses an important behavioral trait: the lookup resolves via the PIN's district and returns district-level, not street-level, data. However, it omits other relevant traits such as invalid-PIN behavior, data freshness details, and what the response contains.
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?
Two tightly written sentences with no wasted language. The core purpose is front-loaded, and the district-level caveat follows immediately as useful qualification.
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 single-parameter lookup with no annotations or output schema, the description covers purpose, input format, example, and result granularity. It does not describe the return payload or error behavior, but the essential information needed to invoke the tool correctly is present.
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 0%, so the description must define the sole parameter. It does so well: '6-digit Indian PIN code', with a concrete example ('110001' for central Delhi) and an explanation of how the PIN is used (district-level lookup). This adds substantial meaning beyond the bare 'pincode' schema property.
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 states a specific verb and resource ('Get current air quality') and precisely scopes it to a 6-digit Indian PIN code, including an example. It also distinguishes the result granularity ('district-level, not street-level'), which helps an agent understand exactly what this tool returns compared with a generic air-quality tool.
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 clearly establishes the context for use: when you have a 6-digit Indian PIN code and want current air quality for that area. It does not explicitly name alternatives such as get_air_quality or lookup_pincode, so it stops short of full when-to-use/when-not guidance, but the applicable scenario is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get current air quality (AQI and pollutant levels) for an Indian city, e.g. 'Bengaluru' or 'Delhi'. Values are modelled estimates, not a ground-station reading.
| Name | Required | Description | Default |
|---|---|---|---|
| city | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full disclosure burden and delivers the non-obvious part: values are modelled estimates, not ground-station readings, which tells the agent how much to trust the numbers. It omits any statement on rate limits or behavior for an unrecognized city, so it is not fully complete.
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?
Two sentences, front-loaded with the verb, resource and return payload, followed by the caveat. Nothing redundant, nothing padded.
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 single-parameter read tool with no output schema, the description covers what comes back (AQI plus pollutant levels) and the data's reliability. The one gap is the lack of differentiation from aqi_by_pincode, which is exactly the disambiguation an agent needs from the sibling list.
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 0%, so the description must compensate, and it does by giving concrete example values ('Bengaluru', 'Delhi') that establish the expected naming convention. It doesn't specify whether variants like 'Bangalore' or 'New Delhi' are accepted.
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 (get current air quality), what is returned (AQI and pollutant levels), and the geographic scope (an Indian city). It never mentions the sibling aqi_by_pincode, so the city-vs-pincode distinction must be inferred from the parameter rather than stated.
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?
Usage is only implied: the examples 'Bengaluru' or 'Delhi' show this tool takes a city name, which hints that aqi_by_pincode handles postal-code lookups. There is no explicit 'use this when / use X instead' routing, which matters given a closely related sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get bank branch details (bank, branch, address, MICR, UPI/NEFT/IMPS/RTGS support) for an 11-character IFSC code such as 'HDFC0000001'.
| Name | Required | Description | Default |
|---|---|---|---|
| ifsc | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations and no output schema, the description usefully discloses the shape of the returned record (bank, branch, address, MICR, payment-rail support), which the agent would otherwise not know. It says nothing about behavior on invalid/unknown codes, rate limits, or auth, which are the remaining gaps.
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 sentence, front-loaded with the action and resource, with the field list compactly parenthesized and the format example placed last. 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?
For a one-parameter read lookup with no annotations and no output schema, the description covers input format, output fields, and purpose. Only error/edge-case behavior and any output structure nuances are left unspecified.
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 0%, so the description must carry parameter meaning, and it does: it specifies the exact format constraint (11 characters) and supplies a concrete example ('HDFC0000001'). This is exactly the missing information in 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 and resource ('Get bank branch details') plus the exact key input type ('11-character IFSC code') and enumerates the returned fields, so the agent knows precisely what it gets. The resource (IFSC code) is disjoint from the sibling tools (pincode, air quality), so no ambiguity arises.
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 example value 'HDFC0000001' implicitly tells the agent when and how to call it (when an IFSC code is in hand). There is no explicit when-not-to-use or alternative routing, but the sibling tools operate on entirely different inputs, so exclusion guidance is largely unnecessary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the post offices, district and state for a 6-digit Indian PIN code.
| Name | Required | Description | Default |
|---|---|---|---|
| pincode | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. The word 'List' plus the domain (postal data) implies a read-only lookup with no side effects, which is reasonable, but it does not state that explicitly nor mention rate limits, auth, or behavior on invalid/nonexistent PIN codes.
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 front-loaded sentence with zero filler; the resource and the input constraint both appear before the sentence ends. Nothing could be removed without losing information.
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 one-parameter lookup with no output schema, the description covers the essential input constraint and names the main returned fields (post offices, district, state). It could say slightly more about the return shape (e.g., a list of post office records), but an agent has enough to call it correctly.
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 0%, so the description must compensate, and it does: it specifies the parameter is a 6-digit Indian PIN code, a constraint the bare string schema does not convey. It stops short of clarifying format edge cases (leading zeros, spaces, exactly six digits), so it is strong but not exhaustive.
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 (List) and concrete return content (post offices, district, state) scoped to a 6-digit Indian PIN code, which is clearly distinct from lookup_ifsc (bank codes) and get_air_quality. However, it never acknowledges aqi_by_pincode, the sibling that takes the same pincode input, so the differentiation is left implicit rather than stated.
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?
Usage is implied by the stated return content — an agent can infer it is the tool for postal/address data on a PIN code. There is no explicit when-to-use statement, no mention of when to prefer aqi_by_pincode (which shares the pincode parameter), and no prerequisite or error guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.2.0aqi_by_pincodeget_air_qualitylookup_ifsclookup_pincodeScored across 4 tools
Each tool targets a distinct input type: IFSC codes, PIN codes, and city names. The only potential confusion is between get_air_quality and aqi_by_pincode, but the descriptions clearly differentiate city-level vs district-level lookups and explain the resolution mechanism.
Two tools use a clean lookup_ prefix (lookup_ifsc, lookup_pincode), but the AQI tools deviate: get_air_quality uses a different verb and aqi_by_pincode drops the verb entirely. The pattern is still readable and mostly predictable, just not uniform.
Four tools is well-scoped for a focused reference server, and each tool earns its place by covering a distinct lookup need without redundancy.
The read-only surface covers the key reference lookups (IFSC, PIN, AQI by city and by PIN) with no dead ends for the stated purpose. Minor gaps exist, such as searching banks by name or resolving a place name to PIN codes, but agents can largely work around them.
Real-world data for agents: air quality, geocoding, quakes, holidays, web search
Free web search, 130M+ business records, local search, weather and travel data for AI agents.
Cross-border payment & banking intelligence for AI agents: SWIFT/BIC, IBAN, sanctions, FX, tracking.
Discover, inspect and run 63,000+ agent tools from one balance. Pay per call, no subscriptions.
