Skip to main content

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.

Welcome to MCP Manager — the enterprise control plane for the Model Context Protocol (MCP). MCP Manager puts a single governed gateway 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. 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 they belong to. Teams decide which gateways a user can reach; their role 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 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 servers.
  • Gateway — the one governed URL in the middle. A gateway 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.

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 on the request, forwards it to the upstream server using the right brokered identity, inspects and redacts the response, and writes an audit-log entry at each hop. Governance happens synchronously, in the path of every call.

Further reading

MCP Servers

The three ways MCP Manager connects to servers — Remote, Managed, and Workstation.

MCP Gateways

The single governed URL at the center of MCP Manager, and how it brokers identity and applies rules.

Security model

Identity, feature governance, runtime protections, and audit — how MCP Manager keeps MCP safe.

Roles & teams

How roles and teams control who can do what, and which gateways they can reach.