ohneben's Wafeq MCP

wafeq_employees_partial_update

Idempotent

Partially update an existing employee record by submitting only the fields that need to change, such as name, email, address, country, or hire date.

Instructions

🟡 WRITE · updates data · Employees · PATCH /employees/{id}/

Partial update employee

Endpoint for partially updating an existing employee.

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": {
      "id": "<id>"
    },
    "name": "wafeq_employees_partial_update"
  }
}

Input Schema

Name	Required	Description
`id`	Yes
`body`	No	A ModelSerializer that takes additional arguments for "fields", "omit" and "expand" in order to control which fields are displayed, and whether to replace simple values with complex, nested serializations
`idempotency_key`	No	Optional idempotency key (sent as the X-Wafeq-Idempotency-Key header). A UUID v4 is generated automatically when omitted, so an automatic network retry can never duplicate this operation. Pass your own stable value to make a deliberate re-invocation safe as well.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv2.0.0Sep 8, 2026

TDQS

C2.8/5.0

Behavior2/5

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

Annotations already convey readOnlyHint=false and destructiveHint=false, so the '🟡 WRITE · updates data' badge adds nothing new. The description fails to disclose the core behavioral trait of a PATCH operation — that omitted fields remain unchanged and only supplied body fields are merged in. It also doesn't mention response shape, validation errors, or permission requirements. Given annotations exist, the bar is lower, but the description still contributes almost no behavioral context beyond what structured fields already state.

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 description is short at roughly four lines, but it is redundant: 'Partial update employee' and 'Endpoint for partially updating an existing employee' say the same thing twice. The metadata badge line (write indicator, resource, HTTP method) is useful and front-loaded, but the duplicated prose wastes space that could have been used for behavioral detail.

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

Completeness2/5

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

For a write operation with a nested request body, no output schema, and a closely related full-update sibling, the description is under-specified. It omits what a successful response contains, the merge semantics of partial update versus full replacement, and any note about the idempotency behavior that would matter for retries. The schema is moderately rich, but the description carries too much of the explanatory burden for this operation's complexity and fails to meet it.

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 coverage is 67%; the body fields and idempotency_key are well-documented in the schema, with each nested field (city, name, user, email, address, country, date_hired) carrying a meaningful description. The id parameter lacks a schema description and the description text does not compensate for it. The body's own schema description is unhelpful DRF boilerplate ('A ModelSerializer that takes additional arguments...'), but the nested field descriptions mostly carry the weight. The tool description itself adds no parameter-level meaning, so it neither improves nor degrades the 67% coverage baseline.

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 states a clear verb+resource combination ('updates data · Employees · PATCH /employees/{id}/') and explicitly says 'partially updating an existing employee.' The word 'partial' implicitly distinguishes it from the full-update sibling wafeq_employees_update, and the HTTP method PATCH reinforces the intent. However, it never names the alternative or spells out that only submitted fields are modified, so sibling differentiation is implicit rather than explicit.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance on when to use partial update versus the full update (wafeq_employees_update) or the retrieve/destroy siblings. No prerequisites, no exclusions, and no mention of required permissions or whether the employee must already exist. The phrase 'an existing employee' is the only faint contextual signal, which is not enough for an agent to reliably choose among the four employee operations.

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

Deploy Server