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., "@BharatPay MCP validate PAN AABCT3518Q"
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 any AI agent — Claude Desktop, Cursor, Windsurf — instant access to Indian fintech utilities. IFSC bank lookups, PAN/GSTIN validation with checksums, mutual fund NAVs, UPI VPA identification, pincode lookups, and Indian-style INR formatting. Seven tools. Zero auth. Zero cost. Designed to complement Razorpay's official MCP server — they handle execution, BharatPay handles validation and lookups.
🎥 Demo coming soon · 📦 pip install bharatpay-mcp · 🔗 PyPI
Razorpay shipped an official MCP server in early 2025 for executing payment operations — creating orders, capturing payments, refunding. It's excellent.
But every Indian fintech project also needs a layer below that: validation and enrichment. Is this PAN's format correct? Does this GSTIN's mod-36 checksum verify? What bank does this IFSC code belong to? What's the PSP behind user@oksbi? What's today's NAV for Parag Parikh Flexi Cap?
Currently, an AI agent has to either hallucinate these answers or call seven different APIs with seven different auth schemes. BharatPay collapses all of it into a single MCP server an agent can install in 30 seconds.
Position-wise: BharatPay sits next to Razorpay's MCP, not in competition with it. They handle transactions; we handle validation. Use both together for a complete Indian-fintech AI stack.
Related MCP server: Tapetide MCP Server
Claude Desktop autonomously calling lookup_ifsc for an Indian bank lookup:
Tool | Input | What it returns |
|
| Bank, branch, address, MICR/SWIFT, supported rails (NEFT/RTGS/IMPS/UPI). Source: Razorpay's open IFSC API. |
|
| Format check, entity type (Individual/Company/HUF/Trust/...) decoded from the 4th character. |
|
| Format + mod-36 checksum verification, embedded state and PAN extraction. |
|
| District, state, all post offices. Source: India Post API. |
|
| Latest NAV from AMFI's daily file. Fuzzy name search or exact code lookup. Cached for 6h. |
|
| PSP identification (Google Pay/PhonePe/Paytm/...) and underlying bank from the handle suffix. |
|
|
|
┌─────────────────────┐ ┌──────────────────────┐
│ AI Agent │ MCP / stdio │ BharatPay MCP │
│ (Claude / Cursor) │ ─────────────────> │ (this server) │
└─────────────────────┘ └──────────┬───────────┘
│
┌───────────────────────────┼───────────────────────────┐
│ │ │
┌──────▼──────┐ ┌──────────▼─────────┐ ┌────────▼────────┐
│ Pure-logic │ │ Live HTTP APIs │ │ Cached file │
│ validators │ │ (no auth, no cost) │ │ (refreshed 6h)│
├─────────────┤ ├────────────────────┤ ├─────────────────┤
│ PAN │ │ ifsc.razorpay.com │ │ AMFI NAVAll.txt │
│ GSTIN+mod36 │ │ postalpincode.in │ │ (~6 MB, ~30K │
│ UPI VPA │ │ │ │ schemes) │
│ INR format │ │ │ │ │
└─────────────┘ └────────────────────┘ └─────────────────┘Design notes worth calling out:
Validators are pure functions. PAN, GSTIN, UPI, and INR run entirely offline — zero network, zero failures from API outages. The mod-36 GSTIN checksum is implemented from the GSTN spec (verified self-consistent: see tests/test_validators.py::test_gstin_checksum_self_consistent).
Network tools are async. IFSC and pincode lookups use httpx.AsyncClient so the MCP server can handle parallel tool calls without blocking.
AMFI data is cached, not re-fetched per call. A single 6 MB file covers all ~30,000 Indian mutual fund schemes; refreshing it on every NAV query would be wasteful and slow. Cache TTL: 6 hours.
Tool descriptions are LLM-tuned. Each tool's docstring is written for the model to read — explicit input formats, examples, and what it returns. This is what determines whether an agent successfully picks the right tool.
No data leaves your machine for offline tools. PAN/GSTIN/UPI/INR validation never touches the network. Useful for compliance-sensitive contexts.
pip install bharatpay-mcpThen add to ~/Library/Application Support/Claude/claude_desktop_config.json (Mac) or the Windows equivalent:
{
"mcpServers": {
"bharatpay": {
"command": "python",
"args": ["-m", "bharatpay_mcp"]
}
}
}Restart Claude Desktop. Look for the 🔌 icon — bharatpay should be listed.
git clone https://github.com/angelina10504/bharatpay-mcp
cd bharatpay-mcp
pip install -e .Add to .cursor/mcp.json in your project:
{
"mcpServers": {
"bharatpay": {
"command": "python",
"args": ["-m", "bharatpay_mcp"]
}
}
}Once connected, try these prompts in Claude Desktop:
"Look up IFSC code KKBK0000261 and tell me what payment rails it supports."
"Is
29AAGCB7407Q1ZNa valid GSTIN? If so, what state is the entity registered in?"
"What's today's NAV for Parag Parikh Flexi Cap regular growth?"
"My friend's UPI ID is
priya@oksbi— which app does she use?"
"Format ₹12,00,000 in Indian style and tell me what it would be in paise."
The agent will autonomously pick the right tool. You'll see the tool call and its structured JSON response inline.
pip install -e ".[dev]"
pytest tests/ -v17 unit tests cover all offline validators including a self-consistency test for the GSTIN mod-36 checksum.
validate_aadhaar(number) — Verhoeff checksum (offline, no UIDAI API needed)
get_holiday_calendar() — RBI bank holidays (settlement-day awareness)
stock_quote(symbol) — NSE/BSE live quotes for RELIANCE.NS-style tickers
tax_slab_calculator(income, regime) — Old vs new regime estimation
Bundle as npx @bharatpay/mcp for zero-install distribution
Open an issue on GitHub if you want any of these prioritized.
When Razorpay launched their MCP server, they framed it as "designed for an AI-first world." That framing is right — but transactions are only half the picture. Half the engineering effort in any Indian fintech goes into validation, enrichment, and lookups that an AI agent can't reliably hallucinate. That's the gap BharatPay fills.
If you're building AI tools for Indian fintech and you find a utility missing, open an issue or send a PR.
MIT — see LICENSE. All upstream APIs (Razorpay IFSC, India Post, AMFI) are themselves free and publicly available under their respective terms.
Built by Angelina Gupta · April 2026
Format an INR amount in Indian numbering conventions (lakh/crore
grouping with comma every two digits after the first three) and return
word form. Set paise=True if amount is in paise (Razorpay API style,
where 1 INR = 100 paise).
| Name | Required | Description | Default |
|---|---|---|---|
| paise | No | If True, treat amount as paise. | |
| amount | Yes | Number to format. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the responsibility. It discloses the formatting behavior (lakh/crore grouping, word form) and the paise toggle. It could be more explicit about the exact return format (e.g., string structure), but overall it gives good insight.
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 efficient sentences: first sentence states the main purpose and formatting style, second explains the optional parameter. No redundancy.
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 simple formatting tool with an output schema, the description covers the essential behavior. It could elaborate on the exact output structure (e.g., returns both formatted number and word form?), but the provided details are sufficient for use.
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 description adds context for 'paise' by explaining the Razorpay API convention (1 INR = 100 paise). The 'amount' parameter description is minimal but schema covers it.
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 clearly states the tool formats an INR amount using Indian numbering conventions (lakh/crore grouping) and returns word form. It is distinct from sibling tools which are lookups/validations.
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 description explains when to use the tool (formatting INR amounts) and explains the 'paise' parameter for Razorpay API style. However, it does not provide explicit when-not-to-use or alternatives, but the sibling tools are unrelated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up bank, branch, address, and supported payment rails (NEFT/RTGS/IMPS/UPI) for an Indian IFSC code. Uses Razorpay's free public IFSC API.
| Name | Required | Description | Default |
|---|---|---|---|
| ifsc | Yes | 11-character IFSC code (e.g., 'KKBK0000261'). |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool performs a read-only lookup via Razorpay's public API, but omits details like rate limits, authentication, error handling, or data freshness. This is adequate for a simple lookup but lacks depth.
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?
The description is two concise sentences, front-loaded with the primary action and key data returned. Every word serves a purpose, with no redundancy or fluff.
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?
Given that an output schema exists, the description does not need to detail return values. It sufficiently covers the tool's purpose, data fields, and data source. For a straightforward lookup tool with one parameter, this is complete.
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?
The input schema has 100% coverage with a description for the sole parameter. The tool description adds value by providing context (Indian IFSC, example format 'KKBK0000261') and mentioning the API source, going beyond what the schema alone offers.
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 clearly states the tool's function: looking up bank, branch, address, and payment rails for an Indian IFSC code. It explicitly differentiates from siblings (PAN, GSTIN, pincode, etc.) by specifying its unique resource.
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 description implies usage for querying IFSC codes but does not explicitly state when to use vs. alternatives, nor does it mention exclusions or prerequisites. Siblings are distinct enough that no conflict arises, but some guidance would improve clarity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up state, district, and post offices for an Indian PIN code using the free India Post API.
| Name | Required | Description | Default |
|---|---|---|---|
| pin | Yes | 6-digit PIN (e.g., '302001' for Jaipur). |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully convey behavior. It mentions 'free India Post API' hinting at external dependency and potential unreliability, but it does not disclose failure modes, rate limits, or idempotency.
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?
The description is a single sentence with no wasted words, effectively communicating the tool's purpose.
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 has an output schema (not shown) and describes returned data. However, it lacks guidance on error handling, invalid inputs, or network issues, which for a simple tool is adequate but not fully comprehensive.
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 parameter description in the schema is clear. The tool description adds no additional meaning beyond the schema's own description.
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 clearly states the verb 'look up', the resource 'state, district, and post offices', and specifies the API source. It is distinct from sibling tools that handle bank branches or validation.
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 tool's specific domain (Indian PIN codes), but the description does not explicitly state when to use it versus alternatives, nor does it mention when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validate Indian GSTIN: format, mod-36 checksum, and extract embedded state and PAN. Returns the registration state name from the leading state code.
| Name | Required | Description | Default |
|---|---|---|---|
| gstin | Yes | 15-character GSTIN (e.g., '29AABCT1332L1ZS'). |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description transparently details the tool's operations: validation of format and checksum, extraction of state and PAN, and return of state name. It does not cover error handling or rate limits, but the core behavior is well-described.
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?
The description is concise with two sentences, front-loading the purpose and key details. Every sentence adds value without redundancy.
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?
Given the single parameter, presence of an output schema, and clear description of validation logic, the description is nearly complete. It could briefly mention what happens on invalid input, but overall it is adequate.
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 description adds meaning by specifying the parameter is a 15-character GSTIN with an example '29AABCT1332L1ZS', clarifying the format beyond the schema's description.
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 clearly states it validates Indian GSTIN, including format and checksum, and extracts state and PAN. It distinguishes itself from sibling tools like validate_pan by focusing on GSTIN.
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 description does not provide explicit guidance on when to use this tool versus alternatives, such as validate_pan or lookup_pincode. The context of sibling tools suggests distinct purposes, but the description lacks proactive usage advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validate Indian PAN format and identify the entity type (Individual / Company / HUF / Trust / Partnership Firm / etc.) from the 4th character.
| Name | Required | Description | Default |
|---|---|---|---|
| pan | Yes | 10-character PAN (e.g., 'ABCDE1234F'). |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It mentions validation and entity identification but omits what happens on invalid input (e.g., error, null), auth requirements, or side effects. For a tool with no annotations, this is insufficient.
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, no extraneous words. Efficiently conveys core purpose.
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?
Has output schema but description does not elaborate on return values. Missing behavioral details like error handling. Adequate for a simple tool but could be more complete.
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% with a clear example. The description adds general purpose but no additional parameter-specific detail. Baseline 3 for high coverage.
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 clearly states the tool validates Indian PAN format and identifies entity type from the 4th character. It is specific and distinct from sibling tools which handle IFSC, GSTIN, etc.
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?
No explicit guidance on when to use this tool vs alternatives. However, sibling tools are for different entities (IFSC, GSTIN, pincode), so usage is implied. Lacks when-to-use or when-not-to-use statements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validate a UPI VPA's format and identify the issuing PSP and underlying bank from the handle suffix (e.g., 'oksbi' → Google Pay on State Bank of India).
| Name | Required | Description | Default |
|---|---|---|---|
| vpa | Yes | VPA in 'username@psp' format (e.g., 'angelina@oksbi'). |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the core behavior: format validation and PSP/bank identification via suffix mapping. With no annotations, it provides good transparency, though it omits details on error handling or limitations (e.g., doesn't check VPA existence).
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?
Single sentence, no wasted words, front-loaded with action (validate) and result (identify). Example is concise and illustrative.
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 simple tool with one parameter and an output schema, the description fully covers what the tool does. It explains format and mapping, which is sufficient given 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%, but the description adds value by explaining the expected format ('username@psp') and providing an example that maps suffix to PSP and bank. This enriches parameter understanding beyond the bare 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?
The description clearly states the tool validates UPI VPA format and identifies PSP and bank from handle suffix, with an explicit example. This distinguishes it from sibling tools that handle other identifiers (IFSC, PAN, GSTIN, etc.).
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 (when you have a UPI VPA), but no explicit guidance on when not to use it or alternatives. Sibling tools are different, but no comparative instructions.
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.1.0format_inrget_mutual_fund_navlookup_ifsclookup_pincodevalidate_gstinvalidate_panvalidate_upi_vpaScored across 7 tools
Each tool addresses a unique Indian financial or address validation task, with no overlap. IFSC, PAN, GSTIN, pincode, mutual fund NAV, UPI VPA, and INR formatting are all distinct and clearly separated.
All tool names follow a consistent verb_noun pattern (e.g., lookup_ifsc, validate_gstin, format_inr). Verbs like 'lookup', 'validate', 'get', and 'format' are used appropriately, with no mixing of conventions.
Seven tools is an appropriate number for a focused domain of Indian financial utilities. Each tool covers a key operation, and the count is neither too sparse nor excessive.
The tool set covers common Indian financial identifiers (IFSC, PAN, GSTIN, UPI), address lookup (pincode), mutual fund data, and currency formatting. This appears comprehensive for the intended use case, with no obvious missing operations.
Discover, inspect and run 63,000+ agent tools from one balance. Pay per call, no subscriptions.
Verified, pay-per-use API tools for AI agents through one authenticated connection.
140+ data APIs for agents: finance, banking validation, geo, weather, text. One API key.
Pay-per-use tool API for AI agents. Free tier, x402 USDC micropayments, or API key.