MCP standardizes the tool call, not the authority to cause the effect

Ninety minutes separate the time HR recorded from the time the manager asked for in the dev.to walkthrough ^[18]. Nothing on the protocol path can see that gap: the tool exists, the arguments satisfy the schema, the server accepts the token, the target API answers ^[7]. MCP's error taxonomy has two buckets, malformed protocol requests and failures raised during execution ^[2], and a premature offboarding is neither. It is a successful call.

That is the honest way to read the tools specification. It tells a client how to find a capability and shape a payload ^[1], which removes the need for a bespoke discovery path per database, document system, or internal API ^[20]. The security duties it assigns are real but bounded: servers validate inputs, enforce access controls, rate-limit, sanitize outputs ^[3]; clients surface tool activity, validate results, apply timeouts, log usage, and ask for confirmation on sensitive operations ^[4]. Together those establish that the tool exists, the arguments have an acceptable shape, the caller reached the server, the server accepted or rejected the invocation, and the result conforms to an expected structure ^[5]. Every item on that list is about the call.

The offboarding question turns on facts held elsewhere: which system controls the termination time, whether this manager may modify it, whether a legal hold applies, whether HR has cancelled or delayed the event, whether another workflow already started the same task ^[19]. A schema can demand 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 ^[8]. The authorization specification does not close it either. It covers HTTP-based transports, describing how a client discovers an authorization server, obtains a token, and presents it to a protected resource ^[9], which answers whether the client may make requests within a granted scope, not whether this offboarding should happen at 15:30 ^[10].

Identity is where the cost lands. The piece counts four parties in a production workflow: requester, actor, subject, approver ^[11]. Use the manager's token and the target system may record that the manager disabled the account, even though an automated workflow chose the action and the payload ^[12]. Use a service account and the log names the technical actor while omitting who requested the change and which HR decision authorized it ^[13]. Scopes cap what the actor is technically able to request; workflow policy still has to decide what this run may do to this subject at this time ^[14]. When the server calls onward, the official security guidance warns against token passthrough because it weakens audience restrictions and attribution, and a separate downstream credential defends that boundary without establishing the business reason for using it ^[15].

Hence the envelope the author sketches: task_id, purpose, requester, actor, subject, authoritative_event, policy_version, decision, emitted before a consequential tool call ^[16]. The field doing the work is authoritative_event, the pointer at the HR record that makes 15:30 defensible or not. The author states plainly that the envelope is not part of the specification and not a proposed extension to it ^[17]. So the discovery format is standard, and the justification format is whatever each team builds.