How it works
Every number comes from the same services the dashboard reads. There is no metric computed in the MCP layer, because there is no metric that could be — which is the whole reason the logic lives in services.
Writes are the API’s guards, not new ones
The connector can create and rename MCPs, invite and remove teammates, revoke keys and edit the company — everything the dashboard can do except ingest. None of that needed new permission code. Every tool calls the same service function the REST route calls and hits the same guard, so a member is refused with the same sentence they would get in the dashboard. That is the return on “routes are thin, logic lives in services”: the hidden button was never the control. Tools carryreadOnlyHint, destructiveHint or neither, so your client knows what to confirm. Those are hints to the client; the guard underneath is the enforcement.
Two writes deliberately do not exist — minting a key and deleting the account. Tools says why.
Five metric tools, not sixteen
The obvious design is one tool per metric —get_calls, get_retries, get_p95 — so that every question has an obviously named tool.
It is the wrong shape, and this product is the argument against it. Every registered tool costs its schema in the context window of every session, whether or not it is ever called. Shipping sixteen near-identical tools over one metrics query would earn MCPulse its own dead-tool warnings.
So narrowing is a parameter. get_overview({ metrics: ["calls"] }) returns calls and nothing else — one schema, one round trip, a small answer. All sixteen metrics are still reachable; they are arguments rather than names.
The other half of that decision: the default response is a summary. The bulky arrays — daily series, per-tool rows, client splits, sparklines — are opt-in, because returning them on an unqualified question would undo the saving from the other side.
The tools
See Tools for arguments, annotations and the two deliberate omissions.
Next steps
- Connect — wire up Claude, Cursor, or your MCP client
- Authentication — what the OAuth flow does under the hood
- Tools — every argument, and when to reach for which
- Playbooks — prompts that work
- Skills — install MCPulse as a reusable skill for your agent
- Troubleshooting — what the common errors mean