Skip to main content
Glama

HR: Open engagement

hr_open_engagement

Take somebody ON — open a PERIOD of employment for a person in this workspace. This is the row every turnover, headcount and hire-retention number is computed from; without it a hired candidate exists in the funnel and nowhere in the staff. A period, not a status: re-hiring the same person opens a SECOND engagement and both stay readable, which is exactly what makes 'how long do people last' answerable. Opening one for somebody who already has an open period is therefore allowed on purpose (two roles at once) — check hr_list_people / the person's engagements first if you meant to CORRECT the existing one, and use hr_update_engagement for that instead. 'started_on' defaults to today; every id (position, org unit, location, manager) is bounded to this workspace and refused otherwise. Opening an engagement never creates a .NET seat — granting system access is a separate decision. Requires confirmation. CONFIRMATION: this tool is PROPOSED, never performed directly. You get status='confirmation_required' with an action_id and a plan_token, and the write happens only after confirm_action.

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": {
      "person_id": "<person_id>"
    },
    "name": "hr_open_engagement"
  }
}

Input Schema

NameRequiredDescriptionDefault
kindNo
statusNo
scheduleNo
person_idYes
started_onNo
location_idNo
org_unit_idNo
position_idNo
employment_typeNo
probation_untilNo
personnel_numberNo
manager_person_idNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.5/5.0
Behavior5/5

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

Goes well beyond annotations: ids are workspace-bounded and refused otherwise, started_on defaults to today, opening an engagement does not create a .NET seat, and the confirmation protocol is spelled out (status='confirmation_required', action_id, plan_token, write only after confirm_action). The annotations only say it is a non-read-only, non-destructive, closed-world write; the description supplies the whole operational profile.

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-loads the definition, then the period-vs-status nuance, then the confirmation mechanics — a logical order with little filler. 'Requires confirmation.' immediately followed by an expanded CONFIRMATION paragraph is mild redundancy that could be merged.

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?

Covers the non-obvious risks of a 12-param mutation tool (id scoping, default date, no seat provisioning, two-step confirmation) without an output schema to lean on. The remaining gap is per-field semantics for the many optional employment attributes.

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 0% across 12 parameters, so the description must carry the load. It explains started_on's default and the workspace-scoping of id fields, but leaves kind, status, schedule, employment_type, probation_until, personnel_number and manager_person_id entirely to the bare enum/property names.

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 ('open a PERIOD of employment for a person in this workspace') and immediately explains what the resulting row feeds (turnover, headcount, retention). It also carves out a clear boundary against hr_update_engagement and hr_close_engagement.

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?

Explicit when-to-use and when-not-to-use: opening a second engagement for someone already open is allowed on purpose (concurrent roles), but if the intent is to CORRECT an existing period, check hr_list_people / the person's engagements and use hr_update_engagement instead. That is a genuine routing rule an agent can act on.

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