DEV Community
Follow
What MCP Doesn't Solve
The article discusses the limitations of the Multi-Capability Protocol (MCP) in complex production workflows, using an employee offboarding example. While MCP standardizes tool invocation and security controls, it doesn't inherent address business logic or authority. The system can confirm tool existence and valid arguments, but not whether a manager can actually change a termination time. The article emphasizes that transport authorization is distinct from business authorization, as it only verifies client access to the server, not the validity of the business action.Production workflows involve multiple identities: requester, actor, subject, and approver, which if collapsed, create misleading audit trails. A robust runtime environment needs a compact record, an "execution envelope," to explain why an action is permitted before a consequential tool call. This envelope includes details like authoritative event, policy version, and execute-after timestamps, tying the action to official records and preventing premature or unauthorized actions.Approvals can expire if material facts change, necessitating revalidation of critical information like employment status and legal holds close to execution time. A timeout during a write operation doesn't confirm failure, highlighting the need for tools to expose execution details like idempotency keys and status lookups to guide retry or reconciliation strategies.Ultimately, responsibility for workflow integrity remains distributed. The host manages tool exposure, the runtime evaluates policy and handles recovery, the MCP server validates requests, and the target system is authoritative for its own records. Implementing these controls has a cost, but it is necessary for high-consequence actions like account disabling, where precise authority, current evidence, and failure semantics are paramount.