Skip to main content
Glama
rehan1020

mcp-india-stack

by rehan1020
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

calculate_gst

Read-onlyIdempotent

Compute GST breakdown with CGST/SGST/IGST split and optional cess for invoices, quotations, or compliance. Handles GST-inclusive amounts and intra/inter-state transactions to determine total payable tax.

Instructions

Calculate GST breakdown with CGST/SGST/IGST split and optional cess.

Use when computing tax for invoices, quotations, or GST compliance.

Args: amount: Base amount or GST-inclusive amount in rupees. gst_rate: Valid GST rate percentage. transaction_type: 'intra_state' or 'inter_state'. amount_includes_gst: Set True to back-calculate base. cess_category: For 28% items, specify applicable cess.

Returns: Standard envelope with base amount, CGST/SGST/IGST breakdown, cess amount, total GST, and total payable amount.

Notes: Rates are for general reference. Actual classification may vary.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
amountYesBase amount in rupees (or inclusive amount if flagged)
gst_rateYesGST rate as percentage: 0, 0.1, 0.25, 1.5, 3, 5, 12, 18, 28
cess_categoryNoCess category for 28% items. Default: 'default' (no cess)default
transaction_typeYes'intra_state' (CGST+SGST) or 'inter_state' (IGST)
amount_includes_gstNoIf True, back-calculate base from GST-inclusive amount

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed8 schema fields changedv0.5.0
    • removedInput schema / additionalProperties
      Removed value: -false
    • addedInput schema / properties / amount / title
      Added value: +"Amount"
    • addedInput schema / properties / amount_includes_gst / title
      Added value: +"Amount Includes Gst"
    • addedInput schema / properties / cess_category / title
      Added value: +"Cess Category"
    • addedInput schema / properties / gst_rate / title
      Added value: +"Gst Rate"
    • addedInput schema / properties / transaction_type / title
      Added value: +"Transaction Type"
    • addedInput schema / title
      Added value: +"calculate_gstArguments"
    • addedOutput schema / title
      Added value: +"calculate_gstDictOutput"
  2. First observedv0.3.0

TDQS

A4.2/5.0
Behavior4/5

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

The description adds value beyond the read-only and idempotent annotations by explaining key behavioral details: amount can be inclusive or exclusive of GST, mutations are not made, and rate classification warnings are given. A minor gap is not being explicit about what happens if invalid GST rates are provided, but overall transparency is strong.

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 well-structured with a clear purpose line, use context, Args, Returns, and Notes sections. It is fairly concise but includes some vertical space and content that overlaps with the schema, which prevents a perfect score.

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?

With full schema coverage, an output schema, and annotations signaling read-only idempotent behavior, the description provides ample context: it states the business scenario, explains the optional cess behavior, and warns about rate variability. No critical operational detail is missing.

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?

The schema already covers 100% of parameters with clear descriptions, so the description's parameter section adds marginal value. It restates the same meanings (e.g., 'base amount or GST-inclusive amount', 'back-calculate base') without introducing substantially new semantics.

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?

The description uses the specific verb 'Calculate' and identifies the exact resource: GST breakdown with CGST/SGST/IGST split and optional cess. It clearly distinguishes the tool from siblings like calculate_gst_late_fee by naming the core computation and its use cases.

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?

It explicitly states when to use the tool: 'Use when computing tax for invoices, quotations, or GST compliance.' This provides clear context, though it does not explicitly contrast with sibling calculators like calculate_gst_late_fee or check the xlsx calendar.

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