{"slug": "what-mcp-doesn-t-solve", "title": "What MCP Doesn't Solve", "summary": "An engineer argues that the Model Context Protocol (MCP) solves tool interoperability but does not address business authorization, using an employee-offboarding example to show that a valid tool call can still be unauthorized. The post emphasizes the need for an execution envelope that records the requester, actor, subject, and policy version to support auditability and correct authorization.", "body_md": "Consider an illustrative employee-offboarding workflow. The HR system records that access should end at 17:00. At 15:30, the employee’s manager sends a message: “Their last meeting is done. Offboard them now.”\n\nThe agent finds the correct identity-management tool. Its arguments satisfy the input schema. The MCP server accepts its access token, and the target API is available.\n\nNone of that establishes whether the manager can change the effective termination time.\n\nThe connection may work exactly as designed while the resulting business action is premature, unauthorized, or blocked by information the tool call never examined.\n\nThe MCP tools specification gives applications a consistent way to discover and invoke capabilities.\n\nA server publishes tool definitions containing names, descriptions, input schemas, and optional output schemas. A client discovers them through `tools/list`\n\nand invokes one through `tools/call`\n\n. The protocol also distinguishes malformed protocol requests from errors produced during tool execution.\n\nThis boundary solves a real interoperability problem. An application does not need a custom discovery mechanism for every database, document system, or internal API it connects to. Tool definitions give the model enough information to choose a capability and construct an argument payload.\n\nThe specification also assigns important security responsibilities. Servers must validate inputs, enforce access controls, rate-limit calls, and sanitize outputs. Clients should expose tool activity to users, validate results, apply timeouts, log usage, and request confirmation for sensitive operations.\n\nThese controls can establish that:\n\nThe offboarding decision depends on additional facts. Which system controls the termination time? Can this manager modify it? Is there a legal hold? Has HR cancelled or delayed the event? Has another workflow already started the same task?\n\nAn input schema can require employee_id, effective_at, and reason. It cannot determine which source has authority over effective_at unless the surrounding system supplies and enforces that rule.\n\nThe MCP authorization specification defines authorization for HTTP-based transports. It describes how a client discovers an authorization server, obtains an access token, and presents that token to a protected MCP resource.\n\nThat flow helps answer whether the client may make requests to the server with the granted scope. It does not contain the organization’s employment policy or decide whether this offboarding should happen at 15:30.\n\nProduction workflows often involve at least four identities:\n\nCollapsing these roles creates misleading audit records. If the agent uses the manager’s token, the target system may record that the manager disabled the account even though an automated workflow selected the action and payload. If the agent uses a service account, the log may identify the technical actor while omitting who requested the change and which HR decision authorized it.\n\nOAuth scopes can restrict what the actor is technically able to request. Workflow policy must still decide what this run may do to this subject at this time.\n\nThe distinction becomes more important when an MCP server calls another service. The official security guidance warns against token passthrough because it weakens audience restrictions and attribution. A separate downstream credential protects that boundary, but it still does not establish the business reason for using the credential.\n\nBefore a consequential tool call, the runtime should be able to produce a compact record explaining why the action is currently permitted.\n\nThe following execution envelope is illustrative. It is not part of the MCP specification or a proposed extension to it.\n\n```\ntask_id: OFF-2048\npurpose: scheduled_employee_offboarding\n\nrequester: manager:1842\nactor: workload:offboarding-agent-prod\nsubject: employee:7721\n\nauthoritative_event: hris:termination:99108\npolicy_version: access-offboarding@2026-07-15\n\ndecision: allow\nallowed_action: identity.disable_sign_in\nexecute_after: 2026-08-24T17:00:00+07:00\n\napproval_ref: hr-approval:5519\napproval_payload_digest: sha256:84f2...\n\nidempotency_key: OFF-2048:disable-sign-in\n\nevidence_refs:\n  - hris:employee:7721@version-44\n  - idp:user:8fd2@observed-16:59:52\n```\n\nEach field closes a specific gap around the tool call.\n\nauthoritative_event ties the action to an HR record rather than the latest message in chat. policy_version preserves the rule used to reach the decision. execute_after prevents a valid future action from becoming an authorized immediate action. The approval digest binds the reviewer’s decision to a particular payload. The idempotency key gives the target service a way to recognize a repeated request.\n\nEvidence references retain the records behind the decision without forcing every source document into the model context. They also give an operator something concrete to inspect when a run is challenged later.\n\nThe MCP request can carry some of these values as tool arguments. Their presence alone does not make them trustworthy. The runtime still needs to obtain them from authoritative systems, evaluate the applicable policy, and prevent the model or requester from substituting unsupported values.\n\nSuppose HR approves the offboarding plan at 15:30 for execution at 17:00. At 16:45, the termination is delayed. At 16:50, legal places the employee’s documents on hold.\n\nThe earlier approval accurately described an earlier state. Reusing it without another check would authorize an action whose conditions have changed.\n\nThe runtime should revalidate the facts that materially affect the decision as close to execution as practical. For this workflow, that may include:\n\nThis does not require a person to approve every directory read. Approval is more useful when it binds to the consequence: which account will change, when it will change, what related transfers will occur, and which exceptions remain unresolved.\n\nIf a material input changes, the runtime should invalidate the approval or request a narrower review. A generic confirmation for `disable_user`\n\nprovides little evidence if the reviewer never saw the subject, effective time, source event, or dependent actions.\n\nAt 17:00, the agent calls `disable_sign_in`\n\n. The identity provider commits the change, but the response is lost before the MCP server receives it.\n\nFrom the caller’s perspective, the request timed out. That observation does not prove failure.\n\nImmediately retrying may be harmless if the operation is idempotent. The same approach can cause duplicate document transfers, repeated notifications, or multiple service-desk records when applied to other offboarding steps.\n\nThe tool boundary therefore needs more than a generic retry counter. A write-capable integration should expose enough execution information for the runtime to decide whether to retry, inspect, reconcile, or stop. Useful capabilities include:\n\nMCP can transport these arguments and results. It cannot make HR, identity, storage, and ticketing systems participate in one atomic transaction.\n\nThe workflow must retain which actions were planned, approved, attempted, and observed as committed. Restarting the conversation is not a recovery strategy. A resumed run needs durable state that prevents completed writes from being replayed and directs uncertain writes into reconciliation.\n\nThe MCP architecture gives the host responsibility for areas such as connection permissions, consent, and context aggregation. Servers expose focused capabilities, while clients maintain their connections to those servers.\n\nA production workflow adds responsibilities across those components.\n\nThe host determines which servers and tools enter the model’s action surface. The workflow runtime retains task state, evaluates policy, binds approvals, and handles recovery. The MCP server validates requests and translates downstream failure details. The target system remains authoritative for whether its own records changed.\n\nLogs from each component need shared identifiers. Otherwise, every system may contain an audit trail while no operator can reconstruct the complete action.\n\nThis machinery has a cost. Revalidation adds latency. Evidence retention introduces access-control and privacy obligations. Narrow tool exposure reduces flexibility. Reconciliation requires background processing and an owner for cases automation cannot resolve.\n\nA read-only assistant that searches public documentation may not need the same controls as an agent that disables accounts. The required boundary should follow the consequence of the action and the difficulty of recovering from an incorrect result.\n\nMCP makes tool integration more consistent. Production operation still depends on explicit authority, current evidence, durable workflow state, and known failure semantics around each call.\n\nWhen one of your MCP writes times out, what record tells the runtime whether it should retry, reconcile, or stop?\n\n*This article was adapted for the DEV community from MCP Connects Tools. It Does Not Govern the Work., originally published by Coryntas.*", "url": "https://wpnews.pro/news/what-mcp-doesn-t-solve", "canonical_source": "https://dev.to/coryntas/what-mcp-doesnt-solve-1ahe", "published_at": "2026-08-24 07:42:00+00:00", "updated_at": "2026-08-24 08:13:41.320425+00:00", "lang": "en", "topics": ["ai-agents", "ai-tools", "ai-infrastructure", "developer-tools"], "entities": ["Model Context Protocol", "MCP", "OAuth"], "alternates": {"html": "https://wpnews.pro/news/what-mcp-doesn-t-solve", "markdown": "https://wpnews.pro/news/what-mcp-doesn-t-solve.md", "text": "https://wpnews.pro/news/what-mcp-doesn-t-solve.txt", "jsonld": "https://wpnews.pro/news/what-mcp-doesn-t-solve.jsonld"}}