iOffice MCP
# ioffice-mcp
[](https://github.com/chrischall/ioffice-mcp/actions/workflows/ci.yml)
[](https://www.npmjs.com/package/ioffice-mcp)
[](LICENSE)
iOffice MCP server for Claude — developed and maintained by AI (Claude Code)
## Confirmations
Every write and state-changing tool (34 of them) asks the user to confirm first.
A client that can show a confirmation prompt (Claude Code) gets the real prompt
unless `MCP_CONFIRM_ELICITATION=off`.
On one that cannot (claude.ai, Claude Desktop), the first call writes nothing and
returns a preview — the method, path and exact body that would be sent — plus a
single-use `confirmToken`; only a repeat call with that token performs the write,
and a token is refused if any argument changed in between.
An update, delete, `io_cancel_move` or `io_return_mail` first reads the record it
targets, so its preview (and prompt) names what will change — `Delete iOffice
user 42 (Alice Smith)` with her email, not just the id — and a token is also
refused if that record was modified after the preview. An id that does not exist
fails at that read, before anything is previewed.
| variable | default | |
|---|---|---|
| `MCP_CONFIRM_MODE` | `ask-user` | What a write does on a client that cannot show a confirmation prompt (claude.ai, Claude Desktop). `ask-user`: two steps — the first call writes nothing and returns a preview plus a token, and the model must get your approval in chat before calling again with it. `auto`: the same two steps, but the model may use the token after reviewing the preview itself. `refuse`: writes are refused on such clients. A client that can show prompts (Claude Code) always gets the real prompt, unless `MCP_CONFIRM_ELICITATION=off`. An unrecognised value is treated as `refuse`. |
| `MCP_CONFIRM_ELICITATION` | `on` | `off` never shows a confirmation prompt, so every client gets the `MCP_CONFIRM_MODE` behaviour. Set it for a client that says it can show prompts but never does (the write hangs — opencode 2.0.x). Any other value is treated as `on`, with a warning on stderr. |
| `MCP_CONFIRM_TTL_SECONDS` | `600` | How long a token stays valid. |
| `MCP_CONFIRM_SECRET` | random per process | Signing key; set it only if tokens must survive a server restart. |
TDQS
Scored across 53 tools
Each tool follows a resource+action pattern (list/get/create/update/delete per entity, plus explicit state transitions like accept/start/complete/archive for maintenance and checkin/checkout for reservations and visitors). Boundaries between tools are clear: CRUD vs. lifecycle transitions are named distinctly. An agent can reliably pick the right tool for a given intent.
The overwhelming majority use a consistent io_<verb>_<noun> snake_case pattern (io_list_buildings, io_create_space, io_update_reservation), which is highly predictable. The only deviation is io_healthcheck, which lacks a verb and drops the noun_verb grammar, but it is a single outlier.
53 tools is heavy, well above the 25-tool comfort threshold, but the breadth is largely justified by nine distinct facility resources each receiving full CRUD plus workflow transitions. It is borderline: the surface is defensible but large enough to strain context and discovery.
Core lifecycle coverage is strong across buildings, floors, spaces, users, reservations, visitors, maintenance, mail, and moves, including state transitions and a diagnostic healthcheck. Minor gaps exist: no delete tools for visitors, mail, or moves, and mail/move workflows lack full update coverage, but these are workable around.