> For the complete documentation index, see [llms.txt](https://docs.flowcp.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.flowcp.ai/guides/chat-test-your-mcp-server.md).

# Chat-test in the Playground

The **Playground** lets you talk to your MCP server with a real model before you publish. The model can call your enabled tools for real — running live requests in your own authorization context — so you can confirm the whole loop works end to end: tool descriptions, input schemas, OAuth, and the actual API responses.

You can also exercise any capability **directly**, without the model — run a tool with hand-written arguments, read a resource, or preview a prompt — the way a developer tool like the MCP Inspector does. See [Run a tool, read a resource, or preview a prompt](#run-a-tool-read-a-resource-or-preview-a-prompt).

The Playground uses [OpenRouter](https://openrouter.ai) and **your own API key**, so you choose the model and you pay for the usage.

## What you need

1. **An OpenRouter API key.** Create one at [openrouter.ai/keys](https://openrouter.ai/keys).
2. **OAuth configured** for the server's branch (see [Configure OAuth](/guides/configure-oauth.md)). The Playground connects with the same OAuth flow your real AI clients use.

## Open the Playground

1. Open your app and go to **Servers**.
2. Click **Playground** on the server (branch) you want to test. (You can also reach it from the **Tests** page.)

The Playground is a three-pane workspace: a **config rail** on the left (connection, model, and capabilities), the **chat** in the center, and a **Raw JSON** inspector that slides in from the right when you ask for it.

## Save your OpenRouter key

In the config rail, paste your OpenRouter key and click **Save**. The key is stored **encrypted** for your workspace and is never shown again — only the last four characters are displayed. Once saved it collapses to a compact **Connected via OpenRouter** chip; click **Manage** to **Replace** (rotate) or **Remove** it.

## Connect your account

The connection step depends on your server's **auth mode**:

* **User OAuth** (the default) — click **Connect account**. A window opens and runs your server's OAuth flow. After you authorize, the window closes and the status badge turns **Connected**. The resulting access token is held **only in your browser for this session** — it is never stored on our servers. If it expires mid-chat, the Playground asks you to reconnect.
* **API key** or **static bearer token** — no account connection is needed. The Playground notes that the server uses a shared credential, the runtime injects it server-side, and you can chat as soon as your OpenRouter key is saved.
* **No authentication** — nothing to connect; start chatting right away.

For the non-OAuth modes the status badge reads **Ready** instead of **Connected**.

## Chat

Set the model in the config rail (any OpenRouter model id, e.g. `anthropic/claude-haiku-4.5`), type a message, and send. When the model calls one of your tools, the chat shows a card with the tool name, the arguments it sent, and the result it got back. Expand the card to inspect them, or click its **code** button to open the **Raw JSON** inspector (see below). The model's replies render as Markdown. The chat header tracks the running turn and tool-call counts; **New chat** starts a fresh session.

A few things to know:

* The Playground stops after a fixed number of tool steps so a runaway model can't burn through your OpenRouter credits.
* Draft (unpublished) servers are fully testable — that's the point.
* Errors from the model or a tool are surfaced inline (including the exact reason from OpenRouter, e.g. an invalid model id); your key and tokens are never logged.

## Choose which capabilities the model can use

The config rail groups everything your server exposes into collapsible **Capabilities** sections, each with an enabled/total count:

* **Tools** — the model calls them directly. Switch individual tools **off** to test how the model behaves with a narrower toolset; the disabled tools are withheld from the model for the current chat. Each tool also has a **Run** (▷) button to call it directly — see below.
* **Skills** — your server's skill playbooks (also callable as `skill_<slug>` tools). Toggling a skill off withholds its tool the same way. Click **View playbook** to read the skill's `SKILL.md` and bundled references.
* **Prompts** — toggle which prompts are offered. Click **Prompts** in the composer (or pick a starter card on the empty screen) to insert one. If a prompt declares arguments you'll be asked to fill them, then the rendered template drops into the input for you to edit and send. Click **Preview** to see the server-rendered messages instead of inserting them.
* **Widgets** — toggle whether a tool's linked widget renders. When an enabled widget's tool runs, its HTML is shown in a sandboxed frame beneath the result.
* **Resources** — listed for reference (always part of the server's context). Click **View** to read a resource's live content.

These toggles affect **this chat only** — they don't change what your published server exposes. Use **Reset** at the top of the rail to turn everything back on.

## Inspect the raw request and response

Click the **code** button on any tool-call card to open the **Raw JSON** inspector. It shows the exact **Request** (the tool name and the arguments the model sent) and the **Response** (the result the tool returned), each with a one-click **Copy**.

## Run a tool, read a resource, or preview a prompt

Sometimes you want to test one capability **deterministically**, without a model deciding what to do. Each capability in the config rail has a direct action:

* **Run a tool.** Expand **Tools** and click the **Run** (▷) button on a tool. A dialog opens with a JSON editor seeded from the tool's input schema — edit the arguments and click **Run**. The call goes through the same auth and policy as a real request (disabled tools can't be run; a tool that **requires confirmation** shows a confirm switch you must flip first), and the result opens in the **Raw JSON** inspector. Invalid JSON is flagged inline before any call is made. While the call runs, a **Live activity** feed shows the server's MCP notifications — `logging` lines (started / completed / failed, with status and latency) and `progress` updates — streaming in as they happen.
* **Read a resource.** Expand **Resources** and click **View**. Static resources load immediately; resources with URI variables prompt you to fill them first. The content is rendered by type (JSON, Markdown, plain text, or a download link for binary content).
* **Preview a prompt.** Expand **Prompts** and click **Preview**. Fill any arguments, and the server-rendered messages are shown exactly as a client would receive them.
* **View a skill playbook.** Expand **Skills** and click **View playbook** to read the skill's `SKILL.md` and any bundled reference files.

On **User OAuth** servers, running a tool or reading an endpoint-backed resource needs your account connected (the same as chatting); prompt previews and skill playbooks don't.

## Activity: execution logs and live notifications

Click **Logs** in the chat header to open the **Activity** pane, which has two tabs:

* **Execution logs** — this server's recorded tool invocations, newest first, with the tool name, status, latency, MCP client, and model. Both chat turns and direct runs appear here. Click any row to open its full record in the **Raw JSON** inspector. These are durable execution/audit logs.
* **Live** — a rolling feed of the MCP protocol notifications (`logging` and `progress`) emitted by tool runs in the current session. This is the same stream shown in a tool's **Live activity** while it runs, kept here so you can review it afterward. **Clear** empties the feed. (Live notifications are in-session only — they are not persisted like execution logs.)

## Test payments (monetized servers)

If you've [monetized](/guides/monetize-your-mcp-server.md) a server, you can pay for paid tools right here — no real wallet or external agent needed. In the config rail under **Test payments**:

* **Test wallet** — enter an EVM address, or click **Generate** for a throwaway one. This is the payer for mock payments (it's saved for next time).
* **Auto-pay test payments** — when on, paid tools are paid automatically.

When the model calls a paid tool:

* **Auto-pay on** → the Playground constructs a mock x402 payment from your test wallet, settles it, and retries. The tool call shows a **paid** badge with the amount, payer, and network.
* **Auto-pay off** → the turn pauses with a **Payment required** card showing the price; fill in a test wallet and click **Pay & retry**.

These are **mock payments** — no real funds — and settle only against the built-in mock facilitator (development / self-host runtimes). Each one still writes a real receipt under **Monetization → Transactions**, so you can confirm the full earn flow works. Wiring a real on-chain wallet into the Playground isn't supported yet.

## History

Every chat is saved automatically to this server's **History** (titled from your first message). Open **History** to revisit a past session or delete it, and **New chat** to start fresh. Only the transcript is saved — never your OpenRouter key or your connection token.

When everything behaves the way you expect, head to the [Publish page](/guides/publish-your-mcp-server.md).