> 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/reading-the-record/record.md).

# Reading the Record

The server writes one entry per request it handled. This is where you confirm what your client sent.

Every request the server handles produces one entry in the Messages panel. The entry is written from the server's side of the connection, which is the half you cannot see from inside your client.

The record is scoped to you. You see requests made with your own token and nobody else's.

***

## The Panel

Entries arrive live over a stream, newest first, fifty to a page. Each one is a card showing the time, a status badge, the duration in milliseconds, the phase, the method, a label and the protocol revision your client declared.

The label is the scenario ID for tool and protocol traffic. For resource and prompt traffic it is the resource URI or the prompt name instead, because those are not scenario specific.

Click any entry to open the detail drawer, which carries the recorded request headers and a summary of the request params. The summary is not the full params object: a `tools/call` entry shows the tool name and never its arguments. See [Observation Fields](/reading-the-record/record/fields.md).

***

## The Status Badge Is Not the Status Code

The badge shows **OK** for any status below 400, the numeric code for 400 and above, and **CANCELLED** when your client aborted the request.

This matters more than it sounds. A tool error arrives at status 200 and gets a green **OK**, identical to a success. The panel is not hiding anything: there is genuinely nothing at the transport layer that distinguishes the two. See [What the Record Proves](/reading-the-record/record/what-it-proves.md) for how to work around that.

***

## Filters

Five filters narrow the list, and they combine.

| Filter     | Accepts                                                                                                                                     |
| ---------- | ------------------------------------------------------------------------------------------------------------------------------------------- |
| Date range | A from date and a to date, applied to local start and end of day                                                                            |
| Method     | An exact method string, such as `tools/call`                                                                                                |
| Phase      | One of the nine phases                                                                                                                      |
| Category   | Tools, Resources or Prompts, matched on the method prefix                                                                                   |
| Caller     | Substring match on the account email. Your entries are already scoped to you, so this narrows nothing unless you hold more than one address |

Method is an exact match, not a search. `tools` returns nothing; `tools/call` returns tool calls.

***

## Clear All Before a Run

**Clear all** deletes your entries permanently. Use it at the start of a test run so the log holds one run and nothing else, which makes counting invocations reliable.

{% hint style="warning" %}
**Clear all** empties the log. It does not reset your session's invocation counters. Those are separate, and **Terminate** in the Scenarios pane is what resets them. Doing one without the other is the most common way an `onInvocation` test produces a confusing result.
{% endhint %}

***

## Read the Fields Next

[Observation Fields](/reading-the-record/record/fields.md) lists everything an entry carries, the nine phases and what each one covers.