How to test an MCP server online (tools, resources, prompts)

To test an MCP server online, connect an MCP client to the server's HTTP endpoint, let it run the handshake, then list and call the server's tools, resources and prompts while watching the raw JSON-RPC traffic. In Swastik Codes that is an MCP request: paste the URL (for example https://your-server.example.com/mcp), press Connect, and the server's tools, resources and prompts appear in tabs. Each tool gets a form generated from its input schema, and every result, notification and error is logged.

This guide covers what the client does at each step, how to call tools with arguments, how to test the parts of MCP that are hard to exercise from a chat client (elicitation, sampling, roots), and how to debug MCP's OAuth flow.

Remote MCP servers only (in the browser)

The Model Context Protocol has two kinds of transport:

• STDIO – the client starts the server as a local process and talks to it over standard input and output. This is how most desktop AI tools run local servers.
• HTTP – the server is a web service. The current transport is Streamable HTTP (a single endpoint, usually /mcp, that answers POSTs with JSON or an SSE stream). Older servers use the legacy HTTP + SSE transport, with a separate SSE endpoint.

The Swastik Codes web app supports the two HTTP transports. STDIO is not available in the browser: the web app sends traffic through the swastik.codes server, and that server never starts local processes. The transport selector shows the STDIO option disabled for that reason. The same server-side relay also refuses private and loopback addresses, so the MCP server has to be reachable from the internet. If you are building a server on your laptop, deploy it to a staging host or put it behind a tunnel with a public hostname. The desktop app for Windows and Linux connects from your own machine, so it reaches local servers and can also start STDIO servers.

Sending requests requires a free account, because they go through the server. Create one if you have not already.

For a public server to practise on, DeepWiki runs a Streamable HTTP MCP server at https://mcp.deepwiki.com/mcp that needs no key for public repositories. We use it below.

Step 1: create an MCP request and connect

1. Open the app and click + in the tab bar, then choose MCP.
2. Enter https://mcp.deepwiki.com/mcp as the URL.
3. Leave Transport on Streamable HTTP. Choose HTTP + SSE (legacy) only for servers that still use the older transport.
4. Press Connect.

With Streamable HTTP and the protocol version on auto, the client starts with the classic initialize handshake (with an Mcp-Session-Id header, a GET stream for server messages, and a DELETE when you disconnect), tries the newer stateless handshake (server/discover) only if a server refuses it, and finally falls back to the legacy HTTP + SSE transport. You do not need to know in advance which one a server speaks.

Once connected, a summary line shows:

• the server name and version from serverInfo,
• the negotiated protocol version and whether it is a stateless protocol or a session established with initialize,
• the transport, the session id when there is one,
• the capabilities the server declared (for example tools, prompts, resources),
• the server's Instructions, collapsed, when it sent any.

For DeepWiki you will see a FastMCP-based server negotiating 2025-06-18, with tools, prompts and resources capabilities.

Step 2: list and call tools

The Tools tab lists every tool from tools/list with its description. Selecting one shows its Input schema and, when the server provides one, its Output schema. Arguments are entered in a form generated from the JSON schema, with a JSON view when you prefer to type the object yourself.

Select read_wiki_structure, enter a repository in owner/repo form for repoName, and press Run tool. The result panel shows the content blocks the tool returned, and structuredContent when the tool has an output schema. A tool that fails with isError: true is shown as an error, which is different from a JSON-RPC error (an unknown tool, or invalid parameters). Testing both cases is worthwhile:

• call the tool with a valid repository and check the result shape,
• call it with a missing required argument and check that the server answers with a useful error instead of crashing,
• call it with a repository that does not exist and check the error is reported in the tool result.

A search box (Search tools, resources and prompts) filters long lists, and Refresh reloads them, which is useful when a server sends notifications/tools/list_changed.

Step 3: resources and prompts

The Resources tab lists resources/list and resource templates from resources/templates/list. Enter or pick a URI and press Read resource to see the contents. The Prompts tab lists prompts/list; fill in the prompt's arguments and press Get prompt to see the messages the server would hand to a model.

If a server does not declare a capability, the corresponding list is simply empty rather than an error.

Step 4: watch notifications

The Notifications tab collects everything the server sends on its own: progress notifications, log messages, list-changed notifications and server-to-client requests. In the Configuration tab you can set the Server log level (sent as logging/setLevel on session-based connections, or in the request metadata on the stateless protocol), so a server that supports logging streams its debug output into this tab while you call tools.

The Configuration tab is also where you set:

• Protocol version – auto, or a specific revision such as 2026-07-28, 2025-11-25, 2025-06-18, 2025-03-26 or 2024-11-05. Pinning a version is the quickest way to check backwards compatibility.
• Request timeout (ms) – for slow tools.
• Verify TLS certificates – leave it on unless you are testing a staging host with a self-signed certificate.
• Headers – extra HTTP headers sent with every MCP request, for example an organisation header or a static API key.

Step 5: elicitation, sampling and roots

These features are requests from the server to the client. They are hard to test from a chat application because the application decides how to answer. In Swastik Codes you answer them yourself:

• Elicitation (ask the user for input). Turn it on in Configuration and the client advertises the capability. When the server sends elicitation/create, the request is held and shown as Input required. You fill in the requested fields and answer, or decline. This lets you test both the happy path and what your tool does when the user refuses.
• Sampling (the user writes the model's reply). With sampling advertised, a sampling/createMessage request is shown with the messages the server wants completed. You type the reply as the assistant, set the model name reported back, and send it. You can also reject the request. This is a deterministic way to test tools that call back into a model.
• Roots. List file:// URIs (with optional names) under Roots; they are returned to the server's roots/list request. Changing them sends notifications/roots/list_changed on session-based connections.

Held server requests wait until you answer, for up to 10 minutes.

Step 6: authorization and the MCP OAuth debugger

Remote MCP servers that need a user's consent use OAuth 2.1, discovered from the server itself. When a server answers 401, the Authorization tab is marked. It contains the normal auth editor (Bearer token, API key, OAuth 2.0 and so on) and a step-by-step OAuth debugger. Press Run discovery and it performs, and reports, each step the MCP authorization specification describes:

1. Probe the server – send initialize and read the WWW-Authenticate header on the 401.
2. Protected resource metadata (RFC 9728) – find which authorization server protects this MCP server.
3. Authorization server metadata (RFC 8414) – read its endpoints, with a warning when code_challenge_methods_supported does not include S256, which MCP clients require.
4. Client registration (RFC 7591) – register a client dynamically, or skip this when you enter an OAuth client ID (and secret) yourself.

Each step shows the request outcome and the metadata it found, which makes it clear exactly where a misconfigured server breaks. When discovery succeeds, the request's OAuth 2.0 settings are filled in, and Authorize runs the authorization code flow with PKCE in a popup. The web app's callback URL is https://swastik.codes/oauth/callback; register it with your authorization server if it does not use dynamic registration. The token is then sent as a Bearer token on every MCP request. The general OAuth flow is explained in OAuth 2.0 in an API client.

A minimal server to test against

If you want a server of your own, the official Python SDK can serve Streamable HTTP in a few lines:

# server.py  –  pip install "mcp[cli]"
from mcp.server.fastmcp import FastMCP

mcp = FastMCP("demo")

@mcp.tool()
def add(a: int, b: int) -> int:
    """Add two numbers."""
    return a + b

@mcp.resource("greeting://{name}")
def greeting(name: str) -> str:
    """A personalised greeting."""
    return f"Hello, {name}!"

if __name__ == "__main__":
    mcp.run(transport="streamable-http")  # serves http://0.0.0.0:8000/mcp

Deploy it somewhere public (or expose it through a tunnel), connect to https://<your-host>/mcp, and you should see one tool (add) and one resource template (greeting://{name}). Call add with {"a": 2, "b": 3} and the result is 5. Check the SDK documentation for the version you install, as the APIs evolve.

Sharing and reusing what you tested

An MCP request can be saved into a collection like any other request, so the URL, headers, auth and configuration are kept with your other API work and shared with your team when the collection lives in a team workspace. Connections are also recorded in your history. When you are happy with a server, Export configuration produces the JSON snippet to add it to Claude Desktop, Claude Code, VS Code or Cursor.

Troubleshooting

Connection fails immediately. Check the path (/mcp is common, but not universal) and that the host is public. Private and loopback addresses are refused by the swastik.codes relay.

401 Unauthorized. Open the Authorization tab and run discovery. If step 2 fails, the server does not publish protected resource metadata; enter the authorization server details manually in the OAuth 2.0 settings.

Tools list is empty. The server did not declare the tools capability, or it requires auth before listing. Look at the capabilities in the summary line.

Works with one client, not another. Pin the protocol version in Configuration and reconnect. Differences between 2024-11-05 and later revisions (for example, JSON-RPC batching and structured tool output) are a common cause.

Frequently asked questions

Is this an alternative to the MCP Inspector?

For remote servers, it covers the same ground (listing and calling tools, resources and prompts, viewing notifications) and adds saved requests, team workspaces, history and an OAuth discovery debugger. The official MCP Inspector runs on your machine and can start STDIO servers, which the Swastik Codes web app cannot. Many developers use both.

Can I test a local STDIO MCP server?

Not from the web app. It supports Streamable HTTP and the legacy HTTP + SSE transport, and the server must be publicly reachable. The desktop app for Windows and Linux can start a local STDIO server.

Which MCP protocol versions are supported?

Auto-negotiation plus explicit versions from 2024-11-05 to 2026-07-28, including the stateless handshake of the newest revision.

Do I need an account?

The web app needs one, because connections go through the swastik.codes relay.

Try it

Open the app, add an MCP request for https://mcp.deepwiki.com/mcp, and press Connect. Sending requires a free account. The MCP client feature page lists everything the client supports. If your server also exposes a plain REST or SSE interface, the REST client and SSE client live in the same workspace.