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.
On one that cannot (claude.ai, Claude Desktop), the first call sends 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.
| 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 does 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. An unrecognised value is treated as `refuse`. |
| `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 maps to a distinct resource plus action (building/floor/space/user/reservation/visitor/maintenance/mail/move), and lifecycle verbs like checkin/checkout, accept/start/complete/archive, and approve/cancel are clearly differentiated. There is minimal risk of misselection even across the many tools.
Every tool follows the same io_<verb>_<noun> snake_case pattern (io_list_buildings, io_create_floor, io_checkin_visitor, etc.), including a consistent io_healthcheck. No convention mixing is present.
53 tools is heavy for effective agent selection, and the count is inflated because each resource repeats the same confirm-token boilerplate across list/get/create/update/delete plus lifecycle transitions. While the breadth is domain-driven, this is well above a comfortable scope.
Coverage is broad: full CRUD for buildings, floors, spaces, users, reservations, and most lifecycle transitions for maintenance, mail, and moves. Some minor gaps exist (e.g. no delete for visitors/mail/moves and no get for moves by some paths), but agents can work around them.