[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 a problem statement, a specific solution with JSON examples, and — for the most critical ones — formal JSON schemas and working reference implementations in Python and TypeScript.

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

Rather than duplicating everything, I want to summarize the key ideas and hear where the community sees overlap, gaps, or disagreement.

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.

The 15 Proposals (grouped by priority)

Critical (biggest impact, broadest agreement)

#	Proposal	What it adds
1	Capability Discovery & Service Manifest	Standardized manifest at connect time: tools, typed signatures, auth, rate limits, costs, supported extensions
4	Granular Permissions & Scoped Auth	Fine-grained scopes, /permissions pre-flight check, session tokens with TTL
5	Idempotency & Transactions	Idempotency keys on state-changing calls + optional transaction wrapper with compensation-based rollback
8	Streaming & Progress Notifications	Structured progress channel, streaming partial results, checkpoint tokens for resumption

High

#	Proposal	What it adds
11	Structured Error Model	Errors with category (transient/permanent/auth_required), retry_after, suggestion, user_actionable
6	Human-in-the-Loop	requires_confirmation flag + risk_level on tool definitions
2	Intent Hints	Optional intent field so the server can suggest a better tool for the actual goal
7	Provenance	Structured source attribution on responses (source, location, confidence, timestamp)

Medium / Lower

#	Proposal	What it adds
3	Cost & latency transparency	9. Data references between servers
10	Multimodal tool signatures	12. Conformance test suite
14	Session state across calls	13. Server discovery / recommendations
15	Bidirectional context push

What's in the Repo

• README.md — The full proposal with rationale and JSON examples for all 15 points
• schemas/ — 6 JSON schemas (Draft-07): service manifest, structured errors, permissions, transactions, streaming, provenance
• examples/python/server.py — Working reference server (stdlib only, no dependencies) with runnable demo
• examples/typescript/server.ts — Same in TypeScript (Node 18+)
• examples/manifests/ — Realistic example manifests for a Jira and GitHub MCP server

Both reference implementations demonstrate the full flow: manifest → permission check → intent hint → provenance → idempotency → human-in-the-loop → transaction + rollback → session state → structured errors.

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 and multi-turn interactions)
• 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) in the sense of making server responses more machine-readable
• Capability discovery → relates to [Enhancement] Hierarchical Tool Management for MCP - Solving Context Overflow at Scale #532 (Hierarchical tool management) — both address the problem of clients not knowing what's available

The intent is to complement these existing threads, not to replace them. Where there's overlap, I'd love to converge on a shared direction.

Design Constraints

Every proposal follows these rules:

• Model-agnostic. No vendor-specific extensions in the core protocol. Ever.
• Backwards-compatible. Every extension is opt-in. Existing servers work unchanged.
• Incrementally adoptable. Each proposal is independent — implement in any order.
• Proven patterns. Nothing novel: idempotency keys, capability negotiation, session tokens, structured errors — all battle-tested in HTTP, LSP, gRPC.

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 turn any of these into a formal PR against the spec?

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

---

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

Scope

• Protocol Specification
• SDK Features
• Documentation
• Developer Experience
• Other