MCP protocol compatibility

How SnapLogic's MCP Server supports both legacy and modern MCP clients on the same endpoint, and what tool-list caching does and doesn't do.

Dual-era protocol support

An MCP Server advertises support for multiple protocol revisions on a single endpoint: 2024-11-05, 2025-03-26, 2025-06-18, 2025-11-25, and 2026-07-28. You don't need to maintain separate endpoints for older and newer clients:

  • Existing clients continue using the standard initialize handshake.
  • Modern clients (2026-07-28) send protocol version and client capabilities as per-request metadata (_meta) instead of negotiating once at initialization. Client identity can also be supplied this way.
Note: Custom clients must construct the modern per-request metadata correctly. The MCP Server configuration UI does not choose a protocol version for you — version selection happens on the client side, per request.

Server discovery

Modern clients can call the server/discover RPC to retrieve server information and supported protocol revisions without invoking a pipeline. Use this to check compatibility before connecting — a server/discover call does not create a pipeline execution and should not appear in Monitor's pipeline execution history.

Tool-list caching

Set a Cache duration on an MCP Server to let modern clients reduce repeated tools/list and discovery calls. See Register MCP Server for the setting.

  • Setting a Cache duration — any value, including 0 — returns ttlMs and cacheScope hints with modern tools/list and discovery results.
  • The default duration is 0. Existing MCP Server assets without this setting configured are treated as 0 — re-fetch behavior is unchanged unless you opt into a positive duration.
  • Caching is advisory: a client has to honor the returned hints to benefit. Not every client implementation caches.
Important: Cache scope is derived automatically from the server's Authentication Policy — you don't select it manually:
  • An anonymous-only policy can produce a public cache scope.
  • An authenticated policy, or a server with no policy, produces a private cache scope.
  • A mixed configuration of authentication policies (for example, Anonymous combined with an MCP OAuth JWT policy) currently produces a private cache scope. Treat this as the current, conservative behavior rather than a guaranteed final rule.
This matters because a shared, public cache must never expose a tool list that depends on who's asking.

Tool-list caching does not change how tools/call results behave — those remain fully dynamic on every invocation and receive no caching hints. Enabling tool-list caching does not reuse or cache the result of a business operation.

Richer tool definitions and results

  • Schema fidelity: Top-level JSON Schema keywords such as $schema, oneOf, and anyOf are preserved in a tool's inputSchema, instead of being stripped. Agents receive the full set of constraints you defined, which improves the arguments they generate.
  • Structured results: When a tool's result is an object, the response includes a structuredContent field alongside the text content, so clients can consume structured JSON directly instead of parsing text. This does not add a separate outputSchema declaration.
  • Runtime tool failures: A pipeline failure during tool execution now returns a tool result with isError: true instead of an opaque JSON-RPC -32603 error. This lets an agent inspect what went wrong and potentially correct its arguments and retry. Gateway-level authentication failures still return a protocol-level error, not a tool result.

Browser-origin security

Requests with an untrusted Origin header receive an HTTP 403. Requests without an Origin header, same-origin requests, and requests from configured allowed origins are all supported normally. If you have a browser-based integration calling your MCP Server from a different origin, add it to the MCP_ALLOWED_ORIGINS property. Non-browser clients that don't send an Origin header are unaffected by this check.

What this is not

  • There is no single "MCP 2.0" enablement toggle. Protocol behavior is determined by Snaplex node capability and the protocol version a client requests per call — not an account or org-level switch.
  • These protocol changes are server-side. SnapLogic's MCP Client Snaps have not acquired modern negotiation, response caching, or related OAuth changes as part of this work.