MewCP LogoAStheTech
MCPs
Use Cases

Use cases by category

Productivity & InboxInbox, calendar, and daily flowEngineering & DevOpsShip, debug, and run on-callSales & CRMPipeline, outreach, and dealsMarketing & GrowthCampaigns, SEO, and growthSupport & SuccessTriage tickets, keep customers happyFinance & OpsClose, reconcile, and expensesCreative & ContentGenerate assets and contentPeople & HiringHiring, onboarding, and HRResearch & DataSynthesize data and insights
See all use cases
Resources
BlogsProduct updates and storiesArticlesIntegration guides and code examples
PricingDocsSign in
MewCP Logo

Infrastructure You Can Trust for Agentic Products

X

Categories

  • Productivity & Docs
  • Developer Tools
  • CRM & Sales
  • Finance & Commerce
  • Data & Analytics
  • Marketing & SEO
  • Search & Web
  • Communication
  • View All Servers →

Resources

  • Blog
  • Docs
  • Privacy Policy
  • Terms of Service

Blogs

  • View All Blogs →

Articles

  • View All Articles →
Browse Servers|Pricing|Contact

Browse by Category

Productivity & Docs

  • Gmail
  • Google Drive
  • YouTube
  • Google Calendar
  • Google People
  • Google Classroom
  • Notion
  • ClickUp
  • Figma
  • Google Tasks
  • Cal
  • Monday
  • Luma
  • Notion MCP
  • Mem MCP
  • Linear MCP
  • Calendly MCP
  • Consensus MCP
  • Craft MCP
  • Close MCP
  • Dice MCP
  • Lumin PDF MCP
  • Develop21 MCP
  • Granola MCP
  • Lucid MCP
  • Mermaid Chart MCP
  • Fireflies MCP
  • ClickUp MCP
  • Miro MCP
  • Llamaindex MCP
  • Otter MCP
  • Mobbin MCP
  • Descript MCP
  • ToDoist MCP
  • SlidesGPT MCP
  • AgileHero MCP
  • JobYap MCP
  • AccountHub MCP
  • Slicktrip MCP
  • Gemina MCP

Developer Tools

  • Gemini
  • Veo
  • ClickUp
  • Firecrawl
  • Vercel
  • Apify
  • Github
  • Chef
  • Scientific Calculator
  • Figma
  • HTTP
  • Perplexity
  • Apify MCP
  • Hugging Face Hub MCP
  • Buildkite MCP
  • Cloudflare MCP
  • Context7 MCP
  • Ahrefs MCP
  • Sentry MCP
  • Brevo Docs MCP
  • X Docs MCP
  • Jev
  • Linear MCP
  • Calendly MCP
  • Craft MCP
  • DeepWiki MCP
  • Inspo MCP
  • Kernel MCP
  • Malwarebytes MCP
  • Mermaid Chart MCP
  • Supabase MCP
  • Microsoft Learn MCP
  • Webflow MCP
  • Scalar Docs MCP
  • Oneuptime MCP
  • Redocly MCP
  • Reducto Docs MCP
  • Llamaindex Docs MCP
  • B12 MCP
  • Lucid Docs MCP
  • Airwallex Docs MCP
  • Langfuse Docs MCP
  • Glen Docs MCP
  • AgentMail
  • Gogs Docs MCP
  • Netlify MCP
  • Neon MCP
  • Minlify Admin MCP
  • Mintlify Index MCP
  • Fern Docs MCP
  • Greptile MCP
  • Statssif Docs MCP
  • Scorecard MCP
  • Railway MCP
  • Inkbox AI
  • Stele MCP
  • LastPing MCP
  • ConsentStack
  • Iubenda MCP
  • BSV.CX MCP

CRM & Sales

  • Google People
  • OneSignal MCP
  • Brevo Docs MCP
  • Brevo
  • Brevo MCP
  • Carbon Voice MCP
  • Clay MCP
  • Close MCP
  • Attio MCP
  • Clarify MCP
  • Hunter.io
  • Plain MCP
  • Modem MCP
  • Whats MCP

