A 311 platform exposes a lightweight fee-lookup MCP tool and a heavier GIS analysis tool. How should compute be chosen for the MCP servers?
Select an answer to reveal the explanation.
Short Explanation
A postage-stamp fee chart fits in a quick Lambda; a full GIS crunch needs a bigger workbench like ECS. Match MCP server compute to tool weight. Shoving map analysis into a tiny one-second function is how 311 tools time out.
Full Explanation
A 311 platform exposing both a lightweight fee-lookup MCP tool and a heavier GIS analysis tool should size MCP server compute to workload: Lambda-style functions for simple fee lookups and longer-running container compute such as ECS for GIS. That split keeps cheap, short requests fast while giving map analysis CPU, memory, and time budgets that tiny synchronous functions cannot offer for parcel buffers or routing polygons. Running both tools only on a developer laptop during business hours is not a resilient municipal platform and fails after-hours 311 load. Forcing GIS onto a tiny synchronous Lambda with a hard one-second budget regardless of map size causes timeouts and unreliable agent tool calls. Disabling MCP entirely and pasting GIS screenshots into chat manually abandons standardized tools, auditability, and scalability. Exam caveat: mixed light/heavy MCP tools imply heterogeneous compute sizing—not one undersized Lambda for everything or laptop-only hosting. Operational check: publish separate MCP servers per tool class, set GIS timeouts and concurrency appropriate to map jobs, keep fee lookup cold-start tolerant, and track p95 latency and error rates per tool independently.