Sergio by Serviche

Add a staff member

add_staff_member

Idempotent

To rename someone already on the roster, pass rename_staff_id with the new name; the old spelling keeps pointing at them. Otherwise adds a field worker to the roster, as the staff page's Add staff does: name (a profile with that name is reused, never duplicated), optional employment_type (employee or contractor), or client_id to make an existing contact staff (a name clash comes back as name_conflict; call again with link_to_staff_id to link instead). This gives them no sign-in; inviting someone to Sergio is the owner's. Nothing is sent. Pass the same idempotency_key when retrying.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "name": "<name>",
      "idempotency_key": "<idempotency_key>"
    },
    "name": "add_staff_member"
  }
}

Input Schema

Name	Required	Description
`name`	Yes
`client_id`	No
`employment_type`	No
`idempotency_key`	Yes	Your id for this operation (8-128 of A-Z a-z 0-9 . _ : -). Reuse it on every retry of the same operation; use a new one for a new operation.
`rename_staff_id`	No
`link_to_staff_id`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 8, 2026

TDQS

A4.3/5.0

Behavior5/5

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

Beyond the annotations, the description discloses important behavior: profiles are reused rather than duplicated, name clashes return name_conflict, the fallback is link_to_staff_id, no sign-in is granted, nothing is sent, and the idempotency_key should be reused on retries. These details materially improve the agent's ability to invoke the tool correctly.

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?

The content is dense and the main add-staff purpose is not front-loaded; the description opens with the rename edge case before saying 'Otherwise adds a field worker.' It reads as one long paragraph with semicolons and some awkward phrasing, making it harder to parse than necessary.

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

Completeness4/5

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

For a six-parameter mutation with no output schema, the description covers side effects, conflict handling, idempotency, and the no-sign-in/no-send constraint. It is nearly complete, though it does not describe the success response or explicitly state default behavior when optional fields are omitted.

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 description coverage is very low at 17%, so the description must carry the semantic load. It explains the purpose of all six parameters in context: name reuse, employment_type values, client_id promotion, rename_staff_id mode, link_to_staff_id conflict recovery, and idempotency_key retry behavior.

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 clearly states that the tool adds a field worker to the roster, with an alternate rename mode. It is specific about the resource and action, but does not explicitly distinguish this tool from sibling staff-management tools such as review_cleaner_roster or set_staff_availability.

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 gives conditional guidance: use rename_staff_id to rename an existing staff member, otherwise add someone new; use client_id to promote an existing contact; and retry with link_to_staff_id after a name_conflict. It also notes that the tool does not invite users or send anything. However, it does not name alternative tools or explicitly state when not to use this tool.

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

All Sergio by Serviche 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?