malaysia-payroll-mcp

Overview Schema Source Related Servers Discussions Admin

Calculate net pay (payslip)

calculate_net_pay

Read-only

Calculates one month's net pay for a Malaysian employee by applying EPF, SOCSO, SKBBK, EIS and MTD/PCB deductions, employer contributions, and total cost with cited sources.

Instructions

Works out one month's payslip for one employee in Malaysia: EPF, SOCSO, SKBBK, EIS and MTD (PCB) deductions, net pay, and the employer's contributions and total cost. Runs the same calculations as calculate_epf, calculate_socso_eis and calculate_mtd, feeding the employee EPF into MTD, and cites the source of every line. For a non_malaysian employee, say whether they are tax resident (taxResident). Fixed monthly salaries and standard reliefs only; no bonuses or zakat. Include the result's disclaimer in the answer to the user.

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": {
      "monthlySalary": "<monthlySalary>",
      "age": "<age>",
      "citizenship": "<citizenship>"
    },
    "name": "calculate_net_pay"
  }
}

Input Schema

Name	Required	Description
`age`	Yes	The employee's age in whole years.
`children`	No	Qualifying children at RM2,000 relief each: unmarried and under 18, or 18 and over in full-time education below diploma level. Must be 0 in category 1. Defaults to 0. Children in higher education or with a disability (which LHDN counts as 4 or 8) are not supported.
`payPeriod`	No	The calendar month the salary is paid for, as YYYY-MM. It decides which rate tables apply. Defaults to the current month in Malaysia.
`tp1Reliefs`	No	Other reliefs the employee claimed through payroll this month on form TP1 (LP1), in RM. Defaults to 0.
`yearToDate`	No	Required from February. Totals from earlier months of the same calendar year, including any previous employer's (all 0 for someone with no earlier income this year). Or "same_salary_all_year" if every earlier month had this salary and EPF, no TP1 reliefs, and its MTD deducted.
`citizenship`	Yes	malaysian, permanent_resident, or non_malaysian (a foreign worker without PR).
`skbbkStatus`	No	SOCSO's 24-hour protection scheme (SKBBK, Lindung 24 Jam). Everyone is covered by default; opted_out only if PERKESO approved the employee's opt-out, which foreign workers can't do. Defaults to covered.
`taxCategory`	No	Required for a tax resident. LHDN tax category. 1: single. 2: married and the spouse has no income (or is jointly assessed). 3: married with a working spouse, or divorced, widowed, or single with an adopted child.
`taxResident`	No	Required for a non_malaysian employee; defaults to true otherwise. true if tax resident in Malaysia (usually 182 days or more in the calendar year). false for the flat 30% non-resident MTD, with no reliefs: taxCategory, children, tp1Reliefs and yearToDate are then ignored.
`monthlySalary`	Yes	Monthly salary in RM, at most 2 decimal places: basic pay plus fixed allowances. Excludes overtime, commission, bonuses and arrears.
`eisPayableBefore57`	No	Required for employees aged 57 to 59: true if EIS contributions were payable for them before they turned 57 (even if never paid). Can't be worked out from age.
`registeredWithEpfBefore1Aug1998`	No	Only for non_malaysian: true if the employee registered with EPF before 1 Aug 1998, which puts them on the Malaysian rates. Defaults to false.

Output Schema

Name	Required	Description
`basis`	Yes	The rules each calculation used. Call calculate_epf, calculate_socso_eis or calculate_mtd for the full working.
`netPay`	Yes	RM, monthly salary minus every statutory deduction
`citations`	Yes
`payPeriod`	Yes
`deductions`	Yes	What comes off the employee's pay.
`disclaimer`	Yes
`explanation`	Yes
`employerCost`	Yes	RM, monthly salary plus the employer's contributions
`monthlySalary`	Yes
`employerContributions`	Yes	What the employer pays on top of the salary.

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.2.0Nov 2, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds genuinely non-obvious behavior: the employee EPF figure is fed into the MTD calculation, every line cites its source, and the agent must relay the result's disclaimer to the user. What it does not cover are failure modes, e.g. what happens with unsupported child categories or missing yearToDate in February.

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

Conciseness5/5

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

Front-loaded with the scope and output set, then the sibling relationship, then the conditional-input caveat, then the domain limits, then the required answer-handling instruction. Every sentence carries information an agent would otherwise have to infer, and there is no filler.

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?

With 12 parameters, an output schema, and full schema descriptions, the description covers the hard parts: scope exclusions, the EPF-to-MTD chain, tax residency handling, and the citation/disclaimer obligations. Minor gap: rate-table dependence on payPeriod and the February yearToDate requirement are carried only by the schema, not reinforced here.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema baseline is a 3. The description still adds value by surfacing the cross-field computation order (EPF feeding MTD) and the conditional requirement that a non_malaysian employee's taxResident status must be supplied, which is the most likely parameter to trip an agent up.

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 and resource — one month's payslip for one employee in Malaysia — and enumerates the exact outputs (EPF, SOCSO, SKBBK, EIS, MTD, net pay, employer contributions, total cost). It also positions itself against the sibling calculators by saying it runs the same calculations they do, so an agent can tell it is the composite tool.

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?

Names the sibling tools and the relationship (this one bundles their calculations), which lets an agent infer when to prefer the composite over a single deduction. It also sets an explicit scope boundary — fixed monthly salaries and standard reliefs only, no bonuses or zakat — but never states the inverse case ("use calculate_epf alone if you only need EPF").

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

Deploy Server