A detailed engineering account of building a production-grade MCP server on AWS for a B2B intelligence platform with over one million company profiles. Key design decisions include strict read/write tool separation, a default-deny --allow-mutations flag, OIDC-based authentication via AppSync, and a layered testing strategy using mocked GraphQL clients plus MCP Inspector for real-backend validation. The post covers nine narrowly scoped tools, normalization bugs caught by capturing GraphQL variables in tests, a production failure (Lambda null-pointer error) only caught through integration testing, rate limiting for AI search, and structured logging practices. Practical recommendations emphasize treating the MCP layer as a first-class interface rather than a thin API wrapper.

25m read timeFrom infoq.com
Post cover image
Table of contents
IntroductionThe ArchitectureRead and Write Should Not Be BlurredDefault-Deny MutationsTool Contracts Matter More Than Tool CountLocal Validation Is a Production ConcernTest the MCP Layer as Its Own InterfaceFailure Modes and What Worked or FailedLogging and Operational VisibilityPractical RecommendationsConclusionAbout the Author
336 Impressions