Skip to main content
Glama

Taokeh MCP server

Employer cost estimate

employer_cost_estimate
Read-only

Cost a HYPOTHETICAL hire: give a monthly wage and get back what that employee would really cost the employer each month — the wage plus employer EPF, SOCSO, EIS and the HRD Corp levy at this company's own rate — and what the employee would actually take home after employee EPF, SOCSO, EIS, SKBBK and PCB/MTD. Use it for "if I hire someone at RM4,000, what does it really cost me?" and "what would they take home?". SKBBK (PERKESO Lindung 24 Jam) is included for every hire: mandatory for a foreign worker, and deducted by default for local staff (citizens, permanent residents, temporary residents), who could opt out with PERKESO only until 31 Aug 2026. Optional: residency (RESIDENT, the default, or NON_RESIDENT — a non-resident is taxed at a flat 30%), citizenship (MALAYSIAN or FOREIGNER — for a FOREIGNER who is not a permanent resident, EPF is 2% employer + 2% employee (KWSP Third Schedule Part F, from October 2025 wages) and there is no EIS unless they are a temporary resident, worked out on at least the RM1,700 minimum wage; it also drives the HRD Corp levy; it does not change tax residency, so set residency too), permanentResident (FOREIGNER only: true for a Malaysian permanent resident, who pays the Malaysian EPF rates (KWSP Third Schedule Part C from 60: 5.5% employee, 6.5% / 6% employer, not a citizen's 0% / 4%) and EIS), temporaryResident (FOREIGNER, not a PR: true for a temporary resident holding a MyKAS, the green temporary-resident IC — EPF stays on Part F, but EIS applies at the Malaysian rates), ageBand (UNDER_60 or 60_AND_OVER — reduced EPF (0% / 4% for a citizen, Part C for a permanent resident) and SOCSO Category 2), and epfEmployeeRate if the employee elects a reduced EPF rate (for a foreign worker on Part F, only a rate above 2% elected on KWSP Form 17A changes their share; the employer stays at 2%). The PCB comes from Taokeh's implementation of LHDN's official computerised MTD method — the calculation IRBM confirmed in writing on 13 August 2026 (letter ref 2026-256) — not from a simplified formula. The defaults are RESIDENT, single, no children and NO TP1 reliefs, because reliefs are per-employee paperwork nobody has filled in for a person who does not exist yet; every assumption is spelled out in the reply and MUST be repeated to the user. Present it as an estimate on stated assumptions, never as a quote or as tax advice. READ-ONLY — it creates nothing, hires nobody and files nothing. ADMIN AND BOOKKEEPER + PAYROLL ONLY, like every payroll tool here.

Input Schema

NameRequiredDescriptionDefault
ageBandNo
residencyNo
citizenshipNo
monthlyWageYes
epfEmployeeRateNo
permanentResidentNo
temporaryResidentNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / temporaryResident
      Added value: +{
      +  "type": "boolean"
      +}
  2. Changed1 schema field changed
    • addedInput schema / properties / permanentResident
      Added value: +{
      +  "type": "boolean"
      +}
  3. Added

TDQS

A4.6/5.0
Behavior5/5

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

Annotations declare readOnlyHint and closed-world, and the description reinforces rather than contradicts this: "creates nothing, hires nobody and files nothing." Beyond that it discloses the default assumption set (RESIDENT, single, no children, no TP1 reliefs) and why, and imposes a binding behavioural rule that every assumption in the reply must be restated to the user and not framed as a quote or tax advice.

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 is front-loaded in the first sentence, but the body is a single dense run-on block with nested parentheses, em-dashes and statutory references, and no formatting to separate defaults, parameters and conduct rules. Much of the tax-schedule detail earns its place given zero schema coverage, but the packaging makes it hard to scan.

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?

For a seven-parameter calculation tool with no output schema, the description supplies both halves of the return value (employer cost components and employee net pay), the PCB methodology and its provenance, all defaults, and the access and framing obligations. Nothing an agent needs to call it and present the result correctly is missing.

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

Parameters5/5

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

Schema coverage is 0%, so the description carries the full burden, and it does: every one of the seven parameters is explained — residency taxation effect, citizenship's effect on EPF/EIS/HRD levy, permanentResident's Third Schedule Part C rates, temporaryResident's MyKAS/EIS treatment, ageBand's reduced EPF and SOCSO Category 2, and epfEmployeeRate's Form 17A constraint. It also flags the non-obvious interaction that citizenship does not change tax residency, so both must be set.

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 — cost a hypothetical hire, returning employer monthly outlay (wage + EPF, SOCSO, EIS, HRD Corp levy) and employee take-home after statutory deductions. It is unambiguously distinct from the sibling payroll tools (payroll_summary, update_employee_draft), which concern actual payroll data rather than hypothetical costing.

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?

Gives concrete triggering questions ("if I hire someone at RM4,000, what does it really cost me?") and states the audience restriction (admin/bookkeeper + payroll only) and that results must be presented as an estimate with assumptions repeated. It stops short of naming an alternative tool or an explicit when-not-to-use condition, so it is clear context without full routing guidance.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources