MCPulse

Name: MCPulse
Author: mcpulse

Analytics for MCP servers.

От сообществаРаботаетБез входаГлобальныйБесплатноМожет изменять данные

Что умеет

List Mcps: Every MCP server on this account, with calls in the last 30 days and first-call success. Start here when the user names a server you have not seen, or asks what they have.
Get Mcp: One MCP's name and when it was created. For its numbers, use get_overview.
Create Mcp: Add a new MCP server to the account. Returns it with its id. It has no ingest key yet, and keys cannot be minted from here — send the user to the MCP's Keys page in the dashboard, where th

Какие данные видит

Нужен ли аккаунт

Не нужен: сервер работает без входа

Analytics for MCP servers. Publish a server and you can see nothing — not how many people use it, which tools get called, whether the model understands your tool descriptions, or what your server costs the people using it. MCPulse answers that: calls, first-call success, retries, bad arguments, tool errors, crashes, empty results, latency and token cost, broken down per tool and per client. Install the npm package inside your own server and wrap it in two lines — no proxy, no DNS change, and your server keeps working if MCPulse is down

Список инструментов сервера (33)

Технические названия из tools/list. Нужны только разработчикам.

list_mcps	Every MCP server on this account, with calls in the last 30 days and first-call success. Start here when the user names a server you have not seen, or asks what they have.
get_mcp	One MCP's name and when it was created. For its numbers, use get_overview.
create_mcp	Add a new MCP server to the account. Returns it with its id. It has no ingest key yet, and keys cannot be minted from here — send the user to the MCP's Keys page in the dashboard, where the key is shown once.
rename_mcp	Change an MCP's display name. Nothing else about it moves — the id, its keys and its data are untouched.
delete_mcp	Delete an MCP and everything under it — its keys, events, rollups and sessions. This cannot be undone and the data is not recoverable. Confirm with the user first.
list_keys	An MCP's ingest keys — name, prefix, created, revoked. The key itself is hashed and never returned; only the prefix, which is what identifies one in a list.
revoke_key	Stop a key working, immediately. Any server still using it stops reporting — and the SDK swallows the failure, so nobody gets an error, the data simply stops. Be sure which key it is.
get_overview	Headline metrics for one MCP over a date range: calls, first-call success, p95 latency, cost per session, sessions, outcome breakdown and response size. Ask for only what was wanted. `metrics: ["calls"]` returns calls and nothing else — prefer that over pulling the whole overview and reading one field out of it. Omitting `metrics` returns the summary figures; the larger series (daily, tools, clients, follows, sparklines) are returned only when named.
list_tools	Every tool on one MCP with its calls, first-call rate, average response size, p95 latency and schema size — the tool-health table. Use this to find which tool is the problem; use get_tool once you know.
get_tool	One tool in detail: outcome breakdown, latency distribution, retries, first-call success, response size, and which tools get called alongside it. Always returns this tool's numbers broken out per client as well. Read that first when first-call success looks low: a tool that works for one model and not another is a description problem, not a server problem, and the average of the two says neither.
get_insights	What is actually wrong, as sentences with numbers: low first-call success, heavy payloads, silent empty results, dead tools, slow tools. This is the tool to reach for when the user asks how their server is doing rather than for a specific figure. Worth running twice when a rule fires: once unfiltered, then once per client. The same five rules over one model's calls will often show the problem belongs to that model.
get_sessions	Sessions in range with calls, bytes and cost per session, plus the most recent ones. Counted by start time rather than summed per day, so a session crossing midnight stays one.
get_account	The account this person belongs to, and their role in it.
get_usage	What the account is using against its plan — MCPs, events, team size.
list_members	Everyone in the account, arrived or not. Someone with status `invited` has been asked but has not signed in yet — they are a member row without a user, not a separate kind of thing.
invite_member	Add someone to the account by email. They appear in the team list immediately with status `invited`, and become `active` the first time they sign in with that address. Ask for their name — without it the team list shows an address where a person should be.
change_member_role	Promote or demote someone. Admins cannot act on owners, and the last owner cannot be demoted — an account with no owner cannot be administered by anyone.
remove_member	Remove someone from the account, or withdraw an invitation that has not been accepted. They lose access to every MCP in it.
get_profile	The signed-in person's own name and email.
update_profile	Set or clear your own name, or change your dashboard theme. Every field is optional and an omitted one is left alone. Pass null for full_name to clear it — that is a different instruction from omitting it, which changes nothing. There is no null theme: `system` means follow the operating system.
get_company	The account's company details. `timezone` is display only — every metric is bucketed in UTC.
update_company	Change the company details. Only include fields you mean to change; null clears one. `name` is the account's name — this is the only place it can be set.
get_channels	Where anything the product wants to tell this person goes: the four channels, their own switches for the personal two, and the account's Slack and Discord connections. `scope` distinguishes them. `personal` — in-app, email — fans out one delivery per recipient. `shared` — Slack, Discord — delivers once per firing, because posting the same message to the same channel once per team member is the same message five times. `delivers` is the honest answer to whether anything is actually sent. Only in-app is true: the rest record deliveries and queue them, and no job drains any of them yet. A connection's webhook URL is never returned. `webhook_hint` is masked — enough to recognise which webhook it is, useless to anyone who reads it. Per-tool thresholds are not here, and neither is the weekly digest. Both need a scope, so they live on a specific MCP — see list_alerts and get_digest.
update_channels	This person's own switches, for the personal channels — in-app and email. Merges rather than replaces, so sending one channel cannot switch the other off. Switching a channel off silences every alert on it, across every MCP. This is the person's half of delivery; an alert rule is the server's half, and a notification arrives only where the two agree. Slack and Discord are not here. They are the account's connections rather than a person's preference — one webhook for the whole team, and a credential — so connecting them is admin-only and lives in the dashboard.
list_alerts	Every alert rule on one MCP: the sentence it reads as, when it last fired, how often, and which channels it uses. Also returns the metric catalogue — the metrics you may use, each with the unit its threshold is expressed in and the direction that makes sense for it. Read this before creating a rule. The catalogue is the only place the unit is stated, and a threshold in the wrong unit is a rule that silently never fires.
list_alert_firings	What has fired on one MCP, newest first, as sentences. The facts are frozen at fire time, so renaming or deleting a rule does not rewrite its history.
create_alert	Watch one metric on one MCP and say so when it crosses a line. Checked once a night against the day just gone. Admin or owner. A rule only fires on a day with at least `min_calls` calls in scope — two empties out of three calls is 67% and means nothing.
update_alert	Admin or owner. Omitted fields are left alone, so silencing a rule is a one-field call: `{ alert_id, enabled: false }`. Prefer that over deleting — the history survives and it can be switched back on.
delete_alert	Admin or owner. The rule and its recorded firings go; notifications already in someone's inbox stay. Set `enabled: false` with update_alert instead if the intent is only to stop being told for now.
get_inbox	This person's in-app alert deliveries, newest first, with an unread count. Per person: two people on the same team can accept different channels, so the same firing reaches one and not the other.
mark_inbox_read	Clears the unread count. Deliberately all-or-nothing over MCP: marking individual ids read is a click in the dashboard, where the person can see what they are dismissing.
get_digest	Whether this person wants one MCP in their weekly digest, and through which channels. Per MCP all the way through: each subscribed server sends its own digest, so five subscriptions mean five digests rather than one email with five sections. Nothing sends yet.
set_digest	Anyone who can read the MCP may set their own. This is a person choosing what they receive about numbers they are already allowed to look at.