[BUG] [MCP] Cannot list tools in MCP Server #3859
Description
Guys this looks pretty basic, not sure if this is real, but we are not able to see tool listing. Anyone can confirm?
Command: authprobe scan --stdio-command /tmp/daytona-bin mcp start
Scanning: http://127.0.0.1:40871/
Scan time: Feb 21, 2026 02:05:44 UTC
Github: https://github.com/authprobe/authprobe
Funnel
[1] MCP probe (401 + WWW-Authenticate) [-] SKIP
probe returned 405; checking PRM for OAuth config
[2] MCP initialize + tools/list [X] FAIL
initialize -> 200
notifications/initialized -> 202
tools/list -> error: Post "http://127.0.0.1:40871/": context deadline
exceeded (Client.Timeout exceeded while awaiting headers)
[3] PRM fetch matrix [X] FAIL
PRM unreachable or unusable; OAuth discovery unavailable
[4] Auth server metadata [-] SKIP
auth not required
[5] Token endpoint readiness (heuristics) [-] SKIP
auth not required
[6] Dynamic client registration (RFC 7591) [-] SKIP
auth not required
Primary Finding (HIGH): MCP_TOOLS_LIST_FAILED (confidence 1.00)
Evidence:
initialize -> 200 notifications/initialized -> 202 tools/list -> error: Post
"http://127.0.0.1:40871/": context deadline exceeded (Client.Timeout exceeded while
awaiting headers)
MCP servers should respond to tools/list with a valid JSON result enumerating tools per
the MCP specification.
┌─────────────────────┤ RFC RATIONALE ├──────────────────────┐
Explain (RFC 9728 rationale)
1) MCP probe
- AuthProbe did not receive a 401 response that indicates authentication is required, so RFC 9728 PRM discovery is skipped.
┌───────────────────────┤ CALL TRACE ├───────────────────────┐
Call Trace Using: https://github.com/authprobe/authprobe
┌────────────┐ ┌────────────┐
│ authprobe │ │ MCP Server │
└─────┬──────┘ └─────┬──────┘
│ │
│ ╔═══ Step 1: MCP probe ═══════╪═══════════════════╗
│ GET http://127.0.0.1:40871/
│ Reason: 401 + WWW-Authenticate discovery
│ Accept: text/event-stream
│ Host: 127.0.0.1:40871
├─────────────────────────────────────────────────────────────────►│
│ 405 Method Not Allowed
│ Content-Length: 0
│ Date: Sat, 21 Feb 2026 02:04:40 GMT
│◄─────────────────────────────────────────────────────────────────┤
│ │
│ ╔═══ Step 2: MCP initialize ═══════╪═══════════════════╗
│ POST http://127.0.0.1:40871/
│ Reason: Step 2: MCP initialize + tools/list (pre-init tools/list)
│ Accept: application/json, text/event-stream
│ Content-Type: application/json
│ Host: 127.0.0.1:40871
│ Mcp-Protocol-Version: 2025-03-26
├─────────────────────────────────────────────────────────────────►│
│ 200 OK
│ Content-Type: application/json
│ Date: Sat, 21 Feb 2026 02:04:40 GMT
│◄─────────────────────────────────────────────────────────────────┤
│ │
│ POST http://127.0.0.1:40871/
│ Reason: Step 2: MCP initialize + tools/list (initialize)
│ Accept: application/json, text/event-stream
│ Content-Type: application/json
│ Host: 127.0.0.1:40871
│ Mcp-Protocol-Version: 2025-03-26
├─────────────────────────────────────────────────────────────────►│
│ 200 OK
│ Content-Length: 218
│ Content-Type: application/json
│ Date: Sat, 21 Feb 2026 02:04:40 GMT
│◄─────────────────────────────────────────────────────────────────┤
│ │
│ POST http://127.0.0.1:40871/
│ Reason: Step 2: MCP initialize + tools/list (notifications/initialized)
│ Accept: application/json, text/event-stream
│ Content-Type: application/json
│ Host: 127.0.0.1:40871
│ Mcp-Protocol-Version: 2025-03-26
├─────────────────────────────────────────────────────────────────►│
│ 202 Accepted
│ Content-Length: 0
│ Date: Sat, 21 Feb 2026 02:04:40 GMT
│◄─────────────────────────────────────────────────────────────────┤
▼ ▼
┌───────────────┤ FAILED TEST VERBOSE OUTPUT ├───────────────┐
== Step 2: MCP initialize + tools/list (pre-init tools/list) ==
> POST / HTTP/1.1
> Host: 127.0.0.1:40871
> Accept: application/json, text/event-stream
> Content-Type: application/json
> Mcp-Protocol-Version: 2025-11-25
>
> {"id":0,"jsonrpc":"2.0","method":"tools/list"}
== Step 2: MCP initialize + tools/list (initialize) ==
> POST / HTTP/1.1
> Host: 127.0.0.1:40871
> Accept: application/json, text/event-stream
> Content-Type: application/json
> Mcp-Protocol-Version: 2025-11-25
>
> {"id":1,"jsonrpc":"2.0","method":"initialize","params":{"capabilities":{},"clientInfo":{"name":"authprobe","version":"0.1"},"protocolVersion":"2025-11-25"}}
== Step 3: PRM fetch matrix ==
┌──────────────────┤ ROOT-CAUSE ANALYSIS ├───────────────────┐
The primary failure, MCP_TOOLS_LIST_FAILED, is a valid and justified finding grounded in the MCP 2025-11-25 core requirements, as well as related standards (RFC 9728, RFC 8414, JSON-RPC 2.0).
Detailed Explanation
Summary of Failure
The tools/list request POST to http://127.0.0.1:40871/ resulted in a client timeout:
```
context deadline exceeded (Client.Timeout exceeded while awaiting headers)
```
This means the server did not respond to the tools/list request within the expected timeframe, indicating either a blocking, unresponsive handler, or a lack of support for this MCP endpoint. The scan logged this as a high-severity failure because enumerating tools is fundamental to MCP operation.
MCP Spec and Protocol Requirements
- MCP 2025-11-25 Spec
The MCP specification mandates an initialization sequence where clients first perform an initialize request, followed by event subscription (e.g., notifications/initialized), and then send requests like tools/list to query available services and capabilities. Specifically:
- Section 4.3 ("Initialization") requires servers to accept the
initializerequest first and only then respond to other MCP requests such astools/list. - Section 5.2 ("Tools Listing") requires the server to respond to
tools/listrequests with a valid JSON response enumerating available tools.
Failure to respond or timing out on tools/list violates these requirements and breaks MCP interoperability.
- Ordering Enforcement Requirement
The secondary finding mentions MCP_INITIALIZE_ORDERING_NOT_ENFORCED, indicating that the server allowed some MCP method calls before a proper initialize handshake, which is not compliant:
- MCP 2025-11-25 requires enforcement of the initialization handshake before accepting other methods (e.g.,
tools/list). - This ensures clients and servers share state, authorization, and capabilities before further operation.
- JSON-RPC 2.0 Behavior (RFC 9728)
MCP leverages JSON-RPC 2.0 semantics for request/response interaction:
- Each request (including
tools/list) MUST be replied to with a JSON-RPC response or error object. - A lack of response or timing out breaks the JSON-RPC contract (RFC 9728 sec. 4): the server must not leave requests hanging indefinitely.
- The server should respond with JSON indicating success or failure promptly.
- OAuth Discovery Considerations (RFC 8414)
Although OAuth discovery (via PRM fetch) failed, the MCP tools/list endpoint should still respond correctly regardless, as it enables clients to discover tool capabilities crucial for OAuth flows.
Correct Server Behavior
-
Respond Timely to MCP Requests: Following the successful
initialize(HTTP 200) andnotifications/initialized(HTTP 202), the server MUST promptly handle thetools/listPOST request and respond with a valid JSON enumeration of available tools. This JSON response conforms to MCP's JSON-RPC 2.0 usage patterns. -
Enforce Initialization Handshake Order: If a client sends
tools/listbeforeinitialize, the server must reject or ignore such requests to avoid inconsistent state. -
Avoid Request Timeouts: The server handler for
tools/listmust not block indefinitely; the absence of response is technically a fault:- It suggests a server-side deadlock/error.
- MCP expects eventual completion with either a success or an error response, never a timeout.
-
Report Errors Properly: If the server cannot fulfill the request, it should return a valid JSON-RPC error response rather than timing out silently.
Conclusion
The failure reported by AuthProbe is valid and justified.
The MCP server under test violated MCP 2025-11-25 requirements by failing to respond to the tools/list request promptly and correctly after initialization. This violates JSON-RPC 2.0 expectations (RFC 9728) and breaks client interoperability.
Recommended changes:
- Implement or fix the
/tools/listhandler to respond with a valid MCP tools enumeration JSON payload as soon asinitializeandnotifications/initializedcomplete. - Enforce the proper initialization ordering before accepting
tools/list. - Ensure robust handling of MCP requests with clear, timely JSON-RPC 2.0 replies.
- Implement appropriate timeouts and error handling to avoid indefinite hangs.
Addressing these points will bring the server into compliance with MCP 2025-11-25, supporting smooth OAuth client and tool discovery workflows consistent with RFC 8414 and JSON-RPC 2.0 expectations.