Custom Server Readiness Checklist

This checklist covers what's needed to connect a custom (self-hosted) MCP server to MCP Manager. Use this if you already have an MCP server running in a data center, cloud instance, or local environment that you manage.

If you're connecting to a third-party hosted server ("remote"), standing up a new server via our managed deployment wizard, or connecting to a locally running server via our workstation pathway, refer to the relevant documentation for those connection types.

1. Web-Accessible Endpoint 

Your server needs to be accessible via the internet so that MCP Manager can connect to it from our cloud. This doesn't mean you have to reduce your security — you can expose your server to our gateway in a secured manner.

• ☐ Server is accessible from the public internet over HTTPS 
  If using ngrok (recommended) or another tunneling solution to expose your server, that's fine — the URL just needs to be stable and not rotate. A direct port-forward with a static IP or a cloud VPS with a public IP also works. If you don't have a public URL today, we can help provide a pre-provisioned ngrok tunnel during an onboarding call with our team.
   
• ☐ You have the full URL ready to share with us 
  Example: https://mcp.yourcompany.com/mcp or https://xxxx.ngrok.io/mcp 
  The conventional MCP endpoint path is /mcp — confirm your server's actual path. We'll enter this URL into MCP Manager to establish the connection.
   
• ☐ The URL does not require VPN access to reach 
  MCP Manager's gateway (hosted on AWS US-East) needs to reach your server directly. If it's only reachable inside your network, we'll need to set up a tunnel to expose it.

2. Authentication

It's important for your server to be secured and allow users to connect to it with an identity marker. Custom servers with OAuth exist but are not common given they are more complicated to create. We support both OAuth methods and authenticating with header tokens.

Header Authentication

• ☐ Your server validates an authentication header on incoming requests 
  MCP Manager sends configurable HTTP headers with every request to your server. This can be Authorization: Bearer <token>, a custom header like X-API-Key: <secret>, or any other header name/value pair — we support arbitrary key-value header pairs. Your server should check for this header and reject requests without it (HTTP 401 or 403).
   
• ☐ You have a token/secret ready to share securely during onboarding 
  We'll enter this into MCP Manager during setup. It's stored encrypted at rest in our secrets vault. Only MCP Manager's gateway and your server will know the token.

OAuth Authentication

• ☐ If you are using OAuth: allowlist our callback URL 
  If you use OAuth as the auth method for your MCP server, you'll need to allowlist our OAuth callback URL so MCP Manager can complete the OAuth flow on behalf of your users: 
  
  https://mcp.mcpmanager.ai/api/v1/mcpm/inbound/oauth/callback 
  
  This requires creating an OAuth client on your side and registering this callback URL.

3. Transport Protocol

• ☐ Your server supports Streamable HTTP (JSON-RPC over HTTP POST) 
  MCP Manager's gateway communicates via HTTP POST requests to your server's endpoint, with Accept: text/event-stream, application/json and Content-Type: application/json. Your server should accept JSON-RPC 2.0 messages (the MCP protocol) and respond with either a JSON response body or an SSE stream. 
  
  This is the current MCP standard transport (Streamable HTTP, per the 2025-06-18 MCP spec). Most servers built with recent MCP SDKs (e.g., @modelcontextprotocol/sdk v1.x+) support this by default.
   
• ☐ If your server is stdio-only (reads from stdin, writes to stdout) 
  This is handled differently. We'll help you wrap it with a transport adapter (Supergateway) to convert the STDIO or SSE transport stream to HTTP. Reach out to our team and we can help with this process.

4. MCP Protocol Compliance

• ☐ Your server responds to the MCP initialize handshake 
  When MCP Manager first connects, it sends a JSON-RPC initialize request. Your server must respond with a valid JSON-RPC response including serverInfo (name and version) and capabilities (which MCP features your server supports). 
  
  This is standard MCP protocol behavior — if your server works with Claude Desktop or other MCP clients today, this should already work.
   
• ☐ Your server responds to tools/list 
  After initialization, MCP Manager calls tools/list to discover available tools. With a high number of tools (40+, per Anthropic's recommendation), this response will be large — make sure your server can return the full list without timing out. If your tool count is very high, test that the tools/list response stays under reasonable size limits (~1MB).
   
• ☐ Your server supports the mcp-session-id header (recommended) 
  MCP Manager tracks session IDs for continuity. If your server returns a mcp-session-id header in its initialize response, the gateway will include it on all subsequent requests. This enables stateful sessions. 
  
  If your server is stateless, this is optional — but stateful sessions improve reliability (the gateway can auto-recover from "Session not found" errors by re-initializing).
   
• ☐ Your server features (tools, prompts, resources) contain relevant metadata (recommended) 
  MCP Manager uses feature names, descriptions, titles, and annotations to help with rug pull defense and provision tools more safely to users via gateway policies. Accurate metadata helps with configuration of ideal gateway workflows.

5. Server Stability & Uptime

• ☐ Server is running and will stay running during the onboarding session 
  If the Docker container or VM restarts, the tunnel or port forward may drop. Make sure it's live and stable during testing and in production.

What to Send Us Before An Onboarding Call

What we can provide during the call

• One pre-provisioned ngrok tunnel, to be used if needed to expose the server
• Engineering support to help connect and troubleshoot live