AWS Has 16,000 APIs. Can MCP Handle It?

The podcast discusses challenges and advancements in developing and optimizing MCP (Multi-Tool Control Protocol) servers, particularly in the context of agent-based systems interacting with complex environments like AWS. A major focus is on improving code review and security, especially regarding the use of "code mode," where agents generate Python scripts for API interactions. This approach poses readability and verification issues, leading to exploration of alternatives such as a constrained, human-reviewable Domain-Specific Language (DSL) to enhance transparency and safety. Security concerns are highlighted, including false positives in detecting malicious behavior, such as documentation changes being flagged as injection attacks.

Further discussion centers on performance optimization through observability, evaluating agent efficiency in terms of tool usage, token consumption, and task completion speed. Techniques like aggregating multiple tool calls into single requests and designing bulk-operation tools aim to reduce latency and cost. The evolution from basic functionality to self-optimizing MCP servers and gateways is explored, along with challenges in maintaining backward compatibility during protocol upgrades like MCP 2.0. Testing complexity and combinatorial scaling are also addressed, emphasizing the need for robust evaluation harnesses and data-driven improvements to understand agent behavior, diagnose failures, and refine system design.

• What if you replaced code mode with a human-reviewable DSL for AWS operations?

  • Move: Design a minimal Domain-Specific Language (DSL) with strict grammar and JSON schema validation for common AWS workflows (e.g., S3 uploads, DynamoDB queries), then build a parser that translates DSL into secure API calls.
  • Why Now?: Code mode generates hard-to-audit Python scripts; with rising security flags (like false injection warnings in documentation), now is the time to shift toward structured, reviewable inputs.
  • Expected Upside: Faster human approval of agent actions, fewer security false positives, reduced risk of harmful code execution, and easier debugging via schema-constrained outputs.

• What if you built observability directly into your MCP server to cut LLM costs by 40%?

  • Move: Instrument your MCP server to log every tool request, correlate sequences, and detect inefficiencies (e.g., repeated single-item calls); then create an aggregation layer that batches redundant requests into bulk operations.
  • Why Now?: You're likely already incurring high token costs from unoptimized round trips - especially if using code mode or chatty agents - and post-launch evaluation data (e.g., from harness tests) makes this the ideal time to act.
  • Expected Upside: Fewer LLM turns, lower latency, reduced cost per task, and cleaner audit trails for agent behavior - all measurable via eval metrics like tokens/turns before and after.

• What if you scoped your MCP server down to a single domain (e.g., DynamoDB) and launched it as a standalone tool?

  • Move: Extract DynamoDB-related APIs from the full AWS set, design 5 tightly scoped tools (e.g., query, scan, update-item), add search support, and publish it as a lightweight, discoverable MCP server on GitHub.
  • Why Now?: With 16,000 AWS APIs overwhelming general-purpose agents, niche tools are emerging as more usable and efficient - plus community-driven servers are already gaining traction.
  • Expected Upside: Higher success rates for database tasks, easier maintenance, better performance due to focused context, and faster adoption by developers who don't need the full AWS surface.

• Implement observability in your MCP server to track and correlate agent tool calls, enabling identification of inefficiencies like redundant requests.
• Design bulk-operation tools instead of single-item tools to reduce LLM round trips and improve performance in agent workflows.
• Develop a low-code DSL with schema validation for agent actions to replace hard-to-review code mode outputs, improving security and maintainability.
• Limit the number of exposed tools (e.g., max 5) and implement a search-based discovery mechanism to prevent overload and simplify agent decision-making.
• Run comprehensive harness-based evaluations with multiple model configurations before deploying changes to catch issues like false-positive injection alerts in production.