Proposal: Pre-Effectuation Execution-Finality Extension for MCP Tool Calls #3236

Proposal: Pre-Effectuation Execution-Finality Extension for MCP Tool Calls

I would like to propose discussion of an optional pre-effectuation execution-finality mechanism for MCP tool calls, particularly for agentic or high-consequence actions.

The core question is:

Should permission to invoke an MCP tool automatically be treated as permission for the resulting action to become externally effective?

For many ordinary tool calls, the present model may be sufficient. However, for actions involving payments, file export, message transmission, infrastructure modification, database writes, credential use, device control, or physical actuation, there may be value in separating computation and tool invocation from authority to create an external consequence.

1. Problem Space

An AI agent may correctly invoke an authorized MCP tool while the resulting action is nevertheless inappropriate because of changed context, revoked permission, destination mismatch, replay, stale authorization, incorrect purpose, excessive scope, or compromised application state.

For example:

• an agent may be permitted to use a payment tool but not to authorize every amount or recipient;
• a file tool may be available, but a particular document may not be permitted to leave a protected environment;
• a messaging tool may be authorized, but the specific recipient, content, or purpose may fall outside the permitted scope;
• an infrastructure tool may be callable, but a destructive operation may require stronger validation immediately before execution.

The proposal therefore distinguishes:

permission to request an operation

from

authority for the specific operation to become externally effective.

2. Existing Approaches and Remaining Gap

Existing security mechanisms remain important.

Authentication identifies principals. Authorization determines permitted access. OAuth and similar mechanisms delegate access. User confirmation can approve sensitive requests. Sandboxing constrains applications. Logging and audit systems record activity. Policy engines can evaluate rules.

The proposed mechanism would not replace these approaches.

The narrower question is whether MCP could support an optional standardized mechanism for preserving a proposed operation in a non-effective state until execution-specific conditions have been validated at, or close to, the point where the consequence actually occurs.

This creates a distinction between:

Tool access authorization

and

Specific execution finality authorization.

The latter would be scoped to the particular act rather than functioning as general permission to use the tool.

3. Short Definitions

Candidate Act
A specific proposed operation generated or requested through an MCP workflow that has not yet been permitted to create its intended external consequence.

Non-Effective State
A state in which the Candidate Act may be constructed, inspected, validated, or rejected but cannot yet produce the external effect.

Protected Validation
A validation step that checks execution-relevant conditions such as identity, purpose, destination, scope, freshness, revocation state, limits, or other policy predicates.

Execution Authority
A narrowly scoped authorization associated with the validated Candidate Act. Stronger implementations could bind this authority to the specific act, execution context, security state, destination, freshness value, and consequence boundary so that simple possession or replay is insufficient.

Finality Sink
The consequence boundary responsible for allowing the operation to become externally effective only after the required execution authority has been successfully verified.

The Finality Sink is a logical role rather than necessarily a single physical component.

Examples could include a payment commit boundary, network transmission boundary, file-release boundary, database commit point, device actuator, or another point where an operation becomes externally consequential.

4. Proposed Flow

Conceptually:

MCP Tool Call

↓

Candidate Act

↓

Non-Effective State

↓

Protected Validation

↓

Scoped Execution Authority

↓

Finality Sink Verification

↓

External Effect

If validation fails:

Failure / Timeout / Replay / Revocation / Ambiguity

↓

Default Denial

↓

No External Effect

The important property is that validation occurs before effectuation, rather than relying only on detection, logging, or remediation after the consequence has already occurred.

5. Example

Consider an MCP-connected payment tool.

The agent requests:

send_payment(recipient, amount)

Instead of immediately committing the payment, the system first creates a Candidate Act containing the load-bearing execution attributes.

The payment remains non-effective while the relevant conditions are checked, for example:

• authorized agent/application identity;
• permitted recipient;
• permitted amount;
• permitted purpose;
• transaction freshness;
• current revocation state;
• applicable limits;
• current security epoch or execution context.

Only after successful validation would scoped execution authority be made available.

The payment consequence boundary would then verify that authority before committing the transaction.

A copied, stale, mismatched, revoked, replayed, or improperly scoped authorization would not be sufficient to cause the payment to become effective.

The same pattern could potentially apply to:

• sending messages;
• exporting files;
• publishing data;
• changing cloud infrastructure;
• database writes;
• API-triggered purchases;
• credential use;
• robotics or device control;
• other high-consequence MCP tools.

6. Why This May Be Useful for Agentic MCP Workflows

Agentic systems can chain multiple tools and make decisions at machine speed.

As tool autonomy increases, the point at which an AI system decides what it wants to do may become increasingly separated from the point at which that decision creates a real-world consequence.

A standardized execution-finality mechanism could provide:

• separation of computation from final execution authority;
• fail-closed handling of uncertain or invalid execution state;
• stronger resistance to stale or replayed authorization;
• act-specific rather than broadly reusable authority;
• clearer enforcement at consequence boundaries;
• more precise auditability of what was actually authorized;
• an additional control for high-consequence autonomous workflows;
• compatibility with existing authentication and authorization mechanisms rather than replacement of them.

7. Backward Compatibility

I am proposing this as an optional extension, not as a requirement for every MCP tool call.

Ordinary tools could continue operating normally.

Tools or hosts dealing with high-consequence operations could advertise or negotiate support for execution-finality semantics where appropriate.

This could allow incremental adoption without changing the basic MCP interaction model for existing implementations.

8. Questions for the MCP Community

I would appreciate feedback from MCP security, authorization, protocol, and SDK contributors on the following:

1. Does the distinction between tool-call authorization and authorization for a specific act to become externally effective represent a meaningful problem for MCP?

2. Should this type of mechanism belong at the MCP protocol/extension layer, or should it remain entirely an implementation concern for hosts and tools?

3. Would it be useful for MCP to standardize a representation for a Candidate Act and scoped execution authority while leaving the actual validation technology implementation-specific?

4. Should verification occur primarily at the MCP host, MCP server, tool implementation, or the actual consequence boundary?

5. Are there existing MCP proposals, authorization efforts, security working groups, or SDK mechanisms that already address this problem?

6. If the concept is considered useful, what would be the appropriate next step for a minimal reference implementation and potential SEP ( STANDARD ESSENTIAL PATENT ) ?

The intent of this discussion is to understand whether the problem space and architectural boundary are useful to MCP before proposing detailed protocol changes.