Today MCP added Streamable HTTP [0] which is a huge step forward as it doesn't require an "always-on" connection to remote HTTP servers.
However, if you look at the specification it's clear bringing the LSP-style paradigm to remote HTTP servers is adding a bunch of extra complexity. This is a tool call, for example:
{
"jsonrpc": "2.0",
"id": 2,
"method": "tools/call",
"params": {
"name": "get_weather",
"arguments": {
"location": "New York"
}
}
}
Which traditionally would just be HTTP POST to `/get_weather` with `{ "location": "New York" }`.
I've made the suggestion to remove some of this complexity [1] and fall back to just a traditional HTTP server, where a session can be negotiated with an `Authorization` header and we rely on traditional endpoints / OpenAPI + JSON Schema endpoint definitions. I think it would make server construction a lot easier and web frameworks would not have to materially be updated to adhere to the spec -- perhaps just adding a single endpoint.
[0] https://spec.modelcontextprotocol.io/specification/2025-03-2...
[1] https://github.com/modelcontextprotocol/specification/issues...
However, if you look at the specification it's clear bringing the LSP-style paradigm to remote HTTP servers is adding a bunch of extra complexity. This is a tool call, for example:
Which traditionally would just be HTTP POST to `/get_weather` with `{ "location": "New York" }`.I've made the suggestion to remove some of this complexity [1] and fall back to just a traditional HTTP server, where a session can be negotiated with an `Authorization` header and we rely on traditional endpoints / OpenAPI + JSON Schema endpoint definitions. I think it would make server construction a lot easier and web frameworks would not have to materially be updated to adhere to the spec -- perhaps just adding a single endpoint.
[0] https://spec.modelcontextprotocol.io/specification/2025-03-2...
[1] https://github.com/modelcontextprotocol/specification/issues...