MCPulse

MCPulse: аналитика вызовов, ошибок и стоимости для собственных MCP-серверов

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

Что умеет

  • Смотреть список подключённых серверов и их метрики
  • Разбирать инструменты по ошибкам, задержке и стоимости
  • Читать сессии и инсайты по использованию
  • Управлять участниками и ролями аккаунта
  • Настраивать каналы уведомлений и алерты

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

Ассистент видит метрики и настройки только тех MCP-серверов, что подключены к аккаунту пользователя.

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

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

MCPulse — MCP-сервер аналитики для разработчиков собственных MCP-серверов. Ассистент показывает число вызовов, успешность первого запроса, повторы, ошибки инструментов, задержки и стоимость токенов — по каждому инструменту и клиенту. Данные собираются SDK, встроенным в сервер разработчика двумя строками кода.

Как подключить

Как подключить MCPulse к Claude

Адрес сервера, который нужно вставить в настройках Claude:

https://mcpulse--mcpulse.run.tools

  1. Откройте Claude (сайт claude.ai или приложение для компьютера).
  2. Перейдите в Настройки → Коннекторы (в английском интерфейсе: Settings → Connectors).
  3. Нажмите Добавить пользовательский коннектор (Add custom connector).
  4. Вставьте адрес сервера, скопированный ниже, в поле URL удалённого MCP-сервера и нажмите Добавить.
  5. В чате нажмите + → Коннекторы и включите новый коннектор.

Пользовательские коннекторы доступны на тарифах Free, Pro, Max, Team и Enterprise. На Free можно добавить только один. В Team и Enterprise коннектор сначала добавляет владелец организации в Настройки организации → Коннекторы.

Авторизация

После нажатия Добавить откроется окно входа в сервис. Войдите под своим аккаунтом и подтвердите доступ. Пароль Claude не видит.

Как подключить MCPulse к ChatGPT

Адрес сервера, который нужно вставить в настройках ChatGPT:

https://mcpulse--mcpulse.run.tools

  1. Откройте ChatGPT в браузере (chatgpt.com). Нужен тариф Plus, Pro, Business, Enterprise или Edu.
  2. Один раз включите режим разработчика: Настройки → Приложения → Дополнительные настройки → Режим разработчика (Settings → Apps → Advanced settings → Developer mode).
  3. Откройте Настройки → Коннекторы и нажмите Создать (Create).
  4. Заполните форму: Название (любое), Описание (одна фраза, что делает сервис), URL MCP-сервера (скопируйте ниже).
  5. В поле Аутентификация выберите OAuth, если сервис требует вход, иначе Нет. Нажмите Создать.
  6. В новом чате откройте + → Приложения/Коннекторы и включите коннектор.

Название раздела у OpenAI менялось (Connectors → Apps/Plugins). Если пункт называется иначе, ищите «режим разработчика» в настройках. В рабочих пространствах Business/Enterprise администратор должен разрешить пользовательские коннекторы.

Авторизация

При первом использовании ChatGPT откроет окно входа в сервис. Войдите и подтвердите доступ.

Как подключить MCPulse к Cursor

Адрес сервера, который нужно вставить в настройках Cursor:

https://mcpulse--mcpulse.run.tools

Быстрый способ: нажмите кнопку Открыть в Cursor ниже, Cursor сам предложит добавить сервер.

Вручную:

  1. В Cursor откройте Settings → Cursor Settings → MCP и нажмите Add new global MCP server.
  2. Вставьте JSON, скопированный ниже, в открывшийся файл ~/.cursor/mcp.json (для одного проекта: .cursor/mcp.json в корне проекта).
  3. Сохраните файл. Сервер появится в списке MCP; при необходимости пройдите авторизацию по кнопке рядом с ним.

Авторизация

Если сервис требует вход, рядом с сервером в списке MCP появится кнопка авторизации.

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

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

list_mcpsEvery 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_mcpOne MCP's name and when it was created. For its numbers, use get_overview.
create_mcpAdd 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_mcpChange an MCP's display name. Nothing else about it moves — the id, its keys and its data are untouched.
delete_mcpDelete 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_keysAn 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_keyStop 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_overviewHeadline 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_toolsEvery 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_toolOne 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_insightsWhat 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_sessionsSessions 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_accountThe account this person belongs to, and their role in it.
get_usageWhat the account is using against its plan — MCPs, events, team size.
list_membersEveryone 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_memberAdd 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_rolePromote 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_memberRemove someone from the account, or withdraw an invitation that has not been accepted. They lose access to every MCP in it.
get_profileThe signed-in person's own name and email.
update_profileSet 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_companyThe account's company details. `timezone` is display only — every metric is bucketed in UTC.
update_companyChange 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_channelsWhere 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_channelsThis 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_alertsEvery 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_firingsWhat 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_alertWatch 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_alertAdmin 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_alertAdmin 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_inboxThis 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_readClears 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_digestWhether 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_digestAnyone 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.