MCP servers for AI integrations
The Model Context Protocol makes your systems usable by AI assistants — under control, auditable, with a clean permission model. We design and operate MCP servers as production software, not as an experiment.
When a server of your own is worth it
Your people already use AI assistants. The open question is no longer whether those assistants reach internal systems, but how: the document store, the ticketing system, the product database. Leave the question unanswered and the connection happens anyway — pasted into a chat window, past every log and every permission.
A server of your own pays off once those accesses become regular. For a single fixed integration a conventional API is enough; MCP would be effort without return. The value appears as soon as several assistants or several systems are involved. MCP is an open standard with broad client support: one tool definition works the same for every client — desktop assistant, internal chat interface or automated agent.
Decisions that come up
Which capabilities you expose. The permission boundary is not drawn in the firewall but in the tool definition: each tool describes exactly one capability with typed input and output. What is not defined does not exist for the model. Read before write is the usual way in.
How identity is established. OAuth 2.1 is part of the protocol. In grown landscapes sign-in usually runs through Keycloak, so roles and groups stay the same as in the rest of your systems — otherwise a second permission store appears next to the existing one, and nobody maintains it.
Where the server runs. Self-hosted keeps the entire data path with you. For personal or confidential holdings that is rarely negotiable, and it is why we do not offer MCP servers as a managed service.
Whether it needs to be MCP at all. For free-text knowledge a RAG system is often the better answer, and for a single integration an API. We say so even when it is the smaller project.
What you get
- Tool design: which capabilities your system exposes, with which guardrails
- Authentication and authorisation (OAuth 2.1, Keycloak)
- Rate limiting, logging, abuse prevention
- Deployment as a standalone service including CI/CD
- Documentation of the tools, so your own developers can carry them on
How you know it holds
Every access is in the log — with timestamp, identity and the tool called. A capability nobody needs any more can be removed without breaking an assistant. And a new client reaches the same tools with no further integration work: what you defined once applies to all of them.