gst-einvoice-mcp

Overview Schema Source Related Servers Discussions Admin

Run the arithmetic and tax-split checks over an INV-01 payload

validate_payload

Run the parser's consistency checks on an INV-01 payload: item totals, invoice total, value-block sums, and tax split. Returns valid, warning paths, and schema errors without re-reading document.

Instructions

Take an INV-01 payload you already have and run the same consistency checks the parser runs, without re-reading any document. Useful for a payload you assembled yourself, or one you edited after parsing.

Four checks run: each item's total against its own components; the invoice total against the value block; each value-block total against the sum of the item fields; and the CGST/SGST-versus-IGST split against the two parties' state codes.

Comparisons use a rupee tolerance (0.05 by default), never exact equality, because real invoices round to the nearest rupee and exact comparison would flag almost every genuine document.

Returns valid (true when nothing was flagged), the warning list with the exact field path for each, and schema_error when the payload does not fit INV-01 at all. The tax-split check reports itself as skipped, as an informational note rather than a warning, under reverse charge and when the place of supply differs from the buyer's registered state, because it cannot evaluate those cases.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`invoice`	Yes
`tolerance`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Sep 15, 2026

TDQS

A4.7/5.0

Behavior5/5

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

With no annotations provided, the description carries full responsibility and delivers: it enumerates all four checks, explains the rupee tolerance and its rationale, and details the return fields (valid, warning list, schema_error) and the specific conditions under which the tax-split check is skipped. This is exceptionally transparent.

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?

The description is long but well-structured and front-loaded with the core purpose. Every sentence adds information, and the paragraphs organize checks, tolerance, and return behavior. It is not padded, though it could be trimmed slightly without losing substance.

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?

Despite having an output schema, the description explicitly covers the return semantics (valid, warning list, schema_error) and the nuanced skip behavior, which the output schema might not fully convey. For a validation tool with complex checks and edge cases, nothing needed for correct invocation is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must explain both parameters. It does: 'invoice' is clearly the INV-01 payload, and 'tolerance' is described as the rupee tolerance with a default of 0.05 and the reason for it. The description adds meaning well beyond the bare schema definitions.

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 ('run the consistency checks') over a specific resource ('an INV-01 payload you already have'), and immediately distinguishes itself from parse_invoice by noting it does so 'without re-reading any document'. The purpose is unmistakable and separate from both siblings.

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

Usage Guidelines4/5

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

Explicitly describes the intended use case ('payload you assembled yourself, or one you edited after parsing'), which is a clear when-to-use signal. It does not explicitly name alternatives or say when not to use it, but the contrast with parse_invoice is strongly implied by the opening phrase, so the guidance is adequate though not exhaustive.

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

Deploy Server