Is your feature request related to a problem? Please describe.

As of 03/26 the Streamable HTTP spec looks like an overly-complex wrapper around the utilities the HTTP specification and industry standards like OpenAPI already provide. For example, for listing tools:

Request

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/list",
  "params": {
    "cursor": "optional-cursor-value"
  }
}

Response:

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "tools": [
      {
        "name": "get_weather",
        "description": "Get current weather information for a location",
        "inputSchema": {
          "type": "object",
          "properties": {
            "location": {
              "type": "string",
              "description": "City name or zip code"
            }
          },
          "required": ["location"]
        }
      }
    ],
    "nextCursor": "next-page-cursor"
  }
}

This is simply a GET request to an OpenAPI specification. Which would have no required parameters or structured message format, just an HTTP GET, and a serialized response well-established by the OpenAPI / JSON schema specs.

And for executing a tool...

{
  "jsonrpc": "2.0",
  "id": 2,
  "method": "tools/call",
  "params": {
    "name": "get_weather",
    "arguments": {
      "location": "New York"
    }
  }
}

This one is especially strange -- because it's the contents of an HTTP POST request { "location": "New York" } wrapped in a JSONRPC envelope, sent via HTTP POST. It's two layers of complexity that simply aren't needed.

On top of that -- OAuth and other negotiations can just be handled the traditional way, with sessions working how they always work -- assign an auth token, and require an Authorization header instead of an Mcp-Session-Id header.

Describe the solution you'd like

We can simplify the entire protocol to a subset of the HTTP protocol with standard conventions.

• HTTP POST to /mcp returns a Bearer [token] authenticating you to the session and providing URLs to HTTP GET resources, prompts and tools from
• Tools
  • HTTP GET to the tools URL, e.g. /.well-known/openapi.json returns the OpenAPI spec and provides tools
  • Requests of any kind (GET, POST, PUT, DELETE) can be made to the tools with an Authorization header and any HTTP response
  • application/json responses are interpreted as they are
  • non-json responses are read as { type: mimeType.split('/')[0], data: base64Data, mimeType: mimeType }
  • where mimeType is the Content-Type response
  • For resources and prompts, HTTP GET with Authorization: Bearer [token] gives you the raw content
  • HTTP DELETE to /mcp with an Authorization header destroys the session
• Resources / Prompts
  • HTTP GET to either url gives you a list of the resources in the MCP-defined format
  • these each have their own URLs that respond to HTTP GET with the Authorization header

Describe alternatives you've considered

Implementing the MCP spec as provided seems unnecessarily complex when the tools already exist and are standard in the ecosystem to handle these use cases. Adhering to this format will require less lift-and-shift and a more straightforward integration path.

Additional context

That's all -- I think the suggestion is easy to interpret and ponder on. :)