The Model Context Protocol (MCP) has been hailed as a breakthrough for AI agent interoperability, but developer Sylwia Lask warns that the simplicity of implementation masks deeper operational risks. In a recent deep-dive, Lask demonstrates that while a functional MCP server can be built in roughly 150 lines of code, the real work begins when you consider access control, idempotency, and human-in-the-loop workflows. The protocol standardizes how AI clients discover and call tools, but it does not solve the fundamental engineering challenges of trusting those tools in production environments.

The Steve Experiment

To illustrate the point, Lask introduces 'Steve,' a grumpy senior developer AI agent built to review code and interact with a mock HR department. Steve’s MCP server exposes four tools: get_employee_record, file_complaint, nominate_for_promotion, and get_hr_stats. The implementation is straightforward, using SQLite for storage and Zod for input schema validation. When Steve reviews a file containing intentional security flawsβ€”such as SQL injection and swallowed exceptionsβ€”he correctly identifies the issues and automatically files a severe HR complaint against the developer, Sylwia. This demonstrates the power of agent-driven automation: the AI didn't just analyze text; it executed a side-effecting action in a database.

Why MCP Beats Custom REST Integrations

Lask addresses the common question of why use MCP when REST APIs already exist. The key advantage is standardization and reusability. While a single internal agent might benefit from hardcoded tools, MCP allows one server to be discovered and used by multiple AI clients without writing custom integration code for each one. Lask proves this by connecting her HR MCP server to Kiro, an agentic IDE from AWS. The same server that Steve used was instantly available to Kiro, which then filed additional complaints against Lask’s own code. This 'write once, use everywhere' approach is the core value proposition of the protocol, shifting the burden from integration maintenance to tool definition.

The Hidden Dangers of Simple Tools

However, the demo reveals critical gaps that production systems must address. First, there is a lack of human-in-the-loop safeguards; Steve filed a complaint on a demo file without asking for approval, potentially causing unnecessary friction. Second, the agent lacks idempotency. When Lask ran Steve a second time without changing the code, he filed a duplicate complaint with a different severity rating ('legendary' instead of 'severe'), highlighting the unpredictability of LLM-based decision-making. Finally, the trust model is weak. Lask notes that tool descriptions are not proof of implementation integrity, and untrusted MCP servers could introduce prompt injection vulnerabilities or perform unintended actions. These issues are not protocol failures but rather classic software engineering challenges that MCP does not automatically solve.

Key Takeaways

  • MCP implementation is trivially easy, often requiring only a few hundred lines of code for basic tool exposure.
  • The protocol enables true interoperability, allowing a single MCP server to serve multiple AI clients like custom agents and IDEs.
  • Operational complexity arises in access control, idempotency, and human oversight, which are not handled by the protocol itself.
  • Developers must implement server-side permission checks and audit trails to prevent agents from making unauthorized or duplicate real-world changes.

The Bottom Line

MCP is a powerful standardization layer, but it is not a silver bullet for agent safety. Builders must treat MCP servers as critical infrastructure, applying rigorous security and business logic constraints rather than assuming the protocol will handle the hard parts of production deployment.