How to Host a Remote MCP Server in Production

What makes an MCP server production-ready

A remote MCP server exposes tools and resources over a network boundary instead of only running on a developer machine. The production version needs predictable deploys, authentication, monitored uptime, and a narrow permissions model.

A hosted MCP server should be treated like any other integration backend. It receives high-value prompts, credentials, file references, and tool arguments, so the operational bar needs to be closer to an API service than a demo script.

Deployment checklist

• Package the server as a container or managed runtime with a repeatable build command.
• Expose a health endpoint that checks the server process and required upstream services.
• Use separate staging and production environments.
• Keep tool schemas stable and version breaking changes.
• Limit outbound network access when the server only needs specific APIs.
• Put the server behind TLS and a gateway that understands agent identity.

OAuth, secrets, and identity

Use OAuth when the MCP server acts on behalf of a human user, such as reading a calendar or drafting an email. Use service credentials when the workflow belongs to the application, such as reading a product catalog or writing to an internal ticket queue.

Do not place API keys in prompts, tool descriptions, or browser storage. Store secrets in the hosting environment, inject them at runtime, and let the gateway attach short-lived tokens to each request. AgentDojo keeps that boundary explicit by separating tool profiles from credential material.

Scaling and monitoring

Most MCP servers scale like normal stateless services if sessions, credentials, and approvals live outside the process. Horizontal replicas work well for read-heavy tools. For write-heavy tools, add idempotency keys, queues, and careful retry rules.

Monitor request count, tool latency, upstream API errors, policy denials, OAuth refresh failures, and queue depth. Alert on failed writes and authentication spikes before they become invisible agent failures.

Working example

This simplified server exposes one tool that creates a support draft. In production, the gateway authenticates the caller, injects the email API token, and records the approval state before the tool runs.

Illustrative example from the original guide; verify commands against your installed version.

import express from "express";

const app = express();
app.use(express.json());

app.get("/health", (_req, res) => res.json({ ok: true }));

app.post("/mcp/tools/create_support_draft", async (req, res) => {
  const userId = req.header("x-agent-user");
  const token = process.env.MAIL_API_TOKEN;
  const { customerEmail, issueSummary } = req.body;

  if (!userId || !token) {
    return res.status(401).json({ error: "missing_identity" });
  }

  const draft = {
    to: customerEmail,
    subject: "Follow-up from support",
    body: `Thanks for the context. We are reviewing: ${issueSummary}`,
  };

  return res.json({ draft, requiresApproval: true });
});

app.listen(process.env.PORT || 3000);

Deploying through AgentDojo

In AgentDojo, register the server, assign it to an environment, attach its secret source, and add the tools to a profile. The profile is what agents see. The hosting and credential details stay behind the control plane.

Illustrative example from the original guide; verify commands against your installed version.

agentdojo server register support-mail \
  --url https://mcp.example.com \
  --env production \
  --auth oauth \
  --profile support-prod