What is the Pingstack remote MCP server?
The Pingstack remote MCP server is a hosted Model Context Protocol endpoint at https://app.pingstack.io/mcp, so AI assistants can connect to it without installing or running anything locally.
Pingstack MCP ServerVerifiedFeatured
@Pingstack
Basic information
Transport
Streamable HTTP
Authentication
OAuth
Last updated
Category
Developer Tools
Author
Pingstack
Submitted by
Jason Chance
About Pingstack MCP Server
Pingstack monitors cron jobs and scheduled tasks with heartbeat checks, and checks websites, TCP ports, DNS records, SSL certificates and domain expiry. This MCP server lets your agent create and update checks, build dashboards and publish them as status pages, set up notification groups, and read incidents with their causes, uptime, run history and latency. Browser sign-in, no API key needed. Free for 15 checks, with MCP on every plan.
Connection details
https://app.pingstack.io/mcpSetup
claude mcp add pingstack --transport http https://app.pingstack.io/mcpPingstack MCP Server tools
28Read what this connection can do in its account, with no arguments. Returns the account's id and name, the permissions this connection holds (scopes), the check kinds and the fields each kind accepts with their types and limits (fields_by_kind), plan limits such as check_limit, min_interval_seconds, history_days and run_history_days (a missing or null limit means no cap), current usage including a count of checks in each status (usage.checks_by_status), active probe locations, the user's time zone, and billing guidance. It's the cheapest way to see whether anything is down and what a write would be allowed to do. Usage is a snapshot, not a reservation. features.dashboard_domains is true when public dashboards can be served on a Pingstack subdomain or custom domain, and billing.upgrade_url is null when self-service upgrades are unavailable.
List the account's checks, oldest first, 20 per page by default. Each item has the check's id, current status (up, down, late, degraded, paused or pending), status_reason (why it isn't up, from its open incident), last activity, expiry date for domain and SSL checks, configuration, notification group ids and dashboard ids. Filter by name text, kind, or one or several statuses; filters combine, and no match returns an empty list. This shows current state only, not history or incidents. A website check's url leaves out any query string and credentials; url_has_query says whether it has one. Heartbeat ping URLs are never included. next_cursor is null on the last page.
Read one check by id: its current status, status_reason (why it isn't up, from its open incident, or null), last activity, expiry date for domain and SSL checks, configuration for its kind, probe locations for website and TCP checks, notification group ids and dashboard ids. A website check's url leaves out any query string and credentials; url_has_query says whether it has one. This is the check's current state and settings only: run history, incidents and heartbeat ping URLs aren't included. An id that doesn't exist or belongs to another account returns not_found.
Read one check's history as one row per calendar day, oldest day first: the date, how many runs were recorded (run_count), the mean response time in milliseconds (average_duration_ms, null for heartbeat, domain and SSL checks and for days with no measurement) and how many incidents started that day (incident_count). It's the summary to use for trends over weeks or months; it has no individual runs or percentiles. days is 7, 14, 30, 90 or 365 and defaults to 30; asking for more than the plan's limits.history_days returns quota_exceeded. An unknown check id returns not_found. time_zone (an IANA name) sets where each day starts and ends; the default is UTC, and the response names its zone along with the window's start_at and end_at.
List one check's individual runs inside a window, oldest first, 20 per page: each run's id, when it was received (received_at), how long it took in milliseconds (duration_ms, null when no time was measured) and the probe_id or resolver_id it came from. A run is one heartbeat received or one probe or lookup made. It shows exactly when a check ran and which probe or resolver each run came from; daily totals and latency percentiles are separate reads. days is 7, 14, 30 or 90 and defaults to 30; asking for more than the plan's limits.run_history_days returns quota_exceeded. An unknown check id returns not_found. Request payloads, source IPs and credentials are never returned. time_zone (an IANA name) sets the zone for the window and timestamps; the default is UTC, and the response names its zone. next_cursor is null on the last page.
Read recorded latency counts, min, mean, p50, p95 and max for 7, 14, 30 or 90 calendar days, up to the plan's limits.run_history_days. probe_id or resolver_id narrows the result to one source. Not an availability estimate. time_zone (an IANA name) sets the zone for days and timestamps; the default is UTC, and responses name their zone.
Read one check's uptime over a rolling window: the window's length in seconds (window_seconds), the time spent in incidents (downtime_seconds) and uptime_percentage, which is the incident-free share of the window. The window starts at the check's creation when the check is newer than the period asked for, and uptime_percentage is null until the check has a run or an incident. Time spent paused or pending isn't known and counts as up, so this is incident-free time, not verified availability. days is 7, 14, 30, 90 or 365 and defaults to 30; asking for more than the plan's limits.history_days returns quota_exceeded. An unknown check id returns not_found. time_zone (an IANA name) sets the zone for timestamps; the default is UTC, and the response names its zone.
List incidents across the account's checks that are still open or were resolved in the last 7 or 30 days (30 by default), newest first, 20 per page. Each item has the incident id, check id and name, cause (what failed, such as an HTTP status or a missed heartbeat; null when none was recorded), started_at, resolved_at (null while open), resolved and duration_seconds, which counts up to now for open incidents. Filter by one check or by open or resolved state. Notes, status updates and notification details aren't included. next_cursor is null on the last page.
Read one incident by id: its check id and name, cause (what failed, or null when none was recorded), when it started and resolved (null while open), whether it's resolved, and its duration in seconds, counted up to now while open. Notes, status updates and notification details aren't included.
List the account's notification groups, the recipients a check alerts when it fails or recovers, oldest first, 20 per page. Each item has the group id, name, user_ids (account members alerted directly), roster_ids (on-call rosters), check_count, delivery_configured (true when the group has at least one channel, member or roster) and channels_awaiting_confirmation. Channel addresses and delivery credentials aren't included. next_cursor is null on the last page. channels_awaiting_confirmation counts email channels that get no alerts until someone at the address confirms it in the app's confirmation email.
List the account's on-call rosters, oldest first, 20 per page. Each item has the roster id, name and the user ids of its members. A roster is a named set of people that notification groups can alert together. There are no filters, and an account with no rosters returns an empty list. Rosters are created and edited in the app. next_cursor is null on the last page.
List the people on the account, 20 per page. Each item has the user id, name, email address, role (admin, editor, billing or viewer) and whether they own the account. Only current members appear; pending invitations don't. next_cursor is null on the last page.
Create a notification group: a named set of recipients that checks alert when they fail or recover. Members and rosters must already belong to the account; nobody is invited or emailed. New members are alerted at all hours. Channels such as email, Slack or SMS aren't added here. A name already in use returns validation_failed and nothing is created. Returns the group with its user_ids, roster_ids and check_count.
Rename a notification group or change who it alerts. user_ids and roster_ids each replace the whole list when sent and are left alone when omitted; people who stay keep their alert schedule. Members must already belong to the account. Channels aren't changed. Returns the updated group.
Add one notification group to several checks at once, by a list of up to 100 check ids or by every check on a dashboard. Each check keeps its other groups, and checks that already have the group are unchanged. A dashboard with more than 100 checks returns invalid_arguments. Returns the check ids covered and how many gained the group.
Add a section to a custom dashboard. Sections are the headings that organize a dashboard's checks, on the dashboard and on its status page; dashboard results list them as groups. The new section is empty and goes last. A name already used on the dashboard returns validation_failed. On a public dashboard the change shows on its status page right away. Overview can't be changed.
Rename a section of a custom dashboard, or set which checks it holds. check_ids lists the section's checks in display order; each must already be on the dashboard, checks listed move into the section, and checks left out move outside any section. Checks stay on the dashboard either way. Returns the section with its checks in order.
List the account's dashboards, including the built-in Overview, oldest first, 20 per page. Each item has the dashboard id, name, assignable (false for Overview, which always shows every check and can't be changed) and public. It's a directory of dashboards: the checks, sections and display settings of each one aren't included. public_url and public_wallboard_url are the links anyone can open, set only while the dashboard is public; otherwise both are null. domain_url and domain_wallboard_url are set when a public dashboard is also served on its own verified subdomain or custom domain. An account always has at least Overview. next_cursor is null on the last page.
Read one dashboard by id, Overview included: its name, display settings, whether it's public and editable, its sections (listed as groups, in display order, up to 100) and its checks. Checks come 20 per page in display order, each with its full details, its position and the id of its section, and next_cursor is null on the last page. This is the way to see what a dashboard holds; a list of dashboards gives only names and links. An id that doesn't exist or belongs to another account returns not_found. public_url and public_wallboard_url are unauthenticated sharing links, set only for already-public dashboards; otherwise both are null. domain_url and domain_wallboard_url are set when the public dashboard is also served on its own verified subdomain or custom domain. Does not add domains.
Create a private custom dashboard, optionally with up to 100 checks already on it. Requires an idempotency key; repeating the call with the same key returns the first dashboard. A plan limit returns quota_exceeded and nothing is created. The new dashboard is private until it's published. Returns the dashboard's id, name and display settings.
Change a custom dashboard's name or display settings and return the updated dashboard. Only the settings sent change; the rest keep their values. It doesn't touch the dashboard's checks or sections, and it doesn't publish or unpublish. On a public dashboard the change shows on its status page right away. Overview can't be edited, and its id returns not_found, as does an unknown id. A setting the dashboard doesn't have returns invalid_arguments naming it, and a name another dashboard uses returns validation_failed; neither changes anything. Returns the dashboard's id, name, settings, whether it's public and its public links.
Create a supported check. Requires an idempotency key. Assigning notification groups or dashboards needs their own permissions. Website and TCP checks run from the account's default probe location unless probe_locations lists region ids such as us-east-1. A plan limit returns quota_exceeded with the limit and, when available, a billing upgrade URL; nothing is created.
Change fields of an existing check by id and return the updated check. Only the fields sent change, and they must be ones the check's kind accepts; the kind itself can't change. notification_group_ids replaces the check's groups and needs the notification_groups:assign permission. For website and TCP checks, probe_locations replaces the whole set of region ids the check runs from. Values the check can't save return validation_failed, and a plan limit returns quota_exceeded with the limit and, when available, a billing upgrade URL; in both cases nothing changes.
Add one check, or up to 100 at once, to a custom dashboard, outside any section. Checks already there are unchanged. Overview isn't a custom dashboard; it always shows every check.
Remove a check from a custom dashboard, and from its status page when the dashboard is public. The check itself and its other dashboards are unchanged, and removing a check that isn't there changes nothing.
Set the display order of the checks in one section of a custom dashboard, or of its checks outside any section when group_id is omitted. check_ids must list every check in that section exactly once, first to last; a missing, extra or repeated id returns invalid_arguments and nothing changes. Checks stay in their sections, and public dashboards and Overview can't be reordered. Returns the dashboard id and the new order.
Make a custom dashboard public as a status page. Anyone with the link can then see its checks' names and statuses, and its incident history when that setting is on; no sign-in is needed. Only account admins can publish. Publishing an already public dashboard changes nothing, and Overview can't be published. Returns the dashboard with public_url and public_wallboard_url, plus domain_url when it's served on its own domain.
Post a status update on an incident, as the person who approved this connection. The text appears in the incident's timeline in the app and, when the incident's check is on a public dashboard that shows incident history, on that status page right away. Updates can't be edited or deleted here, and each call adds a new one. Doesn't open, resolve or change the incident. Returns the update's id, text, author and time.
Overview
Pingstack tells you when a scheduled job doesn't run, a site goes down, or a certificate or domain is about to expire. Its MCP server lets Claude Code, GitHub Copilot and other MCP clients work with your monitoring directly.
Ask your agent to add a heartbeat check for the job it just wrote, with the right cron schedule, time zone and grace period. Ask which checks had incidents last week, what caused them and how long they were down. Ask it to build a dashboard for a client, publish it as a status page and set up who gets alerted.
What your agent can do
- Create and update heartbeat, website, TCP, DNS, SSL certificate and domain checks
- Build dashboards, organize them into sections and publish them as status pages
- Create notification groups from people on your account and assign them to checks, one at a time or a whole dashboard at once
- List incidents with their causes and post incident updates
- Read uptime and daily history for up to a year, and run history and latency for up to 90 days, in your own time zone and within your plan's history
- See why a check is down, when it last ran and when a certificate or domain expires
- Read your plan's limits and usage
The server has 35 tools. 28 are listed here. The other seven appear only when you turn their permission on.
Off unless you turn them on
- Retrieve heartbeat ping URLs
- Pause and resume checks
- Delete checks, dashboards and notification groups
- Unpublish a status page
These permissions start unticked when you approve a connection. A connection can delete 10 items a minute, and the account owner gets an email listing what was deleted.
What it can't do
Invite people, add notification channels such as email, Slack or SMS, send test alerts, manage custom domains, manage your account, or buy anything. It works within the approving user's role and the plan's limits. At a plan limit it returns an upgrade link for a person to open.
Sign-in
OAuth in the browser. An Owner or Admin approves the connection and picks its permissions. Publishing a status page needs an Admin. Clients without browser sign-in can use an API key (Authorization: Bearer psa_...).
Setup
Claude Code:
claude mcp add --transport http pingstack https://app.pingstack.io/mcp
Other clients:
{
"mcpServers": {
"pingstack": {
"type": "http",
"url": "https://app.pingstack.io/mcp"
}
}
}
Setup for claude.ai, Claude Desktop, VS Code, Cursor, Codex, Copilot CLI, Gemini CLI and Antigravity: https://docs.pingstack.io/mcp/clients/
Example prompts
- Add a daily heartbeat for the backup job with a 15 minute grace period and attach it to the Infrastructure dashboard.
- Which checks had incidents in the last 7 days, what caused them, and how long were they down?
- Create a dashboard for the Northstar client with their checks, and a notification group that alerts Alex and me for all of them.
- Create website checks for every domain in this README.
- What's the p95 latency for the API check over the last 30 days?
Links
- Docs: https://docs.pingstack.io/mcp/overview/
- Tool reference: https://docs.pingstack.io/mcp/tools/
- Pricing: https://pingstack.io/pricing/ (free for 15 checks, with MCP on every plan)
- Privacy: https://pingstack.io/privacy-policy/
- Support: support@pingstack.io
Frequently asked questions
How do I connect to the Pingstack MCP server?
Add the endpoint https://app.pingstack.io/mcp to any MCP-compatible client such as Claude Code, Cursor, or VS Code. The setup snippets on this page configure each client in one step.
Does the Pingstack MCP server require authentication?
Yes. Pingstack uses OAuth: the first time you connect, your MCP client opens a browser window to sign in and authorize access, then reuses the credentials for future sessions.
Which transport does the Pingstack MCP server use?
Pingstack exposes a Streamable HTTP endpoint, the transport used by remote MCP servers and supported by all major MCP clients.
More remote MCP servers
ARVX
ARVX™ reads client relationship health using the science of why partnerships last. It models two people, factors in what's influencing each of them, and reads their relationship across five areas, with what moved since t
AIsa
AIsa is one key for 950+ data APIs across SEO and AI visibility, finance, social, web search, sales and agent mail — the go-to-market data stack behind prospecting, competitor research and brand monitoring. Five tools ra
9apes
The 9apes MCP server lets an AI assistant read the GitHub Actions data 9apes already collects for your organization: runs, jobs, steps, and their durations. Ask it why a build got slower, which jobs take the longest, or
A
AI-Ready Webpage Extractor (Apify)
Convert web pages to clean Markdown and retrieval-ready chunks with browser rendering support.
A
AccountHub
One MCP connection for all your Gmail, Google Calendar, Drive and Contacts accounts, Slack workspaces and Notion — free.
Comments