1. Create an MCP and mint a key
1
New MCP
Name it after the server you are instrumenting. Creating it opens it.
2
Create key
On the Installation page. Name it
production or laptop — whatever you will recognise later.3
Copy it now
The full key is shown once. Only a hash and the first 12 characters are stored.
/m/:id/keys with the name and prefix you expect.
2. Wire it up
.env
debug: true and look at stderr. You want watching. If you get disabled — no key or not an MCP server, stop here — troubleshooting covers both.
3. Connect a client
Point Claude Desktop, Cursor, or any MCP client at your server. Check: stderr showsstartup: N tools, client <name>. That N should be the number of tools you registered. If it is lower, watch() ran before some of them were registered — move it below the last registerTool.
4. Make some calls
Use each tool at least once, including the ones you expect to be slow or to return nothing. The point of the first session is to prove every path reports. Check the dashboard. Within about five seconds:
Those three wait for the nightly pass at 02:00 UTC and are labelled as of yesterday. That is normal and nobody minds.
5. Check the tool list is complete
Open tool health. Every tool you registered should be listed, including any that were never called — those come from the startup payload and carry their schema size. A tool missing from the list either was not registered whenwatch() ran, or is registered under a different name than you think. The recorded name is what the client actually sent.
6. Come back tomorrow
The first genuinely useful reading is the day after the nightly pass has walked a full day of your traffic. That is when first-call success and the insights that depend on it appear.Next
Improve first-call success
The headline metric, once you have one.
Cut context cost
Actionable from day one — response size is live.