Creates a real employee record in Holded by sending employee data as the API request body, so you can add staff to Holded from an AI assistant.
WRITE: creates a real employee record in Holded (API v2). data is sent verbatim as the request body — see https://www.holded.com/es/desarrolladores/referencia-api (Empleados → Crear) for the payload fields (name, email, etc.).
| Name | Required | Description | Default |
|---|---|---|---|
| data | Yes | Employee payload, sent verbatim as body |
Changes observed during successful MCP inspections.
v2.0.3Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does disclose two real traits: the operation is a write that creates a genuine (non-dry-run) record, and `data` is passed straight through with no validation or field mapping. It omits permissions/auth requirements, duplicate handling, and what happens on failure or success — meaningful gaps for an unannotated mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero filler; the WRITE marker and the persistence fact are front-loaded, and the pass-through semantics follow immediately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter write tool with no annotations and no output schema, the description should say more about the RESULT (does it return the created employee ID?) and about error or duplicate behavior. The external documentation link partially compensates for the free-form payload, but the return contract is entirely unaddressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema defines only a free-form object with a terse description, so the field-level burden falls on the description. Saying the payload is 'sent verbatim as the request body' is valuable — it tells the agent there is no server-side transformation — and the external reference plus sample fields (name, email) gives a path to the required shape, though the agent must leave the context to get the full field list.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('creates a real employee record in Holded') plus the API version. It differentiates against siblings implicitly by naming the resource 'employee record' rather than employee_time or salary_record, but never names an alternative tool explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'WRITE:' prefix and 'real employee record' imply a persisting mutation, which is enough to infer when to use it over read tools like list_employees/get_employee. However, no exclusions are given — nothing about when to use update_employee instead, or preconditions such as whether the employee must not already exist.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.