Finance & Commerce

  • Kite
  • Razorpay
  • Polymarket
  • Stripe
  • Binance
  • Upstox
  • Aiwyn MCP
  • Era-Context-MCP
  • Granted MCP
  • XDC AI MCP
  • Agentery MCP
  • Agent Embassy
  • Quick Commerce MCP
  • Longbridge MCP
  • Mercury MCP
  • Blockscout MCP
  • Octagon AI MCP
  • Stripe MCP
  • Taskrabbit MCP
  • SeatGeek MCP
  • Clarity AI MCP
  • Beyond Payday MCP
  • DeFade MCP

Data & Analytics

  • Apify MCP
  • Cloudflare MCP
  • Ahrefs MCP
  • Candid MCP
  • Consensus MCP
  • Contentsquare MCP
  • Era-Context-MCP
  • Instinct MCP
  • legal Data Hunter MCP
  • Marcopolo MCP
  • Mixpanel MCP
  • MOSPI MCP
  • Hex MCP
  • OpenRevenue MCP
  • Statsig MCP
  • Synthesize Bio MCP
  • PostHog MCP
  • PopHIVE MCP

Marketing & SEO

  • YouTube
  • Google Business
  • Mailchimp
  • Google Search Console
  • OneSignal MCP
  • Cloudflare MCP
  • Brevo Docs MCP
  • Brevo
  • Brevo MCP
  • AirOps MCP
  • Clay MCP
  • Contentsquare MCP
  • Reelsmith MCP
  • GoDaddy MCP
  • Metricool MCP
  • Webflow MCP
  • Windsor MCP
  • Commonroom MCP
  • B12 MCP
  • Hunter.io
  • Get MCP Ads
  • Minlify Admin MCP
  • Zernio MCP
  • Affiliatespy MCP
  • VarynForge
  • ListingGood MCP

Search & Web

  • Web Scrapper
  • Firecrawl
  • Apify
  • Perplexity
  • Context.dev
  • Exa
  • Brave Search
  • Apify MCP
  • Ahrefs MCP
  • DeepWiki MCP
  • Dice MCP
  • GoDaddy MCP
  • Granted MCP
  • Microsoft Learn MCP
  • Viator MCp
  • Scholargateway MCP
  • Parallel MCP
  • Mintlify Index MCP
  • OpenWeather MCP
  • Simplescraper MCP
  • SearchApi MCP

Communication

  • Gmail
  • Google Meet
  • Google Calendar
  • Mailchimp
  • WhatsApp
  • Slack
  • OneSignal MCP
  • Brevo Docs MCP
  • Carbon Voice MCP
  • Hunter.io
  • Outlook
  • Nylas MCP
  • Resend MCP
  • Read AI MCP
  • Whats MCP
  • Inkbox AI

© 2026 MewCP. All rights reserved.

  1. Home
  2. MCPs
  3. LastPing MCP
LastPing MCP

LastPing MCP Integration for AI Agents

LastPing enables AI agents to monitor website and API uptime, track endpoint response times, inspect incidents, and receive alerts when services become unavailable, helping developers troubleshoot outages and maintain service reliability.

v0.2.050 toolsOAuth
Open in ChatGPTChatGPT
Open in ClaudeClaude
Playground
VS CodeVS Code
Connected to LastPing MCP via MewCP.

Encrypted at rest, isolated from the model

Resolved from an AES-256-GCM vault at the moment of the call and attached to the request — the model never sees the secrets.

Try asking

Everything LastPing MCP can do

Tools50

add_incident_note

write

Requires the write scope or higher. Adds a diagnosis note to an incident; it appears on the incident's page in order, stored with author 'agent' (no author argument exists). Notes are append-only: no edit or delete exists, so a correction is a new note and the history stays evidence. Several notes per incident are normal, up to a cap of 50, and a closed incident still accepts them. A note can record a failure that was not fixed as well as one that was. Without a note, the incident page shows only the alert.

adopt_discovered_agent

write

Requires the write scope or higher. Counts a discovered trace source's traces under an agent from now on. Without agent_id, a new agent named after the source is created (409 AGENT_EXISTS when its slug is taken). With agent_id (e.g. a suggested_agent_id), the source merges into that agent. Earlier traces stay where they are (backfilled is false). Re-adopting into the same agent changes nothing; into a different one is 409 ALREADY_ADOPTED. `untrusted_fields` names the `data` fields LastPing did not write (job output, exporter data or user-supplied names).

