MCPulse

Name: MCPulse
Author: mcpulse

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](https://www.npmjs.com/package/@mcpulse/sdk) inside your own server and wrap it in two lines — no proxy, no DNS change, and your server keeps working if MCPulse is down

该来源不提供完整文件导出（国内平台多为平台内托管），仅存元数据与原链

接入信息

传输形态: http
鉴权方式: 鉴权未知
端点: https://mcpulse--mcpulse.run.tools

鉴权方式未标注，请核对官方文档后再接入——不要直接使用以下片段

{
  "mcpServers": {
    "MCPulse": {
      "url": "https://mcpulse--mcpulse.run.tools"
    }
  }
}

能力清单

工具	说明
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.

纠错与举报（发现条目失效、署名有误或涉及侵权？）

提交举报 / 纠错

侵权举报经核验成立后，我们会即时下线该条目并删除已存的内容副本。