[Proposal] 15 Protocol Extensions for Robust Agent Workflows — Schemas + Reference Implementations

[davioe]

Pre-submission Checklist

• I have verified this would not be more appropriate as a feature request in a specific repository
• I have searched existing discussions to avoid duplicates

Your Idea

I've put together a set of 15 concrete, prioritized extension proposals for MCP, focused on what's needed to move from single-step tool calls to reliable multi-step agent workflows. Each proposal includes:

• Formal JSON schemas (JSON Schema 2020-12, validated via ajv)
• Working reference implementations in Python and TypeScript with JSON-RPC 2.0 wire framing
• A per-proposal spec alignment audit against MCP 2025-11-25 (including Tasks, Extensions framework, Elicitation, and tool annotations)
• Transport-level demos (real HTTP servers with SSE, HMAC-signed URLs, cross-server Saga orchestration)
• Three SEP drafts ready for submission (formatted per the official SEP template)

The full proposal, schemas, and code live here: https://github.com/davioe/mcp-extension-proposals

The Core Problem

MCP works remarkably well for single-step tool calls. But in practice, real agent workflows are multi-step, data-intensive, and failure-prone. Five systematic gaps emerge:

1. Clients call tools semi-blindly. There's no standardized way to discover what a server can do, what it costs, or what permissions it requires -- until something fails.
2. No safe multi-step operations. No idempotency guarantees, no transactions, no rollback. A network failure mid-workflow leaves things in an inconsistent state.
3. Long operations block silently. No progress feedback, no streaming, no resumption after interruption.
4. Errors are opaque. Generic error responses don't tell the client whether to retry, re-authenticate, or give up.
5. Permissions are binary. A server is connected or it isn't -- there's no granular scope model and no pre-flight permission check.

Spec Alignment: What's Genuinely New vs. Already Covered

Every proposal has been audited against MCP 2025-11-25 (including Tasks SEP-1686, Extensions framework, Elicitation, tool annotations, OAuth 2.1, and MCP Apps SEP-1865). The result: 0 proposals superseded, 7 partially addressed, 8 not addressed at all. Full audit files: docs/spec-alignment/

The 15 Proposals

Critical (biggest impact, broadest agreement)

#	Proposal	What it adds	Spec Status
1	Capability Discovery & Service Manifest	Standardized manifest: tools, typed signatures, auth, rate limits, costs, supported extensions	Partially addressed (major) -- initialize + annotations exist, but no operational metadata
4	Granular Permissions & Scoped Auth	Fine-grained scopes, can_execute pre-flight check, session tokens with TTL	Partially addressed (major) -- OAuth 2.1 at transport level, but no per-tool scopes
5	Idempotency & Transactions	Idempotency keys on state-changing calls + compensation-based rollback + cross-server Saga coordination	Gap -- idempotentHint is advisory only, no wire-level mechanism
8	Streaming & Progress Notifications	Structured progress channel, streaming partial results, checkpoint tokens for resumption	Partially addressed (major) -- Tasks (SEP-1686) handles status but not partial streaming

High

#	Proposal	What it adds	Spec Status
11	Structured Error Model	Errors with category, retry_after, suggestion, user_actionable	Gap -- JSON-RPC codes only
6	Human-in-the-Loop	requires_confirmation + risk_level on tool definitions (mandatory, not advisory)	Partially addressed (major) -- destructiveHint is advisory, Elicitation is runtime data-gathering
2	Intent Hints	Optional intent field so the server can suggest a better tool	Gap
7	Provenance	Source attribution on responses (source, location, confidence, timestamp)	Gap

Medium / Lower

#	Proposal	Spec Status
3	Cost & latency transparency	Gap
9	Data references between servers	Gap
10	Multimodal tool signatures	Partially addressed (minor)
12	Conformance test suite	Gap
13	Server discovery / recommendations	Partially addressed (minor)
14	Session state across calls	Partially addressed (major)
15	Bidirectional context push	Partially addressed (major)

What's in the Repo

• README.md -- Full proposal text with rationale, JSON examples, and gap analysis table for all 15 proposals
• schemas/ -- 10 JSON Schema 2020-12 definitions, validated via ajv in CI
• examples/python/server.py -- Reference server with JSON-RPC 2.0 wire framing, 7 conformance tests (stdlib only)
• examples/typescript/server.ts -- Same in TypeScript
• examples/manifests/ -- 5 realistic manifests (GitHub, Jira, Slack, Linear, Notion)
• Transport-level demos (real HTTP, not simulations):
  • SSE subscription demo -- Server-Sent Events over HTTP with JSON-RPC notification envelopes
  • Signed-URL data reference demo -- HMAC-SHA256 signed URLs, TTL expiry, zero-copy-through-client transfer
  • Cross-server Saga demo -- 3 independent HTTP servers, compensation-based rollback with server-unavailability failure
• docs/spec-alignment/ -- Per-proposal audit against MCP 2025-11-25 (15 files)
• seps/ -- 3 SEP drafts ready for submission (Human-in-the-Loop, Idempotency & Transactions, Structured Errors)
• CI -- GitHub Actions validates all schemas (ajv) and runs all 10 demos on every push

Relation to Existing Discussions

Several of these proposals overlap with or extend ideas already discussed here:

• Streaming & progress -> relates to Update README.md #117 (Streaming tool use results) and #314 (Task semantics)
• Scoped auth & permissions -> relates to doc: Add Rust SDK to REAME #483 (Fine-grained resource control) and #804 (Gateway-based authorization)
• Structured errors -> relates to MCP server not recognizing x-session-id/x-user-id headers via POST /messages/ in FastAPI integration #315 (Suggested response format)
• Capability discovery -> relates to [Enhancement] Hierarchical Tool Management for MCP - Solving Context Overflow at Scale #532 (Hierarchical tool management)

The intent is to complement these existing threads, not to replace them.

Design Constraints

Every proposal follows these rules:

• Model-agnostic. No vendor-specific extensions.
• Backwards-compatible. Every extension is opt-in. Existing servers work unchanged.
• Incrementally adoptable. Each proposal is independent.
• Framed as MCP Extensions. Using the GA Extensions framework (SEP-2133), not core spec changes.
• Proven patterns. Idempotency keys, capability negotiation, session tokens, Saga compensation -- all battle-tested.

SEP Submission

Three proposals have draft SEPs ready for submission to modelcontextprotocol/modelcontextprotocol:

1. Human-in-the-Loop Confirmation -- Mandatory confirmation protocol (complementary to Elicitation and tool annotations)
2. Idempotency & Transactions -- Wire-level idempotency keys + compensation-based rollback with cross-server Saga coordination
3. Structured Error Model -- Machine-readable error categories, retry semantics, and remediation suggestions

Each SEP includes the official preamble fields, RFC 2119 language, and self-contained descriptions. See the submission checklist for the process.

What I'm Looking For

• Which of the 15 proposals resonate most with your experience?
• Are any of these already being worked on in a way I've missed?
• Where do you disagree with the approach?
• Would it be useful to submit the three prepared SEPs as PRs?
• Interested in sponsoring any of the SEPs as a Core Maintainer?

Happy to contribute schemas, implementations, or spec text for whichever proposals gain traction.

---

Full repo: https://github.com/davioe/mcp-extension-proposals