Preamble

• Status: Draft
• Type: Standards Track
• Created: 2026-03-27
• Author(s): Zachary German
• Sponsor: TBD
• Discussion: TBD

Summary

Add an optional execution.requirements field to tool definitions:

{
  "name": "launch_rocket",
  "execution": {
    "requirements": [
      "auth:oauth2",
      "auth:claim:role:mission_control",
      "capability:rocket.launch",
      "env:production",
      "state:weather.clear",
      "feature:launch_window.open"
    ]
  }
}

execution.requirements declares a set of opaque requirement identifiers that MUST be satisfied for successful execution.

This enables clients to optionally avoid actions that would deterministically fail, without introducing new semantics into MCP.

Motivation

Currently, tool calls may fail due to unmet preconditions such as missing capabilities, permissions, or environmental constraints. These failures:

• Waste compute and network resources
• Increase latency
• Degrade user experience
• Complicate agent planning and orchestration

MCP does not currently provide a standardized way for tools to declare execution preconditions.

As a result, clients must rely on trial-and-error execution or non-standard metadata, both of which limit interoperability and efficiency.

This proposal introduces a minimal, standardized mechanism to declare preconditions without requiring agreement on their semantics.

Specification

Field

execution?: {
  requirements?: string[]
}

• Each value is an opaque string identifier
• Strings SHOULD be namespaced (e.g., capability:rocket.launch)
• MCP does not define or interpret the meaning of these values

Server Behavior

• Servers MUST enforce all declared requirements at execution time.
• If any requirement is not satisfied, the server MUST fail the call.
• Error responses SHOULD indicate which requirements were unmet when possible.

Client Behavior

Clients MAY use execution.requirements to influence behavior, subject to the following constraints:

• Clients MUST treat requirement strings as opaque.

• Clients MUST NOT infer equivalence between different strings.

• Clients MUST NOT use execution.requirements for any decision-making unless:

  • All requirements are known to the client.
  • The client can determine that at least one requirement cannot be satisfied.

• If the above conditions are met, clients MAY use execution.requirements to influence behavior (e.g., filtering, ranking, or avoiding failures).

• If any requirement is unknown, or if all requirements may be satisfied, clients MUST behave as if execution.requirements were not present.

Backward Compatibility

This change is fully backward compatible:

• Existing clients that do not recognize execution.requirements will ignore it
• Existing servers are not required to implement the field
• No existing behavior is modified

The field is optional and additive.

Security Considerations

• Requirement strings are treated as untrusted input and MUST NOT be interpreted beyond exact matching
• Servers MUST NOT rely on clients for enforcement
• Servers remain the authoritative enforcement point for all requirements
• Clients MUST NOT make security decisions based on inferred semantics

This design ensures that incorrect or incomplete client implementations cannot introduce new security vulnerabilities.

Reference Implementation

A reference implementation can be achieved by:

• Extending tool definitions to include an optional execution.requirements field
• Adding server-side validation logic to check requirements prior to execution
• Optionally implementing client-side logic that applies the strict evaluation rules defined above

Reference implementation: TBD

Relationship to Existing Proposals

This proposal is intentionally minimal and complements ongoing work in the MCP ecosystem rather than overlapping with it.

Several proposals explore adjacent areas:

• Tool annotations (e.g., SEP-1984: Comprehensive Tool Annotations for Enhanced Governance and UX #1984 ) introduce richer, structured metadata
• Invocation guidance (e.g., SEP-1938: agencyHint tool annotation #1938 ) provides hints for tool usage
• Security and auth proposals (e.g., SEP-2061: Action Security Metadata for MCP Tools #2061 , SEP-1933: Workload Identity Federation #1933 , SEP-1932: DPoP Profile for MCP #1932 ) define authentication mechanisms

These proposals address important concerns but do not provide a minimal, enforceable mechanism for declaring execution preconditions.

This proposal fills that gap with a semantics-free primitive:

• execution.requirements: string[] defines preconditions without standardizing meaning
• Servers enforce requirements
• Clients may conservatively optimize

This proposal does not compete with or replace existing work and can serve as a foundational primitive for future extensions.

Why Not _meta?

While _meta can be used for experimentation, it does not establish a consistent contract across implementations.

Using _meta would result in:

• No shared field name
• No shared expectations for enforcement
• No reliable client behavior

This proposal defines a minimal, shared contract that enables interoperability while remaining unopinionated about semantics.

Non-Goals

This proposal does not:

• Define a capability or permission taxonomy
• Model authentication or OAuth scopes
• Introduce structured or dynamic requirements
• Require client-side enforcement
• Guarantee successful execution

Future Work

This field is intentionally minimal and may be extended in the future to support:

• Structured requirement objects
• Standardized namespaces
• Integration with authentication metadata
• Richer capability or policy systems

All such extensions can be introduced without breaking compatibility with this proposal.

Rationale

This proposal provides a minimal primitive for declaring execution preconditions.

It is designed to:

• Introduce no new failure modes
• Enable incremental adoption
• Avoid requiring ecosystem coordination
• Improve efficiency by reducing avoidable failed calls

By standardizing only the container (string[]) and not the semantics, this approach allows the ecosystem to evolve naturally while providing immediate value.

A strict, all-or-nothing client evaluation model ensures that execution.requirements can only be used when it is safe to do so, preventing partial or speculative reasoning.