create_api_key

write

Requires the admin scope or higher. Creates an API key. The plaintext key appears only in this result and cannot be retrieved again. expires_at makes a short-lived key. create_ingest_key, which needs only the write scope, mints a single-monitor tracing key.

create_destination

write

Requires the write scope or higher. Creates a notification destination (channel) that monitors can route alerts to, from the fields of the chosen kind; unrelated fields are ignored. Non-email kinds are usable immediately; an email destination starts unverified, sends a confirmation link, and can join a route once the link is clicked. A project holds at most 25 destinations (DESTINATION_CAP_REACHED beyond that). Returns the new channel id, which set_route takes.

create_ingest_key

write

Requires the write scope or higher. Creates a tracing key: an ingest-scoped key bound to one monitor, able to send traces, metrics, logs and pings for it and nothing else; every REST call refuses it. For automation that stores the key itself (a CI secret, a deployment's secret store). The plaintext key appears only in this result, which puts it in the conversation; the console's Create a tracing key keeps it out of chat.

create_monitor

destructive

Requires the write scope or higher. Creates a monitor, or updates the existing one when slug matches (an upsert; the result says 'updated'). Heartbeat and ci monitors take schedule_kind: 'simple' with period_s, 'cron' with cron_expr, or 'on_demand' with neither. http monitors take probe_url and probe_interval_s; probe_expected_status and probe_expected_body define a healthy response, and a probe with neither only checks that something answered. ci_provider can be set only here, and the webhook secret it returns appears only in this result.

create_status_page

write

Requires the write scope or higher. Creates a status page: one page showing the current status and recent history of a chosen set of monitors, for people who cannot log in to the project. Pages are private unless visibility is 'public', which publishes every monitor name on the page.

declare_run_expectations

write

Requires the write scope or higher. Declares, at the start of a run, the criteria its success ping body is judged by when the run closes, so the run does not grade itself: a success whose body fails any declared criterion is recorded as a failed run with cause 'assertion', whatever the exit code. One declaration per rid, immutable (a second call is a conflict). For use right after the run's /start ping; get_ping_instructions' expectations_how_to has a worked example.

delete_agent

destructive

Requires the write scope or higher. Permanently deletes an agent from the registry by UUID; cannot be undone. Its monitors are not deleted: each survives with its ping history and incidents, becomes unowned (agent_id null) and keeps running. update_monitor can attach a survivor to another agent, and delete_monitor removes a monitor.

delete_destination

destructive

Requires the write scope or higher. Permanently deletes a notification destination (channel); cannot be undone. It is removed from every monitor's routing, so an event type routed only to it stops notifying anyone, with no incident to show for it. get_monitor's `routes` shows which event types route to it, and set_route changes routing without deleting the destination.

delete_monitor

destructive

Requires the write scope or higher. Permanently deletes a monitor by UUID; this cannot be undone. Its pings, run steps, traces, incidents, routes, alert templates, assertions and delivery history are deleted with it, and the ingest keys bound to it (from create_ingest_key) are deleted too, so they stop working.

delete_route

destructive

Requires the write scope or higher. Stops routing one event type of a monitor to any destination, so its alerts for that event go nowhere; every other event type's routing is unchanged. set_route with the remaining ids drops a single destination instead. An event type with no routing answers "route not found".

delete_status_page

destructive

Requires the write scope or higher. Permanently deletes a status page; cannot be undone, and its public URL stops working immediately. The monitors on it are unaffected and keep running and alerting. update_status_page with visibility 'private' stops sharing without deleting.

discover_monitors_reconcile

write

Requires the write scope or higher. Turns a scan of a repository or host (`sources`, every scheduled job found) into monitors. Creates one monitor per source not already monitored; never deletes, pauses or edits existing monitors, so a scheduled re-run is safe drift detection. Returns `created`, `existing` (unmodified, hand-tuned values intact) and `orphaned` (source not in this scan; still running and alerting). Each created monitor can page a person; this endpoint has no delete path. source_kind plus source_ref is the diff key, so source_ref has to stay stable: a changed ref creates a duplicate; a crontab ref names the file and the command, so each line is its own source. Kinds: 'crontab' (crontab -l, /etc/cron.d/*, /etc/crontab), 'github-actions' (on.schedule.cron), 'k8s-cronjob' (spec.schedule), 'systemd-timer' (OnCalendar=). A source without schedule_cron becomes on-demand. crontab and systemd-timer fire in the host's local time (`timedatectl show -p Timezone --value` or `readlink /etc/localtime` prints it); github-actions and k8s-cronjob in UTC. A stated tz is stored as given: the API cannot tell a guessed 'UTC' from one read from the host. list_monitors shows each source.

export_terraform

read

Requires the read scope or higher. Exports existing monitors, destinations, routes, alert templates and status pages as Terraform HCL, with import blocks so they are adopted rather than recreated. Secrets are not exported; the output references Terraform variables that hold them.

get_agent

read

Requires the read scope or higher. Gets one agent by UUID, with the same fields as list_agents: its live status rollup, usage_24h and top_dependencies. `untrusted_fields` names the `data` fields LastPing did not write (job output, exporter data or user-supplied names).

get_agent_dependencies

read

Requires the read scope or higher. What one agent calls, heaviest first, from its traces: each model, tool, HTTP host, database, queue, RPC endpoint or agent: calls, errors, error_rate (0-1), p50_ms, p95_ms (bucket ceiling; p95_is_floor: over 60s), daily series, and for a model tokens, cost_usd and cost_source (client, estimated or mixed). operations: up to five span names per outgoing row, sampled from the ten newest traced runs. At most 50 rows; `more` counts the rest. `untrusted_fields` names the `data` fields LastPing did not write (job output, exporter data or user-supplied names).

get_agent_usage

read

Requires the read scope or higher. Model usage, one row per model per UTC day: tokens_in (cache reads included, so tokens_cache_read is not added to it), tokens_out, tokens_cache_read, tokens_cache_write, cost_usd (decimal text) and cost_source: client (the tool reported its cost), estimated (LastPing priced tokens at API list prices), mixed (a traced day holds both) or empty (unknown). origin is traces or metrics; a day and model can have one of each, never summed. With id, one agent's usage; without, the project's, traces only, plus by_agent (costliest first). Both carry by_project: per project (a Claude Code session's folder) its runs, tokens and cost from traced runs only (project_scope traces_only). by_project sums each run's traced totals, while one agent's days prefer a Claude Code metrics export's reported cost, so the two need not match. With project, days become one row per UTC day with model and provider empty; project narrows days and by_project, not by_agent. `untrusted_fields` names the `data` fields LastPing did not write (job output, exporter data or user-supplied names).

get_alert_templates

read

Requires the read scope or higher. Gets a monitor's custom alert message templates: a map of event-type (or event-type/cause) keys to template strings. Keys: 'down', 'recovery', 'fail', 'every-run', 'success', 'started', 'blocked', 'note', or 'event_type/cause' (e.g. 'down/silence'). An empty result means every alert uses the built-in plain-language defaults.

get_incident

read

Requires the read scope or higher. Gets one incident and its ordered timeline: run_started, step, run_failed/cancelled/blocked, incident_opened, alert_delivered/failed/suppressed/pending (destination and attempts; down and fail alerts only), note, incident_resolved. For what the run was doing, who was paged and what was tried. run_* events are matched on the run id recorded at opening, so none means no run was recorded. Delivery error text is omitted. `untrusted_fields` names the `data` fields LastPing did not write (job output, exporter data or user-supplied names).

get_monitor

read

Requires the read scope or higher. Gets one monitor by UUID with its full configuration, including `assertions` (conditions a successful run's ping body has to satisfy), `guards` (ceilings on a number the job reports) and `routes` (which destinations receive which event type); each is absent when empty. update_monitor's assertions and guards and set_route each replace a whole set, and this result holds the current sets.

get_ping_instructions

read

Requires the read scope or higher. Returns what a monitor needs in order to report: its ping URLs, copy-paste snippets (curl_success, curl_start, curl_fail, curl_step, run_example) and three reporting mechanisms, for wiring up a new monitor. `reporting_options` holds the rule for choosing between them: `how_to` is the manual protocol and works in any agent with no prerequisite (with expect_every_s, a lapse opens an incident); `hook_install` is a one-time install that automates the same protocol through hooks and alone sends every state, blocked and note included; it is returned only when `tool` is set (claude-code, codex or antigravity), otherwise `hook_install_note` says so; `run_wrapper` puts `lastping run` before a launched command (cron job, CI step, script) and reports start, success, fail and cancel. Also returned: `failure_inbox_how_to`, `expectations_how_to` (declare_run_expectations), `tracing_how_to` (OpenTelemetry, detailed by get_trace_setup), `otel_env_lines`, export lines whose key placeholder stands for the person's tracing key, and `docs_url`. An exporter that cannot set headers can POST to `<ping_url>/v1/traces`, which needs no Authorization header.

get_run

read

Requires the read scope or higher. Gets one run's full timeline: every recorded event (start, step, log, success/fail/cancel, incident_opened) in time order, its declared assertions with pass/fail/not_evaluated verdicts against the terminal ping body, the terminal output excerpt, CI metadata when present, and its OTLP spans (spans[], parents before children, siblings by start time) when traced. A current Claude Code hook's run holds its turns' traces; a prompt after an interrupt or a blocked turn continues the open run. Also carries project, receiving_spans, in_hook_session, is_test, failure_cause and upstream_error (as in list_runs). For the detail behind a run (id + rid) found elsewhere. outcome: succeeded, failed, cancelled, blocked, running or unfinished (no end ping, no incident, not blocked, older than max_runtime_s or 24h; never pages). Caps: 200 events (events_truncated; the terminal event is kept), 2,000 spans (spans_truncated, spans_dropped). A span's gen_ai block (system, model, tokens, cost_usd) is present only on GenAI calls. `untrusted_fields` names the `data` fields LastPing did not write (job output, exporter data or user-supplied names).

get_run_history

read

Requires the read scope or higher. Gets a monitor's run history from pings, CI and agent runs alike (no filters; trace-only runs are in list_runs). Each run has rid, kind, received_at, steps (seq, name, at; matched on rid), title and incident_detail. CI runs add failing_stage, actor, commit_sha, run_url, branch, duration_s and outcome. A ping with neither ci_meta nor a rid is excluded. duration_ms is LastPing's own /start-to-success timing, separate from CI's duration_s. `untrusted_fields` names the `data` fields LastPing did not write (job output, exporter data or user-supplied names).

get_trace_diagnostics

read

Requires the read scope or higher. Why traces, metrics or logs sent to one monitor did or did not arrive: the newest 20 ingest attempts (kept 7 days), last_accepted_at, and the newest traced run's summary. For checking a test span, or telemetry sent with nothing showing. Each attempt: outcome (accepted; refused: something to fix; dropped: routine, answered 202), reason, span_count, bytes, protocol, user_agent, signal. Rejections: unsupported_media_type (not http/protobuf, e.g. gRPC to the HTTP URL), body_too_large (over 1 MB), too_many_spans or too_many_records (over 500 per batch), unknown_monitor (lastping.monitor_id missing or outside the project), expired_key (a new tracing key comes from the Connect page), wrong_scope (not a tracing key), wrong_project, monitor_mismatch, over_budget/over_log_budget (daily, resets 00:00 UTC), rate_limited, busy, malformed. Refused after a 202: future_start (sender clock), too_many_series. Dropped: unknown_event, unknown_metric, cumulative_temporality, invalid_point. No row: gRPC to the gRPC port, or a missing or wrong key. `untrusted_fields` names the `data` fields LastPing did not write (job output, exporter data or user-supplied names).

get_trace_setup

read

Requires the read scope or higher. Returns the steps that make a tool send OpenTelemetry traces to one monitor: what to write and where, how to verify it, and the tool's limits. For setting up tracing, observability or telemetry. `prompt` is the full set-up procedure for the named tool, credential handling included. Each block has `files`, a `key_line` (the terminal line that stores the tracing key the person creates on the monitor's Connect page) and, for Claude Code and Codex, a reviewable `bang_script` run with `bang_command`.

list_agents

read

Requires the read scope or higher. Lists the project's agents: id, slug, name, status, monitor_count, last_seen. status is rolled up live from the agent's monitors, worst first: down, blocked (a run needs a human), late, running, up, pending (no report yet) or idle (no monitors, or all paused or in maintenance). usage_24h: model tokens and cost over 24 hours (null with no model call); top_dependencies: its five heaviest outgoing dependencies. `untrusted_fields` names the `data` fields LastPing did not write (job output, exporter data or user-supplied names).

list_api_keys

read

Requires the admin scope or higher. Lists the project's API keys without plaintext values. Each has its non-secret prefix, scope (read, write or admin), created_by_key_id (the key that minted it, absent for a dashboard key; revoking a key revokes every key below it), last_used_at and last_used_surface (mcp, terraform or api; both absent when never used). last_used_surface comes from the caller-controlled User-Agent header: a hint, not proof of identity.

list_deliveries

read

Requires the read scope or higher. Lists recent alert deliveries across the project's monitors: whether an alert fired, failed or was suppressed, and to which destination. Each row is one (incident event, destination) outcome: pending (attempt in flight), delivered, dead (per-channel attempt ceiling reached) or suppressed (the destination's rate cap dropped it). Covers 30 days and returns only the newest page; the dashboard's delivery log has the archive. `untrusted_fields` names the `data` fields LastPing did not write (job output, exporter data or user-supplied names).

list_dependencies

read

Requires the read scope or higher. Everything the project's agents call, across every agent, most calls first: each dependency with the same figures as get_agent_dependencies plus agents (which agents call it, and how often). Answers questions such as which agents call postgres or use a model. At most 50 rows; `more` counts the rest. `untrusted_fields` names the `data` fields LastPing did not write (job output, exporter data or user-supplied names).

list_destinations

read

Requires the read scope or higher. Lists the project's notification destinations (channels) of every kind (webhook, telegram, discord, slack, ntfy, pushover, msteams, googlechat, email). Their ids are what set_route takes.

list_discovered_agents

read

Requires the read scope or higher. Trace sources that sent spans but match no registered agent: id, source_name (the OpenTelemetry service.name), first and last seen, span_count, and suggested_agent_id when a registered agent's slug or name now matches. For traces that arrive while no agent shows them; adopt_discovered_agent counts a source under an agent. At most 200, most recently seen first. `untrusted_fields` names the `data` fields LastPing did not write (job output, exporter data or user-supplied names).

list_incidents

read

Requires the read scope or higher. Lists a monitor's recent incidents, newest first; an open incident has closed_at=null. `untrusted_fields` names the `data` fields LastPing did not write (job output, exporter data or user-supplied names).

list_monitors

read

Requires the read scope or higher. Lists every monitor in the project with id, name, slug, status and ping_url. tag narrows the list to monitors carrying one tag.

list_open_incidents

read

Requires the read scope or higher. Returns an agent's failure inbox: every open incident on the monitors it owns, newest first, with context no single failure body carries. For learning, at a run's start, what broke meanwhile. failure_signature.occurrences: how often this exact failure has been seen (first_seen, last_seen, fingerprint), which separates retry from escalate. failed_step: the last step reported (for 'stalled', where the live run is stuck). exit_code: 137 (usually OOM) and 1 differ. duration_vs_normal: e.g. '8.2x the typical run (41m vs 5m), from 30 archived days', plus run_ms, typical_ms, ratio, days_sampled (0: the norm is the median of 5+ recent runs). cause: 'fail' (the job reported an error), 'silence' (it never reported; usually the scheduler or host) or 'upstream' (consecutive model-provider API errors; detail names the last). Also body_excerpt, run_id, ci.run_url. A missing field is no evidence, not none, normal or a clean exit; exit_code 0 marks a success that failed its expectations. add_incident_note takes an entry's incident_id. `untrusted_fields` names the `data` fields LastPing did not write (job output, exporter data or user-supplied names).

list_runs

read

Requires the read scope or higher. Lists runs across every monitor in the project, newest started first, including runs that exist only as OpenTelemetry traces (traced: true). Each run carries check_id, check_name, rid, title, outcome, started_at, ended_at, duration_ms, step_count, exit_code, its incident, and when traced span_count, tokens, cost_usd and cost_source (client, estimated or mixed); plus agent_id, agent_name, source_name, multi_trace, project (the Claude Code session's folder), receiving_spans (spans in the last 2 minutes), in_hook_session, is_test (excluded from counts). failure_cause is 'upstream' when the run ended on the model provider's API error (pages after 3 in a row, or failure_threshold when higher; upstream_error names it) or 'assertion' when a success failed an output assertion or declared expectation. outcome: succeeded, failed, cancelled, blocked, running or unfinished (started, never ended within max_runtime_s or 24h; never pages). Filters combine and also narrow counts (per-outcome totals). Pages with next_cursor. `untrusted_fields` names the `data` fields LastPing did not write (job output, exporter data or user-supplied names).

list_status_pages

read

Requires the read scope or higher. Lists the project's status pages: id, slug, title, the monitors on each, visibility, and the public URL of any public page. A status page shows a monitor's health to people outside the project, such as customers or another team. update_status_page's check_ids replaces a page's monitor set, and this result holds the current set.

pause_monitor

write

Requires the write scope or higher. Pauses a monitor (paused=true): it still receives pings but raises no alert.

regenerate_api_key

destructive

Requires the admin scope or higher. Replaces an API key's secret: a new key, with a new id and the same name, scope and (for a tracing key) monitor. The old key stops working immediately wherever it is held, including when it is the calling key. No expiry stays no expiry; an expiring key gets a fresh 90 days, capped at the calling key's expiry. Keys the old key created keep working (no cascade). Refused (403, with max_scope) for a key scoped above the caller's. The plaintext key appears only in this result.

register_agent

write

Requires the write scope or higher. Registers an autonomous agent in the project's agent registry and returns its id, slug and wire-up steps. One agent stands for one autonomous worker, which can own many monitors: create_monitor and update_monitor attach a monitor through agent_id (the id or the slug). An agent_id that does not exist is an error (400 UNKNOWN_AGENT), never an implicit create. The slug is derived from the name, so registering the same name again is refused (409) rather than creating a second agent.

resume_monitor

write

Requires the write scope or higher. Resumes a paused monitor (paused=false); alerting resumes from the next missed ping.

revoke_api_key

destructive

Requires the admin scope or higher. Permanently revokes an API key and every key it created, recursively; all of them stop authenticating immediately. This cannot be undone; list_api_keys' created_by_key_id shows which keys a revoke reaches.

set_alert_template

destructive

Requires the write scope or higher. Sets or clears one alert message template on a monitor; every other template is kept (read-modify-write). The template is validated for allowed variables before saving, and an empty template resets that entry to the built-in default. Event types: 'down', 'recovery', 'fail', 'every-run', 'success', 'started', 'blocked', 'note'. The template argument lists the variables.

set_route

destructive

Requires the write scope or higher. Routes a monitor's alerts for one event type to a set of destinations (channels). Replaces the whole destination set for that event type: destinations not listed stop receiving it, including ones someone else configured. get_monitor's `routes` field holds the current set, so adding a destination means sending the existing ids plus the new one. An empty channel_ids removes all routing for the event. Destinations have to be verified and enabled (an email one confirmed). list_destinations returns the ids.

snooze_monitor

write

Requires the write scope or higher. Sets or clears a maintenance window on a monitor. During it, deadline incidents (a missed or never-started run, an overrun, a stall, a blocked run outliving blocked_timeout_s) and, on an HTTP monitor, failing probes (any fail there counts as a probe's) are recorded but open no incident; a site still failing afterwards opens one on its next failure. Still notified: the job's own fail ping, the page a blocked ping queues, a runaway ping rate, and routed note, started, success and every-run events. Takes exactly one of duration, until or clear=true.

test_destination

write

Requires the write scope or higher. Sends something through a destination now. By default it delivers a synthetic 'LastPing test alert', which confirms a new destination's credentials. With resend_verification=true it instead re-sends an unverified email destination's confirmation link, for when the first one never arrived or expired; an unverified email cannot join a route, and a test alert does not change that.

update_agent

destructive

Requires the write scope or higher. Updates an agent's name, description or slug by UUID with merge-patch semantics: supplied fields change, omitted ones keep their value. Renaming never changes the slug. A new slug has to be unique in the project; saved links, Terraform references and trace sources (service.name) naming the old slug then stop matching the agent unless they equal its name (case-insensitive), past traced runs included, and a slug equal to a source another agent receives takes that source's traces, past runs included. Attached monitors stay attached.

update_destination

destructive

Requires the write scope or higher. Updates a notification destination's name and/or config in place; only the supplied fields change. The kind cannot change (delete and recreate instead). A new email address resets verification and sends a new confirmation email.

update_monitor

destructive

Requires the write scope or higher. Updates a monitor by UUID with merge-patch semantics: supplied fields change, omitted fields keep their stored value. tags, assertions (conditions a successful run's ping body has to satisfy, which catch a job that exits 0 having done nothing) and guards (ceilings on a number the job reports, which catch a looping agent) each replace the whole set; get_monitor returns the current sets. slug and ci_provider are immutable; only the ci_workflow and ci_branch filters change here. clear removes a setting.

update_status_page

destructive

Requires the write scope or higher. Updates a status page's title, slug, visibility or monitor set; arguments not supplied keep their value (the tool reads the page and merges, so an omitted check_ids never blanks it). A supplied check_ids replaces the whole monitor set; list_status_pages returns the current ids. A new slug changes the public URL and breaks links already shared.

Connect LastPing MCP to your agent

One endpoint, the same key, whichever client you use.

Apps

SDKs

Claude Desktop

Claude Desktop

~/Library/Application Support/Claude/claude_desktop_config.json (Mac) · %APPDATA%\Claude\claude_desktop_config.json (Windows)

JSON
{
  "mcpServers": {
    "mewcp": {
      "command": "npx",
      "args": [
        "-y",
        "mcp-remote@latest",
        "https://gateway.mewcp.com/personal/mcp",
        "--header",
        "Authorization: Bearer API_KEY"
      ]
    }
  }
}

Replace API_KEY with your own key.

Already have an "mcpServers" section in your config? Just add the server entry inside it.

  1. 01Open Claude Desktop → Settings → Developer → "Edit Config"
  2. 02Paste the snippet inside the outer { } of the config file (merge with your existing "mcpServers" section if you have one)
  3. 03Save the file and restart Claude Desktop
  4. 04Start a new conversation — your tool will be available

One endpoint. Every service.

VS CodeAny agent
One Gateway

Firecrawl

API Key

Github

OAuth

HTTP

No auth

LastPing MCP

OAuth

Discovery, routing, credentials, tool scoping and execution logs all happen at the gateway→connections stay ACTIVE with no work from you

Separate connections░░░░░░░░░░░░░░░░░░░░░░░░░░░░121 tool definitions ~23k tokensWith MewCP░░░░░░░░░░░░░░░░░░░░░░░░░░░░4 meta-tools ~2.7k tokens

Built for AI agents

LastPing MCP runs through a gateway that holds the credentials, scopes the access and records every call.

Managed authentication

  • OAuth to LastPing MCP handled end to end, with tokens refreshed before they expire.
  • One credential per end user, not one shared key across your users.
  • Reconnect an account without touching your agent's config.

Credentials stay out of context

  • LastPing MCP credentials are resolved at the gateway and attached to the outbound call.

Ready to connect LastPing MCP?

Managed auth, hosted MCP servers, and every Gmail tool your agent needs.

Free to start.

  • The agent sees tool results, never a token.
  • Revoke an account and the next call stops working — no redeploy.
  • Scoped access, fully logged

    • Choose exactly which LastPing MCP tools an agent is allowed to call.
    • Every call is logged with its outcome, latency and which account it ran as.
    • Catalog changes are reviewed before they ship, so tool descriptions cannot shift under you.

    One endpoint for every server

    • Reach LastPing MCP through the same MCP endpoint as the rest of your toolset.
    • Tools are discovered on demand, so 50 tools do not fill the context window.
    • Stateless: no sessions to keep alive and no reconnect logic.