Implement SEP-1319: Decouple Request Payload from RPC Methods #413

This is a tracking issue for implementation of SEP-1319.

Summary

Refactor the MCP specification and type definitions so that all request/response payloads are defined as standalone, named schemas, and JSON-RPC method definitions simply reference these models. This keeps the on-the-wire format unchanged but makes the spec more modular, transport-agnostic, and easier to maintain (e.g., for future gRPC bindings).

Needs to implement:

• Standalone payload models

  • Define top-level *Params and (where applicable) *Result interfaces/types for all MCP operations (e.g. CallToolRequestParams).
  • Ensure these payload models are transport-agnostic and do not depend on JSON-RPC wrapper details.

• RPC method wrappers referencing payloads

  • Update JSON-RPC request/response interfaces to reference the new payload models instead of inlining param/result structures, e.g.:
    • params: CallToolRequestParams instead of inline { name: string; arguments?: { ... } }.
  • Apply consistently across all MCP method groups (tools, sampling, resources, prompts, roots, etc.).

• Spec structure and documentation

  • Restructure the spec so data models (payloads) are defined in their own section(s) and referenced from transport-specific sections.
  • Clearly document the separation between:
    • Data layer: payload models (e.g. CallToolRequestParams)
    • Transport layer: JSON-RPC method wrappers (e.g. CallToolRequest)

• Backward compatibility

  • Verify that no changes are made to the JSON wire format; existing compliant clients/servers must remain valid.
  • Add or update tests (and/or schema/codegen fixtures) to ensure the refactor does not alter serialized messages.

• Codegen and tooling

  • Update any code-generation or schema tooling that relies on the spec structure so it can consume the new decoupled payload definitions.
  • Validate that the new structure makes it easier to add alternative transports (e.g. gRPC) in the future.