Exam Room · Advanced Generative AI Developer

Pop Quiz: Where the MCP Server Lives

· 6 min read

Exam-style

A team is publishing two MCP servers to the same agent. The first wraps a DynamoDB lookup and returns in about 40ms. The second holds a 6GB in-memory graph that takes ninety seconds to build, then answers path queries against it in milliseconds. Where should each one run?

Reveal the answer

B. The lookup as a Lambda target, and the graph server as a long-running task on Amazon ECS with AWS Fargate behind the gateway

Apply the statelessness test to each server on its own. The DynamoDB lookup carries nothing between calls: the gateway invokes it, it reads a row, it returns, and nothing is lost when the execution environment goes away. A Lambda function registered as a gateway target covers it. The graph server fails the test on its first line. Lambda routes each request to whichever execution environment is free, so the one that spent ninety seconds building a 6GB graph is not reliably the one that serves the next request. Provisioned concurrency pre-initialises a pool of environments rather than pinning traffic to a single one: the ninety-second build runs in every environment Lambda allocates, runs again when Lambda recycles an environment, and traffic beyond the pool falls back to on-demand environments that start cold. It also bills continuously, invoked or not. Rebuilding the graph from an Amazon S3 snapshot turns a millisecond query into a ninety-second one. Raising memory to 10,240 MB, the Lambda maximum, changes neither the build time nor the routing. State that has to stay resident belongs in a long-running container, registered as an MCP server target on the gateway. Putting the 40ms lookup in a container as well leaves a task running between calls for work that finishes in milliseconds.

Generative AI Development · part of The Exam Room

Q. One MCP server wraps a DynamoDB lookup and answers in 40ms. The other builds a 6GB in-memory graph over ninety seconds, then answers path queries against it. Where does each run?

A. The lookup goes on Lambda. The graph server goes in a long-running container on Amazon ECS with AWS Fargate, registered through the same gateway.

Why? Ask what survives between calls. The lookup keeps nothing, so an execution environment that disappears after the response takes nothing with it. The graph server holds six gigabytes and ninety seconds of build time. Lambda routes each request to whichever execution environment is free, so the next call may land on one that has never built the graph. Provisioned concurrency pre-initialises a pool rather than pinning traffic to a single environment, and the build runs in each environment it allocates. Anything that has to stay resident, hold a connection pool or carry a session runs in a container. The fifteen-minute execution ceiling and the ninety seconds of reloading on every cold start are the second and third tells. Both servers sit in the same gateway catalogue under the same tool-schema discipline, reached by the agent over streamable HTTP. Where they run follows from the state they hold, not from the interface they present.

These posts are LLM-aided. Backbone, original writing, and structure by Craig. Research and editing by Craig + LLM. Proof-reading by Craig.