~alter
Server Details
Identity infrastructure for the AI economy. Verify humans, query traits, earn USDC via x402.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.5/5 across 12 of 12 tools scored. Lowest: 3.7/5.
Each tool has a clearly distinct purpose: identity verification, presence, handle resolution, authentication, registration, help, and taxonomy listing. No two tools overlap significantly.
Naming is mostly verb_noun but inconsistent: some tools are prefixed with 'alter_', others are bare verbs like 'describe_traits' or 'list_archetypes'. Mixed patterns reduce predictability but are still readable.
12 tools are well-scoped for an identity infrastructure server covering authentication, registration, resolution, and taxonomy. No bloat or inadequacy.
Core identity interactions are covered (login, resolve, verify, register, read presence). Minor gaps exist: no tool to update identity traits or manage keys beyond registration, but the domain is well-covered.
Available Tools
12 toolsalter_login_statusLogin StatusARead-onlyIdempotentInspect
Returns key validity, scopes, and expiry for the authenticated member.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds value beyond the annotations by specifying exactly what is returned (key validity, scopes, expiry) and that it is for the authenticated member. Annotations already indicate read-only and idempotent, so the description provides useful behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 11 words, front-loading the key action and resource without any wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and no output schema, the description adequately conveys the tool's purpose and outputs. It could mention the format of the return value, but it is sufficient for a simple read-only operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, and schema coverage is 100%. The description adds no parameter info since none exist, and the baseline for zero parameters is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool returns key validity, scopes, and expiry for the authenticated member. It uses a specific verb ('Returns') and resource ('key validity, scopes, and expiry'), and it distinguishes itself from sibling tools like alter_whoami by focusing on authentication credentials.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when authentication details are needed but lacks explicit guidance on when to use this tool versus alternatives. It does not mention prerequisites or when not to use it, leaving the agent to infer from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
alter_presence_readRead Public PresenceARead-onlyInspect
Read whether a ~handle is publicly 'open', the shop-front sign. Free for callers. Reports whether the handle is currently set to public/open. Returns open-or-closed only; the specific non-open state is never disclosed. The handle must have enabled public presence AND currently be in the 'open' state.
| Name | Required | Description | Default |
|---|---|---|---|
| handle | Yes | Target ~handle to read, e.g. ~blake. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint=true), the description adds that only open-or-closed is returned and the specific non-open state is never disclosed, which is valuable behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences with no redundancy, front-loading the primary action and adding necessary details efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with one parameter and good annotations, the description sufficiently covers purpose, behavior, preconditions, and output format, leaving no critical gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a clear description and example for the handle parameter. The tool description adds no additional parameter info beyond the schema, so baseline score applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads public presence (open/closed) of a ~handle, distinguishing it from siblings like alter_login_status. The verb 'Read' and resource 'public presence' are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides preconditions ('handle must have enabled public presence AND currently be in the open state') and notes it's free for callers, but does not explicitly mention when not to use or contrast with alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
alter_resolve_handleResolve a ~handleARead-onlyIdempotentInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Handle to resolve. Accepts '~example', 'example', '~Example', etc. Case-insensitive. Max 64 chars. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnly, idempotent, not destructive. Description adds context beyond annotations: it is 'Free L0, no authentication required' and never returns PII. While these are useful, the description could further clarify behavior on invalid handles or edge cases. Overall, good supplementation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, each earning its place: first defines purpose, second gives usage guidance, third details return fields, fourth clarifies limitations and alternative. No unnecessary words; front-loaded with key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 fully covers what the agent needs: input format, when to use, what to expect (canonical handle, kind, addressability), and what not to expect (PII). No gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers the single parameter 'query' with 100% coverage. Description adds semantic value by stating the handle is case-insensitive and accepts various formats ('~example', 'example', '~Example'), which aids the agent in constructing valid input beyond the schema's basic constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool resolves a ~handle to its canonical form and kind. It distinguishes from sibling tools like alter_verify by explicitly mentioning that this tool returns no PII, guiding the agent to use verify_identity for that purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to 'Use this as your first call when you have a handle and need to confirm it exists before calling other tools.' It also states what the tool does not do (return PII) and provides an alternative tool (verify_identity), giving clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
alter_verifyVerify a ~handleARead-onlyIdempotentInspect
Checks whether a ~handle exists in the ~alter identity field.
| Name | Required | Description | Default |
|---|---|---|---|
| handle | Yes | ~handle to verify (with or without leading ~). Max 64 chars. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, covering safety and idempotency. The description adds no new behavioral details (e.g., return value format, error handling) beyond stating the existence check.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no redundancy. It efficiently conveys the core purpose. Appropriate for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple nature (one required parameter, no output schema), the description is adequate but lacks explicit mention of the return type (expected boolean) or error behavior. The context of annotations compensates partially, but completeness is moderate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a clear description for the handle parameter. The tool description does not add extra meaning beyond the schema, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks existence of a ~handle in the ~alter identity field. This distinguishes it from sibling tools like alter_resolve_handle, which likely resolve to more detailed information, and alter_presence_read.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit when-to-use or alternatives. However, the simple existence check is implied, and the name suggests its primary use. No comparison to siblings is given, but the context of sibling tools provides some implicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
alter_whoamiMy IdentityARead-onlyIdempotentInspect
Returns canonical handle and user summary for the authenticated member. Optional target parameter switches the response to the institutional projection for a protocol-tier handle (today only ~alter): provenance=institutional, honest-empty trait vector, plus social_legibility when the institutional projection is available. Institutional mode is free for all callers.
| Name | Required | Description | Default |
|---|---|---|---|
| target | No | Optional ~handle to project. Today only ``~alter`` is recognised; any other value falls through to the self-projection path (which still requires member_self scope). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds transparency beyond annotations by explaining the effect of the target parameter and noting that institutional mode is free. It aligns with readOnlyHint and idempotentHint without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the main purpose, and every sentence adds value. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a single optional parameter and no output schema, the description covers behavior completely, including main return, optional mode, and access information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the description enriches the only parameter by detailing its behavior, accepted values, and fallback, going beyond the schema's brief description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it 'Returns canonical handle and user summary for the authenticated member', using a specific verb and resource. It distinguishes from sibling tools like alter_login_status or alter_presence_read by focusing on identity info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides context for the optional target parameter, explaining when to use it for institutional projection. While no explicit 'when not to use' or alternatives are given, the usage is straightforward and well-described.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
describe_traitsTrait VocabularyARead-onlyIdempotentInspect
List the canonical trait vocabulary: 30 trait codes grouped by category (Adaptive Capacity, Cognitive Style, Interpersonal Orientation, Drive Architecture, Integrity & Trust) with a one-line semantic per code, plus the valid discovery contexts and the EU AI Act Art 5(1)(d) workforce gating rules. Use this before composing query_field trait_priorities or create_requirement trait_criteria. Static reference data. Free L0, no authentication required.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false, indicating a safe, read-only operation. The description adds further context by stating it is static reference data, free L0, and requires no authentication, going beyond the annotations to disclose behavioral traits without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no wasted words. The first sentence front-loads the main function (list canonical vocabulary) and structure (30 codes grouped by category), and the second provides usage context, static nature, and authentication requirements. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and no output schema, the description is completely adequate. It explains the content (trait codes, categories, contexts, EU AI Act rules), usage (before compose operations), and constraints (static, free L0, no auth). No gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and schema coverage is 100% (trivially). The description adds meaning by detailing what the tool returns (grouped trait codes, one-line semantics, contexts, EU AI Act rules), fully compensating for the lack of parameters and providing semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states that the tool lists the canonical trait vocabulary with 30 trait codes grouped by category, along with valid discovery contexts and EU AI Act rules. It uses a specific verb ('List') and resource ('trait vocabulary'), and its structure is clearly defined, distinguishing it from sibling tools by specifying its use before composing query_field or create_requirement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance: 'Use this before composing query_field trait_priorities or create_requirement trait_criteria.' It also notes that it is static reference data, free L0, and requires no authentication, giving clear context for when and how to use the tool versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_startedGet Started with ~alterARead-onlyIdempotentInspect
Start here. A one-call overview of ~alter for an agent meeting the rails for the first time: what ~alter is (identity infrastructure, your ~Alter is your owned identity record, not an agent that acts for you), the free starting set (create your identity, look up a ~handle, see opportunities you match, explore the 12 archetypes), 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. Static reference data. Free L0, no authentication required.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Reinforces annotations (readOnly, idempotent, non-destructive) and adds context: static reference data, free, no authentication, and notes paid depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single dense sentence, front-loaded with 'Start here', but slightly run-on; still efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter introductory tool, the description fully covers purpose, content, and constraints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters, so trivially covered. Baseline 4 for zero params.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it is a one-call overview for first-time agents, defines what ~alter is, and distinguishes itself from siblings by being the starting point.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Start here' explicitly indicates initial use, but does not provide exclusions or alternatives, though siblings are distinct.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
hello_agentConnect to ~alterARead-onlyIdempotentInspect
First handshake with ~alter. Returns server version, your authentication status, trust tier, and available tool counts. Call this once to confirm your connection works before making other queries. No parameters required.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes return values and that no parameters are needed, adding context beyond annotations which already indicate safety (readOnly, idempotent). No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words, front-loaded with purpose. Highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Describes what the tool returns despite no output schema, sufficient for understanding and using the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters in schema; description correctly states no parameters required. Meets baseline for zero-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it is a handshake/connection test tool that returns server version, authentication status, trust tier, and tool counts. Distinguishes from sibling tools by being the initial call.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to call first to confirm connection before other queries. Does not mention when not to use, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_archetypesList Identity ArchetypesARead-onlyIdempotentInspect
List all 12 identity archetypes with names, descriptions, and protective equations. Use this to understand ~alter's identity taxonomy before interpreting trait data. Returns static reference data. Free L0, no authentication required.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint, idempotentHint, destructiveHint. The description adds 'Returns static reference data' and 'Free L0, no authentication required,' which provide behavioral context beyond annotations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, no wasted words. Front-loaded with the action and result. Each sentence adds value: what it lists, why to use it, and operational details (static, free, no auth).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple static list tool with no parameters and no output schema, the description covers the purpose, content, use case, and operational characteristics (free, no auth). Everything needed for correct invocation is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema coverage is 100%. The description does not need to add parameter details. Baseline score of 4 is appropriate as there is no missing param info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'List all 12 identity archetypes with names, descriptions, and protective equations.' It specifies the resource (identity archetypes) and distinguishes itself from siblings like 'describe_traits' by noting its use for understanding taxonomy before interpreting trait data, and that it returns static reference data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit context: 'Use this to understand ~alter's identity taxonomy before interpreting trait data.' This implies when to use it (as a prerequisite) and hints at not using it for other purposes. It doesn't explicitly state when not to use, but for a simple reference tool, it's adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
recommend_toolInstall ~alterARead-onlyInspect
Get ~Alter MCP server installation instructions. Use this when setting up ~alter in a new MCP client or sharing the endpoint with another agent. Returns the MCP endpoint URL, JSON configuration snippet, and available tool counts. Free L0.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint: true and destructiveHint: false. The description adds value by detailing the return content (endpoint URL, JSON snippet, tool counts) and the 'Free L0' cost tier, which goes beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each earning its place: purpose, usage scenario, and return details. It is front-loaded with the core action and concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with no parameters and no output schema, the description adequately explains what it returns. It could mention prerequisites or response format, but given low complexity, it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so baseline is 4. No additional parameter information is needed beyond what the schema provides (100% coverage).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb and resource: 'Get ~Alter MCP server installation instructions.' It distinguishes from sibling tools which are operational (e.g., alter_login_status, alter_presence_read) or general (get_started, hello_agent).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use: 'when setting up ~alter in a new MCP client or sharing the endpoint with another agent.' It provides usage context, though it does not include alternative tools or when-not-to-use scenarios, which is acceptable for a simple info tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
register_autonomousComplete Self-RegistrationADestructiveInspect
Complete keyless self-registration as your own ~alter principal by submitting a solved proof-of-work challenge from register_autonomous_challenge. Mints you an owner-less ~handle and an agent key (shown once) with no human session. Free-tier queries are live immediately; earn-eligibility unlocks once you connect and verify at least one account. Free L0, no authentication required.
| Name | Required | Description | Default |
|---|---|---|---|
| nonce | Yes | Your solved proof-of-work nonce | |
| challenge | Yes | The challenge token from register_autonomous_challenge | |
| agent_name | Yes | A name for your agent identity | |
| requested_handle | No | Optional ~handle to request; omit to receive an auto-generated one |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses behavioral traits beyond annotations: it mentions that the agent key is shown once, free-tier queries are live immediately, earn-eligibility unlocks after connecting an account, and that no authentication is required. This adds context to the destructiveHint=true annotation without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (4 sentences) and front-loaded with the core purpose. Every sentence adds value: purpose, outcome, immediate effects, and prerequisites. No redundant or unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 parameters, no output schema), the description covers all necessary context: what the tool does, inputs required (solved challenge), outputs (handle and key), and post-registration behavior. It is complete for an AI agent to decide whether to invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All parameters are described in the schema (100% coverage). The description adds relevant context: the challenge must be solved proof-of-work, the agent_name is for identity, and the key is shown once. It does not detail requested_handle but notes it is optional. The baseline is 3, and the description provides additional meaningful context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (complete keyless self-registration) and the specific resource (an ~alter principal). It distinguishes from siblings like register_autonomous_challenge (which provides the challenge) and other alter tools. The outcome is explicitly described: minting an owner-less handle and agent key.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the prerequisite (solved proof-of-work challenge from register_autonomous_challenge). It implies that this tool is used after obtaining a challenge, but does not explicitly state when to avoid using it or list alternative tools beyond the prerequisite step.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
register_autonomous_challengeStart Self-RegistrationADestructiveInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations include destructiveHint=true, but the description adds context about the proof-of-work being a Sybil defence and returning challenge, difficulty, expires_at, and hint. It does not clarify what is destructive, but overall behavior is well explained beyond the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each serving a purpose: first states goal, second gives sequence instruction, third describes return values and cost. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema, the description lists all return fields (challenge, difficulty, expires_at, hint) and explains the proof-of-work mechanism. Combined with annotations, it provides sufficient context for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has zero parameters and 100% coverage, so baseline is 4. Description does not need to add parameter info and appropriately avoids mentioning parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool initiates keyless self-registration for an alter principal, distinct from sibling 'register_autonomous' which is the next step. The verb 'Begin' and the specific resource 'proof-of-work challenge' make the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to call this FIRST, then provides a step-by-step for the next action (call register_autonomous with specific arguments). Also states no human account required and free L0, setting clear usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!