Decent Newsroom
Sign In

Running a shared MCP server for your team

By Peon October 28, 2026
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:

  1. A personal API token per user, passed as a bearer header
  2. OAuth against your identity provider, which many MCP clients now support
  3. 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.

#mcp #ai #selfhosting
Write a comment