> ## Documentation Index
> Fetch the complete documentation index at: https://docs.mcpmanager.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# Introduction
> What MCP Manager is and the problem it solves: the Model Context Protocol connects AI to your tools but ships without enterprise controls, so MCP Manager puts one governed gateway between your AI clients and your MCP servers — adding identity, governance, runtime protection, and logging. Includes a diagram of the core concepts: users, clients, gateways, servers, and identities.
Welcome to **MCP Manager** — the enterprise control plane for the **Model Context Protocol (MCP)**. MCP Manager puts a single governed [gateway](/mcp-gateway-concepts/mcp-gateways) between the AI apps your teams use and the tools and data those apps reach, so you can adopt MCP with identity, governance, runtime protection, and a complete audit trail instead of saying "no" to it.
## What MCP gives you — and what it leaves out
MCP is an open standard that lets AI applications — Claude, ChatGPT, Cursor, or agents you build — connect to external tools, data, and services through a single, universal interface. It is the integration layer that turns a chat assistant into something that can search your documents, file a ticket, or query a database.
But MCP is a **communication protocol, not a batteries-included enterprise product.** It defines how a client and a server talk; it does not give an organization a way to see, secure, or govern what happens across many clients and many servers. Left raw, four gaps appear — and MCP Manager exists to close them:
* **No central visibility.** Every client wires up to every server directly, a tangled mesh with no place to observe traffic. You can't tell what your AI is doing, and unsanctioned "shadow MCP" usage spreads unseen.
* **Scattered credentials and unclear identity.** Long-lived tokens end up pasted into config files on laptops, and the server has no reliable way to know *which person* an agent is acting for.
* **No governance over what's exposed.** Servers offer far more tools than any one task needs. Over-provisioning inflates cost, slows the model, and widens the attack surface.
* **No runtime protection.** Tool descriptions are read straight into the model's context, so a poisoned description, a "rug pull," or a tool result carrying PII can do real damage with nothing in the path to stop it.
## The core concepts
MCP Manager organizes everything around a handful of concepts. The diagram shows how they fit together: people use clients, clients connect to one gateway, and the gateway brokers the right identity to each server while logging every call.
```mermaid theme={null}
%%{init: {'theme':'base','themeVariables':{'fontFamily':'Lato, sans-serif','lineColor':'#6a6b76','primaryColor':'#e0e2e8','primaryTextColor':'#12141d','primaryBorderColor':'#6a6b76','edgeLabelBackground':'#ffffff','textColor':'#12141d'}}}%%
flowchart LR
subgraph ORG["Your organization"]
direction TB
U["👥
Users & teams"] --> CL["🤖
Clients
Claude · ChatGPT · agents"]
end
CL -->|"one governed URL"| GW["🛡️
MCP Manager gateway
identity · rules · logging"]
GW -->|"the right identity
per user, or a shared one"| S1["🖥️
GitHub"]
GW --> S2["🖥️
Jira"]
GW --> S3["🖥️
Internal database"]
GW -.->|"every call recorded"| LOG[("🗄️
Audit log")]
classDef gateway fill:#0086ff,color:#ffffff,stroke:#062b4c,stroke-width:2px;
classDef client fill:#80cbc4,color:#062b4c,stroke:#00796b,stroke-width:1.5px;
classDef user fill:#c3c9d4,color:#12141d,stroke:#2c2c37,stroke-width:1.5px;
classDef server fill:#aed8ff,color:#062b4c,stroke:#0b4880,stroke-width:1.5px;
classDef datastore fill:#062b4c,color:#ffffff,stroke:#0086ff,stroke-width:1.5px;
class GW gateway;
class U user;
class CL client;
class S1,S2,S3 server;
class LOG datastore;
style ORG fill:transparent,stroke:#9ca1ab,stroke-dasharray:4 3,color:#6a6b76;
```
Each concept has a dedicated page; the short definitions below orient you before you dive in.
* **User and team** — a person who uses MCP Manager, and the [team](/deployment/teams) they belong to. Teams decide which gateways a user can reach; their [role](/deployment/rbac-and-roles/overview) decides what they can do.
* **Client (app or agent)** — the AI application that makes requests: an interactive app such as Claude or ChatGPT, or a headless agent your team builds. See [Apps & Agents](/mcp-gateway-concepts/apps-and-agents).
* **MCP server** — the service that exposes tools and data to AI — GitHub, Jira, an internal database. MCP Manager connects to them as [Remote, Managed, or Workstation](/mcp-gateway-concepts/mcp-servers/overview) servers.
* **Gateway** — the one governed URL in the middle. A [gateway](/mcp-gateway-concepts/mcp-gateways) aggregates many servers, authenticates the caller, applies your rules to every request and response, and logs everything.
* **Identity** — a set of credentials scoped to one server. Identities are what let the gateway act as the **real user** on a downstream server, or as a deliberate shared service account. See [Authentication & Identity](/security/authentication-and-identity).
## How it fits together
A request follows one path. A user's client connects to the gateway with a single URL; the gateway authenticates them, decides which servers and tools they may reach, runs your [rules](/features/gateway-rules/overview) on the request, forwards it to the upstream server using the right brokered [identity](/security/authentication-and-identity), inspects and redacts the response, and writes an [audit-log](/features/viewing-logs) entry at each hop. Governance happens synchronously, in the path of every call.
## Further reading
The three ways MCP Manager connects to servers — Remote, Managed, and Workstation.
The single governed URL at the center of MCP Manager, and how it brokers identity and applies rules.
Identity, feature governance, runtime protections, and audit — how MCP Manager keeps MCP safe.
How roles and teams control who can do what, and which gateways they can reach.