LastPing

Overview Schema Source Related Servers Discussions Admin

Create API key

create_api_key

Creates a LastPing API key with a defined scope and optional expiry; the plaintext key appears only once, so copy and store it immediately.

Instructions

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.

Input Schema

TableJSON Schema

Name	Required	Description
`name`	Yes	Label for the key, e.g. "github-actions".
`scope`	No	What the new key may do. "read" is every GET; "write" (the default) is everything except managing API keys, so a key at that tier cannot mint itself a replacement; "admin" is everything. A scope above the creating key's is refused, and the refusal names the ceiling. "ingest" only sends pings and telemetry (traces, metrics, logs) and cannot call the REST API, for a key kept in a dotfile or an exporter's config.
`check_id`	No	Only with scope "ingest": binds the key to this one monitor (UUID from list_monitors), so it sends telemetry for that monitor alone. An exporter that cannot name its monitor, such as Codex, needs it.
`expires_at`	No	Optional RFC 3339 expiry, e.g. "2026-12-31T00:00:00Z". Omitted: 90 days. Either way it is capped at the creating key's own expiry.

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedv0.1.17Oct 7, 2026

changedInput schema / properties / check_id / description

Previous value: -"Only with scope \"ingest\": binds the key to this one monitor (UUID from list_monitors), so it can send telemetry for that monitor and nothing else. Required for an exporter that cannot name its monitor, such as Codex."New value: +"Only with scope \"ingest\": binds the key to this one monitor (UUID from list_monitors), so it sends telemetry for that monitor alone. An exporter that cannot name its monitor, such as Codex, needs it."

changedInput schema / properties / expires_at / description

Previous value: -"Optional RFC 3339 expiry, e.g. \"2026-12-31T00:00:00Z\". Omit for a 90-day key, capped at the creating key's own expiry. A key can never be given a longer life than the key that creates it."New value: +"Optional RFC 3339 expiry, e.g. \"2026-12-31T00:00:00Z\". Omitted: 90 days. Either way it is capped at the creating key's own expiry."

changedInput schema / properties / scope / description

Previous value: -"What the new key may do. \"read\" is every GET; \"write\" is everything except managing API keys; \"admin\" is everything, key management included. Omit for \"write\", which is the right tier for a credential handed to a job or an agent: it can do the work and cannot mint itself a replacement. A key can never be given a HIGHER scope than the key that creates it; asking for one is refused and the refusal names the ceiling. \"ingest\" can only send pings and telemetry (traces, metrics, logs) and cannot call the REST API at all: use it for a key that lives in a dotfile or an exporter's config. This tool needs an admin key; with a write key, use create_ingest_key, which mints a tracing key bound to one monitor."New value: +"What the new key may do. \"read\" is every GET; \"write\" (the default) is everything except managing API keys, so a key at that tier cannot mint itself a replacement; \"admin\" is everything. A scope above the creating key's is refused, and the refusal names the ceiling. \"ingest\" only sends pings and telemetry (traces, metrics, logs) and cannot call the REST API, for a key kept in a dotfile or an exporter's config."

Changed4 schema fields changedv0.1.6Sep 26, 2026

addedInput schema / properties / check_id

Added value: +{
+  "description": "Only with scope \"ingest\": binds the key to this one monitor (UUID from list_monitors), so it can send telemetry for that monitor and nothing else. Required for an exporter that cannot name its monitor, such as Codex.",
+  "type": "string"
+}

changedInput schema / properties / expires_at / description

Previous value: -"Optional RFC 3339 expiry, e.g. \"2026-12-31T00:00:00Z\". Omit for a key that never expires. A key can never be given a longer life than the key that creates it."New value: +"Optional RFC 3339 expiry, e.g. \"2026-12-31T00:00:00Z\". Omit for a 90-day key, capped at the creating key's own expiry. A key can never be given a longer life than the key that creates it."

changedInput schema / properties / scope / description

Previous value: -"What the new key may do. \"read\" is every GET; \"write\" is everything except managing API keys; \"admin\" is everything, key management included. Omit for \"write\", which is the right tier for a credential handed to a job or an agent: it can do the work and cannot mint itself a replacement. A key can never be given a HIGHER scope than the key that creates it; asking for one is refused and the refusal names the ceiling."New value: +"What the new key may do. \"read\" is every GET; \"write\" is everything except managing API keys; \"admin\" is everything, key management included. Omit for \"write\", which is the right tier for a credential handed to a job or an agent: it can do the work and cannot mint itself a replacement. A key can never be given a HIGHER scope than the key that creates it; asking for one is refused and the refusal names the ceiling. \"ingest\" can only send pings and telemetry (traces, metrics, logs) and cannot call the REST API at all: use it for a key that lives in a dotfile or an exporter's config. This tool needs an admin key; with a write key, use create_ingest_key, which mints a tracing key bound to one monitor."

changedInput schema / properties / scope / enum

Previous value: -[
-  "read",
-  "write",
-  "admin"
-]New value: +[
+  "read",
+  "write",
+  "admin",
+  "ingest"
+]

Changed2 schema fields changedv0.1.3Sep 12, 2026

changedInput schema / properties / expires_at / description

Previous value: -"Optional RFC 3339 expiry, e.g. \"2026-12-31T00:00:00Z\". Omit for a key that never expires."New value: +"Optional RFC 3339 expiry, e.g. \"2026-12-31T00:00:00Z\". Omit for a key that never expires. A key can never be given a longer life than the key that creates it."

addedInput schema / properties / scope

Added value: +{
+  "description": "What the new key may do. \"read\" is every GET; \"write\" is everything except managing API keys; \"admin\" is everything, key management included. Omit for \"write\", which is the right tier for a credential handed to a job or an agent: it can do the work and cannot mint itself a replacement. A key can never be given a HIGHER scope than the key that creates it; asking for one is refused and the refusal names the ceiling.",
+  "enum": [
+    "read",
+    "write",
+    "admin"
+  ],
+  "type": "string"
+}

First observedSep 6, 2026

TDQS

A4.7/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations only cover the safe-write profile (destructive=false, idempotent=false); the description goes well beyond them by disclosing that the plaintext key is shown once and is unrecoverable, that expires_at defaults to 90 days and is capped at the creating key's expiry, and that a scope above the creating key's is refused with the ceiling named in the error.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Four short sentences, front-loaded with the scope prerequisite followed by behavior and the alternative route. Every sentence carries a distinct fact (permission, effect, one-time secret, routing), with no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, so the description carries the return-value burden and does so by explaining that the plaintext key appears only in this result. Combined with the scope precondition, expiry defaults and sibling routing, an agent has everything needed to call this correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents name, scope, check_id and expires_at in depth (including the 90-day default, the expiry cap, and the ingest/check_id binding). The description largely restates that ("expires_at makes a short-lived key"), adding little semantic meaning the agent could not read from the schema, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ("Creates an API key") and immediately differentiates it from the sibling create_ingest_key, which mints a narrower single-monitor key. An agent can pick between the two credential-creation tools without opening either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

"Requires the admin scope or higher" sets the precondition up front, and the closing sentence names the alternative (create_ingest_key) plus the condition that selects it (only the write scope, single-monitor tracing). That is explicit when-to-use and when-to-use-something-else guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Create API key

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools