> 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/what-it-proves.md).

# What the Record Proves

The record shows what your client sent and what the server answered. What your client did next is the part you have to observe yourself.

The record is written from one side of the connection. Knowing which side saves you from reading conclusions into it that it cannot support.

***

## What It Proves

* **Your client sent the request.** With the method, the params and the timing.
* **The server answered, and how fast.** A duration that matches a configured delay proves the wait happened server side.
* **Which revision your client negotiated.** Frequently not the one you configured, and it decides which protocol paths run.
* **Whether your client cancelled.** A **CANCELLED** badge means the abort reached the server. A client that gives up locally without telling the server produces no such badge, and the difference is invisible to your user.
* **How many times your client called.** Which is how you catch retry storms and how you confirm an `onInvocation` test ran the way you meant.
* **Which scenario was live.** The label on the card, so you never have to trust your memory of what you saved.

***

## What It Cannot Prove

The server does not record the response body it sent, and it cannot see your client at all.

So the record cannot tell you whether a failure surfaced to a person, whether it reached the model, whether your client retried for the right reason, or whether an answer your user saw was real or invented. Those are the questions worth asking, and every one of them is observed on your side.

The record's job is to remove doubt about the input, so that what you observe in your client has only one explanation.

***

## Reading a Failure You Configured

You already know what the server did, because you configured it. Use the record to confirm the failure landed where you intended, then read your client.

The method is the same for every scenario.

{% stepper %}
{% step %}

#### Confirm the count

Did the failing call land on the invocation you configured? If not, your counter was not at zero. Terminate the session, clear the log, run again.
{% endstep %}

{% step %}

#### Confirm the scenario

The label on the card should be the scenario you saved. A stale session shows the old one.
{% endstep %}

{% step %}

#### Confirm the revision

If `clientProtocolVersion` is not what you expected, some of what you are about to conclude is about revision handling rather than error handling.
{% endstep %}

{% step %}

#### Then read your client

Knowing the input was exactly what you meant it to be.
{% endstep %}
{% endstepper %}

***

## The Case Where the Record Says Nothing

Run [Tool Error](/scenarios/scenarios/tool-error.md) and both calls come back **OK** at status 200. Nothing in the log distinguishes them.

That is the finding, not a gap in the tooling. A tool error is delivered inside a successful response, so no transport level record anywhere can separate it from a success. Your own monitoring does the same arithmetic and reaches the same wrong answer.

What you do with that: you know which call carried the failure because you set `onInvocation`. If a normal answer still reached your user after that call, your client passed a failed result upward as content, and no amount of server side logging would have told you. Only watching your client does.

***

## Entries Expire

Records are deleted after seven days by default, and a background job prunes them every fifteen minutes. Pull anything you want to keep into your own tracker before then. See [Data Handling](/reference/data-handling.md).