Skip to main content
Glama
tp322d

LastPing

by tp322d
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Go
Hybrid

create_api_key

Create a new LastPing API key with custom scope and expiry. Admin access required; plaintext key is shown once only, so save it immediately in a secret manager. For tracing-only keys, use create_ingest_key instead.

Instructions

Requires an API key with the admin scope or higher. Create a new LastPing API key. The plaintext key is returned ONCE and cannot be retrieved again — store it immediately in a secret manager. Set expires_at for a short-lived key. To give an exporter a tracing key for one monitor, use create_ingest_key instead: it needs only a write key.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYesLabel for the key, e.g. "github-actions".
scopeNoWhat 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.
check_idNoOnly 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.
expires_atNoOptional 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.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv0.1.6
    • 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"
+]
  2. Changed2 schema fields changedv0.1.3
    • 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"
+}
  3. First observed

TDQS

A4.7/5.0
Behavior5/5

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

With all annotations false, the description carries the full burden and handles it well: it discloses that the plaintext is returned once and cannot be retrieved again, warns to store it immediately, and notes the admin requirement. These are exactly the non-obvious behaviors an agent needs to know.

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 sentences with no filler: prerequisite, creation, one-time-secret warning, and the sibling alternative. The most critical information is front-loaded and every sentence earns its place.

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?

For a security-sensitive mutation with no output schema, the description covers prerequisites, secret handling, expiry advice, and the correct alternative tool. Combined with fully documented parameters, an agent has everything needed to invoke it 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 explains every parameter thoroughly; baseline 3 applies. The description adds only a light hint to set expires_at for short-lived keys, which is marginal beyond the schema's detailed enum and explanation.

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?

The description opens with a clear verb+resource: "Create a new LastPing API key," and the name itself is unambiguous. It also distinguishes itself from the sibling create_ingest_key by stating that tool is for exporter tracing keys, so an agent can tell them apart.

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?

It states the prerequisite (admin scope or higher), gives a security directive (store immediately in a secret manager), and explicitly routes to create_ingest_key for the exporter-with-write-key case. This is explicit when-to-use and when-not-to-use guidance.

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

Deploy Server

Other Tools