Remote transports and protocol versions
The web app connects to MCP servers over HTTP: Streamable HTTP and the older HTTP+SSE transport. With Streamable HTTP the client starts with the initialize handshake every current server answers (with an Mcp-Session-Id session), tries the stateless discovery of newer protocol revisions only when a server refuses it, and falls back to HTTP+SSE, so older and newer servers both work. You can also pin a specific protocol version instead of automatic negotiation. Local STDIO servers and servers on localhost or your private network need the desktop app: the web app connects through our servers, which cannot start programs on your computer or reach your network.
After connecting you see the server's name and version, its declared capabilities and any instructions it sends, plus the negotiated protocol version and session id.
Tools, resources and prompts in one place
The client lists the server's tools, resources and prompts, with a search box when the list is long and a reload button for servers that change them at runtime.
- Tools: arguments are rendered as a form from the tool's input JSON schema, and you can switch to raw JSON. Call the tool and inspect the result content.
- Resources: read a resource by URI and view its contents.
- Prompts: fill in the prompt's arguments and get the rendered messages.
Every request and reply is recorded in a message log, so you can see the exact JSON-RPC traffic, and server log notifications appear at the log level you choose.
{
"method": "tools/call",
"params": {
"name": "search_issues",
"arguments": { "query": "label:bug state:open", "limit": 5 }
}
}Elicitation, sampling and roots
MCP servers can call back into the client. You choose which client capabilities to advertise:
- Elicitation: when the server asks the user for input, the request is held in the log until you answer it (or decline).
- Sampling: when the server asks the client's model for a completion, you write the reply yourself, which is a precise way to test how your server handles it.
- Roots: list the roots the server sees when it calls
roots/list, and replace them during a live session to test change notifications.
OAuth for MCP servers
Many remote MCP servers are protected with OAuth 2.1. The built-in OAuth debugger walks the discovery steps one at a time (the 401 challenge, protected resource metadata, authorization server metadata and dynamic client registration), shows the outcome of each request, fills in the request's OAuth 2.0 settings and gets a token with authorization code and PKCE. When something in the chain is misconfigured, you see which step failed. See also authorization.
How it works
- Open the app, create a request and change its type to MCP.
- Enter the server URL, for example
https://mcp.example.com/mcp, add headers or auth, and connect. - Browse tools, resources and prompts and call them.
Connecting needs a free account: the web app relays the session through the Swastik Codes server, which only reaches public addresses. Save MCP requests in collections so the whole team can test the same server, and keep them alongside the HTTP endpoints the server wraps.
Frequently asked questions
Can I test a local STDIO MCP server?
Not in the web app. It supports remote servers over Streamable HTTP and HTTP+SSE. The desktop app for Windows and Linux can also start local servers over STDIO.
Which MCP protocol versions work?
Version negotiation is automatic by default and covers both older initialize-based servers and newer revisions; you can also pin a version when testing compatibility.
Can I see the raw JSON-RPC messages?
Yes. Every request, response and notification is shown in the message log, and the log can be searched and downloaded as JSON.
How do I test a server that requires OAuth?
Use the OAuth debugger to discover the authorization server, register a client if the server supports dynamic registration, and get a token. The token is then sent with your MCP requests.