A Model Context Protocol server is stateful by design: a client connects, negotiates capabilities, and keeps calling tools over the same session. That doesn't fit a serverless function that spins up per request and forgets everything in between. On DenkOps it runs in one always-on slot instead, the process stays up, the transport stays open, and nothing gets recycled underneath the client.
Give tool calls a place to write things down: a durable disk at /persist for cached embeddings or session state, and an egress allowlist so the server can reach the APIs it needs and nothing else.
Usually yes, an MCP server holds a session (stdio or a long-lived HTTP connection) rather than answering one-off requests. On a DenkOps slot the process just keeps running, so there's no cold start and no risk of the transport being torn down mid-session the way it can be on a serverless function.
The same way you deploy anything else: install the DenkOps plugin in Claude Code, say "log in to DenkOps" and approve it once in the browser, then say "deploy on DenkOps" from your MCP server's project directory. You get back a live URL and an API key.
← Deploy AI agents · Bun+Hono MCP server guide · FastAPI MCP server guide