MCP solves tool invocation, not authorization: the gaps agent builders must close

A tool call that passes every check

A post on dev.to by Coryntas uses an employee-offboarding workflow to show where the Model Context Protocol stops helping. The HR system records that an employee's access should end at 17:00. At 15:30, the employee's manager tells the agent that the last meeting is done and to offboard them immediately. The agent locates the right identity-management tool, builds arguments that satisfy the input schema, presents a token the MCP server accepts, and reaches an available API. According to the author, none of that establishes whether the manager is allowed to move the effective termination time. The integration can behave exactly as designed while the business action it performs is premature or unauthorized.

What MCP's tool boundary actually covers

The article credits MCP with solving a real interoperability problem. Servers publish tool definitions with names, descriptions and input schemas; clients discover capabilities through tools/list and invoke them through tools/call; and the specification separates malformed protocol requests from errors raised during execution. It also assigns security duties: servers must validate inputs, enforce access controls, rate-limit calls and sanitize outputs, while clients should surface tool activity, validate results, apply timeouts, log usage and seek confirmation for sensitive operations.

Those controls, the author notes, establish only that the tool exists, the arguments have an acceptable shape, the caller can reach the server, and the result matches an expected structure. They cannot say which system holds authority over a field like the effective time, whether a legal hold applies, or whether another workflow already started the same task.

Transport authorization answers a narrower question

MCP's authorization specification covers HTTP transports: how a client finds an authorization server, obtains an access token and presents it to a protected resource. The post argues this answers whether the client may make requests within a granted scope, not whether this particular offboarding should happen at 15:30.

Real workflows involve at least four identities, the author writes: the requester who initiates the work, the workload identity acting on the target system, the subject whose access changes, and an approver supplying authority the others lack. Collapsing these roles distorts audit records. With the manager's token, the target system logs the manager as having disabled an account that an automated workflow actually selected; with a service account, the log names the technical actor but drops who requested the change and which HR decision authorized it. OAuth scopes limit what the actor can technically request, while workflow policy must still decide what this run may do to this subject at this time. The article also cites official security guidance against token passthrough when an MCP server calls downstream services, noting that a separate downstream credential still does not supply the business reason for using it.

An execution envelope the runtime can inspect

Before a consequential call, the author proposes that the runtime should hold a compact record of why the action is currently permitted: an illustrative execution envelope that is explicitly not part of the MCP specification. Its fields include requester, actor and subject identifiers, a pointer to the authoritative HR event, the policy version used, an allowed action, an execute-after timestamp, an approval reference with a payload digest, an idempotency key and evidence references. Each field closes a specific gap. The execute-after value stops a valid future action from becoming an authorized immediate one, and the digest binds an approval to one exact payload. The author warns that carrying such values as tool arguments makes them no more trustworthy; the runtime must source them from authoritative systems and block the model or requester from substituting its own.

Approvals expire, and timeouts lie

The timing argument runs like this: HR approves a 17:00 execution at 15:30, the termination is delayed at 16:45, and a legal hold arrives at 16:50. The earlier approval accurately described an earlier state. The runtime should revalidate the facts that materially affect the decision as close to execution as practical, including the current HR event and effective time, employment status, active holds, approval validity, the proposed payload and the observed state of the target account, and it should invalidate an approval or request narrower review when inputs change. A generic confirmation prompt for a disable-user action proves little if the reviewer never saw the subject, the timing or the dependent actions.

Finally, the identity provider may commit a write whose response is lost on the way back. A timeout does not prove failure, and blind retries can duplicate document transfers, notifications or service-desk records. The author argues that write-capable integrations should expose enough execution information for the runtime to choose between retrying, inspecting, reconciling or stopping.

Why it matters

For teams building agent integrations, MCP removes the plumbing: discovery, invocation and transport authentication. It leaves the judgment layer untouched. Authorization to reach a tool is not authorization to act, and a green tool call can encode a decision no human or policy actually made. The gaps the article identifies, from identity separation and policy-versioned approvals to time-bound execution, revalidation and idempotency, all sit above the protocol, which means every organization wiring agents into production systems has to build and audit that layer itself.