Streamable HTTP: Content-Type handling is order dependent and accepts invalid values
Maintainers usually reply within 1 day
@jayzuccarelli is already working on this.
Since Oct 12, 2026.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 76/100
- Issue type
- Bug
- Clarity
- Clearly specified
- Activity status
- Active
- Tech stack
- python
- Domain
- backend-api-design, security
Research direction
Start by reading the content-type checks in src/mcp/server/transport_security.py and src/mcp/server/streamable_http.py, then trace the corresponding modern transport check. Add or update tests for the listed Content-Type values, including parameters and comma-separated values. Done means only application/json, with optional parameters, is accepted consistently across transports.
Written by the indexing model from the issue text.
Description
Initial Checks
- I confirm that I'm using the newest release of my line (the latest 2.x, or the latest 1.x if I'm still on v1)
- I confirm that I searched for my issue in https://github.com/modelcontextprotocol/python-sdk/issues before opening this issue
Release line
2.x (current stable)
Description
The Content-Type header:
- accepts values that are not JSON media types.
application/json, text/plainis accepted and the request is executed, although a comma cannot appear inside a media type. On the modern transportapplication/jsonxis accepted as well - The answer depends on order.
application/json, text/plainis accepted whiletext/plain, application/jsonis rejected, so the same invalid value gets opposite answers.
The first check is a prefix test in the middleware:
# src/mcp/server/transport_security.py
return content_type is not None and content_type.lower().startswith("application/json")
The second splits the value on ; and , and compares the result:
# src/mcp/server/streamable_http.py
content_type_parts = [part.strip() for part in content_type.split(";")[0].split(",")]
return any(part == CONTENT_TYPE_JSON for part in content_type_parts)
The second check rejects application/jsonx. The 2.x modern transport has no equivalent, so it accepts that value.
For reference, the TypeScript SDK answers 415 for application/json, text/plain and for application/jsonx, and mcp-go answers 400 for both.
Reproduction
Against a server started with stateless_http=True, so no session handshake is needed:
curl -s http://127.0.0.1:8901/mcp \
-H 'Content-Type: application/json, text/plain' \
-H 'Accept: application/json, text/event-stream' \
-d '{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"ping","arguments":{}}}'
Observed: 200 with a normal JSON-RPC result, and the tool's handler runs.
Content-Type sent |
Expected | handshake transport (1.x and 2.x) | modern transport (2.x only) |
|---|---|---|---|
application/json |
accepted | 200 |
200 |
application/json; charset=utf-8 |
accepted | 200 |
200 |
application/json, text/plain |
rejected | 200, body executed |
200, body executed |
application/jsonx |
rejected | 415 |
200, body executed |
text/plain, application/json |
rejected | 400 |
400 |
text/plain |
rejected | 400 |
400 |
For modern transport calls were sent with MCP-Protocol-Version: 2026-07-28 plus the Mcp-Method and Mcp-Name headers.
Fix
Parse the media type, the segment before the first ;, and compare it exactly to application/json. Parameters keep working, so application/json; charset=utf-8 is unaffected, while the values above are rejected.
Python & MCP Python SDK
Reproduced on the 2.x line (`2.2.0`, `2.3.0`) and the 1.x line (`1.30.0`)
- Dominant language
- Python
- Stars
- 24.6k
- Forks
- 4.2k
- Avg merge
- 10h 37m
- Merged PRs (30d)
- 38
Getting set up
- No Dockerfile or Docker Compose file
- Has a pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from modelcontextprotocol/python-sdk
-
OAuth token expiry equality boundary causes intermittent downstream test failuresMay be free again A pull request for this issue was closed without being merged. Openbug v1 v2
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
modelcontextprotocol/python-sdk#3729 · 2 comments ·
Maintainers usually reply within 1 day
-
bug v1 v2
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
modelcontextprotocol/python-sdk#3725 · 4 comments ·
Maintainers usually reply within 1 day
-
bug v1 v2
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
modelcontextprotocol/python-sdk#3698 · 2 comments ·
Maintainers usually reply within 1 day
-
Skills: URI traversal validation skips percent-encoded dot-segmentsMay be free again @Varshith-Kali claimed this 7 days ago, and no pull request is open. Openbug v2
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
modelcontextprotocol/python-sdk#3685 · 2 comments ·
Maintainers usually reply within 1 day
-
Type annotation gaps and unhandled FileNotFoundError in src/mcp/cli/cli.pyMay be free again A pull request for this issue was closed without being merged. Openenhancement
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
modelcontextprotocol/python-sdk#3673 · 4 comments ·
Maintainers usually reply within 1 day
All issues in modelcontextprotocol/python-sdk
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
-
[Device Support Request] HOBEIAN ZG-204ZL (Tuya PIR motion sensor with illuminance)Possibly taken @lenucksi claimed this today. Open
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
zigpy/zha-device-handlers#5493 ·
Maintainers usually reply within 3 days
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
drevendev/BeautifulRepo#42 ·
Maintainers usually reply within 1 day
-
enhancement good first issue
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
writerslogic/holographic-memory#93 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 66/100
antoine-tena/kiln#47 ·
Maintainers usually reply within 1 day