mcp-india-stack

Overview Schema Source Related Servers Discussions Admin

calculate_salary_restructuring

Read-onlyIdempotent

Calculate tax-optimized salary restructuring options and compare CTC structures to plan deductions and estimate income tax for employees in India.

Instructions

Calculate salary restructuring options for tax optimization.

Use when advising employees on tax-efficient salary structures, comparing restructuring options, or planning CTC optimization.

Args: current_gross: Current gross annual salary in INR current_basic_ratio: Current basic salary as ratio of gross structure_type: Structure option (standard, optimized, startup) include_meal_card: Include Sodexo/Food card allowance include_wallet_allowance: Include flexible wallet allowance has_hra: Employee receives HRA rent_in_metro: Rent paid in metro city (higher HRA) family_medical: Include family medical insurance parents_medical: Include parents medical insurance

Returns: Standard envelope with tax-optimized structure, deductions, and estimated tax

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": {
      "current_gross": "<current_gross>"
    },
    "name": "calculate_salary_restructuring"
  }
}

Input Schema

Name	Required	Description	Default
`has_hra`	No	Employee receives HRA
`current_gross`	Yes	Current gross annual salary in INR
`rent_in_metro`	No	Rent paid in metro city (higher HRA)
`family_medical`	No	Include family medical insurance
`financial_year`	No	Financial year (e.g. '2025-26', '2026-27')	2025-26
`structure_type`	No	Structure option: standard, optimized, or startup	standard
`parents_medical`	No	Include parents medical insurance (additional)
`include_meal_card`	No	Include Sodexo/Food card allowance
`current_basic_ratio`	No	Current basic salary as ratio of gross (0.40-0.60)
`include_wallet_allowance`	No	Include flexible wallet allowance

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"
+}

Changed12 schema fields changedv0.5.0Aug 25, 2026
- removedInput schema / additionalProperties
```
Removed value: -false
```
- addedInput schema / properties / current_basic_ratio / title
```
Added value: +"Current Basic Ratio"
```
- addedInput schema / properties / current_gross / title
```
Added value: +"Current Gross"
```
- addedInput schema / properties / family_medical / title
```
Added value: +"Family Medical"
```
- addedInput schema / properties / has_hra / title
```
Added value: +"Has Hra"
```
- addedInput schema / properties / include_meal_card / title
```
Added value: +"Include Meal Card"
```
- addedInput schema / properties / include_wallet_allowance / title
```
Added value: +"Include Wallet Allowance"
```
- addedInput schema / properties / parents_medical / title
```
Added value: +"Parents Medical"
```
- addedInput schema / properties / rent_in_metro / title
```
Added value: +"Rent In Metro"
```
- addedInput schema / properties / structure_type / title
```
Added value: +"Structure Type"
```
- addedInput schema / title
```
Added value: +"calculate_salary_restructuringArguments"
```
- addedOutput schema / title
```
Added value: +"calculate_salary_restructuringDictOutput"
```
Addedv0.4.2Jun 8, 2026

TDQS

A3.6/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true and openWorldHint=false, so the safety profile is fully covered by structured data. The description adds only a one-line 'Returns' note about a standard envelope with optimized structure, deductions and estimated tax, which is largely redundant since an output schema exists. Nothing is said about the assumptions or limitations of the optimization logic (e.g. regime dependence, statutory caps), so it adds little beyond annotations.

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?

The purpose sentence and use-case block are well front-loaded and earn their place. The remainder is a docstring-style parameter list that duplicates the input schema field-for-field, which is repeated rather than informative. Trimming the Args block would preserve all value.

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 10-parameter tool with only one required field and an existing output schema, the description covers purpose, trigger conditions and the return shape adequately. The main gap is guidance on how mutually exclusive or interacting flags (structure_type vs. include_meal_card vs. has_hra) should be combined, which an agent must currently guess.

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 baseline is 3. The 'Args' block restates the schema descriptions nearly verbatim (e.g. 'Current gross annual salary in INR', 'Current basic salary as ratio of gross'), adding no new semantics such as valid ranges or interaction effects between options. It also omits financial_year, which appears in the schema, so it does not even fully mirror the input contract.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: 'Calculate salary restructuring options for tax optimization.' An agent can distinguish this from calculation siblings like calculate_income_tax or calculate_hra_exemption because the resource is salary structure design rather than a single tax computation. However, the description never names or contrasts those siblings explicitly, so differentiation is inferred rather than stated.

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?

Provides clear use-case triggers: 'advising employees on tax-efficient salary structures, comparing restructuring options, or planning CTC optimization.' This is enough context to decide when to reach for it. What is missing is the boundary against near-neighbors (calculate_hra_exemption, calculate_income_tax, calculate_epf_esic) and any preconditions such as needing gross salary first.

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

Deploy Server