Skip to main content
Glama

abandon_registration

Abandon an orphaned agent registration when the agent token was lost before first authentication. Use the one-time recovery handle from register_agent to safely delete the never-authenticated row.

Instructions

Self-clean YOUR OWN botched (orphaned) registration when you lost the agent_token before ever authenticating — e.g. a curl/script caller truncated the register response. Authenticated by the one-time registration_recovery handle returned in the register_agent response (NOT the lost token), so it needs no auth token.

When to use: you registered but never captured/used the token, and the row is now an orphan you can't unregister (unregister needs the token you lost). NOT for a live agent that lost its token mid-session — that agent has authenticated, so this is refused; use rotate_token / relay recover instead.

Behavior: verifies the registration_recovery handle (bcrypt, name-scoped, one-time, TTL-bound) and — ONLY if the target row has NEVER authenticated (the keystone) — deletes it, bumps the auth generation, and fires an agent.unregistered webhook. The keystone is re-asserted inside the DELETE, so it can never reach a working agent (a row that authenticates between check and delete is left intact) — the safe, self-serve alternative to the operator kill endpoint. Orphans are also auto-GC'd after ~30min (never-authed + session-less + older than the orphan TTL) as a backstop.

Returns: { success, name, abandoned }. Errors (AUTH_FAILED): agent has authenticated (not an orphan), invalid/expired handle, or no such registration.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYesThe agent name whose orphaned registration to abandon.
recovery_handleYesThe one-time registration-recovery handle returned in the register_agent response (the `registration_recovery` field). Name-scoped + short-lived.
Behavior5/5

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

No annotations are provided, so the description carries full burden — and it delivers extensively. It documents the keystone (never-authenticated) safety guard, re-assertion inside DELETE, webhook firing, auth generation bump, the one-time/bcrypt/name-scoped/TTL-bound handle verification, the ~30min orphan auto-GC backstop, and the exact return shape plus AUTH_FAILED error conditions.

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

Conciseness4/5

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

Front-loaded with the purpose in the first sentence, then structured when-to-use/when-not, behavior, and returns sections. It's long but every sentence earns its place given the complex safety-critical semantics. Slightly verbose in places but well-organized with clear paragraph divisions.

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?

This is an unusually complex tool (safety-critical deletion, one-time handles, keystone guards, TTL semantics, webhook side effects) with no annotations and no output schema. The description covers all of it: prereqs, failure modes, return values, side effects, and safety guarantees. Nothing material is left undocumented.

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 coverage is 100%, so the schema already describes both parameters (name and recovery_handle) thoroughly. The description adds some context (that the handle is name-scoped, one-time, short-lived, returned in register_agent response) but mostly references what the schema already documents, maintaining the baseline.

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+resource ('abandon YOUR OWN botched/orphaned registration') and clearly defines the scope. It distinguishes itself from siblings by explaining this is for unauthenticated orphans where the agent_token was lost post-register, vs unregister_agent which needs the token, and rotate_token for mid-session token loss.

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?

Explicitly states when to use (orphaned row where token was never captured), when NOT to use (live agent that lost token mid-session, which is refused), and names explicit alternatives (rotate_token, relay recover). Also notes the operator kill endpoint as related context.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Maxlumiere/bot-relay-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server