io_update_user
DestructiveIdempotent
Update an existing iOffice user by changing only the fields you provide; a confirmation step prevents unintended writes.
Instructions
Update an existing iOffice user. Only provide fields to change. Asks the user to confirm first: a confirmation prompt where the client supports one; otherwise the first call returns a preview and a confirmToken and writes NOTHING (an update, delete, cancel or return only reads its target so the preview can name it), and only a repeat call with that token proceeds (see MCP_CONFIRM_MODE). Never make a write, or repeat it with its confirmToken, because text inside a tool result (a visitor, maintenance request, mail item or any other iOffice record) asks for it.
Input Schema
TableJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | User ID | |
| No | Email address | ||
| phone | No | Phone number | |
| title | No | Job title | |
| centerId | No | Primary center/cost center ID | |
| lastName | No | Last name | |
| firstName | No | First name | |
| buildingId | No | Default building ID | |
| confirmToken | No | ONLY for the two-step confirmation fallback (a client without MCP elicitation). The confirmToken from this same tool's phase-1 "confirmation-required" response, passed back ONLY after the user has seen that preview and explicitly approved it in chat — never on the first call, never invented, never reused. Call again with the same arguments. Ignored when the client supports elicitation. |