MCP
MCP (Model Context Protocol) is how an AI client reaches the platform. It is the protocol underneath Claudia, and it is available to your own client too.
The one sentence that governs it:
MCP is an integration layer, never a bypass
Every tool is a thin call to the same domain service the back office uses. Not a shortcut into the database, not a parallel API with its own rules. If a service refuses a person, it refuses the tool — because it is the same service, asked by the same person.
Bound to one user, decided by the server
The tool server is started for a specific ERP user, and that user is fixed at startup by the trusted server-side runner.
It is not a parameter. There is no tool that takes a user. A model cannot ask to be somebody else, because the question has no place to be asked.
Everything follows from that:
- Permissions are that person's permissions.
- The organization boundary is that person's boundary.
- The activity trail records the action, the time, the object — and the assistant's signature beside the person's name.
What is exposed
Nearly every module ships tools: content and content types, entities and fields, taxonomy, media and image styles, listings, displays, blocks, layout, menus, addresses and meta tags, forms, files, translations, languages, moderation and workflows, search, sites, partners and CRM, documents, inventory, projects, helpdesk, HR, mail and campaigns, registers, billing, accounting, access and permissions, and the platform's own configuration.
Tools are generated from the service signatures, so a tool's arguments are the service's arguments. There is no second definition to drift.
Parity is required
If an agenda can be created through MCP, it can also be changed and deleted through MCP. A test enforces it. An agenda exposed in half strands whoever used it halfway — with records an assistant made and only a human can clean up.
Refusals
A refusal comes back as a structured answer, not an exception:
| Code | Means |
|---|---|
validation |
The service refused the values, with the fields named |
forbidden |
The user may not do this |
error |
Something else went wrong, with the message |
A client can read a refusal and correct itself. It never receives a traceback, and a refusal is never dressed up as a success.
Switching tools off
Back office → System → Claudia → Disabled tools. An agenda switched off is not in the surface at all. This is the control to reach for when a whole area — accounting, mail — should never be touched by an assistant in your firm, regardless of who is asking.
Connecting your own client
The tool server speaks MCP over stdio and is launched as a management command bound to a user. Because the binding is the security boundary, the launch is a server-side action: a client does not choose the user it runs as.
Do not hand out a server-side launcher
Anything that can start the tool server chooses whose permissions it starts with. Treat that ability the way you treat a superuser account, because that is what it is equivalent to.
Least privilege, and approval for what matters
Two rules the platform holds to:
- AI access is least-privileged. The user Claudia runs as should be a user with exactly the access the task needs, not an administrator because it is convenient.
- High-impact actions require a human. Publication, financial and irreversible operations pass the same approvals and authorizations they pass for a person — the four-eyes rule does not have an exception for assistants.