mcp-india-stack

Overview Schema Source Related Servers Discussions Admin

calculate_tds

Read-onlyIdempotent

Compute TDS on contractor payments, professional fees, rent, interest, commissions, or goods using section, gross amount, PAN status, and prior payments for FY2025-26.

Instructions

Calculate TDS for a given section and payment amount (FY2025-26).

Use when computing withholding tax on contractor payments, professional fees, interest, rent, commissions, or purchase of goods.

Args: section: TDS section key from supported sections. payment_amount: Gross payment in rupees. pan_available: Whether payee PAN is available (affects rate). is_senior_citizen: For 194A bank interest threshold. aggregate_payments_ytd: Prior payments to same payee in current FY. payee_type: 'individual_huf' or 'other' - affects 194C rate.

Returns: Standard envelope with TDS applicability, rate, amount, net payment.

Notes: FY2025-26 rates. Actual rates may vary by DTAA or Form 15G/15H.

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": {
      "section": "<section>",
      "payment_amount": "<payment_amount>",
      "pan_available": "<pan_available>"
    },
    "name": "calculate_tds"
  }
}

Input Schema

Name	Required	Description	Default
`section`	Yes	TDS section key, e.g. '194C_individual', '194J_professional'
`payee_type`	No	Payee type: 'individual_huf' or 'other' (affects 194C rate)	individual_huf
`pan_available`	Yes	Whether payee has provided PAN
`financial_year`	No	Financial year (e.g. '2025-26', '2026-27')	2025-26
`payment_amount`	Yes	Gross payment amount in rupees
`is_senior_citizen`	No	For 194A bank interest — applies higher threshold for seniors
`aggregate_payments_ytd`	No	Prior payments to same payee under this section in current FY

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.8.0Nov 5, 2026

addedInput schema / properties / financial_year

Added value: +{
+  "default": "2025-26",
+  "description": "Financial year (e.g. '2025-26', '2026-27')",
+  "title": "Financial Year",
+  "type": "string"
+}

Changed9 schema fields changedv0.5.0Aug 25, 2026
- removedInput schema / additionalProperties
```
Removed value: -false
```
- addedInput schema / properties / aggregate_payments_ytd / title
```
Added value: +"Aggregate Payments Ytd"
```
- addedInput schema / properties / is_senior_citizen / title
```
Added value: +"Is Senior Citizen"
```
- addedInput schema / properties / pan_available / title
```
Added value: +"Pan Available"
```
- addedInput schema / properties / payee_type / title
```
Added value: +"Payee Type"
```
- addedInput schema / properties / payment_amount / title
```
Added value: +"Payment Amount"
```
- addedInput schema / properties / section / title
```
Added value: +"Section"
```
- addedInput schema / title
```
Added value: +"calculate_tdsArguments"
```
- addedOutput schema / title
```
Added value: +"calculate_tdsDictOutput"
```

Changed2 schema fields changedv0.4.2Jun 8, 2026

addedInput schema / properties / aggregate_payments_ytd

Added value: +{
+  "default": 0,
+  "description": "Prior payments to same payee under this section in current FY",
+  "type": "number"
+}

addedInput schema / properties / payee_type

Added value: +{
+  "default": "individual_huf",
+  "description": "Payee type: 'individual_huf' or 'other' (affects 194C rate)",
+  "type": "string"
+}

First observedv0.3.0May 30, 2026

TDQS

A4/5.0

Behavior4/5

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

Annotations already declare readOnly/idempotent/closed-world, so the safety profile is covered. The description adds genuinely useful behavior context: the rates are FY2025-26 specific and 'actual rates may vary by DTAA or Form 15G/15H', which warns the agent that output is an estimate, plus it lists what the envelope contains (applicability, rate, amount, net payment).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose and when-to-use are front-loaded and clear, but the Args and Returns blocks duplicate a schema that is already 100% documented and an output schema that exists. The redundancy costs space without adding much, and the financial-year mismatch adds noise.

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 7-parameter calculation tool with a full output schema, the definition covers purpose, trigger conditions, and the important accuracy caveat (DTAA / 15G-15H). It is nearly complete; the only real gap is not reconciling the hardcoded FY2025-26 framing with the financial_year parameter.

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 Args block mostly restates schema text. It adds a little meaning — pan_available 'affects rate' and is_senior_citizen drives 'the 194A bank interest threshold' — but omits financial_year, and the description's framing of the tool as FY2025-26 conflicts with a schema parameter that accepts '2026-27'.

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+resource ('Calculate TDS') plus the scoping inputs (section, payment amount) and the fiscal regime (FY2025-26). No sibling tool covers withholding tax, so an agent can route to it 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.

Usage Guidelines4/5

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

The 'Use when computing withholding tax on contractor payments, professional fees, interest, rent, commissions, or purchase of goods' line gives a concrete trigger set tied to payment categories. It stops short of exclusions or naming a competing tool (e.g. calculate_income_tax or calculate_gst) that an agent might confuse it with.

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

Deploy Server