HTTP server

Mon, 01 Jan 0001 00:00:00 +0000

If your MCP server speaks MCP’s streamable-HTTP transport natively (JSON-RPC 2.0 over HTTP POST), Krypton treats it like any other Agent.

Ports refresher: client traffic to :8080 (gateway), introspection / UI on :8090 (control plane). See Ports & endpoints for the full breakdown.

Container contract

Your container needs to:

Listen on spec.port (default 8080)
Accept POST at spec.invocationPath (default /) with JSON-RPC 2.0 bodies
Implement initialize, notifications/initialized, tools/list, tools/call
Honor Accept: text/event-stream if you want strict MCP clients (Postman MCP, MCP Inspector) — return SSE frames when requested, plain JSON otherwise

Deploy

apiVersion: krypton.ai/v1alpha1
kind: Agent
metadata:
 name: my-mcp
 namespace: agents
spec:
 image: my-registry/my-mcp-server:v1
 imagePullPolicy: IfNotPresent
 protocol: mcp
 port: 8080
 invocationPath: /
 mode: always-on
 minReplicas: 1
 maxReplicas: 3

kubectl apply -f my-mcp.yaml

The pod starts, the Service exposes it inside the cluster, the operator UI surfaces its tools.

STDIO server

Mon, 01 Jan 0001 00:00:00 +0000

Most published MCP servers (the official @modelcontextprotocol/server-* packages, plenty of community ones) only speak stdio. Krypton can host them via mcp-stdio-bridge — a tiny HTTP-in-front-of-stdio shim that runs alongside your server inside the same container.

How it works

%%{init: {"theme": "base", "flowchart": {"nodeSpacing": 60, "rankSpacing": 70, "diagramPadding": 24}, "themeVariables": {"fontFamily": "Inter, ui-sans-serif, system-ui, sans-serif", "primaryColor": "#eef2ff", "primaryTextColor": "#1f2937", "primaryBorderColor": "#6366f1", "lineColor": "#64748b", "secondaryColor": "#ecfeff", "tertiaryColor": "#f8fafc"}}}%%
flowchart LR
 request["HTTP POST /<br/>JSON-RPC"] --> bridge["mcp-stdio-bridge"]
 bridge --> stdin["Child stdin"]
 stdout["Child stdout"] --> bridge
 bridge --> response["HTTP response<br/>id-routed"]

 subgraph child["Long-lived MCP process"]
 stdin --> process["Server command"]
 process --> stdout
 end

 classDef traffic fill:#ecfeff,stroke:#0891b2,color:#164e63;
 classDef bridgeNode fill:#eef2ff,stroke:#6366f1,color:#312e81;
 classDef processNode fill:#f0fdf4,stroke:#16a34a,color:#14532d;
 class request,response traffic;
 class bridge bridgeNode;
 class stdin,stdout,process processNode;

The bridge forks $MCP_COMMAND once at container startup.
HTTP requests are serialized to the child’s stdin.
Responses are demultiplexed by JSON-RPC id, so concurrent HTTP requests don’t cross-talk.
Notifications (no id) are fire-and-forget.
One-shot stdio servers (process-per-call) aren’t supported — the child must be long-lived.

Deploy

The published bridge image is a pure-Go binary on distroless/static. That’s enough for stdio binaries that are themselves statically linked. For runtime-dependent servers (Node, Python), layer the runtime onto a derived image first.

Deploying your first MCP server on Krypton Runtime

HTTP server

Container contract

Deploy

STDIO server

How it works

Deploy