hibob-advanced-mcp

hibob_update_position

Idempotent

Update an existing position by providing its ID and fields. Modify name, effective date, manager, type, FTE, employment type, department, site, job profile, or reason; other fields stay unchanged.

Instructions

Change details of an existing position.

Only the fields supplied are modified. Use hibob_search_positions to find the position ID first.

Args: position_id: The position's ID. fields: Flat mapping of field IDs to new values.

Returns: str: JSON confirming the update, or an error message beginning with "Error:".

Examples: - "Move that position's start to October" -> fields with '/position/effectiveDate'.

Rate limit: 10 requests/minute.

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": {
      "position_id": "<position_id>",
      "fields": "<fields>"
    },
    "name": "hibob_update_position"
  }
}

Input Schema

Name	Required	Description	Default
`fields`	Yes	Fields to change, as a flat mapping. Updatable: name, effectiveDate, managerPositionId, positionType, fte, employmentType, department, site, jobProfile, reason.
`position_id`	Yes	ID of the position to update.

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Sep 4, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already establish readOnly=false, idempotent=true, and destructive=false. The description adds relevant behavior beyond annotations: only supplied fields are modified, the response is a JSON string or error, and there is a 10 requests/minute rate limit. No contradiction with annotations exists.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and well-structured: purpose, partial-update semantics, prerequisite lookup tool, args, return format, example, and rate limit all appear in a tight, readable layout. Every section earns its place with no redundant filler.

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?

For a two-parameter tool with rich schema coverage, annotations, an output schema, and a clear example, the description provides all essential call-time information. An agent can correctly select the tool, find the required position ID, format the update payload, and interpret the result.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 100% description coverage, so the baseline is 3. The description adds value with the example mapping '/position/effectiveDate' and clarifies that fields is a flat mapping from field IDs to new values, helping agents construct valid payloads beyond the schema's field list.

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 'Change details of an existing position,' naming a specific verb and resource, and is reinforced by the title 'Update a HiBob position.' This makes it clearly distinct from sibling tools like create, cancel, or opening/budget updates.

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?

It explicitly instructs agents to use hibob_search_positions first to find the position ID, which is a concrete precondition. It does not enumerate when to avoid this tool versus update_position_opening or update_position_budget, but the 'existing position' scope together with sibling names provides adequate context.

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

Deploy Server