> ## Documentation Index
> Fetch the complete documentation index at: https://docs.getmcpulse.com/llms.txt
> Use this file to discover all available pages before exploring further.

# The sample MCP

> Acme Orders — thirty days of fabricated traffic, seeded into every new account so the product can show what it does before you have wired anything up.

Every new account arrives with one MCP already in it: **Acme Orders**, carrying thirty days of history.

Without it, a first session is a list with nothing in it, an overview of zeros and an install page — the product cannot show what it does until you have already done the work.

## It is a real MCP

Not a mock screen. It is an ordinary row in the same table your own servers live in, with ordinary hourly counters underneath it, and every read path treats it as one.

That is the point: no panel knows it exists, so there is no second code path to keep correct, and the sample is free QA on all of them.

## The shape of the data is the design

A sample where everything is healthy makes the insights panel say *"Nothing worth flagging"* — and that panel is the product. So the tools deliberately trip all five [insight rules](/insights/overview), with two healthy ones beside them so it does not read as a server on fire.

| Tool                          | What it demonstrates                      |
| ----------------------------- | ----------------------------------------- |
| `search_orders`               | Low first-call, 64% — the headline metric |
| `find_product`                | Silent empties, 9%                        |
| `list_inventory`              | Slow, 17.7% over 2 seconds                |
| `export_report`               | Heavy payload at 14 kB, and slow          |
| `sync_catalog`                | Registered, never called — the dead tool  |
| `get_customer`, `fast_lookup` | Healthy                                   |

Three clients sit at 85%, 54% and 83% first-call, on shares of 68 / 24 / 8. That thirty-point spread is the sharpest thing this product can say — the same tools read differently by different models — and it is visible on day one rather than only in a demo.

The payoff is on the [cross-filter](/metrics/overview): `search_orders` reads **76% for `claude-desktop` and 22% for `cursor`**, where the server-wide figure is a flat 64%.

<Note>
  Latency is deliberately **not** varied per client. A model has no speed — the tool it called does — so the latency panel under a client filter shows a real distribution rather than an invented one. Error rates *are* varied, which is what puts Cursor's `bad_args` on `search_orders` at 12% against Claude's 5%.
</Note>

## Two alert rules ship with it, and one has already fired

* *Cursor on `search_orders` below 60%* — **fired**, at 19%
* *Server-wide first-call below 70%* — did not, because the average across clients is 81%

Same metric, same day, same server: one rule finds the problem and the other cannot see it. That is the argument for scoping a rule to a tool and a client, made on your own first screen rather than in a doc. It also means [Alerts](/alerts/rules) and the inbox are populated on day one.

## What it does not affect

* **Your usage.** The sample is excluded from the calls counted against your [plan](/billing/usage). Otherwise a brand-new account would open the billing page a third of the way through its allowance having made no calls at all.
* **Your ordering.** Samples sort below your own MCPs on the list.
* **Your nightly figures.** The [nightly pass](/api/concepts/nightly-pass) skips sample MCPs. It recomputes rather than accumulates, and it would rebuild a 664-call day out of the 60 individual calls seeded behind it.

## It says what it is, and offers to go

A **Sample** badge on the list row, and a banner at the top of its overview — above the panels, not below them, because a disclaimer under six charts is a disclaimer nobody reads — carrying a **Remove** button.

Sixteen thousand calls you never made, presented without comment, would be the product lying on the first screen you see.

## It goes stale, and that is accepted

The dates are seeded at signup and never refreshed, so a sample left for two months shows an empty chart. Deleting it is one click and always visible; re-seeding on read would mean writing to your account during a page load and inventing a rule about when "stale" begins.

## Related

* [Create an MCP](/mcps/create) — your own
* [Delete an MCP](/mcps/delete)
* [Insights](/insights/overview) — the five rules it trips