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.”
The 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.
None of that establishes whether the manager can change the effective termination time.
The connection may work exactly as designed while the resulting business action is premature, unauthorized, or blocked by information the tool call never examined.
MCP defines a useful tool boundary
The MCP tools specification gives applications a consistent way to discover and invoke capabilities.
A server publishes tool definitions containing names, descriptions, input schemas, and optional output schemas. A client discovers them through tools/list and invokes one through tools/call. The protocol also distinguishes malformed protocol requests from errors produced during tool execution.
This 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.
The 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.
These controls can establish that:
- the requested tool exists;
- the arguments have an acceptable shape;
- the caller can reach the MCP server;
- the server accepted or rejected the invocation; and
- the result conforms to an expected structure.
The 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?
An 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.
Transport authorization has a narrower job
The 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.
That 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.
Production workflows often involve at least four identities:
- The requester initiates the work. In this case, that may be the manager.
- The actor is the workload identity calling the identity-management system.
- The subject is the employee whose access will change.
- The approver supplies authority for a decision the requester or actor cannot make alone.
Collapsing 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.
OAuth 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.
The 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.
The runtime needs a decision it can inspect
Before a consequential tool call, the runtime should be able to produce a compact record explaining why the action is currently permitted.
The following execution envelope is illustrative. It is not part of the MCP specification or a proposed extension to it.
task_id: OFF-2048
purpose: scheduled_employee_offboarding
requester: manager:1842
actor: workload:offboarding-agent-prod
subject: employee:7721
authoritative_event: hris:termination:99108
policy_version: access-offboarding@2026-07-15
decision: allow
allowed_action: identity.disable_sign_in
execute_after: 2026-08-24T17:00:00+07:00
approval_ref: hr-approval:5519
approval_payload_digest: sha256:84f2...
idempotency_key: OFF-2048:disable-sign-in
evidence_refs:
- hris:employee:7721@version-44
- idp:user:8fd2@observed-16:59:52
Each field closes a specific gap around the tool call.
authoritative_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.
Evidence 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.
The 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.
Approval can expire before execution
Suppose 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.
The earlier approval accurately described an earlier state. Reusing it without another check would authorize an action whose conditions have changed.
The runtime should revalidate the facts that materially affect the decision as close to execution as practical. For this workflow, that may include:
- the current HR event and effective time;
- the employee’s employment status;
- active legal or security holds;
- the validity of the approval;
- the proposed action payload; and
- the observed state of the target account.
This 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.
If a material input changes, the runtime should invalidate the approval or request a narrower review. A generic confirmation for disable_user provides little evidence if the reviewer never saw the subject, effective time, source event, or dependent actions.
A timeout does not reveal whether the write happened
At 17:00, the agent calls disable_sign_in. The identity provider commits the change, but the response is lost before the MCP server receives it.
From the caller’s perspective, the request timed out. That observation does not prove failure.
Immediately 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.
The 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:
- a caller-supplied idempotency key;
- a stable downstream operation identifier;
- a status lookup independent of the original request;
- a result that distinguishes rejected, committed, and unknown states; and
- documented retry and compensation behavior.
MCP can transport these arguments and results. It cannot make HR, identity, storage, and ticketing systems participate in one atomic transaction.
The 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.
Responsibility remains distributed
The 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.
A production workflow adds responsibilities across those components.
The 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.
Logs from each component need shared identifiers. Otherwise, every system may contain an audit trail while no operator can reconstruct the complete action.
This 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.
A 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.
MCP makes tool integration more consistent. Production operation still depends on explicit authority, current evidence, durable workflow state, and known failure semantics around each call.
When one of your MCP writes times out, what record tells the runtime whether it should retry, reconcile, or stop?
This article was adapted for the DEV community from MCP Connects Tools. It Does Not Govern the Work., originally published by Coryntas.
Top comments (2)
Strong distinction. One addition I would make is to separate the decision envelope from the outcome receipt. The envelope proves why the call was allowed using current authority and evidence; the receipt proves what state was actually observed afterward. They can share task, subject, and idempotency identifiers, but should carry different timestamps and digests. Otherwise a valid policy decision can be mistaken for evidence that the side effect committed. For an unknown outcome, the next legal action should come from a status or reconciliation transition, not a fresh model decision.
Really liked the four-identity breakdown. Most MCP discussions collapse those roles into one authorization check, but the offboarding case shows each identity answers a different question and the seam between them is where authorization actually breaks.
One structural approach that follows from your framing is to split proposal from confirmation. The tool proposes the action with the full execution envelope, and a separate context outside the tool scope decides whether to authorize it. That separation means the runtime can revalidate supporting evidence right before execution, and the retry-in-doubt problem becomes simpler because the same proposal replayed against the same confirmation gate produces the same result rather than a new side effect. The propose-confirm split is also the same pattern that applies when the side effect has a financial cost. Some teams building agent-native infrastructure apply it to payment flows: the agent proposes, a wallet confirms, and the key never enters the tool call.