MCP Deployment: self-hosted scalable stack on AWS Lambda (move off FastMCP Cloud)

MCP Deployment: self-hosted scalable stack on AWS Lambda

Tracking · Parent EPIC: #493 — R2O related support / downstream applications · PI: 26.4 Operationalization
Owner: R2O team · Related: AKD Labs technical-infrastructure doc → R2O collaboration → "MCP tool deployment" theme

Context

AKD agents are composed from a spec, a model, and tools — and the external tools are MCP tool servers, wired per-agent purely by URL. Today those MCP servers lean on hosted FastMCP Cloud, which carries recurring cost ($$$) and platform limitations we don't control.

The goal is to move off the hosted FastMCP Cloud stack onto our own self-hosted, scalable MCP deployment — built by the R2O team on top of AWS Lambda (serverless MCP: scale-to-zero, pay-per-use, our infra, our limits). Because AKD references MCP tools by URL, cutover is expected to be largely a matter of changing tool URLs between stacks — but the deployment stack itself needs to be designed, built, and operationalized.

What this issue covers

• Design a scalable MCP deployment stack on AWS Lambda — serverless MCP servers (streamable-HTTP interface), fronted by API Gateway / Lambda Function URLs, scaling with demand.
• Infrastructure-as-code for it (e.g. Terraform / CDK) so it's reproducible across dev and prod, consistent with the broader R2O CI/CD direction.
• A repeatable pattern to package and deploy an MCP server onto the stack (one tool server → one deployable unit).
• Authentication for the deployed MCP endpoints — how AKD agents authenticate to them.
• A path to cut existing MCP tools over off FastMCP Cloud to the new stack (swap tool URLs), with a cost / limitations comparison to confirm the win.

Done when

• MCP deployment stack on AWS Lambda stood up via IaC in dev (with a defined prod path).
• At least one representative MCP tool server deployed on it and reachable by an AKD agent end-to-end.
• Deployment pattern documented — how to add and deploy a new MCP server.
• Authentication for MCP endpoints designed and working.
• Cutover plan for existing tools off FastMCP Cloud (URL swap), with cost / limitation comparison captured.

Notes / dependencies

• Relates to sibling R2O themes under #493 — IaC CI/CD, secrets management, and auth consolidation; coordinate rather than duplicate.
• A tool registry (discovering / managing available MCP tools) is a related but separate concern — flag if it should be split into its own issue.

Out of scope

• Building new MCP tools / agents themselves — this is the hosting/deployment substrate, not the tools that run on it (e.g. the PSI agent tools are their own track).
• Non-MCP parts of the R2O operationalization effort beyond what this stack needs.