Running a shared MCP server for your team

Why and how to self-host one MCP server for a whole team, with authentication, per user tokens and audit logs.

Most people start with MCP servers running locally: a process on each developer's laptop, started by their AI client, using their personal credentials. That is fine for one person. For a team it creates a sprawl of tokens, versions and invisible actions. A shared, self-hosted MCP server fixes that.

Problems with local only MCP#

Every developer stores long lived credentials on their laptop
Nobody knows which version of each tool people are running
Actions are not logged anywhere central
Offboarding means hoping someone revokes all the right tokens

What a shared server looks like#

One MCP server runs on your infrastructure, reachable over HTTPS using the streamable HTTP transport. Developers connect their client to it and authenticate as themselves. The server holds the integration credentials (or better, maps each user to their own scoped token) and enforces what each person may do.

Authentication#

Options, from simplest to most robust:

A personal API token per user, passed as a bearer header
OAuth against your identity provider, which many MCP clients now support
Short lived tokens issued by a gateway

Whatever you pick, avoid one shared secret for the whole team. You lose the ability to tell people apart.

Authorization#

The server should check permissions on every call. A practical model:

Viewers can read status and logs
Developers can deploy and roll back in their projects
Admins can change settings and secrets

Mirror the roles you already use in your deployment platform or Git host rather than inventing new ones.

Deployment#

Run it like any other internal service:

services:
  mcp:
    image: your-mcp-server:1.4.0
    environment:
      MCP_AUTH_MODE: token
    restart: unless-stopped

Put it behind your reverse proxy with TLS, restrict access by IP or VPN if possible, and pin versions so everyone uses the same tools.

Logging and audit#

Log each tool call with user, tool name, arguments (minus secrets) and result. This is your answer to "what did the agent do last night". Keep these logs longer than application logs.

Rate limits and timeouts#

Agents can loop. Limit calls per user per minute and set timeouts on long running tools so a stuck agent cannot hammer your infrastructure.

Rollout tips#

Start with read only tools for everyone
Add write tools for a small group first
Document which client configuration to use, with the URL and auth header
Review the audit log weekly for the first month

When local is still better#

Tools that only touch a developer's own machine, such as a local filesystem or a browser, belong on the laptop. Shared infrastructure belongs on a shared server.

There is a step by step version, including client configuration, in this guide on how to self-host an MCP server for your team.

Disclosure: I work on Peon, whose MCP server uses personal API tokens and workspace roles in this way.