Skip to main content

Transport

  • Every request is a separate POST.
  • Do not mint or require Mcp-Session-Id for modern requests.
  • Validate every present HTTP Origin against an explicit allowlist.
  • Require the matching MCP-Protocol-Version and Mcp-Method headers.
  • Require Mcp-Name for named requests such as tools/call.
  • Require protocol version, client info, and client capabilities in params._meta.

Discovery and result shape

Implement server/discover and advertise 2026-07-28 plus the tools capability. Completed results return:
  • resultType: "complete";
  • _meta.io.modelcontextprotocol/serverInfo;
  • deterministic ttlMs and cacheScope where required.

Feedback binding

The server registers record_product_feedback_consent and report_product_feedback. tools/list can advertise both, but each product result exposes only the action allowed at that stage. A Never ask or previously approved Ask once result uses:
On a schema-less product tool, that object lives at structuredContent._agentFeedback. When a business tool declares outputSchema, its structuredContent remains untouched and schema-valid; the exact same object is instead carried by a standalone JSON TextContent block shaped as {"_agentFeedback": {...}}. Agents inspect both allowed locations and act on the one present. A following plain-text instruction is only a restatement, not a second action. An unresolved Ask once or Ask always result withholds the report action and schema. The question is mode-specific; never reuse the per-interaction question to collect continuing Ask-once permission:
For Ask always, configuredMode and mode are ask_always, consentPolicy is always, and the question asks only about this use. Ask once without a stable verified customerRef intentionally falls back to that same per-use contract rather than pretending the answer can be remembered. Ask the exact returned question and pass only the explicit answer to record_product_feedback_consent. Approval returns a new feedback_ready action for the same interaction. Refusal returns no report action, and silence creates no decision. Never call report_product_feedback from a consent_required result. Successful background reporting is silent bookkeeping: it should not add a receipt or disclosure aside to the user’s final answer unless the user explicitly asked about feedback. Permission questions remain visible, and failures may be disclosed when the user needs to know a requested action did not complete. The product-tool call is confirmed immediately with confirmation method mcp. The later report enriches that same interaction. Put the stage-aware outcome action near the start of the MCP server’s instructions. Tell clients to look for _agentFeedback in structured content or a standalone JSON content block. Keep the two-value decision shape in the native consent tool and the full report shape in the native report tool. The result-local _agentFeedback block supplies the scoped handle and timing; it is not a substitute for registering both tools. Current Codex and Claude MCP clients reliably follow Never ask when the action appears in both server instructions and the product result. Ask once and Ask every time additionally depend on the client surfacing a question and resuming the tool chain after the user’s reply; support is inconsistent. Prefer Never ask for MCP unless you have verified the exact target clients and versions. Do not fall back to inferred approval when a client cannot resume consent.

2025 compatibility

A server may accept the 2025-11-25 initialize handshake as a stateless compatibility fallback. Modern requests must never depend on that fallback or introduce transport-session state.