io_update_visitor
Destructive
Update an existing iOffice visitor record by passing only the fields to change, with a user confirmation required before any write.
Instructions
Update an existing iOffice visitor record. 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 makes NO network call, 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 | Visitor ID | |
| No | Visitor email address | ||
| phone | No | Visitor phone number | |
| company | No | Visitor company/organization | |
| purpose | No | Purpose of visit | |
| lastName | No | Visitor last name | |
| firstName | No | Visitor first name | |
| 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. | |
| expectedArrival | No | Expected arrival date/time (ISO 8601) | |
| expectedDeparture | No | Expected departure date/time (ISO 8601) |