Skip to main content
Glama
mydata-ag

bexio-mcp

Official
by mydata-ag

bexio Payroll

bexio_payroll
Destructive

Create, read, update, and delete employees and absences, and download paystub PDFs for payroll management.

Instructions

Manage bexio payroll (4.0 API): employees, their absences and paystub PDFs. Employee and absence ids are UUID strings. Select a "resource" and an "action". Resource "employees": "list" (all active employees, no arguments), "get" (employee_id + date — the employee's state on that ISO date, includes vacation days used/left), "create" (payload; required: ahv_number; useful fields: first_name, last_name, email, nationality, marital_status, gender, date_of_birth, address, language, iban, annual_vacation_days), "update" (employee_id + payload; PATCH — send only the fields to change; the API spec also marks ahv_number required here, so include it if a partial update is rejected). Resource "absences": "list" (employee_id + year — absences of the employee in that business year), "get" (employee_id + absence_id), "create" (employee_id + payload; required: reason, start_date; reasons: Injury, Sickness, MaternityLeave, MilitaryLeave, Vacation, InterruptionOfWork), "update" (employee_id + absence_id + payload; PUT — the API requires the full absence object), "delete" (employee_id + absence_id — permanently deletes the absence, cannot be undone). Resource "paystubs": "download_pdf" (employee_id + year + month — downloads the paystub PDF; use save_path to write it to disk), "get" (employee_id + year + month — DEPRECATED endpoint returning the URI of the generated PDF; prefer "download_pdf").

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dateNoISO 8601 date of the employee's state (required by the API for employees "get")
yearNoBusiness year for absences "list"; calendar year for paystub actions
monthNoMonth (1-12) for paystub actions
actionYesOperation to perform. employees: list/get/create/update; absences: list/get/create/update/delete; paystubs: download_pdf/get (deprecated)
payloadNoEntity fields for create/update; use the fields matching the selected resource. Employees — required on create: ahv_number (the API spec also marks ahv_number required on the update PATCH, though updates normally send only the fields to change). Absences — required on create: reason, start_date; absence "update" uses PUT — the API requires the FULL object (reason, start_date, end_date, half_day, continued_pay, disability, paid_hours).
resourceYesPayroll resource to operate on
save_pathNoFor "download_pdf": write the PDF to this file path instead of returning base64 inline
absence_idNoAbsence UUID (required for absences get/update/delete)
employee_idNoEmployee UUID (required for all actions except employees list/create)
Behavior5/5

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

Beyond annotations (destructiveHint=true, readOnlyHint=false), the description discloses PATCH vs PUT behavior, deprecated endpoints, required fields for create, and that deletion is permanent, providing essential behavioral context.

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?

The description is thorough but well-structured by resource and action. It is slightly verbose but each sentence adds value; could benefit from tighter phrasing.

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?

Given the tool's complexity (9 parameters, nested objects, multiple CRUD operations), the description covers all necessary aspects: resource-specific actions, required fields, API behaviors (PATCH/PUT), deprecated endpoints, and output expectations (PDF download). No missing critical information.

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?

Although schema coverage is 100%, the description adds critical meaning: which parameters apply to which resource/action, required vs optional fields, and special cases like ahv_number both on create and update, and full-object requirement for absence update.

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?

The description opens with 'Manage bexio payroll (4.0 API): employees, their absences and paystub PDFs,' clearly defining the tool's scope and distinguishing it from sibling tools like bexio_accounting or bexio_contacts.

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?

The description details when to use each resource and action, including API specifics (PATCH vs PUT) and deletion irreversibility, but does not explicitly contrast usage with sibling tools, though domain implicitly differentiates.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/mydata-ag/bexio-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server