Skip to main content
Glama
Sign In
mcp-india-stack

mcp-india-stack

by rehan1020
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

validate_pan

Read-onlyIdempotent

Validate Indian PAN format, decode entity type from the fourth character, and normalize tax identity records for KYC, invoicing, or vendor onboarding. Optionally verify against the online registry.

Instructions

Validate Indian PAN format and decode entity type from the 4th character.

Use when normalizing tax identity records in KYC, invoicing, or vendor onboarding.

Args: pan: PAN string, example: AAAPL1234C. Spaces and hyphens stripped automatically. verify_online: Optional opt-in online registry attestation (A4 level).

Returns: Standard envelope containing format validity, entity type, and decoded segments.

Notes: PAN check character is not publicly verifiable algorithmically.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "pan": "<pan>"
    },
    "name": "validate_pan"
  }
}

Input Schema

NameRequiredDescriptionDefault
panYes10-char PAN (spaces/hyphens allowed)
verify_onlineNoOptional opt-in online registry attestation (A4 level)

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.8.0
    • addedInput schema / properties / verify_online
      Added value: +{
+  "default": false,
+  "description": "Optional opt-in online registry attestation (A4 level)",
+  "title": "Verify Online",
+  "type": "boolean"
+}
  2. Changed4 schema fields changedv0.5.0
    • removedInput schema / additionalProperties
      Removed value: -false
    • addedInput schema / properties / pan / title
      Added value: +"Pan"
    • addedInput schema / title
      Added value: +"validate_panArguments"
    • addedOutput schema / title
      Added value: +"validate_panDictOutput"
  3. First observedv0.3.0

TDQS

A3.7/5.0
Behavior4/5

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

Annotations already cover read-only, idempotent, closed-world behavior, and the description adds genuinely useful context: spaces/hyphens are stripped automatically, check-character validity cannot be algorithmically confirmed, and verify_online is an opt-in attestation. Minor tension: an 'online registry attestation' option sits awkwardly with openWorldHint=false, though the default false keeps baseline behavior closed.

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-loads the purpose in the first sentence and then uses labeled Args/Returns/Notes blocks, so nothing is buried. Slightly verbose for a two-parameter validator, and the Returns section partly duplicates the output schema.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a two-parameter, read-only validator with an output schema and full annotation coverage, the description tells the agent everything needed to call it, including the normalization behavior and the check-character caveat. The only omission is guidance on batch or decode-only alternatives among the many sibling validators.

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 coverage is 100%, so the baseline is 3. The description does add a worked example ('AAAPL1234C') and clarifies that spaces and hyphens are stripped rather than rejected — useful, but modest given the schema already documents both parameters, including the same A4-level phrasing for verify_online.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Names a specific verb and resource ('Validate Indian PAN format') and adds a second function ('decode entity type from the 4th character'), which is more specific than the sibling validate_din/validate_tan names alone would convey. It stops short of distinguishing itself from decode_pan_type or bulk_validate_pan, both of which overlap with the decode and batch aspects.

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

Usage Guidelines3/5

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

'Use when normalizing tax identity records in KYC, invoicing, or vendor onboarding' gives a real usage context, but there are no exclusions and no routing to alternatives — notably bulk_validate_pan for batches and decode_pan_type if the caller only wants entity typing. Usage is implied rather than decided.

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

Deploy Server

Other Tools