As it was mentioned in our previous blog post[1], MCP supports a transport mechanism called HTTP + SSE (Server-Sent Events) that can be used with remote MCP servers, although it seems likely to be replaced soon by Streamable HTTP. This remote mechanism works by creating two streams of data, just as “stdio” does but in two different HTTP connections.
Using this transport mechanism represents a challenge when doing security assessments, since our standard toolkit works perfectly fine with HTTP connections, but it does not support working with those two streams of data, sending requests and receiving responses for the appropriate one.
For this reason, NCC Group has released an HTTP to MCP Bridge[2], which is an HTTP server that establishes an SSE communication with the target and, at the same time, it provides a pure HTTP interface that can be used with Burp or your favourite HTTP tool, to assess MCP remote servers through it.
Under The Hood (or the Bridge)
Our initial thought was to create a full HTTP to SSE bridge, and to be able to manipulate every single detail in the SSE communication. This was a good approach to test SSE implementations, but probably somewhat excessive to test the MCP protocol itself. Given that SSE may be replaced by other transport mechanisms, it was decided to keep it as simple as possible and to use the internal “sse_client” method within the official mcp python library[3].
When using that method, we receive a context from where we can extract the read and write memory object streams, established through the “/sse” and “/messages/” endpoints. Now we just need to send valid JSON-RPC messages in the corresponding memory object stream, and wait for responses (if any) in the other stream. All the details of the SSE protocols are handled by the MCP Python SDK library under the hood, so we can focus on the MCP layer.
Using the HTTP to MCP Bridge
The README file in the GitHub repository already includes instruction on installing dependencies and making the tool work, so we will focus on the final step: calling the tool.
$ python3 main.py --remote-url="http://127.0.0.1:8787/sse"
The HTTP server will be listening on the default interface and port (“http://127.0.0.1:8000”), and the SEE connection will be established to the provided remote URL (“http://127.0.0.1:8787/sse”). A remote MCP server with HTTP+SSE support should exist at the given URL, which will be our target.
The first step when using it is to obtain a bridge session ID. This can be obtained from the error message when accessing the “/sse/messages/” endpoint with no valid session ID. This allows for keeping several sessions active. During this action, the HTTP to MCP Bridge creates a new SSE client and keeps it in memory, associated with the session ID.
After a new session is created, you can send JSON-RPC messages to the endpoint “/sse/messages/[session_id]”. For MCP communications, the first message should be an initialisation handshake, where both peers exchange information about protocol version, metadata, and capabilities, as seen below:
This handshake requires one last message from the client to the server acknowledging the server initialisation message. As this message does not require a response, the “timeout=0” parameter can be added to avoid being blocked for several seconds. Obtaining a timeout message from the bridge is expected because, as mentioned before, this notification message does not require a response:
Once the initialisation has been completed, MCP capabilities can be invoked by sending the corresponding JSON-RPC messages. For example, the method “tools/list” obtains a list of the tools available, which typically should include a description of the tool and its parameters, so that the associated agent can use it to identify if the user intent includes this method call.
Those tools listed can be invoked using the method “tools/call” with the tool name and arguments. Remember to adjust the “timeout” parameter if your specific tool takes more time to be executed than the bridge’s default value (1 second). The result message is also another JSON structure, as can be seen below:
It is worth mentioning that the HTTP to MCP Bridge shows the result corresponding to the given request, although under the hood it happens asynchronously. This allows one to use tools such as Burp Intruder or other automations to show the results of every request easily. The example below shows Burp Intruder being used to invoke the “add” tool with several combinations of numbers and to extract the response:
This is an example of methods that can be invoked, but tools[4] are not the only ones available. Also, resources[5] and prompts[6] can be used, as long as you create the corresponding JSON-RPC message for them. You can find the right format in the MCP documentation referenced in this blog post.
Other client MCP capabilities such as sampling[7] and roots[8] are not supported yet, as those are not server-side capabilities, but we will add support for client side testing soon.
Further Steps
The HTTP to MCP Bridge tool is in an early stage of development and we want to incorporate several improvements over the following months, but it is also important that the community report the needs and troubles that they find when using it, as the adoption of MCP with HTTP+SEE is still not massive, and the protocol itself can be updated based on the needs.
We also have on our roadmap to incorporate MCP client capability testing, and even local MCP testing support, so you can also use your HTTP tools even in that scenario.
References
[1] “5 MCP Security Tips”, https://www.nccgroup.com/us/research-blog/5-mcp-security-tips/
[2] “Github – HTTP to MCP Bridge”, https://github.com/nccgroup/http-mcp-bridge
[3] “MCP Python SDK – sse_client”, https://github.com/modelcontextprotocol/python-sdk/blob/58c5e7223c40b2ec682fd7674545e8ceadd7cb20/src/mcp/client/sse.py#L23
[4] “MCP Documentation - Tools”, https://modelcontextprotocol.io/docs/concepts/tools
[5] “MCP Documentation - Resources”, https://modelcontextprotocol.io/docs/concepts/resources
[6] “MCP Documentation - Prompts”, https://modelcontextprotocol.io/docs/concepts/prompts
[7] “MCP Documentation - Sampling”, https://modelcontextprotocol.io/docs/concepts/sampling
[8] “MCP Documentation - Roots”, https://modelcontextprotocol.io/docs/concepts/roots
Acknowledgements
Special thanks to NCC Group’s research and AI security team that proofread this blogpost before being published.