An open-source MCP server for Indian business, checkout, and logistics data — no API keys required. It offers the following tools:
Bank Branch Lookup (lookup_ifsc): Retrieve bank name, branch, address, contact, and supported payment features (UPI, RTGS, NEFT, IMPS) using an 11-character IFSC code.
PIN Code Lookup (lookup_pincode): Resolve a 6-digit Indian postal PIN code to associated post offices, blocks, circles, districts, and states via India Post's public API.
GSTIN Validation (validate_gstin): Validate the structure and Mod-36 checksum of a 15-character GSTIN offline, and extract the registered state/UT, embedded PAN, and entity type (e.g., Individual, Company, LLP, Trust).
PAN Validation (validate_pan): Validate the format of a 10-character PAN number offline and extract the legal entity type of the holder (e.g., Individual, HUF, Firm, Company, Government).
PIN Code Serviceability Check (check_pincode_serviceability): Determine whether a PIN code falls within allowed states or districts — useful for managing e-commerce delivery zones.
GST Tax Calculation (calculate_gst_tax): Compute a full GST breakdown (CGST, SGST, IGST) by validating the seller's GSTIN, detecting intra-state vs. inter-state transactions, and supporting both exclusive and inclusive tax modes.
Provides lookup of IFSC codes to get bank, branch, address, and payment features using Razorpay's public IFSC API.
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-business-mcp-server Validate PAN ABCDE1234F"
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 open-source Model Context Protocol (MCP) server designed to streamline tax withholding (TDS), verification, and invoicing compliance when hiring and paying Indian freelance developers and independent contractors. Exposes public data APIs, local tax-compliance rules, and validation tools directly to LLM agents (like Claude Desktop or Cursor).
This server enables LLM clients to verify contractor identities, cross-reference GSTIN and PAN alignment, compute tax withholding (TDS) percentages (e.g., Section 194J vs. 194C), validate banking details (IFSC), and verify delivery zone serviceability.
graph TD
A[LLM Agent / Client] -->|Tool Call or Resource Read| B(MCP Server Entrypoint)
B --> C{Request Type}
C -->|IFSC / Pincode| D{24hr In-Memory Cache}
D -->|Hit| E[Return Cached JSON]
D -->|Miss| F[Fetch Upstream Public API]
F -->|Success| G[Update Cache & Return]
F -->|429 Rate Limit| H[Error: Rate Limit Message]
C -->|GSTIN / PAN| I[Local Regex & Checksum Logic]
C -->|Tax / Serviceability| J[Process with State & Zone Rules]
C -->|GST Slabs / State list| L[Read Static Resource Data]
I --> K[Return Output Payload]
J --> K
L --> K
E --> A
G --> A
H --> A
K --> ARelated MCP server: mcp-india-stack
Every company hiring remote Indian software developers or onboarding independent contractors spends hours validating their tax identifiers (PAN, GSTIN), verifying payout destination branch details (IFSC), and calculating withholding tax (TDS) brackets (e.g. Section 194J vs 194C). Because these systems are usually verified manually, LLM agents running contractor onboarding pipelines couldn't inspect or cross-reference these rules mid-workflow.
This server bridges that gap by grouping tax compliance rules, bank lookups, and offline structural validators into a single plug-and-play local server, allowing AI agents to fully handle freelancer onboarding verification.
This server performs structural validation (e.g., verifying a GSTIN's Mod-36 checksum, checking PAN pattern syntax, and checking PAN-GSTIN matching logic). It does not query official databases (like NSDL or the GST portal) to verify if the identifiers are active or registered to a real entity. This is an auxiliary utility for onboarding, forms, routing, and autocomplete, not a replacement for official, paid KYC/verification APIs.
This server implements Tools (executable actions) from the Model Context Protocol specification. This allows LLM agents to perform validation checks, local compliance calculations, and branch lookups.
lookup_ifscDescription: Queries bank, branch, address, contact, and supported payment features (UPI, IMPS, NEFT, RTGS) from an 11-digit IFSC code.
Upstream API: Razorpay's public IFSC API (https://ifsc.razorpay.com/) - free, no key.
Features: Automated local regex checking and a 24-hour local TTL cache.
lookup_pincodeDescription: Resolves a 6-digit Indian PIN code to a list of post offices, divisions, districts, states, and circles.
Upstream API: India Post's public API (https://api.postalpincode.in/) - free, no key.
Features: Automated local formatting validation and a 24-hour local TTL cache.
validate_gstinDescription: Verifies a 15-digit GSTIN (Goods and Services Tax Identification Number) locally.
Features:
Full structural regex check.
Offline Mod-36 weighted sum checksum validation.
Extracts registered Indian State/UT name, PAN, and Taxpayer/Entity Type (e.g. Individual, Company, Firm, LLP, Trust).
validate_panDescription: Validates format and structure of a 10-character Permanent Account Number (PAN) card locally.
Features:
Full structural regex check.
Extracts the legal entity type of the holder (Individual, HUF, Firm, LLP, Company, Government, Trust, etc.).
check_pincode_serviceabilityDescription: Custom utility to check if a PIN code belongs to specific allowed states or districts. Useful for managing serviceable checkout/delivery zones in e-commerce workflows.
calculate_gst_taxDescription: Computes GST tax breakdowns (CGST, SGST, IGST) automatically.
Validates the seller's GSTIN and matches the seller's registration state against the buyer's state.
Handles exclusive and inclusive tax calculations.
Routes taxes to CGST+SGST (if intra-state) or IGST (if inter-state).
verify_freelance_contractorDescription: Evaluates an Indian freelancer or contractor for onboarding and tax compliance (TDS withholding brackets under Section 194J/194C, PAN-GSTIN matching, entity classification).
Features:
Offline-first validation and verification.
Cross-checks if the PAN embedded inside the GSTIN matches the standalone PAN.
Classifies Holder Type (Individual vs Corporate entity) based on the 4th letter of the PAN.
Computes appropriate TDS withholding rate brackets (e.g. 2% for Technical Services under Section 194J, 1% for Individual Contractors under 194C, 2% for Corporate Contractors under 194C, and a 20% penalty withholding alert under Section 206AA if PAN is invalid).
Returns actionable warnings and recommendations for compliance and banking audits.
bulk_validate_gstinsDescription: Validates a batch of GSTIN codes in a single request (maximum 50 items). Returns verification status, state registrations, and taxpayer types.
bulk_validate_pansDescription: Validates a batch of PAN card numbers in a single request (maximum 50 items). Returns validation status and entity classifications.
bulk_lookup_ifscDescription: Performs batch bank branch lookups for a list of IFSC codes in a single call (maximum 50 items). Optimizes speed by retrieving details from the 24-hour cache where available.
MCP Resources are read-only documents that LLM agents can pull to gain domain context on Indian business rules.
india-business://gst-slabsName: Indian GST Rate Slabs Reference
MimeType: text/markdown
Content: The official GST rate slabs in India (0%, 5%, 12%, 18%, 28%) and which goods/services they apply to.
india-business://state-codesName: GST State Codes Reference
MimeType: text/markdown
Content: Complete mapping of 2-digit GST state codes (e.g. 27 -> Maharashtra, 29 -> Karnataka) for cross-referencing state codes.
Here is how the tools respond directly in an LLM client:
Active configuration showing connected status in Cursor Settings
Real-time tool execution in Cursor Chat returning Indian business data lookup results
Instead of calling tools in isolation, an LLM agent (like Claude or Cursor) can chain these tools together to resolve a complete checkout business task.
User Prompt:
"Process a customer refund payout of ₹11,800 (GST inclusive, rate 18%) for a buyer located in Karnataka (pincode
560001). Verify their pincode is serviceable under our 'Karnataka' delivery rules. Our company's seller GSTIN is27AAPFU0939F1ZV(registered in Maharashtra). If serviceable, calculate the CGST/SGST/IGST tax routing breakdown and lookup the bank branch details for their beneficiary IFSC codeHDFC0000123so we can queue the payout transfer."
How the Agent Solves It (Multi-Turn Tool Chaining):
Serviceability Check:
The Agent calls check_pincode_serviceability(pincode: "560001", allowedStates: ["Karnataka"]).
Output: Pincode 560001 belongs to Bangalore, Karnataka. Status: Serviceable.
GST Routing & Calculations:
The Agent calls calculate_gst_tax(amount: 11800, rate: 18, sellerGstin: "27AAPFU0939F1ZV", buyerStateCodeOrName: "Karnataka", inclusive: true).
Output: The seller is registered in Maharashtra (27) and the buyer is in Karnataka (29). Because these are different states, it routes the entire tax as IGST (₹1,800) on a base amount of ₹10,000.
Bank Transfer Destination Verification:
The Agent calls lookup_ifsc(ifsc: "HDFC0000123").
Output: IFSC code resolves to HDFC Bank, Madurai West Veli Street branch (Tamil Nadu).
Final Agent Response:
"Refund payout verified and calculated successfully:
Logistics: Pincode
560001is confirmed serviceable inside Karnataka.Tax Routing: Out-of-state transaction (Maharashtra to Karnataka), requiring IGST (18%) routing. Base amount is ₹10,000.00 and routed IGST is ₹1,800.00 (total invoice payout: ₹11,800.00).
Settlement: Beneficiary bank branch is HDFC Bank, Madurai branch, West Veli Street. UPI, IMPS, NEFT, and RTGS are supported.
Transfer is ready to be queued for payout."
Prompt: "What is the branch address and state for IFSC HDFC0000123?"
Claude Tool Call:
{
"name": "lookup_ifsc",
"arguments": {
"ifsc": "HDFC0000123"
}
}Response:
{
"isValid": true,
"data": {
"ifsc": "HDFC0000123",
"bank": "HDFC Bank",
"branch": "MADURAI - TAMIL NADU",
"address": "NO. 7-A WEST VELI STREETMADURAITAMILNADU625 001",
"city": "MADURAI",
"district": "MADURAI",
"state": "TAMIL NADU",
"contact": "+919840673333",
"upi": true,
"rtgs": true,
"neft": true,
"imps": true
}
}Prompt: "Calculate 18% GST tax breakdown for a ₹10,000 service sold by a seller with GSTIN 27AAPFU0939F1ZV to a buyer in Karnataka."
Claude Tool Call:
{
"name": "calculate_gst_tax",
"arguments": {
"amount": 10000,
"rate": 18,
"sellerGstin": "27AAPFU0939F1ZV",
"buyerStateCodeOrName": "Karnataka"
}
}Response:
{
"isValid": true,
"sellerState": "Maharashtra",
"buyerState": "Karnataka",
"isInterState": true,
"breakdown": {
"baseAmount": 10000,
"cgstRate": 0,
"cgstAmount": 0,
"sgstRate": 0,
"sgstAmount": 0,
"igstRate": 18,
"igstAmount": 1800,
"totalGstRate": 18,
"totalGstAmount": 1800,
"totalAmount": 11800
}
}Prompt: "Run onboarding compliance check for a contractor with PAN AAPPU0939F and GSTIN 27AAPPU0939F1ZA."
Claude Tool Call:
{
"name": "verify_freelance_contractor",
"arguments": {
"pan": "AAPPU0939F",
"gstin": "27AAPPU0939F1ZA"
}
}Response:
{
"panValid": true,
"gstinValid": true,
"gstinProvided": true,
"entityType": "P",
"entityTypeName": "Individual (Proprietorship)",
"isIndividualFreelancer": true,
"panGstinMatch": true,
"tdsWithholdingSection": "Section 194J (Technical Services) / Section 194C (Contractor)",
"tdsStandardRatePercent": "2% (Technical Services/Software) or 1% (General Contract)",
"tdsRateAppliedPercent": 2,
"complianceStatus": "MATCHED",
"warnings": [],
"recommendations": [
"For software development or coding consulting, deduct 2% TDS under Section 194J.",
"For general outsourcing contracts (non-technical), deduct 1% TDS under Section 194C.",
"The contractor has a valid GSTIN. Verify that their invoices charge the standard 18% GST for services and display their GSTIN."
]
}Node.js (v18.0.0 or higher recommended for native fetch support).
npm (comes with Node.js).
Available on npm — run directly via npx:
{
"mcpServers": {
"india-business-data": {
"command": "npx",
"args": [
"-y",
"@denispaul/india-business-mcp-server"
]
}
}
}Clone the project to your chosen workspace directory:
git clone https://github.com/denispaul2406/india-business-mcp-server.git
cd india-business-mcp-serverInstall dependencies:
npm installCompile the TypeScript codebase:
npm run buildTo connect the server to Claude Desktop, edit your claude_desktop_config.json file.
Windows Path: %appdata%\Claude\claude_desktop_config.json
macOS/Linux Path: ~/Library/Application Support/Claude/claude_desktop_config.json
Add the server using your local build path:
{
"mcpServers": {
"india-business-data": {
"command": "node",
"args": [
"build/index.js"
]
}
}
}(Note: Because Claude Desktop runs globally, you must replace "build/index.js" with the absolute path to this folder on your machine, e.g. "C:/Users/username/Desktop/mcp-server/build/index.js").
Restart Claude Desktop, and you will see the tool icon appear in the chat prompt.
To connect the server to Cursor:
Open Cursor Settings -> Features -> MCP.
Click + Add New MCP Server.
Configure as:
Name: india-business-data
Type: stdio
Command: node build/index.js (Note: Replace with the absolute path on your machine, e.g. node C:/Users/username/Desktop/mcp-server/build/index.js)
Save and look for the green status light indicating it's active.
You can dry-run the core logic and cache verification using our prebuilt test script:
node build/test.jsMIT License. Feel free to copy, modify, and build upon this for your projects!
GitHub: github.com/denispaul2406
LinkedIn: linkedin.com/in/DenisPaul
Calculates GST (CGST, SGST, IGST) breakdown based on transaction amount, GST rate, seller's GSTIN and buyer's location/state. Determines inter-state vs intra-state routing automatically.
| Name | Required | Description | Default |
|---|---|---|---|
| rate | Yes | The GST tax rate percentage (e.g. 5, 12, 18, 28). | |
| amount | Yes | The transaction amount (price of goods/services). | |
| inclusive | No | Whether the provided amount is inclusive of GST. Defaults to false (exclusive). | |
| sellerGstin | Yes | The 15-character GSTIN of the seller. | |
| buyerStateCodeOrName | Yes | The state name or 2-digit state code of the buyer (e.g., 'Delhi' or '07'). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It describes the core logic (breakdown calculation, inter/intra-state routing) but omits behavioral details like validation requirements, error handling, or side effects. Adequate but not comprehensive.
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, well-structured sentence that front-loads the purpose and key functionality. No redundant words; every phrase adds value.
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 moderate complexity (5 parameters, no output schema). The description explains inputs and routing logic but lacks details about output structure or return format. While sufficient for basic use, it leaves gaps for an agent unfamiliar with GST.
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?
Input schema has 100% parameter coverage with descriptions. The description adds context (seller's GSTIN, buyer's location, inter-state routing) but does not enhance individual parameter semantics beyond the schema. Baseline score of 3 applies.
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 verb 'Calculates' paired with the resource 'GST (CGST, SGST, IGST) breakdown' clearly defines the tool's function. It distinguishes itself from sibling tools (validation/lookup) by being a calculation 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?
The description implies usage for GST calculation based on transaction details, but no explicit when-to-use or when-not-to-use guidance is provided. It does not mention alternatives or exclusions, leaving the agent to infer context from sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Checks if a given Indian PIN code is serviceable based on lists of allowed states or districts. Extremely useful for e-commerce checkout and shipping verification.
| Name | Required | Description | Default |
|---|---|---|---|
| pincode | Yes | The 6-digit PIN code (e.g., '560001') | |
| allowedStates | No | Optional list of allowed state names (e.g., ['Karnataka', 'Maharashtra']) | |
| allowedDistricts | No | Optional list of allowed district names (e.g., ['Bangalore', 'Mumbai']) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It explains that serviceability is based on allowed states/districts but does not disclose how the parameters interact (e.g., AND vs OR logic), error handling for invalid pincodes, or side effects. The description provides basic but incomplete behavioral context.
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 with no redundancy. The purpose and use case are stated upfront. Every word adds value.
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 no output schema and moderate parameter count (3), the description is insufficient. It lacks details on return format, error scenarios, and how allowedStates and allowedDistricts combine (e.g., union or intersection). For a serviceability check in e-commerce, agents need more complete guidance.
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 baseline is 3. The description does not add meaning beyond the schema—it merely restates that the check is 'based on allowed states or districts'. No elaboration on parameter constraints or interactions.
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 'checks' and the resource 'Indian PIN code serviceability', specifying it uses lists of allowed states or districts. It explicitly mentions the e-commerce checkout use case, distinguishing it from siblings like lookup_pincode.
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 provides a use case ('e-commerce checkout and shipping verification') but does not explicitly state when not to use this tool or what alternatives exist among siblings (e.g., lookup_pincode). The guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieves details about an Indian bank branch using its IFSC code (e.g. Bank Name, Branch, Address, Contact, and features like UPI, RTGS, NEFT, IMPS support). Uses caching to optimize response times.
| Name | Required | Description | Default |
|---|---|---|---|
| ifsc | Yes | The 11-character Indian Financial System Code (e.g., 'HDFC0000123') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It mentions caching to optimize response times, a behavioral trait. However, it does not disclose error handling, rate limits, or behavior for invalid IFSC 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?
Two sentences: first sentence states purpose and outputs, second mentions caching. Efficient and front-loaded with essential information, no wasted words.
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 no output schema, the description covers purpose, key outputs, and caching behavior. It could mention error responses or return format, but 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?
The single parameter 'ifsc' has 100% schema description coverage. The description adds format context (11-character, example) and the data retrieved, going beyond the schema's basic 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 tool retrieves details about an Indian bank branch using IFSC code, listing specific fields like Bank Name, Branch, Address, etc., and distinguishes it from sibling tools that handle GST, pincode, PAN, 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?
The description implies usage when an IFSC code is known, but does not explicitly state when to use this tool vs alternatives or provide when-not-to-use conditions. Sibling tools are different in domain, so confusion is low.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieves location details for an Indian Postal PIN code (e.g., Post Office name, Block, Circle, District, State). Uses caching to optimize response times.
| Name | Required | Description | Default |
|---|---|---|---|
| pincode | Yes | The 6-digit PIN code (e.g., '560001') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses caching behavior, which is a positive. However, it does not mention rate limits, data freshness, error handling, or any potential side effects beyond cache optimization.
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 extremely concise with two sentences, front-loading the purpose and key detail (caching). Every word adds value without unnecessary elaboration.
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 tool's simplicity (one parameter, no output schema), the description adequately covers purpose and caching. It lists the types of location details returned, which compensates for the lack of an output schema. A 5 would require mention of error states or source authority.
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% (one parameter with schema description). The description adds no further semantics beyond the schema's explanation of the pincode parameter, so it meets the baseline but does not exceed 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 retrieves location details for an Indian postal PIN code, listing specific output fields (Post Office name, Block, etc.). It uses a specific verb 'Retrieves' and resource 'location details for an Indian Postal PIN code', which distinguishes it from siblings like 'check_pincode_serviceability' that likely serve a different purpose.
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 mentions caching for optimization but does not provide explicit guidance on when to use this tool versus alternatives like 'check_pincode_serviceability'. Usage context is implied but not clearly delineated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validates the structure, format, and checksum of a GSTIN (Goods and Services Tax Identification Number), and extracts the State, PAN, Entity Type, and Checksum status.
| Name | Required | Description | Default |
|---|---|---|---|
| gstin | Yes | The 15-character GSTIN (e.g., '27AAPFU0939F1ZV') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the validation and extraction behavior but lacks details on side effects, rate limits, or authentication needs. For a simple validation tool, this is adequate but not superior.
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 sentence that conveys all essential information without unnecessary words. Perfectly front-loaded with the main 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?
For a tool with one parameter and no output schema, the description fully covers what the tool does and what it returns. No gaps remain given the tool's simplicity.
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 that the tool extracts State, PAN, Entity Type, and Checksum status, and provides an example format. This goes beyond the schema's type and pattern constraints.
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 explicitly states the tool validates structure, format, and checksum of a GSTIN and extracts components. This clearly distinguishes it from sibling tools like validate_pan or check_pincode_serviceability.
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 validating GSTINs but provides no explicit guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validates the format and structure of a Permanent Account Number (PAN), and extracts the legal entity/holder type (e.g., Individual, Company, Firm, Trust).
| Name | Required | Description | Default |
|---|---|---|---|
| pan | Yes | The 10-character PAN card number (e.g., 'ABCDE1234F') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must fully disclose behavior. It states validation and extraction but does not specify behavior on invalid input (error vs flag) or any side effects. For a validation tool, this is a gap.
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, front-loaded with purpose and extraction detail. Every word adds value, 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 validation tool with one parameter and no output schema, the description covers purpose and core behavior (extraction). Minor gap: no mention of return format, but extraction hint compensates.
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% with the single parameter 'pan' described. The description adds no new semantic information beyond the schema, meeting the baseline.
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 PAN format and extracts holder type, using specific verb ('validates', 'extracts') and resource ('Permanent Account Number'). It distinguishes from sibling tools like validate_gstin which validate different identifiers.
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 name and description but no explicit guidance on when to use vs alternatives. Siblings are different enough that confusion is unlikely, but the description lacks direct comparison or exclusion notes.
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.
v1.0.0calculate_gst_taxcheck_pincode_serviceabilitylookup_ifsclookup_pincodevalidate_gstinvalidate_panScored across 6 tools
Each tool targets a distinct function: GST calculation, pincode serviceability, IFSC lookup, pincode details, GSTIN validation, and PAN validation. Despite some semantic overlap between lookup_pincode and check_pincode_serviceability, the descriptions clearly differentiate them, so no ambiguity.
All tool names follow a consistent verb_noun pattern in snake_case (e.g., validate_gstin, lookup_ifsc). While verbs vary (calculate, check, lookup, validate), the pattern is uniform and predictable, enhancing readability and agent understanding.
With 6 tools, the server is well-scoped for its purpose of supporting Indian business operations. Each tool serves a unique and necessary function without redundancy, and the count is appropriate for the domain.
The tool set covers core Indian business needs: tax (GST), identification (PAN, GSTIN), banking (IFSC), and postal (pincode). However, it lacks tools for company registration (CIN) or other common identifiers, leaving minor gaps that a broader business verification server might address.
PDF tools + invoice extraction, bank statement parsing, GST reconciliation & GSTIN validation.
Exactly 50 data transformation and live web verification tools for AI agents.
300+ deterministic data utilities for AI agents: validate, normalize, parse, match, redact.
Indic transliteration plus Indian name, address, PIN, PAN, GSTIN normalization.
