Skip to main content
Glama

~Alter Identity

by com.truealter

Start Self-Registration

register_autonomous_challenge
Destructive

Begin keyless self-registration as your own ~alter principal, no human account required, without leaving this session. Call this FIRST to receive a proof-of-work challenge. Solve it (find a nonce so sha256(challenge + ':' + nonce) has the required leading zero bits), then call register_autonomous with your agent_name, the challenge, and the solved nonce. The proof-of-work is a Sybil defence. Returns challenge, difficulty, expires_at, and a hint. Free L0, no authentication required.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
agent_nameNoOptional and ignored at this step; provide it now if convenient, then pass it again to register_autonomous.

TDQS

A4.7/5.0
Behavior4/5

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

The description adds significant behavioral context beyond annotations: proof-of-work mechanics, Sybil defense, free tier, no authentication required, and return fields. It does not contradict the annotations, though the destructiveHint=true annotation is not explained in the description, which is a minor gap given that the operation appears to be a challenge request.

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 compact and well-structured: three sentences, first states purpose, second gives the challenge protocol, third covers rationale and returns. Every sentence carries essential information with no redundancy, making it easy to parse quickly.

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?

With no output schema, the description explicitly lists the return values (challenge, difficulty, expires_at, hint) and explains the complete procedure and security rationale. It also notes session continuity and cost/layer ('Free L0, no authentication required'), making it fully self-contained for an agent to act.

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?

The schema already fully documents the single optional agent_name parameter (100% coverage). The description adds value by explaining that the parameter is ignored at this step and should be passed again to register_autonomous, providing useful workflow context beyond the schema.

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 clearly states the exact purpose: starting keyless self-registration as an ~alter principal. It explicitly says 'Call this FIRST to receive a proof-of-work challenge,' which distinguishes it from the sibling tool register_autonomous and defines the resource and action.

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 provides explicit usage guidance: call this first, solve the challenge, then call register_autonomous with the required inputs. It clearly differentiates the step from the alternative tool and describes the exact sequence, leaving no ambiguity.

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

All ~Alter Identity 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.6/5.0
Disambiguation3/5

Several tools have overlapping purposes: alter_verify and alter_resolve_handle both check if a handle exists, and hello_agent and get_started both serve as introductions. However, descriptions clarify the distinctive features (canonical form vs simple existence; server info vs overview), so most pairs are distinguishable.

Naming Consistency2/5

Tool names are inconsistent: some use the alter_ prefix (alter_login_status, alter_whoami), while others use bare verb_noun forms (describe_traits, get_network_stats). Verbs vary across describe, get, hello, list, recommend, and register, making the set feel disjointed and unpredictable.

Tool Count4/5

With 14 tools, the count is within the ideal range for an identity infrastructure server. There are a few redundant tools (hello_agent vs get_started, verify vs resolve), but overall the surface is reasonably scoped without being overwhelming.

Completeness2/5

The server covers registration, existence checks, and reference data, but lacks any tool for querying identity fields (despite describe_competencies and describe_traits hinting at query_field). There are also no update or delete operations for identities or presence, leaving significant gaps for common workflows.

Resources