Skip to content

Instantly share code, notes, and snippets.

@nerdalert

nerdalert/mcp-profile-support.md

Last active July 8, 2026 05:39
Show Gist options

  • Select an option

    Learn more about clone URLs
  • Save nerdalert/cbfa0825f791e48be046324c5faa7bc8 to your computer and use it in GitHub Desktop.

Select an option

Learn more about clone URLs
Save nerdalert/cbfa0825f791e48be046324c5faa7bc8 to your computer and use it in GitHub Desktop.
Download ZIP
Raw
mcp-profile-support.md

MCP Profile Support Discussion

Summary

Praxis should keep three MCP operating modes available for now:

  • Pass-through / classifier mode for backend-owned MCP behavior.
  • protocol_profile: current for the existing session-based broker behavior.
  • protocol_profile: stateless for the MCP 2026-07-28 release-candidate broker behavior.

The strategic broker direction should be stateless, but pass-through should stay first-class because it is the safest interoperability path for ContextForge, old HTTP+SSE servers, and externally managed MCP gateways.

Note: pass-through is not currently a broker protocol_profile value in config. It is an operating mode: Praxis forwards MCP traffic without owning the MCP session or catalog. The configured broker profiles are current and stateless.

Terms

Name Praxis meaning MCP shape
Pass-through / classifier mode Praxis forwards traffic to a backend MCP server or gateway. It may classify/promote metadata, but it does not own the MCP catalog or session lifecycle. Works best for old HTTP+SSE, current Streamable HTTP, external gateways, and ContextForge-managed endpoints.
protocol_profile: current Existing broker profile. Praxis owns static catalog behavior and preserves the session-based MCP flow. Streamable HTTP 2025-03-26 style behavior: initialize, optional Mcp-Session-Id, current tools/list, ping, and DELETE cleanup semantics.
protocol_profile: stateless New broker profile. Praxis owns discovery, catalog, and routing without protocol sessions. MCP 2026-07-28 release-candidate behavior: per-request _meta, MCP-Protocol-Version, Mcp-Method, server/discover, cache metadata, and no protocol session.
Legacy HTTP+SSE Older MCP transport from pre-2025 MCP versions. GET opens the SSE stream, POST sends messages with a server-issued session_id. Use pass-through unless a deliberate compatibility broker is implemented.

Current Evidence

The local MCP/A2A plan already separates the modes:

  • Preserve pass-through for old SSE and server-owned legacy or stateful backends.
  • Use classifier mode for safe body-aware routing and observability.
  • Keep the stateless broker explicit/configured while the 2026-07-28 spec is still a release candidate.
  • Avoid making Praxis-owned MCP session maps the default path because the RC removes protocol-level sessions.

External references:

Decision Options

Option Pros Cons
Maintain all three modes: pass-through, current, and stateless Best ecosystem compatibility. Lets operators put Praxis in front of old SSE, current session-based Streamable HTTP, ContextForge, and the new stateless RC. Gives a safer migration path and avoids forcing every backend to upgrade at once. Larger test matrix. More docs. More security/session/cache semantics to keep straight. Higher maintenance cost.
Maintain only the new stateless broker profile Cleanest architecture. Aligns with MCP direction. No sticky protocol session state. Easier horizontal scaling. Simpler broker behavior for server/discover, cacheable tools/list, and tools/call routing. Breaks or sidelines existing session-based and old SSE deployments. Weak ContextForge bridge. Removes the safest low-touch proxy mode. Forces upstream server upgrades.
Maintain pass-through plus stateless, but de-emphasize current broker Practical compromise. Keeps compatibility through pass-through while making new broker work stateless-first. Avoids deeper investment in session-owned broker behavior. Operators lose a Praxis-owned compatibility broker for current session-based MCP. More burden moves to external gateways or backends.
Maintain current plus stateless, but stop emphasizing pass-through Broker behavior remains explicit and testable. Poor fit for ContextForge and old HTTP+SSE. Pass-through is the cleanest way to avoid breaking server-owned sessions and external gateway behavior.

ContextForge Integration Needs

ContextForge is an MCP/A2A/REST/gRPC registry and proxy. Its own project describes support for centralized discovery, governance, observability, multiple transports including SSE and Streamable HTTP, auth, retries, rate limiting, plugins, Redis-backed federation/caching, and protocol-version choice.

That matters because ContextForge can already be the component that owns:

  • Tool, prompt, and resource registry.
  • MCP server federation.
  • REST/gRPC-to-MCP virtualization.
  • Auth, token forwarding, and upstream authorization.
  • Transport bridging.
  • Caching and observability.
  • Potentially session semantics for backends that still require them.

Praxis should not assume it always owns the MCP catalog. In a ContextForge deployment, Praxis may instead need to sit in front of ContextForge and provide:

  • TLS, routing, rate limits, policy, and observability.
  • Header hygiene and reserved-header stripping.
  • MCP version/method/name metadata promotion.
  • Path and host routing.
  • Optional classifier decisions.
  • Clean pass-through of ContextForge-owned MCP sessions and streams.

For direct Praxis broker mode, ContextForge integration may later need:

  • Import or sync of a ContextForge catalog into the Praxis static/dynamic broker catalog.
  • Tool namespace/prefix mapping between Praxis exposed names and ContextForge/backend names.
  • server_url or connector_id resolution for Responses API MCP tool definitions.
  • Auth/header injection rules that do not leak client-controlled internal headers.
  • Explicit behavior for old HTTP+SSE, current session-based Streamable HTTP, and stateless Streamable HTTP.

Recommendation

Keep all three modes for now:

  1. Keep pass-through as the universal compatibility and integration mode.
  2. Keep protocol_profile: current for existing session-based broker behavior, but treat it as compatibility.
  3. Make protocol_profile: stateless the strategic broker path for new MCP work.

Do not invest heavily in new stateful broker behavior unless there is a concrete backend or ContextForge requirement. If the team wants to reduce maintenance, the first reduction should be to freeze current as compatibility-only, not to remove pass-through.

Discussion Questions

  • Should docs call these "MCP operating modes" to avoid implying pass-through is a broker protocol_profile?
  • Should protocol_profile: current eventually be renamed or aliased to something more explicit like streamable_session?
  • Should old HTTP+SSE ever get a broker compatibility mode, or should it remain pass-through only?
  • Should ContextForge be treated as an upstream MCP backend, a catalog source, or both?
  • Should the Responses API connector_id story resolve through ContextForge, a Praxis connector registry, or direct server_url only for MVP?
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment