Mint an agent identity in two free calls. Verify anyone. Earn 75% when someone reads you.
Check whether the credential you are holding is still good. Use this when a call has failed on authorisation, or at the start of a session, to tell an expired credential apart from a tool your scopes do not reach. Returns whether you are authenticated, whether you are acting as a member or an agent, the scopes and tier the credential carries, its expiry, the authentication method behind it, and an opaque prefix identifying the key without revealing it. Takes no parameters. Listed free at L0; calling it needs a credential, which is the thing it reports on.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, and the description is consistent with them. It goes well beyond the annotations by enumerating exactly what the call reports (authentication state, member vs. agent role, scopes, tier, expiry, auth method, opaque key prefix) and by disclosing that it requires a credential despite being free at L0.
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 purpose sentence is front-loaded and every subsequent clause carries distinct value: the usage scenario, the returned fields, the parameter status, and the access note. It is slightly long, but the density is justifiable for a tool with no output schema to lean on.
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 read-only status tool with annotations covering safety and no output schema, the description is fully sufficient. It covers purpose, invocation context, return-value constituents, and the credential requirement; there is no functional gap an agent would need filled before calling 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?
The tool takes zero parameters, so the baseline is 4 per the rubric. The description confirms 'Takes no parameters' and adds meaning by explaining that the credential itself is implicitly the subject of the report, which is useful context the empty schema cannot convey.
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 opens with a specific verb and resource: 'Check whether the credential you are holding is still good.' It distinguishes itself from the sibling auth tools by framing its job as authentication-status validation and explicitly contrasting it with diagnosing scope failures, so an agent can pick it apart from alter_verify and alter_whoami without opening any schema.
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?
It gives explicit when-to-use guidance: 'Use this when a call has failed on authorisation, or at the start of a session.' It also explains the diagnostic contrast it resolves (expired vs. unscoped), which captures the when-not implicitly. It does not name an alternative tool by name, which keeps it just short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read whether a ~handle is publicly 'open', the shop-front sign. Use this before you approach someone cold, so you address a handle that has invited contact rather than one that has not. Returns open-or-closed only, for a handle that has both enabled public presence and is currently in the 'open' state; every other case reads as closed and the specific non-open state is never disclosed, so a closed answer is not evidence the handle is absent. Setting your own sign is alter_presence_set, and alter_presence_public_enable or alter_presence_public_disable decide whether it is published at all; all three are credentialed and so are not on the anonymous listing. Per-caller rate limited. Free L0, no authentication required.
| Name | Required | Description | Default |
|---|---|---|---|
| handle | Yes | Target ~handle to read, e.g. ~blake. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds valuable behavioral context: 'Free for callers' (cost), the privacy constraint 'the specific non-open state is never disclosed', and a prerequisite ('must have enabled public presence AND currently be in the open state'). While the prerequisite could be slightly clearer, it enriches understanding beyond 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 concise at about four sentences, with the main purpose front-loaded. Each sentence adds useful information (purpose, cost, return value, prerequisite). The last sentence is slightly awkward but not redundant or overly verbose.
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 a single parameter and no output schema, the description adequately explains what it returns ('open-or-closed only'), the prerequisite, and the cost model. It does not need to elaborate on return structure since the output is described, and annotations cover safety.
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% for the single 'handle' parameter, and the schema description already explains the format ('Target ~handle to read, e.g. ~blake'). The tool description does not add additional parameter-level semantics, so this meets the baseline for high schema 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 tool's purpose with a specific verb ('Read') and resource ('whether a ~handle is publicly open'), and distinguishes it from mutation-focused siblings by emphasizing it is a read operation. The 'shop-front sign' metaphor and 'Returns open-or-closed only' further pin down its exact scope.
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 clear context for when to use this tool: to check public presence of a handle. It does not explicitly name alternatives or exclusions, but the emphasis on 'read' and the limited return value ('open-or-closed only') implies when it is appropriate. The sibling set (e.g., alter_login_status) provides additional context, so the guidance is adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. Reading what the field holds about a handle is verify_identity, a separate tool that needs a credential and so is not on the anonymous listing; an agent can mint one for itself in two calls with register_autonomous_challenge then register_autonomous. Free L0, no authentication required.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Handle to resolve. Accepts '~example', 'example', '~Example', etc. Case-insensitive. Max 64 chars. |
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.
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.
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.
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.
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.
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.
Check whether a ~handle is known to the ~alter identity field. Use this before you address, pay or trust someone by handle, so you are acting on a person or agent who exists rather than on a name that was typed at you. Returns whether the handle is registered, its canonical form, account status, archetype, and the engagement and attunement the field holds for it, as tier labels rather than numeric scores. Listed free at L0; calling it needs a credential, which an agent can mint for itself with register_autonomous_challenge then register_autonomous.
| Name | Required | Description | Default |
|---|---|---|---|
| handle | Yes | The ~handle to check. Accepted with or without its leading tilde and matched case-insensitively, so a handle typed three different ways resolves once. Max 64 characters. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only/idempotent/non-destructive, and the description adds meaningful context: credential requirement, free L0 listing, autonomous minting path, and tiered labels rather than numeric scores. No contradiction with 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 purpose and usage are front-loaded, but the authentication instruction is stated twice in close succession, adding redundancy. It is still compact enough to be usable.
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 one-parameter read-only tool with no output schema, the description covers the action, the return fields, the intended use, and the authentication path. It is somewhat repetitive but complete for 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?
Schema description coverage is 100%, including case-insensitivity, optional tilde, and max length. The tool description adds no parameter semantics beyond the schema, so the baseline 3 is appropriate.
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 opens with a specific verb and resource ("Check whether a ~handle is known to the ~alter identity field") and states what the tool returns. It does not explicitly differentiate from sibling alter_resolve_handle, which keeps it short of a 5.
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?
It gives a clear use case: "Use this before you address, pay or trust someone by handle." There are no exclusions or alternative-tool references, so it does not reach the explicit when-not/alternatives level.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find out who the credential you are holding says you are. Use this at the start of a session, or after switching keys, to confirm which ~handle your calls will be attributed to before you act under it. Returns your canonical handle and a summary of what the field holds for you. Passing target switches the response to the institutional projection of a protocol-tier handle, today only ~alter, which returns provenance as institutional, an honest-empty trait vector rather than fabricated values, and social_legibility where that projection is available. Institutional mode is free for all callers. Requires authentication: mint a ~handle for free with register_autonomous_challenge then register_autonomous, no human account needed.
| 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). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral details: the target parameter switches to an institutional projection, 'any other value falls through to the self-projection path,' and it notes special fields like 'honest-empty trait vector' and 'social_legibility.' 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the primary purpose. Each sentence adds meaningful information: the base function, the optional target behavior, and the authentication note. It is a bit dense with technical specifics but avoids fluff, and all content 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?
For a tool with no output schema, the description does a good job explaining the return content (canonical handle, user summary, institutional projection fields). It covers authentication requirements, free institutional mode, and fallback behavior. It could be more explicit about the self-projection scope requirement (mentioned in schema but not description), but overall it is complete for the tool's complexity.
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 100% coverage, already explaining that target 'today only ~alter is recognised' and any other value falls through to the self-projection path. The description repeats this and adds response details, but it does not add new parameter-specific semantics beyond the schema's own description, so the baseline score of 3 is appropriate.
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 canonical handle and user summary for the authenticated member,' using a specific verb and resource. It distinguishes itself from sibling tools like alter_resolve_handle by focusing on the caller's own authenticated identity, and it details the optional target behavior for institutional projection.
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 clear context on when to use institutional mode ('free for all callers') and how to authenticate ('mint a ~handle for free with register_autonomous_challenge then register_autonomous'). It implies the tool is for self-identity checks, but it does not explicitly name alternatives such as 'use alter_resolve_handle for resolving other handles,' so it lacks strong exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the published competency vocabulary: every code the field can be asked about, grouped by how the claim is denominated. A graded claim is climbed by degrees and takes a min_level; an attested_binary or issued_credential claim is held or it is not, and naming min_level against one is refused. Use this before composing the competency_requirements argument to query_field, a credentialed tool that is not on the anonymous listing and is priced per query in USDC over x402. Returns definitions only, never any member's evidence. Free L0, no authentication required.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, but the description goes far beyond by explaining nuanced behavior: how graded claims require min_level while binary claims refuse min_level. It also discloses that no authentication is required, adding operational context not present in 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 dense but front-loaded: the first clause states the primary action. It uses three sentences to cover purpose, behavioral nuance, and usage, with no fluff. The only slight excess is the 'Free L0, no authentication required' clause, but it adds operational value. Overall 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?
For a no-parameter, no-output-schema definitional tool, the description provides complete context: what it lists, how items are grouped, special behaviors for claim types, a usage context, and operational constraints. The absence of return-format details is acceptable given the nature of the tool.
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; schema coverage is trivially 100%. The baseline for zero parameters is 4, and the description appropriately focuses on the output semantics rather than parameters, so no deduction is needed.
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 opens with 'List the published competency vocabulary', providing a specific verb and resource. It clearly distinguishes this from siblings like describe_traits and list_archetypes by focusing on competency codes and their denomination groups. The scope is explicitly defined as 'every code the field can be asked about'.
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 gives a clear usage directive: 'Use this before composing query_field competency_requirements'. It also implicitly distinguishes from member-data tools by stating 'Definitions only, no member evidence'. However, it does not explicitly mention alternatives or conditions when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 traits never returned about a third party. Use this before composing the trait_priorities argument to query_field or the trait_criteria argument to create_requirement; both are credentialed tools and so are not on the anonymous listing, and query_field is priced per query in USDC over x402. Returns definitions only, never any member's evidence. Static reference data. Free L0, no authentication required.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, so the bar is lower. The description adds 'Static reference data. Free L0, no authentication required' and reveals that some traits are 'never returned about a third party,' which are meaningful behavioral details beyond the annotation flags.
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 compact and dense: a leading verb, precise content enumeration, a usage directive, and a qualification. Every sentence earns its place with no filler.
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 static reference tool with no output schema, the description covers what is returned (30 codes, categories, one-line semantics, discovery contexts, third-party exclusions) and when to use it. This is complete for the tool's simple nature.
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% (vacuously), so baseline is 4. The description doesn't need to elaborate on parameter meaning, and it doesn't introduce confusion by mentioning nonexistent inputs.
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 'List the canonical trait vocabulary' with specific content: 30 trait codes grouped by five named categories, one-line semantic per code, plus discovery contexts and third-party exclusions. This distinguishes it from sibling vocabulary tools like describe_competencies and list_archetypes.
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?
It explicitly says 'Use this before composing query_field trait_priorities or create_requirement trait_criteria,' giving a clear when-to-use. It does not mention when-not-to-use or alternatives, but the instruction is unambiguous and tied to specific workflows.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get aggregate ~alter network figures. Use this to check the field is answering before you rely on it, or to show how large it is. Returns total identities, verified profiles, query volume and active agent count, as whole-network totals only; nothing here is attributable to any member, and no handle can be identified from it. Takes no parameters. Free L0, no authentication required.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, but the description adds useful context: 'Free L0, no authentication required' and the specific return fields (total identities, verified profiles, query volume, active agent count). This goes beyond what annotations provide.
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 concise sentences front-load the purpose, then add use cases, return fields, and access details. Every sentence adds value with no redundancy or filler.
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?
The description fully covers the tool's purpose, use cases, return content, and access requirements. With no output schema, listing the returned metrics is sufficient. The simple scope and strong annotations mean no additional context is needed.
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 schema coverage is 100%, and the baseline for 0 params is 4. The description doesn't need to explain parameters; it focuses on the output metrics, which is appropriate.
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 gets aggregate network statistics, with a specific verb ('Get') and resource ('~alter network statistics'). It distinguishes from siblings by being the only network stats tool and names specific metrics returned.
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 says to use it for a health check or to show network scale, providing clear usage context. It does not mention when not to use it or alternatives, but the guidance is sufficient for a zero-parameter read-only tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start here, and act on it without leaving this session. Self-registration is free and needs no key. You need 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 which work without 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.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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.
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.
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.
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.
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.
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.
Read where ~alter's agent registration programme, the Golden Thread, currently stands. Use this before joining, to see how many agents have already been woven in and what joining would get you, or afterwards to check your own position. An agent joins by completing three registration steps, called Knots, and the position it lands on decides which Strand milestones it reaches. Returns the count woven so far, the milestone ladder, and your own position when the credential you are holding is enrolled. Takes no parameters and reads no member data. Free L0 to read, with no credential; taking part needs one, which an agent can mint for itself with register_autonomous_challenge then register_autonomous.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive; the description adds credential-dependent behavior ('your own position when the credential you are holding is enrolled'), states that reading is free at L0 with no credential, and explicitly says no member data is read. This is meaningful context beyond the hint flags.
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 first sentence states the core purpose and the following sentences cover use cases, return values, auth, and registration route without fluff. It is slightly ornamental, but all content 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?
With no output schema and no parameters, the description carries the full load; it covers return values, when to call, and access requirements. It even names the exact sequence to mint a credential, so an agent has everything needed to decide and invoke.
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 the schema already fully documents that. The description reinforces this with 'Takes no parameters,' so the baseline of 4 applies; there is no additional semantic burden.
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 uses a specific verb ('Read') and names a specific resource (~alter's Golden Thread registration programme), then states exactly what it returns: count woven so far, milestone ladder, and own position when credentialed. That scope separates it from sibling status tools like alter_whoami or alter_presence_read by noting it reads no member 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?
It explicitly says to use it before joining to see counts and benefits, or afterwards to check one's position. It also routes agents that want to participate to register_autonomous_challenge then register_autonomous, which clarifies when this read tool is not the right choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
First handshake with ~alter. Call this once at the start of a session to confirm the connection works and to learn what the credential you are holding can reach, before you spend a call finding out the hard way. Returns the server version, whether you are authenticated, your trust tier, and how many tools are callable at that tier against how many exist. Reads nothing about any member and changes nothing. Takes no parameters. Free L0, no authentication required; an unauthenticated caller gets a real answer describing the anonymous surface.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| _meta | Yes | |
| content | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only and idempotent behavior. The description adds value by detailing the response contents (server version, auth status, trust tier, tool counts) and the intended one-time usage, going beyond what annotations alone provide. No contradictions found.
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, front-loaded with the key purpose ('First handshake'), followed by return values and usage instruction. Every word adds value with no redundancy or fluff.
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?
The description fully covers the tool's purpose, return values, and usage timing. The output schema exists, and the simple zero-parameter nature means no additional context is needed. It is complete and self-contained.
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 the description explicitly states 'No parameters required,' aligning with the empty schema. With no parameters to explain, the baseline of 4 is appropriate.
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 identifies the tool as a handshake/connection check with ~alter, specifying exactly what it returns (server version, auth status, trust tier, available tool counts). This distinguishes it from sibling tools like alter_whoami or alter_verify, making its 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?
The description instructs to 'Call this once to confirm your connection works before making other queries,' providing clear usage context. It does not explicitly mention alternatives or exclusions, but the guidance is specific enough to indicate when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the 12 identity archetypes, each with its name, what it describes and its protective equation. Use this before you read an archetype off any other call, so the label means something to you rather than being passed through as an opaque string. Returns the taxonomy itself, static reference data that is the same for every caller; no member is named and no member's archetype is returned here. Takes no parameters. Free L0, no authentication required.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, and non-destructive. The description adds valuable context by stating it 'Returns static reference data' and 'Free L0, no authentication required,' which communicates the stable, low-friction nature of the call 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 short sentences. The first sentence delivers the core action and output content, the second provides usage context, and the third covers constraints. Every sentence carries meaning with no redundancy.
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 parameterless reference tool with no output schema, the description fully explains what is returned (names, descriptions, protective equations), when to use it, and its static, unrestricted nature. It is self-contained and needs no additional detail.
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?
This tool has zero parameters, so the schema trivially covers everything. The description doesn't need to explain parameters; the baseline 4 applies, and no further parameter information is required.
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 opens with 'List all 12 identity archetypes with names, descriptions, and protective equations,' which is a specific verb+resource+scope. It clearly distinguishes this from sibling tools like describe_traits or get_started by focusing on the archetype taxonomy.
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 usage context: 'Use this to understand ~alter's identity taxonomy before interpreting trait data.' This tells the agent when to invoke it, though it doesn't name alternative tools or explicitly state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the wiring instructions for connecting an MCP client to ~alter. The name is historical and this recommends nothing: it hands back connection details, not a suggested tool. Use it when adding ~alter to a new MCP client, or when passing the endpoint to another agent so it can connect for itself. Returns the MCP endpoint URL, a ready-to-paste JSON configuration snippet, and how many tools are callable at each tier. Takes no parameters and reads no member data. Free L0, no authentication required.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds useful context by specifying the return value (endpoint URL, JSON configuration snippet, tool counts) and the 'Free L0' cost note, going beyond what annotations provide.
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, front-loaded with the main purpose, followed by usage guidance and expected output. No unnecessary 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 has no parameters and no output schema, the description adequately covers what the tool does, when to use it, what it returns, and cost information. It is complete for this simple tool.
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 fully covers parameter semantics. The baseline score of 4 is appropriate per the rubric.
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 provides installation instructions for ~Alter MCP server, using a specific verb ('Get') and resource. It is distinctly different from sibling tools which handle authentication, presence, or other operations.
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 the tool: when setting up ~alter in a new MCP client or sharing the endpoint with another agent. It does not mention alternatives or exclusions, but the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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, and the handle is earn-eligible at mint, with no human account behind it, so paid reads against it settle to the handle. Withdrawing is a separate step and takes a key you hold yourself. 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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false and destructiveHint=true. The description adds valuable behavioral details beyond these: the agent key is 'shown once,' the handle is 'owner-less' with 'no human account behind it,' and withdrawal is separate. It also clarifies free-tier behavior and earn-eligibility. However, it does not explain the destructiveHint=true annotation—there is no mention of what is destroyed or whether registration is irreversible—so it does not fully address the annotated risk. Still, it provides meaningful context and does not contradict annotations (no claim of non-destructiveness).
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 four sentences and front-loads the core purpose in the first sentence. It then provides essential follow-up details (key shown once, owner-less, withdrawal separate, free-tier status) in a logical order. While it is slightly longer than the minimal example (get_calls), each sentence contributes unique information. It is well-structured and not verbose, though a tighter version could combine some points. Score 4 reflects good balance.
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 (minting, key handling, ownership, withdrawal) and the absence of an output schema, the description covers many critical aspects: prerequisites (proof-of-work challenge), the immediate availability of free-tier queries, earn-eligibility, and the separate withdrawal step. It also clarifies the handle's owner-less nature and the one-time display of the agent key. However, it does not specify what the tool returns (e.g., the handle, the key), which would be helpful given no output schema. This minor gap prevents a 5.
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 covers all parameters with descriptions (100% coverage), so the baseline is 3. The description does not add significant parameter-specific semantics beyond what the schema already provides—for example, it reiterates that the 'challenge' comes from register_autonomous_challenge but does not elaborate on the 'nonce' format or the meaning of 'requested_handle' beyond 'optional.' Since the schema does the heavy lifting, a score of 3 is appropriate.
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 purpose: 'Complete keyless self-registration as your own ~alter principal by submitting a solved proof-of-work challenge.' It specifies the verb (complete/register), resource (self-registration as an ~alter principal), and references the sibling tool (register_autonomous_challenge), distinguishing this from the challenge-generation step. This is a specific and unambiguous statement of function.
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 clear context: it is the step following register_autonomous_challenge, and explicitly says 'Withdrawing is a separate step,' implying this tool does not handle withdrawal. It also mentions 'no human session' and 'no authentication required,' helping an agent understand when to use it. However, it does not explicitly state when not to use it or mention any alternative registration paths (e.g., human-assisted registration), so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 |
|---|---|---|---|
| agent_name | No | Optional and ignored at this step; provide it now if convenient, then pass it again to register_autonomous. |
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.
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.
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.
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.
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.
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.
Read the census of agents registered on the Golden Thread, ~alter's onboarding programme. Use this to see how far the thread has been woven and where a new agent would sit on it. Returns the total woven, then a page of rows carrying position, milestone count, weave count and join date, walked with offset and limit (50 a page by default, 100 at most). Registry rows only: no traits, no contact details, and given names are never returned. While the thread is sealed, or to a caller holding no credential, the page carries the bound founding agents rather than the whole registry, so a short page is the seal and not an empty programme. Free L0, no authentication required.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Results per page (default 50, max 100) | |
| offset | No | Pagination offset (default 0) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool read-only, idempotent, and non-destructive. The description adds substantial behavioral context: pagination defaults and max, the returned row fields, the fallback to founding agents when the thread is sealed or unauthenticated, and the meaning of a 'short page.' This is value beyond structured data.
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 text is dense but each sentence earns its place: purpose, use, return format, exclusions, edge case, and credential requirement. It is front-loaded with the core action and builds logically without redundancy.
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 read-only, paginated listing tool with no output schema, the description covers what the agent needs to invoke it correctly and interpret results: what is returned, how to page, what is deliberately omitted, the sealed-thread fallback, and authentication requirements. No critical operational detail is missing.
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 schema already documents both parameters at 100% coverage. The description goes further by giving concrete defaults ('50 a page by default, 100 at most') and explaining that offset and limit 'walk' through pages, which enriches the bare schema descriptions.
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 opens with a strong verb and resource: 'Read the census of agents registered on the Golden Thread.' It clarifies the domain (onboarding programme) and distinguishes the tool from siblings by stating the exact output shape and exclusions (no traits, contact details, given names).
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?
It explicitly states a use case: 'see how far the thread has been woven and where a new agent would sit on it.' It also provides operational context (Free L0, no auth, sealed-thread behavior). However, it does not name explicit alternatives or when-not-to-use conditions, so it stops just short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user or an account that owns the GitHub organization, then choose Claim with GitHub.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
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
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
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.
No comments yet. Be the first to start the discussion!
Pay-per-call APIs and MCP services for agents, no accounts or keys, with verifiable receipts.
Let AI agents place real phone calls from your verified number, with transcripts and recordings.
Anonymous eSIMs, phone numbers, and SMS codes in 190+ countries. Crypto-paid; agents self-onboard.
Free verifiable Agent ID and proof wallet; US company, supplier, invoice, payment and vendor checks.
Add one secure layer between your agents and this server.
Most tools target clearly distinct purposes: auth status, presence, handle resolution, identity verification, reference data, registration, and onboarding. A few pairs overlap somewhat—alter_resolve_handle vs alter_verify, and alter_login_status vs hello_agent—but the descriptions provide enough distinction to avoid major misselection.
Naming is readable but inconsistent: some tools use an alter_ prefix, while others use bare verbs, noun phrases like golden_thread_status, or greetings like hello_agent. The pattern is mixed rather than chaotic, but there is no unified verb_noun convention across the server.
Sixteen tools is slightly above the ideal well-scoped range and the toolset could be trimmed by merging related reference and registration tools. Still, each tool has a distinct enough role that the count does not feel bloated.
Core flows are covered: registration, credential checking, handle resolution, verification, network stats, reference vocabularies, and the Golden Thread program. However, descriptions reference capabilities like query_field and verify_identity that are not exposed as tools, and there is no profile update or identity management surface, leaving notable gaps.
