Infrastructure
MCP hosting costs: CPU, memory, traffic, and the idle problem
Why MCP cost depends on runtime isolation and usage patterns, and how to price a hosting platform sustainably.
CPU and memory vary with workload
An MCP server does not consume a fixed amount of CPU and memory at all times. A quiet runtime may use little CPU while retaining its process memory. Tool calls create short CPU and network bursts, and response parsing can increase memory temporarily.
Account for idle capacity
The largest early cost is often idle reservation, not raw compute. Giving every free MCP a permanently running container with a generous memory request limits how many tenants fit on a node even when they receive no traffic. Small runtime classes, concurrency limits, and eventually scale-to-zero improve density.
Separate upstream and model costs
Traffic adds two other costs: upstream and model calls made by the tool, and platform egress. Generation through an LLM should be metered separately from runtime calls because its cost profile is much higher and less predictable.
Budget for operational headroom
A sustainable plan combines an active-MCP limit, a monthly tool-call allowance, and progressively larger runtime classes. Keep operational headroom on each node for Kubernetes, image pulls, rollouts, and failure recovery instead of selling every byte of advertised RAM.
Price from observed usage
Measure real p50 and p95 memory, cold-start time, request duration, and calls per endpoint before tuning prices. Published allowances should follow observed density and support costs, not just the server invoice.