Skip to content
Agentmart
Submit a tool

LastPing

AI agent monitoring: alerts when your agents fail, stall or need you

Connector by lastping.devOfficial · Domain verified by the MCP Registry

IndexedMITRemote (HTTP)★ 3
Write a review

Chalk Labs

Need help deploying LastPing?

Chalk Labs sets up agents like this inside real teams: connected to your tools, tested on your data, with a human in the loop where it matters.

Book a call

Install

Works with Claude Code, VS Code, Cursor, Windsurf. Read the repository before you give any tool access to your data.

npx agentmarket install connector/lastping-dev-lastping

Asks which of your tools to add it to (Claude Code, Codex, Cursor, VS Code, Windsurf, Gemini CLI, Claude Desktop) and shows the change first. See https://agentmart.dev/cli.

Remote endpoint

  • https://mcp.lastping.dev/mcp Remote (HTTP)

Get the weekly diff

The weekly diff: one email a week with new agent tools, notable updates and grade changes, plus security alerts for tools you follow. Double opt-in, one-click unsubscribe.

We use your email only for this newsletter. Privacy

About

AI agent monitoring: alerts when your agents fail, stall or need you

No reviews yet. Installed it? Reviews come from verified installers only. How reviews work

Permissions

What this server can do and what it asks for, from its tool list and install config. Checked Oct 25, 2026.

Tools
27 read · 16 write · 6 delete · 1 not yet classified
Secrets
1 (API keys, tokens or passwords)
Install scripts
Nothing to install (hosted)
Runs as
Hosted (remote endpoint)

Tools by what they do 50

Read from the source code; the running server may list different tools.

Read 27 · Look things up without changing anything.

  • adopt_discovered_agent
  • discover_monitors_reconcile
  • get_agent
  • get_agent_dependencies
  • get_agent_usage
  • get_alert_templates
  • get_incident
  • get_monitor
  • get_ping_instructions
  • get_run
  • get_run_history
  • get_trace_diagnostics
Show 15 more tools
  • get_trace_setup
  • list_agents
  • list_api_keys
  • list_deliveries
  • list_dependencies
  • list_destinations
  • list_discovered_agents
  • list_incidents
  • list_monitors
  • list_open_incidents
  • list_runs
  • list_status_pages
  • pause_monitor
  • resume_monitor
  • snooze_monitor

Write 16 · Create, change, send or run things.

  • add_incident_note
  • create_api_key
  • create_destination
  • create_ingest_key
  • create_monitor
  • create_status_page
  • declare_run_expectations
  • regenerate_api_key
  • register_agent
  • set_alert_template
  • set_route
  • test_destination
Show 4 more tools
  • update_agent
  • update_destination
  • update_monitor
  • update_status_page

Delete 6 · Delete, drop, revoke or wipe things.

  • delete_agent
  • delete_destination
  • delete_monitor
  • delete_route
  • delete_status_page
  • revoke_api_key

Not yet classified 1 · We could not tell from the name and description.

  • export_terraform

Secrets and settings it asks for

Secrets: values you paste in that let it act as you.

  • Authorization

Network hosts it talks to 1

  • mcp.lastping.dev · found in remote endpoint, install command

Tools (50)

Read from the source code; the running server may differ. Descriptions are the server’s own words; hidden characters are shown as [U+…].

  • add_incident_note

    Description is built at runtime.

  • adopt_discovered_agent

    Description is built at runtime.

  • create_api_key

    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

    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

    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

    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

    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

    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

    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

    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

    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

    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

    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

    Description is built at runtime.

  • export_terraform

    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.

Show 35 more tools
  • get_agent

    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

    Description is built at runtime.

  • get_agent_usage

    Description is built at runtime.

  • get_alert_templates

    Description is built at runtime.

  • get_incident

    Gets one incident and its ordered timeline: run_started, step, run_failed/cancelled/blocked, incident_opened, recovery_ping, incident_resolved, alert_delivered/failed/suppressed/pending, note. run_* events match the opening run id. incident_opened carries body_excerpt and exit_code from the ping that opened it when no run event does, so a ping with no run id shows its output. A missing field means not recorded. Alert error text is omitted. `untrusted_fields` names the `data` fields LastPing did not write (job output, exporter data or user-supplied names).

  • get_monitor

    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. A hook-fed parent's repos lists each repository's monitor with state, last run and 24-hour spend; a repository's monitor has parent_monitor_id and repo.

  • get_ping_instructions

    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 ant…

  • get_run

    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…

  • get_run_history

    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

    Description is built at runtime.

  • get_trace_setup

    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

    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

    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. A read or write API key gets 403 here; an admin API key works.

  • list_deliveries

    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 (event, destination) outcome: pending (in flight), delivered, dead (attempt ceiling reached) or suppressed (not sent: the destination's rate cap, or a blocked run answered within the hold; last_error says which). Covers 30 days, newest page only. `untrusted_fields` names the `data` fields LastPing did not write (job output, exporter data or user-supplied names).

  • list_dependencies

    Description is built at runtime.

  • list_destinations

    Description is built at runtime.

  • list_discovered_agents

    Description is built at runtime.

  • list_incidents

    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

    Lists every monitor in the project with id, name, slug, status and ping_url. tag narrows the list to monitors carrying one tag. A repository's monitor, which LastPing creates under a hook-fed agent monitor for each git repository its runs come from, carries parent_monitor_id and repo, so a failing repository can be named; split_by_repo is the parent's switch.

  • list_open_incidents

    Description is built at runtime.

  • list_runs

    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 en…

  • list_status_pages

    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

    Pauses a monitor (paused=true): it still receives pings but raises no alert.

  • regenerate_api_key

    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

    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

    Resumes a paused monitor (paused=false); alerting resumes from the next missed ping.

  • revoke_api_key

    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

    Description is built at runtime.

  • set_route

    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

    Description is built at runtime.

  • test_destination

    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

    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

    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

    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

    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.

Signals

Stars
3
Forks
0
Open issues
0
Last commit
Oct 20, 2026 (10 days ago)
Last release
Oct 20, 2026 (10 days ago)

From GitHub (fetched Oct 24, 2026).

Details

Registry name
dev.lastping/lastping
Version
0.2.2
Auth
Bearer token
License
MIT
First seen
Oct 24, 2026
Last checked
Oct 24, 2026

Done for you

Rather not set it up yourself?

Chalk Labs scopes, builds and runs agents for your team: the task audit, the eval harness, the integrations and the weekly ops report. Fixed scope, priced before we start.

See how we build AI agents →Read the case studies

Chalk Labs is a two-founder AI and growth studio. We build AI agents, CRMs and MVPs for Web3 and AI companies, and have shipped 50+ product and token launches.

launches shipped
50+
launches shipped
media placements
500+
media placements
founders on every account
2
founders on every account

Press we've placed: Forbes · CoinDesk · Decrypt · Cointelegraph · The Block

Rahil Jain, Co-founder, Chalk Labs. Ex-Goldman Sachs engineer. You talk to the person who builds it.

Get LastPing running in your business

Tell us what you want to automate. A founder replies within one working day with a plan, not a pitch deck.

Goes to the Chalk Labs founders, not the newsletter. Privacy

Need help deploying LastPing?

CallGet help
Cite this page

LastPing MCP server. Agent Mart. https://agentmart.dev/connectors/lastping-dev-lastping (last updated 2026-10-24)