What the MCP platform is

The platform gives AI clients (Claude Code, Claude Desktop, claude.ai) access to company systems such as GitLab, Jira, Confluence, OpenSearch and a service desk through one MCP address. People sign in with their company account. For every call the platform checks the policy, adds the credential the user connected in the portal, asks for a one-time code before a destructive operation and writes an audit trail. The workstation never holds a token that works against the systems.

You are	Start with
A user of an AI client	Sign in to the portal
An administrator who approves servers and handles incidents	Servers
An operator who installs and runs the platform	Requirements
An author of an MCP server	Developer quickstart

Parts

Part	What it does
Gateway	The single MCP address (https://<platform>/mcp). Validates the user’s token, decides whether the call is allowed, takes the user’s credential from the broker, forwards the call to the MCP server and writes the audit event.
Credential broker	Holds each user’s credential for each system, in OpenBao. Runs the authenticator that confirms destructive operations. Knows how to obtain a credential for a product through its adapter.
Portal	The web page where users connect their accounts and administrators add and approve systems and servers, edit the scope mapping and use the kill switch.
MCP servers	Programs that expose tools for one system (GitLab, Jira, Confluence, OpenSearch, service desk, or your own). They hold no user credentials.
Keycloak	The identity provider. Signs users in (password and OTP) and issues the tokens the other parts check.
OpenBao	The secret store behind the broker. Only the broker can reach it.
nginx	The reverse proxy in front of all of it: portal on /, gateway on /mcp, Keycloak on /auth. The only part that publishes ports (443 and 80).

The platform bundle runs the gateway, broker, portal, Keycloak, OpenBao and nginx as one Docker Compose project. MCP servers are separate programs, started next to the bundle or on another host, and added at runtime in the portal.

How a tool call flows

Example: a user asks Claude Code to list GitLab projects.

1. Claude Code sends tools/call to https://<platform>/mcp with the user’s Keycloak token.
2. The gateway validates the token, finds the tool and checks the policy and the user’s groups (scope mapping). If the tool is disabled or not approved, the call ends here.
3. If the tool is destructive, the gateway holds the call and asks for a confirmation code from the user’s authenticator app.
4. The gateway asks the broker for the user’s GitLab credential. The broker reads it from OpenBao (a token or OAuth token the user connected in the portal).
5. The gateway forwards the call to the GitLab MCP server together with the credential. The gateway pins the server’s TLS certificate by fingerprint unless it chains to a trusted CA.
6. The server calls the GitLab API with the user’s own token, so GitLab applies the user’s own rights.
7. The result returns the same way. The gateway writes an audit event.

Systems that do not need a personal credential use another credential type: a token exchange at Keycloak (OpenSearch) or a service account key held by the platform. See the glossary.

System and server

A system is data in the credential broker: how to get a credential for a product (adapter, base address, credential types). A server is a program that exposes tools. The server’s manifest names its system. Without the system, users have nothing to connect and tool calls fail. See Systems and Servers.