mirror of
https://github.com/saidsurucu/borsa-mcp.git
synced 2026-04-26 07:45:53 +03:00
[GH-ISSUE #6] null id accepted in mcp request (minor) #1
Labels
No labels
pull-request
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/borsa-mcp#1
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @clgtm on GitHub (Feb 12, 2026).
Original GitHub issue: https://github.com/saidsurucu/borsa-mcp/issues/6
Not a big deal but thought of reporting nonetheless
┌────────────────────┤ LLM EXPLANATION ├─────────────────────┐
The primary failure reported by the AuthProbe scan is MCP_JSONRPC_ID_NULL_ACCEPTED, which is a high-confidence, high-priority finding. This finding identifies that the target MCP OAuth server at
https://borsamcp.fastmcp.app/mcpaccepts JSON-RPC requests with"id": nulland responds with a status202 Accepted. According to MCP 2025-11-25 and related specifications, this behavior is incorrect and non-compliant. Here is the detailed analysis grounded in the authoritative specifications:1. Background: JSON-RPC ID Semantics in MCP
The MCP specification, aligned with JSON-RPC 2.0, requires that every JSON-RPC request includes an
"id"field that is either a string or a number (see JSON-RPC 2.0 Specification):"id"member is used to correlate requests and responses."id"must be a string, number, ornull. But importantly, per JSON-RPC 2.0 Section 4.1, if a request's"id"isnull, the request is treated as a notification and the server must not return a response.MCP 2025-11-25 adopts JSON-RPC 2.0 semantics for its tool RPC requests (MCP Section 3.X). This implies the server must interpret
"id": nullas a notification and respond accordingly.2. Why Acceptance of
"id": nullRequests and Returning202Is InvalidEvidence from the scan:
"id": nullreturns HTTP status202.Why this is a failure:
MCP 2025-11-25: Section on MCP JSON-RPC usage requires correct
"id"management. The"id"must be a string or number for standard requests expecting a response. Null IDs indicate notifications, which must not generate a response (or any HTTP status indicating acceptance with content).JSON-RPC 2.0 (Section 4.1 and 1.1): Notifications are requests without an
"id"(or"id": null) and do not require a response.Returning HTTP
202(Accepted) as a response to a JSON-RPC request with"id": nullis violating this contract, because 202 is a positive, actionable HTTP response that incorrectly implies the server accepted and will process a request expecting a response.Instead, the MCP server should not return any JSON-RPC response object at all for a null
"id"request or if it returns anything at all, the HTTP status should indicate no response content (204 No Content would be more appropriate if any HTTP response must be sent). The response should not be a JSON-RPC response object or an acknowledgement message with"id": null.3. Related Protocol and Security Considerations
"id": nullmay lead to client-server protocol confusion or unexpected state, especially if clients rely on strict@saidsurucu commented on GitHub (Feb 19, 2026):
fixed.
@clgtm commented on GitHub (Feb 19, 2026):
github.com/saidsurucu/borsa-mcp@b0d669fdac