Skip to main content
Glama

~Alter Identity

by com.truealter

Resolve a ~handle

alter_resolve_handle
Read-onlyIdempotent

Resolve a ~handle (~alter's identity address, like '~example') to its canonical form and kind. Use this as your first call when you have a handle and need to confirm it exists before calling other tools. Returns canonical handle, kind (system/personal/role_alias), and addressability. Never returns PII; use verify_identity for that. Free L0, no authentication required.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
queryYesHandle to resolve. Accepts '~example', 'example', '~Example', etc. Case-insensitive. Max 64 chars.

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive. The description adds valuable behavioral context: it returns canonical handle, kind, and addressability; never returns PII; and is free with no authentication required. This goes beyond the safe-read declaration to clarify scope and limitations.

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 a tight paragraph that front-loads the primary action, then gives usage, return values, exclusions, and cost/auth in sequence. Every sentence earns its place with no redundancy.

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?

Given the tool's simplicity (one parameter, no output schema), the description covers all essential context: what it returns, when to use it, what it doesn't return, and prerequisites (none). The sibling tool list and annotations are also aligned, so no further clarification needed.

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?

The schema has one parameter 'query' with a full description (100% coverage), so the baseline is 3. The description doesn't add additional parameter syntax details beyond the schema, but it does contextualize the handle format. However, the schema already covers case-insensitivity and max length, so no extra value.

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 tool resolves a ~handle to its canonical form and kind, with a specific verb and resource. It also distinguishes itself by noting that verify_identity is for PII, positioning this tool for existence confirmation rather than identity details.

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 explicitly instructs to use this as the first call when you have a handle and need to confirm existence before other tools. It also provides an exclusion: never returns PII, use verify_identity for that, giving a clear alternative.

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