stub

Save payslip template

save_payslip_template

Create or update a payslip template: a named line set of earnings, deductions and contributions with each line's kind, rate, quantity, amount and formula. Omit id to create; pass an id to update that template. On update, lines is the full set. A template is master data: it changes future payslips only and posts nothing to the ledger.

Input Schema

Name	Required	Description
`id`	No
`name`	No
`lines`	No	The full set of lines. It replaces the stored set; send the id of every line you keep.
`notes`	No
`archived`	No
`statutory`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed8 schema fields changedNov 3, 2026

addedInput schema / properties / lines / description

Added value: +"The full set of lines. It replaces the stored set; send the id of every line you keep."

addedInput schema / properties / lines / items / properties / category / enum

Added value: +[
+  "earning",
+  "deduction",
+  "contribution",
+  "benefit"
+]

addedInput schema / properties / lines / items / properties / code / description

Added value: +"The line's code: letter-led, then letters, digits, _ or -. Formulas and pay values name a line by its code. A reserved code (get_payroll_setup) is refused. Omit it to mint one from the description."

addedInput schema / properties / lines / items / properties / formula / description

Added value: +"A formula over line codes, e.g. \"basic * 0.1\". get_payroll_setup lists the formula names. Null makes the line fixed."

addedInput schema / properties / lines / items / properties / id / description

Added value: +"The id of a line you keep. Send the id on EVERY line you keep: the lines you send replace the stored set, and a line sent without its id is a new line with a new id."

addedInput schema / properties / lines / items / properties / kind / description

Added value: +"fixed: amount as sent. rate: rate times quantity. formula: the formula prices the line."

changedInput schema / properties / lines / items / properties / kind / enum

Previous value: -[
-  "fixed",
-  "rate",
-  "formula",
-  "item"
-]New value: +[
+  "fixed",
+  "rate",
+  "formula"
+]

addedInput schema / properties / lines / items / properties / role / description

Added value: +"A pack line role, \"<prefix>-<code>\", e.g. \"sars-3601\". get_payroll_setup lists the roles each category allows."

Changed1 schema field changedOct 29, 2026
- removedInput schema / properties / lines / items / properties / payitem
```
Removed value: -{
-  "type": "string"
-}
```
AddedOct 14, 2026

TDQS

A3.8/5.0

Behavior4/5

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

Beyond the annotations (readOnly=false, destructive=false), the description discloses the critical non-merge semantics: 'The lines are replaced entirely — not merged.' This is exactly the behavioral detail an agent needs to avoid data loss on update. It doesn't mention permissions, side effects on existing payslips, or return behavior.

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 create/update semantics and the destructive replace rule immediately. Sentences are tight and each carries meaning; minor redundancy in restating id usage.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a mutation tool with 6 params and 17% schema coverage and no output schema, the description covers the create/update decision and the replace behavior well, but leaves several parameters and all line-field semantics to the schema, which only partially documents them.

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 low (17%), so the description must compensate. It gives meaning to id, name, and lines (replace-not-merge, required-on-create) but leaves the line sub-fields (rate, kind, formula, etc.) and the notes/archived/statutory parameters unexplained. Partial compensation.

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?

The description leads with a specific verb and resource: 'Create or update a payslip template: a named set of earning and deduction lines.' It defines what a template is, distinguishing it from a payslip instance conceptually, but doesn't explicitly contrast with siblings like save_payslip or list_payslip_templates.

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?

Clear create-vs-update routing: 'Omit an id to create with the given lines. Supply an id (optional) or name+lines to update.' It also states when name+lines are required vs optional. No named alternative tools or exclusions, so it stops short of a 5.

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

All stub tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?