Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

Error responses carry "id": null, which the MCP schema does not allow

Ouverte
  • Quelque chose ne va pas ?
#606 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

@koic y travaille déjà.

Depuis le 15/10/2026.

  • #607 par @dominikklein — fermée sans fusion
  • #615 par @koic — ouverte

Évaluation

Difficulté
3/5
Temps estimé
Une demi-journée
Accessibilité débutants
45/100
Type d'issue
Bug
Clarté
Clairement spécifiée
Activité
Active
Stack technique
json, ruby
Domaine
api

Piste de recherche

Start with the error builders json_rpc_error_response and invalid_request_response, then JsonRpcHandler.error_response, and trace where handle_json and StreamableHTTPTransport#handle_request produce "id": null. Run the repro in the issue, then the tests that assert id: null on purpose. Done means error responses omit id when the request id cannot be read, those tests are updated, and the output validates against the MCP JSONRPCErrorResponse schema.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

bug

When the server can't read a request's id, its error response has "id": null. Plain JSON-RPC 2.0 asks for that, and the tests say it's on purpose. MCP narrows it, though: the id of an error response is optional and, if present, a string or an integer.

  • Error responses MUST include the same ID as the request they correspond to (except in error cases where the ID could not be read due a malformed request).

The shape right above it is id?: string | number (Basic Protocol, Error Responses, same in 2026-07-28), and JSONRPCErrorResponse in schema.json has id as an optional RequestId. So these responses don't validate against the schema.

With 1.7.0 (main at 9d12f51 is the same):

server = MCP::Server.new(name: "repro", version: "1.0.0", tools: [], capabilities: { tools: {} })

server.handle_json('{"jsonrpc":"2.0","id":true,"method":"tools/list"}')
# => {"jsonrpc":"2.0","id":null,"error":{"code":-32600,"message":"Invalid Request","data":"Request ID must match validation pattern, or be an integer or null"}}

transport = MCP::Server::Transports::StreamableHTTPTransport.new(server, stateless: true, enable_json_response: true)
env = Rack::MockRequest.env_for("/mcp", method: "POST", input: '{"jsonrpc":"2.0","id":1,"method":"tools/list"}', "CONTENT_TYPE" => "text/plain", "HTTP_ACCEPT" => "application/json")
transport.handle_request(Rack::Request.new(env)).last.first
# => {"jsonrpc":"2.0","id":null,"error":{"code":-32600,"message":"Unsupported Media Type: Content-Type must be application/json"}}

The other HTTP-level errors (406, 405, a body that isn't an object, ...) go through the same json_rpc_error_response and invalid_request_response. The refusal in #605 would follow too, since it goes through JsonRpcHandler.error_response.

Leaving id out when it's unknown would match the schema. The TypeScript SDK sends id: null in the same places, so it's a question of which spec wins; I'd go with the MCP schema, since that's what implementations get checked against (the conformance suite's wire-schema-valid check, for example). I'll open a PR with the change.

Langage dominant
Ruby
Étoiles
924
Forks
136
Merge moyen
1 j 5 h
PR mergées (30 j)
37

Préparer son environnement

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de modelcontextprotocol/ruby-sdk

Toutes les issues de modelcontextprotocol/ruby-sdk

Issues similaires

Plus d'issues Ruby

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.