mcp-india-stack

Overview Schema Source Related Servers Discussions Admin

calculate_tds

Read-onlyIdempotent

Calculate TDS for FY2025-26 with section, payment amount, and PAN status, returning TDS rate, amount, and net payment for contracts, professional fees, interest, rent, or commissions.

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.

Input Schema

TableJSON 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
`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

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

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.1/5.0

Behavior4/5

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

Annotations already declare readOnlyHint and idempotentHint, so the safety profile is covered. The description adds valuable behavioral context: it is scoped to FY2025-26 rates, rates may vary due to DTAA or Form 15G/15H, and the result is a standard envelope with applicability, rate, amount, and net payment. This is not contradicted by the annotations.

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 appropriately sized for a six-parameter calculation tool, with clearly separated Args, Returns, and Notes sections. It front-loads the core purpose and usage context. There is a stray trailing 'P' in the provided text, which slightly detracts from polish but does not meaningfully harm clarity.

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?

Given six parameters, full schema coverage, read-only annotations, and an output schema, the description covers the key operational details: purpose, when to use it, parameter roles, and return shape. The main gap is that 'section' refers to 'supported sections' without enumerating them, but the schema's examples and the tool's nature make this acceptable.

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 description coverage is 100%, so the schema already documents all six parameters. The description mostly restates the same parameter meanings, though it adds small nuances like 'affects rate' for PAN and payee type and clarifies that aggregate_payments_ytd is prior payments 'to same payee' under the section. This is incremental but does not significantly compensate beyond the schema.

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 opens with a specific verb and resource: 'Calculate TDS for a given section and payment amount,' which makes the tool's core function immediately unambiguous. It also clarifies the fiscal year (FY2025-26) and lists concrete payee/payment contexts, clearly distinguishing it from sibling calculation tools like calculate_income_tax or calculate_advance_tax.

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 description explicitly states when to use the tool: 'Use when computing withholding tax on contractor payments, professional fees, interest, rent, commissions, or purchase of goods.' It provides clear usage context, though it does not explicitly name alternatives or state when not to use it, so it falls short of a perfect 5.

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

Deploy Server