> For the complete documentation index, see [llms.txt](https://mcp-test-kitchen-docs.cakewalk.security/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://mcp-test-kitchen-docs.cakewalk.security/start-here/quickstart.md).

# Quickstart

Sign in, connect a client and get your first record on screen. About five minutes, no failure configured yet.

This run uses `baseline`, the scenario that breaks nothing. It proves your token, your endpoint and your client configuration all work, which removes three explanations before you start testing failures.

***

## Before You Start

You need a Google or GitHub account to sign in, and an MCP client that connects to a remote server over HTTP and lets you set a request header. If you have no client yet, the console generates a working TypeScript one wired to your endpoint and your token.

***

## Six Steps

{% stepper %}
{% step %}

#### Sign in

Open [mcp-test-server.cakewalk.security/console](https://mcp-test-server.cakewalk.security/console) and sign in with Google or GitHub. Both land you in the same console.
{% endstep %}

{% step %}

#### Copy your client configuration

The **MCP access token** dialog opens by itself the first time you land in the console. If you closed it, the lock icon in the header brings it back. It holds your personal access token and, below it, the full client configuration JSON with the endpoint and token already filled in. Copy the JSON.
{% endstep %}

{% step %}

#### Add it to your client

Paste it into your client's MCP server configuration and reconnect. See [Connect a Client](/start-here/connect-a-client.md) for what the object contains and what your client has to support.
{% endstep %}

{% step %}

#### Select Baseline and save

In the Scenarios pane, choose **Baseline (success)** and click **Save**. Saving stores the selection against your account and applies it to your next session.
{% endstep %}

{% step %}

#### Call the tool

Ask your client to call `run_configured_test_scenario`. No arguments are required.
{% endstep %}

{% step %}

#### Read the record

Watch the Messages pane. Entries arrive live, newest first.
{% endstep %}
{% endstepper %}

***

## What You Should See

Three or four entries, depending on what your client does on connect.

| Phase                | Method                      | What it tells you                                           |
| -------------------- | --------------------------- | ----------------------------------------------------------- |
| `INITIALIZE`         | `initialize`                | Your client reached the endpoint and the token was accepted |
| `CLIENT INITIALIZED` | `notifications/initialized` | The handshake completed                                     |
| `DISCOVERY`          | `tools/list`                | Your client asked what tools exist                          |
| `TOOL EXECUTION`     | `tools/call`                | The tool ran                                                |

Every entry carries a green **OK** badge. Click the `initialize` entry to open the detail drawer and confirm the protocol revision your client declared, which is the value most worth knowing before you configure a scenario around it.

The tool returns a single text content block holding a JSON string:

```json
{
  "content": [
    { "type": "text", "text": "{\"scenarioId\":\"baseline\",\"invocation\":1,\"delayMs\":0}" }
  ]
}
```

`invocation` counts calls within your session. It is the number the failure scenarios match against.

***

## If Nothing Appears

{% hint style="warning" %}
An authentication failure produces no entry you can see. The server records the request before it checks your token, but a rejected request has no owner, so it never reaches your Messages pane. An empty log with a client reporting 401 means the token, not the server.
{% endhint %}

Work down this list.

* **Your client reports 401.** The token is missing, malformed or no longer the current one. Reopen the token modal, copy it again and check your client sends it as `Authorization: Bearer <token>`. **Regenerate** invalidates the previous token immediately, so any other client still holding it stops working.
* **Your client reports a connection or protocol error.** Confirm the URL ends in `/mcp` and that your client speaks streamable HTTP to a remote server. See [Endpoint and Authentication](/reference/endpoint-and-auth.md).
* **Entries appear but no `tools/call`.** Your client connected and never ran the tool. Check it discovered `run_configured_test_scenario` in `tools/list`.
* **Everything looks right and the result is wrong.** Confirm which scenario is live. The Scenarios pane names the saved one, and the label on each tool entry is the scenario ID that produced it.

***

## Next

Run a failure. [Tool Error](/scenarios/scenarios/tool-error.md) is the one worth doing first: it arrives at HTTP 200 with a green **OK** badge, so it is the failure your existing tooling is least likely to catch.

Before that run, read [How Scenarios Work](/scenarios/scenarios.md), in particular the invocation counters. Setting a failure to land on the second call and forgetting to terminate your session is the most common way a first test produces a confusing result.