MCP Server Manager for Model Context Protocol

Overview

MCP Server Manager (MCPM) is a lightweight manager for the Model Context Protocol (MCP) that centralizes deployment and lifecycle control of model contexts across multiple clients. It provides a Homebrew-style, centralized control plane so teams can publish, version, and revoke model contexts from a single server that clients can query or sync against. MCPM is useful for organizations that need reproducible context delivery, coordinated updates, and simple auditability for model-related metadata.

MCPM is intended for developers and SREs who run model-serving infrastructure or client applications that consume model contexts. It provides a CLI and server component to host contexts, manage client registrations, and control distribution rules. The tool focuses on operational simplicity: declarative context configuration, push/pull synchronization, and minimal runtime dependencies to fit into existing deployment workflows.

Features

• Centralized MCP server to host and version model contexts
• CLI for managing server lifecycle, contexts, and client registrations
• Declarative YAML config for server settings, context definitions, and access policies
• Context versioning and rollbacks
• Push/pull synchronization endpoints compatible with MCP-compatible clients
• Lightweight storage backends (local FS, configurable object storage)
• Access control via API tokens and TLS
• Audit logging for deployments and context changes

Installation / Configuration

Clone the repository and install the CLI/server binary locally, or run via Docker. Examples below assume the CLI binary is named mcpm.

Install from source (simple):

git clone https://github.com/pathintegral-institute/mcpm.sh.git
cd mcpm.sh
# build (if Go/Make-based) or copy the script to /usr/local/bin
# Example for script-style distribution:
sudo cp mcpm.sh /usr/local/bin/mcpm
sudo chmod +x /usr/local/bin/mcpm

Run the server with a config file:

# Create a default config
mcpm init --config /etc/mcpm/config.yaml

# Start the server (foreground)
mcpm server start --config /etc/mcpm/config.yaml

# Run as a background service (systemd example)
mcpm server install-service --config /etc/mcpm/config.yaml

Docker (example):

docker run -d \
  --name mcpm \
  -p 8080:8080 \
  -v /etc/mcpm:/etc/mcpm \
  ghcr.io/pathintegral-institute/mcpm:latest \
  mcpm server start --config /etc/mcpm/config.yaml

Example server config (YAML):

server:
  listen: 0.0.0.0:8080
  tls:
    enabled: true
    cert_file: /etc/mcpm/tls/server.crt
    key_file: /etc/mcpm/tls/server.key
storage:
  type: filesystem
  path: /var/lib/mcpm/contexts
auth:
  tokens:
    - id: admin
      token: "REPLACE_WITH_SECRET"
logging:
  level: info

Available Resources

• GitHub repository: https://github.com/pathintegral-institute/mcpm.sh
• Example configs and CLI reference: see the examples/ and docs/ folders in the repo
• Issue tracker and feature requests: GitHub Issues on the repo
• Container image (if published): check GitHub Packages / container registry in repo README

CLI Quick Reference

Example: add a context definition:

mcpm context add --file examples/contexts/vision-context.yaml

List contexts:

mcpm context list
# Output:
# NAME          LATEST  VERSIONS  UPDATED
# image-class   v1.2    3         2026-04-09T12:34:56Z

Use Cases

• Centralized context distribution:

  • A team maintains canonical model contexts (prompts, metadata, environment pins) in MCPM. Client applications pull the latest approved context by calling the MCP endpoint or using the mcpm CLI, ensuring all consumers use the same baseline.

• Coordinated rollouts and rollbacks:

  • Publish a new context version (v2.0) and designate it as staged. A/B test with a subset of clients, then promote to stable. If issues arise, roll back to a prior version with a single command:

    mcpm deploy --context image-class --version v1.2
    

• Auditable context changes:

  • Every context add/update is logged with an author and timestamp. Teams can review the audit trail to track who changed a context and why, simplifying compliance and debugging.

• Multi-environment separation:

  • Use separate configs for dev/staging/prod MCP servers or separate context namespaces within a single server to avoid accidental cross-environment promotion.

• Offline or air-gapped environments:

  • Export contexts from MCPM and import into an isolated instance using the CLI,