GST tax invoices for India
Scored across 1 tool
The server exposes a single tool, so there is no possibility of selecting the wrong one. Its description also clearly delineates what it does versus what it explicitly does not do (e-invoice/IRN, e-way bill, export invoices).
The sole tool, generate_gst_invoice, follows a clean verb_noun snake_case convention that directly names its domain and action. There is no competing convention to clash with.
A single tool for a narrow, well-defined purpose (GST invoice generation) is defensible, but the surface is thin and the one tool is overloaded with parsing, validation, tax logic, rounding, and two output formats. Splitting validation/preview from generation would make the set easier to use.
The tool covers the core lifecycle of producing a GST invoice: input parsing, CGST/SGST/IGST determination, GSTIN validation, HSN summary, rounding, and PDF/Excel output. Gaps exist around post-generation correction, retrieval of prior invoices, and explicit exclusions (cess, e-invoice, e-way bill) that agents cannot work around within this server.
Use this when the user wants a GST invoice in the GST invoice format (a GST bill format or tax invoice for India) as a PDF and Excel file. Convert what the user pastes, or an uploaded photo or image of a bill or order, into the fields: seller {name, gstin, address, state}, buyer {name, gstin, address, state} and items [{description, hsn, qty, unit, rate, discount, gst_rate}]; details is only a fallback for text you cannot split. Decides CGST + SGST (or UTGST) or IGST from the place of supply, reads state codes from GSTINs, flags an invalid GSTIN without refusing, adds the HSN-wise summary, rounds the total to the nearest rupee and writes amounts in words (lakh, crore). Does not make an e-invoice (IRN, QR) or e-way bill, does not pick GST rates, and does not compute cess. Do not use for export invoices, invoices outside India or invoices without GST.
| Name | Required | Description | Default |
|---|---|---|---|
| sez | No | true when the buyer is an SEZ unit or developer: IGST applies even in the same state. Default false. | |
| bank | No | Optional bank details to print: {account_name, bank_name, account_number, ifsc, branch, upi}. | |
| buyer | No | The buyer: {name, gstin (if registered), address, state}. The buyer's state decides CGST + SGST or IGST unless place_of_supply is given. | |
| items | No | Line items as objects: [{"description":"Steel rod 12mm","hsn":"7214","qty":10,"unit":"kg","rate":520,"gst_rate":18}]. Text lines like "Steel rod, HSN 7214, 10 kg @ 520, 18%" are a fallback. | |
| terms | No | Optional terms or notes to print, e.g. "Payment within 30 days. Goods once sold will not be taken back." | |
| copies | No | 1 (default, original), 2 (original + duplicate) or 3 (original, duplicate for transporter, triplicate for supplier). | |
| seller | No | The seller issuing the invoice: {name, gstin, address, state, phone, email}. | |
| details | No | Fallback only: the invoice details pasted as text when they cannot be split into the fields above. | |
| ship_to | No | Optional delivery address when it differs from the buyer's, e.g. {"name":"Mehta Stores Warehouse","address":"Plot 7, GIDC, Vapi","state":"Gujarat"}. | |
| due_date | No | Optional due date, e.g. "2026-11-27", or terms such as "net 30", "30 days" or "on receipt". | |
| page_size | No | "A4" (default) or "Letter". | |
| invoice_date | No | Invoice date, e.g. "2026-10-28" or "28/10/2026" (day first). Default: today in India. | |
| invoice_number | No | Invoice number, up to 16 letters, digits, - or /, e.g. "INV/2026-27/045". | |
| reverse_charge | No | true when tax is payable on reverse charge. Default false. | |
| place_of_supply | No | Optional place of supply (state name or code), e.g. "Karnataka" or "29". Default: the ship-to state, else the buyer's state, else the seller's state. | |
| prices_include_gst | No | true when the rates already include GST (the taxable value is worked out from them). Default false. |
| Name | Required | Description |
|---|---|---|
| buyer | Yes | |
| lines | Yes | |
| notes | Yes | |
| seller | Yes | |
| supply | Yes | |
| totals | Yes | |
| due_date | Yes | |
| tax_type | Yes | |
| warnings | Yes | |
| downloads | Yes | |
| hsn_shown | No | |
| assumptions | Yes | |
| hsn_summary | Yes | |
| lines_shown | No | |
| invoice_date | Yes | |
| tax_in_words | Yes | |
| invoice_number | Yes | |
| reverse_charge | Yes | |
| total_in_words | Yes | |
| place_of_supply | Yes | |
| prices_include_gst | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare the tool as a non-destructive, idempotent read; the description goes well beyond that by disclosing computed behavior — CGST+SGST/UTGST vs IGST chosen from place of supply, state codes derived from GSTINs, invalid GSTINs flagged rather than rejected, HSN-wise summary, rupee rounding, and amounts in words. It also bounds scope (doesn't pick GST rates, doesn't compute cess), which the annotations cannot express.
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?
Front-loaded with the trigger and output format, then capabilities, then exclusions — a logical order with no filler sentences. It is a single very dense paragraph with semicolon-chained clauses, which costs some scannability, but each clause carries distinct 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 16-parameter, zero-required tool this covers what matters: input modes, derived tax logic, rounding/word conversion, fallback handling, and explicit non-goals. Return values need not be explained because an output schema exists, so nothing an agent needs in order to call it correctly is missing.
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%, so the baseline is 3; the description adds real meaning on top by naming the exact sub-fields expected for seller, buyer, and items, and by framing "details" as strictly a fallback for text that cannot be split. It doesn't explain the more nuanced flags (sez, reverse_charge, prices_include_gst, copies), leaving those to 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 artifact: converts pasted text or an uploaded bill photo into a GST invoice output as a PDF and Excel file. It names the exact output format, input modes, and the field structure (seller, buyer, items), so an agent knows precisely what it produces without opening the schema.
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?
Gives an explicit trigger ("Use this when the user wants a GST invoice...") plus hard exclusions: not for export invoices, not for invoices outside India, not for invoices without GST, and not for e-invoices (IRN/QR) or e-way bills. Those alternatives/exclusions are exactly what an agent needs to route correctly.
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.
generate_gst_invoiceCreate invoices, quotes, receipts and credit notes with GST or VAT, as prefilled links or PDFs.
PDF tools + invoice extraction, bank statement parsing, GST reconciliation & GSTIN validation.
India GST e-invoicing for AI agents - generate, query, cancel IRNs at the IRP via a GSP. Stateless.
Quotations, invoices and 8 more document kinds; quote to invoice; tax for 195 countries; forms.
Add one secure layer between your agents and this server.
