Skip to main content
Glama

Taokeh MCP server

Payroll summary

payroll_summary
Read-only

A month's payroll from gross to net, as it was actually run: total gross (basic, allowances, overtime, public-holiday pay and any bonus), what was deducted from staff (EPF, SOCSO, EIS, SKBBK, PCB/MTD, zakat), what the employer contributed on top (EPF, SOCSO, EIS, HRD Corp levy), the total net pay, and the employer's TRUE total cost for the month — wages plus every employer contribution. Also lists who is on approved leave in the next 14 days, so "what does payroll look like this month" and "who is out next week" are one call. With no month it reads the latest FINALIZED or POSTED run; give a month as YYYY-MM for a specific one. A DRAFT run carries run.needsRecompute: when true, an early banner says its figures may be out of date (it was reopened, or employee details, pay before Taokeh, a TP1 sign-off switch or the payroll rules changed after it was computed) and the owner must press Save & recompute in Payroll → Payroll Runs. Even when false, Finalize re-runs the recompute and refuses if any money would move (e.g. a TP1 approval or declaration changed) — so a DRAFT's figures are never final; say so rather than quoting them as final. Set perEmployee: true for the per-person breakdown — those are individual salaries, so ask for them only when the user actually wants them; each entry carries that person's real employeeId. Set staff: true for the full employee ROSTER with ids, which works even when payroll has never been run — that is where the employeeId for update_employee_draft comes from, and it is the only place an id is published: never key an employee by name. Every figure is a sum of the STORED payslips of that run — the same numbers the staff were paid on and the payroll journal was posted from — never a recalculation. If nothing has been run, it says so plainly rather than returning a month of zeros. ADMIN AND BOOKKEEPER + PAYROLL ONLY: payroll sits behind its own role in Taokeh and this tool refuses on any other connection (a plain Bookkeeper included). READ-ONLY — it cannot create a run, pay anybody, or file anything with LHDN, KWSP or PERKESO.

Input Schema

NameRequiredDescriptionDefault
monthNo
staffNoReturn the full employee ROSTER (id, name, staff no., status, designation, basic salary) alongside the summary — independent of any run, so it works even before the first payroll. This is where the employeeId for update_employee_draft comes from. Individual salaries: ask for it only when the user actually needs it.
perEmployeeNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / staff
      Added value: +{
      +  "description": "Return the full employee ROSTER (id, name, staff no., status, designation, basic salary) alongside the summary — independent of any run, so it works even before the first payroll. This is where the employeeId for update_employee_draft comes from. Individual salaries: ask for it only when the user actually needs it.",
      +  "type": "boolean"
      +}
  2. Added

TDQS

A4.9/5.0
Behavior5/5

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

Despite readOnlyHint already covering safety, the description adds substantial behavior: role gating (ADMIN AND BOOKKEEPER + PAYROLL ONLY, refuses otherwise), the read-only boundary (cannot create a run or file with LHDN/KWSP/PERKESO), DRAFT `needsRecompute` semantics, and the crucial fact that figures are stored payslip sums, never recalculations. This is far beyond what annotations provide.

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?

Front-loaded with the core output and use cases, then layered with draft and role caveats in a logical order. It is long and occasionally dense, with some overlap between the `staff` sentence and its schema description, but nearly every sentence carries essential context.

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?

No output schema exists, so the description fully describes return contents (gross components, deductions, employer contributions, net, true cost, leave list, roster). Combined with draft semantics and role gating, an agent has everything needed to call it correctly.

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 only 33% (only `staff` documented), so the description carries the rest: `month` format is given as YYYY-MM, `perEmployee` behavior and its sensitivity are explained, and `staff` is contextualized as the id source. It adds real meaning for the two schema-undocumented parameters.

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 ('a month's payroll from gross to net, as it was actually run') and enumerates the exact figures returned, so an agent knows precisely what it produces. It differentiates from siblings like employer_cost_estimate by emphasizing stored payslip sums rather than estimates. No ambiguity about what the tool is.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

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

Explicitly says what happens with no `month` (latest FINALIZED or POSTED run) versus a given `month` (YYYY-MM), names when to set `staff` and `perEmployee`, and cautions about when not to request per-person data. It also routes to `update_employee_draft` for the employeeId source. Clear when/when-not 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