Skip to main content
Glama

~Alter Identity

by com.truealter

Get Started with ~alter

get_started
Read-onlyIdempotent

Start here, and act on it without leaving this session. Self-registration is free and keyless: holding no ~alter key and no human account, register_autonomous_challenge then register_autonomous mint you an owner-less ~handle in two calls, free-tier queries are live the moment it returns, and that handle is earn-eligible at mint, so paid reads against it settle to the handle. This call also returns what ~alter is (identity infrastructure; your ~Alter is your owned identity record, not an agent that acts for you), the tools callable before you hold a key, an honest note that most depth is paid per query in USDC over x402 with prices read live, and the consent path that gates deep third-party data. Free L0, no authentication required.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

TDQS

A4.3/5.0
Behavior4/5

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

While annotations already declare readOnly, idempotent, and non-destructive behavior, the description adds key context: no authentication required, free tier, and the fact that the call returns specific content (identity explanation, tool list, pricing note, consent path). This goes beyond the annotations without contradicting them.

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

Conciseness2/5

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

The description is a dense, run-on paragraph that mixes agent instructions, tool output contents, and platform details. It is not well-structured or concise, making it harder to parse quickly. Breaking it into clear sentences or bullets would improve readability.

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

Completeness4/5

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

Given there is no output schema, the description carries the burden of explaining return value and usage context. It does cover the essential information: what ~alter is, tools available before a key, pricing model, and consent path. However, the messy structure slightly detracts from completeness.

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 tool has zero parameters, so schema coverage is trivially 100%. Per the baseline for 0-parameter tools, a score of 4 is appropriate; the description doesn't need to elaborate on parameters, but it does provide context about what the tool accomplishes.

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 this is the onboarding entry point ('Start here') and specifies that the call returns foundational information about ~alter, callable tools before holding a key, pricing model, and consent path. It distinguishes itself from registration and query sibling tools by positioning itself as the initial resource.

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 to start here, instructs the agent to register if it has no key (referencing register_autonomous_challenge and register_autonomous), and contrasts free L0 with paid depth, giving clear context for when to use this versus more advanced tools.

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