Skip to main content
Glama

LastPing

by dev.lastping

register_agent

Destructive

Register a new autonomous agent in the project's agent registry, returning its id, slug and wire-up instructions in one call — so an agent can go from nothing to reporting in a single conversation. Call this ONCE per autonomous worker, not once per monitor. ATTACHMENT RULE: after registering, attach monitors to this agent by passing the returned agent_id (its id OR its slug) to create_monitor's agent_id parameter. Naming an agent that does not exist is an error (400 UNKNOWN_AGENT) — it is NEVER an implicit create, so re-running this tool with the same name is the only way to get a new agent_id to attach to. Re-registering with the same name is safe: the API derives a stable slug from name and rejects a duplicate slug rather than creating a second row.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYesHuman-readable agent name, e.g. 'Deploy Bot'. Used to derive the agent's slug.
descriptionNoOptional free-text description of what this agent does. Omit for none.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observed

TDQS

A4.1/5.0
Behavior1/5

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

Annotation Contradiction: The annotations declare destructiveHint=true, but the description explicitly frames re-registration as 'safe', states that the API 'rejects a duplicate slug rather than creating a second row', and describes only additive registration behavior with no mention of destructive effects. This directly conflicts with the destructive hint and undermines the agent's ability to reason about safety.

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?

The description is longer than average, but every sentence earns its place: purpose, usage frequency, attachment rule, error handling, and idempotence behavior are all packed in without repetition. The most important information is front-loaded.

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?

Despite lacking an output schema, the description states what is returned (id, slug, wire-up instructions), how to use it, what to do on re-registration, and the exact failure mode. An agent has sufficient information to call this tool and integrate it with the surrounding workflow.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3. The description goes beyond the schema by explaining that name is used to derive a stable slug, that duplicate slugs are rejected, and that the returned agent_id or slug can be passed to create_monitor. This adds meaningful behavioral context for both parameters.

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 uses a specific verb ('Register'), names the resource ('project's agent registry'), and states the return values ('id, slug and wire-up instructions'). It is clearly distinguishable from sibling tools like create_monitor and delete_agent.

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?

The description explicitly says when to call it ('ONCE per autonomous worker, not once per monitor'), how to use the result with create_monitor, and what re-registering with the same name does. It also warns against the implicit-create misconception and gives the error behavior, leaving no ambiguity about when this tool is appropriate.

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

All LastPing toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.7/5.0
Disambiguation4/5

Tools are organized by clear resource domains, and the long descriptions carefully separate similar reads. The main ambiguity is create_monitor's upsert behavior overlapping with update_monitor, and list_incidents vs list_open_incidents could be confused from names alone.

Naming Consistency4/5

Almost every tool uses verb_noun snake_case with a consistent CRUD vocabulary like create_, list_, get_, update_, and delete_. Minor deviations exist: get_alert_templates is really a list operation, and discover_monitors_reconcile is an awkward verb-object-verb construction.

Tool Count2/5

Thirty-six tools is a heavy surface for an agent to navigate, even for a full monitoring platform. Most tools are individually purposeful, but the count exceeds the range where an agent can quickly scan and select, and the set would be easier to handle if split across domains.

Completeness4/5

Coverage is strong: monitors, destinations, agents, status pages, API keys, routes, alert templates, incidents, run history, discovery, and Terraform export all have read and lifecycle operations. Minor gaps remain, such as no explicit single-incident view and no acknowledgment/resolution action beyond notes, but core workflows have no dead ends.

Resources