What changed in starlette

In starlette 0.49.1, FormParser (the parser for application/x-www-form-urlencoded bodies) had no size limits — Request._get_form simply ran FormParser(self.headers, self.stream()); await form_parser.parse() with no exception path. Starting in 1.3.1 (Kludex/starlette#3329 and #3331), FormParser enforces max_fields=1000 and max_part_size=1MB per field (verified in the installed wheel, formparsers.py:82-97). Exceeding either limit raises MultiPartException, which Request._get_form converts into a starlette HTTPException(status_code=400, detail='Field exceeded maximum size of 1024KB.' / 'Too many fields...') when app is in scope (requests.py:296-308).

Why the SDK's OAuth handlers are affected

The SDK's OAuth handlers all call await request.form() inside try blocks that catch only pydantic ValidationError (or AuthenticationError further up):

• src/mcp/server/auth/handlers/token.py:121
• src/mcp/server/auth/handlers/revoke.py:50
• src/mcp/server/auth/handlers/authorize.py:150 (POST branch)
• src/mcp/server/auth/middleware/client_auth.py:54 (called by token/revoke handlers)

These handlers deliberately construct RFC 6749 §5.2-conformant JSON error objects (TokenErrorResponse / RevocationErrorResponse via PydanticJSONResponse, with Cache-Control: no-store). The new starlette HTTPException is not caught by any of them, so it escapes to the Starlette app's ExceptionMiddleware and is rendered as a text/plain 400 response. If the handlers are composed as raw ASGI without a Starlette app in scope, the raw MultiPartException propagates and produces a 500 instead.

Step-by-step proof

1. A client POSTs to /token with Content-Type: application/x-www-form-urlencoded and a body containing one field larger than 1 MiB (e.g. a huge client_assertion value): grant_type=client_credentials&client_assertion=AAAA...(>1MB).
2. TokenHandler.handle (token.py:121) calls await request.form() inside try: ... except ValidationError.
3. In starlette 1.3.1, FormParser.parse() accumulates the field value, hits the 1 MiB max_part_size check added in Enforce FormParser limits in parser callbacks Kludex/starlette#3331, and raises MultiPartException('Field exceeded maximum size of 1024KB.').
4. Request._get_form catches it and re-raises as starlette.exceptions.HTTPException(400) (because the request is served by a Starlette app).
5. This is not a ValidationError, so the handler's except doesn't fire — the carefully built TokenErrorResponse(error='invalid_request', ...) JSON path is bypassed.
6. ExceptionMiddleware catches the HTTPException and returns 400 with body Field exceeded maximum size of 1024KB. as text/plain — violating RFC 6749 §5.2, which requires the token endpoint to return a JSON error object.

Under 0.49.1, the same request parses successfully (unbounded buffering) and reaches the handler's normal validation path — so the changed error shape is introduced by this bump.

Why this is not a merge blocker

• pyproject.toml constrains starlette>=0.27 with no upper bound, so end users installing the published mcp package already resolve 1.3.1 today regardless of this PR — the lockfile only pins the SDK's own CI/dev environment. Blocking this bump would shield no one.
• The trigger is adversarial or an extreme edge case: no realistic OAuth client sends a single >1 MiB form field or >1000 fields (even large RFC 7523 client_assertion JWTs are orders of magnitude below 1 MiB). The status code is still an RFC-correct 400; only the body shape/content-type differ.
• The upstream change is intentional DoS hardening — 0.49.1's unbounded in-memory buffering of urlencoded bodies was strictly worse. Real deployments behind reverse proxies (e.g. nginx's 1 MB default body limit) would often preempt the app with a 413 anyway.

Suggested follow-up fix

In the four handlers listed above, catch starlette's HTTPException (or MultiPartException) around await request.form() and translate it into the OAuth invalid_request JSON error shape, e.g. TokenErrorResponse(error='invalid_request', error_description='request body too large') with status 400. Alternatively, pass explicit max_part_size/max_fields to request.form() and handle the failure there.

For completeness: the rest of the 0.49.1 → 1.3.1 delta was audited against SDK usage and no other affected paths were found — all imported starlette symbols still exist, removed 1.0 APIs (on_startup/on_event/@app.route/WSGIMiddleware) are unused, sse-starlette 3.0.2's imports remain valid, and request.url host-header behavior changes (starlette#3326) don't touch server-side SDK code.