Skip to main content
You publish an MCP server and you can see nothing. Not how many people use it, not which tools get called, not whether the model understands your tool descriptions, not what your server costs the people running it. The directories report none of this. MCPulse answers that. An npm package installed inside your own server records what each tool call did — how long it took, how it ended, how big the answer was — and posts it to MCPulse. Two lines to install, no proxy, no change to your URL, and no arguments or results ever leave your process. In MCPulse, everything hangs off an MCP: one tracked server. You create an MCP, it gives you an ingest key, you wrap your server with that key, and the overview fills in. The sidebar gives you MCPs and Settings, and nothing else.

Start with your goal

Instrument your first server

Create an MCP, mint a key, wrap your server, and see live numbers.

Understand first-call success

The headline metric: did the model get what it wanted on the first try?

Find what is wrong

Five rules that name a tool, a number, and a consequence.

Cut what your server costs

Heavy payloads and dead tools, priced in tokens and dollars.

Use the REST API

Every number the dashboard shows, computed server-side and available to you.

Use MCPulse with AI (MCP)

Ask Claude how your server is doing, and have it read the real figures.

How MCPulse works

1

Create an MCP

One MCP per server you want to track. Creating one opens it and hands you the install steps.
2

Mint an ingest key

A key looks like mp_live_…, belongs to exactly one MCP, and is shown once at creation.
3

Wrap your server

watch(server, { key: process.env.MCPULSE_KEY }), after your tools are registered. That is the whole integration.
4

Data arrives

Your server sends a startup payload with the tool list, then one payload per tool call. Batched every 5 seconds or 30 calls, whichever comes first.
5

Read the overview

Calls, first-call success, p95 latency and cost per session, each against the previous window of equal length.
6

Act on the insights

Low first-call success, heavy payloads, silent empties, dead tools, slow tools — each with the number that fired it.

What gets recorded, and what never does

Every payload carries sizes and hashes only. There is no option that turns this off, because the guarantee is only worth something if it cannot be switched off. See Security & data access.

The sixteen metrics

Counted live as calls arrive: calls per tool, calls per day, which client, crashes, tool errors, bad arguments, empty answers, speed, result size, sessions, cost per session. Computed by the nightly pass: retries, first-call success, tool pairs. From the startup payload: schema size, dead tools.