Using the Protocol Tester

Test MCP, A2A, and REST endpoints directly inside the Agentic Asset Designer platform with the built-in Protocol Tester—no external tools required.

Overview

The Protocol Tester is an in-app, Postman-like component that lets you:

Discover capabilities — Connect to an MCP or A2A URL and see tools, resources, prompts, or skills automatically.
Run requests — Fill in parameters using schema-based forms (no raw JSON), then view status, headers, and response body.
Copy cURL — Generate a cURL command from any request for use in scripts or external tools.
Replay history — Recent requests are saved so you can replay or compare results.

Protocol is auto-detected from the URL (e.g. paths containing /mcp or /a2a), and all requests go through the platform’s proxy so CORS and browser security are handled for you.

Where to Find It

Standalone page

Open the sidebar and click Protocol Tester (flask icon).
You’ll see the full tester with URL bar, optional auth and headers, and a history drawer.
Use this when you want to test any MCP, A2A, or REST URL (including servers not yet registered in the platform).

MCP Server detail — Test tab

Open an MCP server from the Servers list, then select the Test tab.
The tester is pre-filled with that server’s MCP endpoint URL and auth (if configured).
Protocol is locked to MCP; after you click Send, tools, resources, and prompts appear as cards you can run.

Agent Card detail — Test tab

Open an agent card from the Agent Cards list, then select the Test tab.
The tester is pre-filled with the card’s A2A endpoint; discovered skills are shown.
The agent header shows the card’s name, description, version, protocol version, and capabilities (streaming, push notifications, history) alongside the skills.
Each skill card can be expanded to reveal its example messages—click an example to load it into the message box.
Protocol is locked to A2A so you can send messages and test skills.

Choosing the A2A protocol version when sending

The Send button is a split button. Clicking the main button sends the message using the card’s default protocol version—the highest version the card advertises, or A2A 1.0 when the card omits any version signal. The caption under the message box shows which version will be sent (for example, Sends as A2A 1.0).

Send as the default version — click the main Send button (or press Enter).
Send as a specific version — click the caret (▾) next to Send and pick a version. This is useful for a genuinely legacy agent whose card omits a version: the tester assumes A2A 1.0, and the caret lets you resend as A2A 0.3.0.

The two versions differ on the wire: A2A 1.0 sends SendMessage (or SendStreamingMessage) with an A2A-Version: 1.0 header, while A2A 0.3.0 sends message/send. The tester adds the A2A-Version header automatically for 1.0 sends unless you already set one in the Headers panel.

For a streaming-capable A2A 1.0 card, a Stream response (SSE) checkbox appears under the message box. When the card advertises streaming, the checkbox is checked by default so Send uses SendStreamingMessage; uncheck it to send the unary SendMessage instead. A2A 0.3.0 cards continue to use message/send and do not show the checkbox.

Copy cURL for an A2A send reproduces the exact request that was sent—the JSON-RPC body for the chosen version and, for A2A 1.0, the A2A-Version: 1.0 header—so the exported command behaves the same as the in-app send.

Continuing a multi-turn A2A task

A2A agents often reply with a Task rather than a final answer—for example an underwriting broker that needs more information will return a task in state input-required along with a taskId and a contextId. The correct A2A flow is to continue that same task by sending your next message with those identifiers, instead of starting a brand-new task each time.

The tester handles this with a Continue task control that appears under the message box once a response carries a task to continue:

When it appears — The control is hidden on the first send. It shows up only after the agent returns a response that includes a taskId or contextId. It resets when you disconnect or switch endpoints, so a stale task never leaks into a new session.
Auto-checked on input-required — When the returned task state is input-required, the checkbox is checked automatically, because the agent is explicitly waiting for your reply. For working or completed states it appears unchecked—tick it yourself if you want to keep adding to the same task.
What it sends — When checked, your next send echoes the returned taskId and contextId on the message and still uses a fresh messageId, so the broker treats it as the same conversation. When unchecked, the send is single-shot exactly as before.
Seeing and clearing the task — A small badge shows the active state, taskId, and contextId (shortened). Use clear to drop them and start a fresh task on the next send.

The tester mirrors the exact identifier casing the agent returned. A2A 0.3.0 and 1.0 both use taskId/contextId in this ecosystem, but if a broker replies with task_id/context_id, the tester echoes those keys back unchanged. Copy cURL reproduces the continuation fields, so the exported command continues the same task too.

REST API detail — Playground tab

Open a REST API from the REST APIs list, then select the Playground tab.
The tester shows all endpoints as interactive cards with method, path, and parameter fields.
Click Refresh to reload endpoints from the API definition.
Protocol is locked to REST.

Exploratory Testing sessions

When an external tester opens an exploratory session entity, the Protocol Tester opens pre-configured for that specific entity (tool, skill, or endpoint).
Interactions are automatically captured and stored as session data.

How It Works

Enter or use the pre-filled URL (e.g. https://your-domain.com/api/platform/SERVER_ID/mcp).
Click Send — The tester detects the protocol, calls the appropriate discovery (e.g. initialize, tools/list, resources/list, prompts/list for MCP), and displays the results.
Use the discovery cards — Each tool, resource, or prompt has a Test button. Click it to open a form built from the schema (text, number, select, etc.).
Submit and view the response — Status, timing, and body are shown; you can switch between formatted JSON, raw text, and headers, and copy the request as cURL.

MCP HTTP-Streamable and SSE

Many MCP servers use the HTTP-Streamable transport. The Protocol Tester is built to work with them:

Headers — It sends Accept: application/json, text/event-stream and User-Agent: ProtocolTester/1.0 (MCP-HTTP) on every MCP request, so servers that expect these headers will respond correctly.
SSE responses — If the server returns Server-Sent Events (e.g. event: message and data: {"result":{...}}), the tester automatically extracts the JSON from the data: line and displays tools and results. No extra configuration is needed.

If discovery finds no tools, resources, or prompts, the UI shows the raw tools/list response (status and body) so you can see exactly what the server returned and debug connection or protocol issues.

Security and Limits

Proxy — All outbound requests are sent through the platform’s proxy. Private and internal IPs are blocked (SSRF protection).
Auth — Credentials you enter (Bearer token, basic auth, etc.) are used only for the request; they are not stored on the server.
Limits — Request body size and timeouts are enforced by the proxy to keep the service stable.

Next Steps

Testing MCP Endpoints — cURL, Postman, MCP Inspector, and SDKs
Creating Your First MCP Server — Build and run a server
MCP Methods Reference — JSON-RPC methods and parameters

Use the Protocol Tester from the sidebar or from any MCP server or Agent Card Test tab to validate endpoints.

Creating Your First MCP Server A² Playground — Collections & Assets