Applications & MCP gateway
How the MCP servers your organisation permits reach agents through LiteLLM, how people sign in to them, and what approval modes change.
An application is an MCPMCPMCPModel Context Protocol, the standard way an agent talks to an outside app. The portal reaches every connected app through one MCP gateway inside your AWS account.Open in glossary server your organisation permits. Agents reach its tools through LiteLLMLiteLLM (model gateway)LiteLLM (cổng mô hình)The gateway every model call passes through. It routes to Bedrock, applies each department's key and budget, and records the cost of every call.Open in glossary, which acts as the MCP gateway as well as the model gateway. To the people using it, an application appears as a connected appConnected appỨng dụng kết nối (Connected app)An outside app, such as a ticketing or CRM system, that agents can use on your behalf after you sign in to it under Settings › Connected apps.Open in glossary.
Key rules
- LiteLLM is the MCP gateway, inside your own AWS account, behind a portal-owned adapter.
- Secrets never reach agents. Credentials, provider sessions and gateway policy stay out of agent configuration and conversation data.
- Visibility decides who reaches an application — resolved before a turn’s tool list is built.
- Run without asking skips the confirmation only. Permissions, OAuth scope, policy, idempotency and audit always apply.
- SharePoint is not a live connector. It reaches agents only through knowledge base sync.
The gateway
The portal does not run its own MCP gateway. LiteLLM — already the model gateway — also serves MCP, deployed inside the customer’s AWS account with no public address. The portal talks to it through its own adapter, so credentials, provider sessions and gateway policy never appear in an agent’s configuration or in a conversation.
See Deployment for where the gateway runs.
What an application declares
An application names the server’s address, its transport and how it authenticates:
| Kind | Credential |
|---|---|
NONE | None. |
API_KEY | One organisation key. |
OAUTH2_CODE | Each person’s own OAuth consent, held as a connection. |
OAUTH2_TOKEN_EXCHANGE | The caller’s own token, exchanged at Keycloak for a scoped one. |
Only OAUTH2_CODE creates a per-person connection; the other three kinds need none. Admins register and switch applications on in Admin console → Applications — see Applications.
Registry and aliases
The portal owns the registry of applications and reconciles it to LiteLLM the same way it reconciles a model. Each server gets an alias that is unique across the deployment, and each of its tools is named alias/tool_name on the gateway.
Which servers a person reaches is the application’s visibility, resolved before a turn’s tool list is built. The gateway key issued for that person names exactly the same servers, so the gateway and the portal agree on what is reachable. Per-tool survival rules for a turn are on Access resolution.
Signing each person in
An OAUTH2_CODE application sends each person through an OAuth consent the first time. The gateway has no public address, so the portal relays the two legs:
-
Authorise
Your browser goes to the gateway’s authorise path for the server’s alias, which the portal serves under
/api/mcpand passes through. -
Consent at the provider
You sign in and consent at the application’s own provider.
-
Callback
The provider sends the answer back to a callback, also served under
/api/mcpand passed through to the gateway. The connection is saved as yours.
- The portal carries the gateway’s own cookie in both directions and reads none of it.
- The gateway is told to name that same
/api/mcppath when it asks the provider where to send the answer. That is the one gateway setting a deployment provides. - Nothing of the gateway is published. The other three authentication kinds send a browser nowhere.
You see, connect and disconnect your own apps — and switch individual tools off for yourself — in Settings → Connected apps. See Connected apps.
Approval modes
Every tool call through an application runs under one of two modes:
| Mode | Behaviour |
|---|---|
Run without asking (YOLO) | The tool runs with no per-operation confirmation. |
Ask before each action (ASK_EACH_OPERATION) | An approval request is saved, the run pauses, and the tool runs after the person approves. A denial returns to the loop as a non-executed tool result. |
The default mode is set by your organisation, and an admin can force a single tool to always ask. How the mode is chosen for a call — tool, agent, organisation — is on Agent execution.
SharePoint: knowledge, not a live app
SharePoint does not appear as a connected app, and no agent reads SharePoint live. It reaches the portal as a tool the organisation runs, under one Entra application granted each site through Sites.Selected:
- a scheduled sync pulls a folder into a knowledge base;
- cited retrieval answers from the snapshot that sync keeps;
- what a person reaches is that knowledge base, resolved against them before a search runs.
See SharePoint sync for how the sync works.
Why it works this way
Why integrate a gateway instead of building one
LiteLLM already sits inside the customer’s account as the gateway every model call passes through, and it is the single place a budget is enforced. Using it as the MCP gateway too, behind the portal’s adapter, keeps credentials, provider sessions and gateway policy out of agent configuration and conversations.
Why the portal relays the OAuth legs
The gateway has no public address. Serving the authorise and callback routes under the portal’s own /api/mcp path lets a person consent without exposing the gateway — and the portal never reads the gateway’s cookie it carries.