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?
Beyond the readOnlyHint annotation, the description discloses key behavioral nuance: a closed result is not evidence of absence, the specific non-open state is never disclosed, the operation is per-caller rate limited, and no authentication is required. This gives the agent meaningful expectations beyond the structured 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?
Although dense, every sentence earns its place: purpose, usage context, return semantics, sibling differentiation, and operational constraints. The primary purpose is front-loaded and the additional clauses are all directly useful for correct invocation.
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 one parameter, no output schema, and simple annotations, the description fully covers what an agent needs: what the tool returns, what edge cases mean, how it differs from siblings, rate limiting, and authentication. Nothing essential 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 the single parameter handle with a clear example and maxLength, so schema coverage is 100%. The description reinforces the ~handle concept but adds no new parameter-level details beyond what the schema provides, so the baseline 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 opens with a specific verb and resource: 'Read whether a ~handle is publicly open, the shop-front sign.' It clearly names the sibling operations it is not (alter_presence_set, alter_presence_public_enable/disable), making the tool's 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?
It gives explicit when-to-use guidance: 'Use this before you approach someone cold, so you address a handle that has invited contact rather than one that has not.' It also names the alternatives and their different roles, and notes that they are credentialed, so an agent can decide when this tool is appropriate versus not.
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?
The annotations already convey read-only, idempotent, and non-destructive behavior. The description adds meaningful context beyond those annotations: it never returns PII, is free and authentication-free at L0, and returns canonical handle, kind, and addressability.
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 essential purpose and usage guidance are front-loaded with little waste. The later sentence about minting a credential for verify_identity is slightly tangential, but it supports the alternative-usage note and is not 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?
This is a one-parameter tool with strong annotations, and the description covers what it does, when to use it, what it returns, privacy behavior, authentication requirements, and the relevant alternative. Nothing important is missing 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?
Schema coverage is 100% and the single query parameter is already described with examples, max length, and case-insensitivity. The description only echoes the '~example' format and adds no new semantic information about the parameter.
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 names a specific verb and resource: resolving a ~handle to its canonical form and kind, and confirming existence. It also differentiates itself from verify_identity early, so an agent can tell it apart from related tools.
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 this as the first call when a handle needs to be confirmed before invoking other tools. It also names verify_identity as the alternative for reading a field about a handle and explains why that tool is not on the anonymous listing.
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 declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds beyond that: it specifies that the return is tier labels rather than numeric scores, and it discloses that calling requires a credential and gives the exact minting sequence (register_autonomous_challenge then register_autonomous). It also mentions the L0 listing. This is useful behavioral context well 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 about four sentences and front-loads the core purpose before explaining usage, returns, and auth. Each sentence earns its place, and it avoids redundancy. It is slightly verbose in the auth explanation but still efficient relative to the complexity of the tool's behavior. Could be trimmed, but not padded.
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 one parameter, no output schema, and annotations covering safety, the description covers the essential context: purpose, usage rationale, return contents, and authentication path. It does not describe error handling or exact output formatting, but the listed return fields give sufficient guidance. Minor gaps remain, but the description is adequate for an agent to call it 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?
The input schema already fully describes the handle parameter (accepted with/without tilde, case-insensitive, max length), and schema description coverage is 100%. The tool description itself does not add any new parameter-level information, so it does not exceed the baseline that the schema establishes. The description's value lies in return semantics, not parameter semantics.
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–resource pair ('Check whether a ~handle is known to the ~alter identity field') and then explains the real-world intent (verifying a handle before addressing, paying, or trusting). It lists concrete outputs (registration status, canonical form, account status, archetype, engagement/attunement tiers), which makes it distinct from generic 'verify' tools and clearly differentiates its role from siblings like alter_resolve_handle.
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 provides a clear usage context: use before address/pay/trust to avoid acting on a non-existent or mistyped identity. It does not explicitly name alternative siblings or state when not to use this tool, but the guidance is concrete enough that an agent can decide to call it in the described scenarios. Lacks explicit exclusions but is not misleading.
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, idempotentHint, and destructiveHint, and the description builds on that with valuable behavioral context: the target-dependent mode switch, institutional provenance, honest-empty trait vectors rather than fabricated values, and social_legibility availability. The phrase 'Requires authentication' followed by 'Institutional mode is free for all callers' is slightly ambiguous, keeping this from a 5.
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 not bloated; every sentence contributes purpose, usage context, target behavior, or authentication guidance. It is front-loaded with the primary use case and then layers details, though the final authentication sentence is slightly convoluted.
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 output schema, the description adequately explains the return concept: canonical handle, a field summary, and the institutional projection fields (provenance, trait vector, social_legibility). It also covers authentication and fallback behavior. The only gap is the exact shape of the 'summary of what the field holds for you.'
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 optional parameter, so the baseline is 3. The description adds meaning beyond the schema by explaining the behavioral consequence of passing target, noting that today only ~alter is recognized, and that any other value falls through to the self-projection path with an added scope requirement.
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 ('Find out') and a clear resource ('who the credential you are holding says you are'), then sharpens it to returning your canonical handle and session attribution. This clearly distinguishes the tool from siblings like alter_resolve_handle or alter_verify, since it is explicitly about the caller's own identity context.
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 concrete when-to-use guidance: 'at the start of a session, or after switching keys' to confirm attribution before acting. It also notes the authentication prerequisite and that institutional mode is free, but it does not explicitly state when not to use this tool versus a sibling or name alternative tools.
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?
Beyond the annotations, the description discloses meaningful behavioral nuance: graded claims require min_level, while attested_binary and issued_credential claims refuse min_level. It also clarifies output scope ('Returns definitions only, never any member's evidence') and access cost ('Free L0, no authentication required'), all of which are useful and consistent with the readOnly/idempotent 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 well-structured: the primary function is front-loaded, followed by necessary domain rules, usage guidance, output limitations, and access details. Every sentence earns its place, and the length is justified by the need to communicate non-obvious claim behaviors.
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 vocabulary tool, this description is complete. It explains what is returned, how results are grouped, an important validation/refusal behavior, the intended usage context, cost, and authentication requirements. Without an output schema, it still gives an agent enough to interpret the result 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?
There are no parameters, so the description need not explain any. The baseline of 4 applies; the description adds useful domain context about claim denominations and min_level semantics, which helps an agent understand what kind of vocabulary it will receive even though no input 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 a specific verb and resource: 'List the published competency vocabulary: every code the field can be asked about, grouped by how the claim is denominated.' It clearly names the subject matter and differentiates itself by stating it returns definitions only and never member evidence, which distinguishes it from evidence-returning tools.
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 an explicit usage trigger: 'Use this before composing the competency_requirements argument to query_field.' It also explains that query_field is a credentialed, per-query priced tool, while this tool is free and requires no authentication, giving the agent clear context for when to call this tool first.
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 indicate read-only, idempotent, non-destructive behavior. The description adds valuable context beyond annotations: 'Returns definitions only, never any member's evidence', 'Static reference data', 'Free L0, no authentication required'. This fully discloses what the tool does and does not expose.
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 long but every sentence carries distinct useful content: scope of data, usage guidance, privacy boundary, and operational cost/auth requirements. It is front-loaded with the primary purpose and remains efficient given the amount of context needed.
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 static reference tool, the description fully specifies what is returned, what is not returned, when to call it, and its operational profile. No output schema exists, but the description adequately covers return semantics with 'definitions only' and 'static reference data'.
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 zero parameters, so there are no parameter semantics to explain. The description instead clarifies the output semantics and constraints, which is sufficient for an empty-argument tool.
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 ('List the canonical trait vocabulary'), enumerates exact content (30 trait codes, categories, semantics, discovery contexts, exclusions), and clearly identifies the tool as static reference data, distinguishing it from credentialed query tools. It leaves no doubt what the tool does.
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 directs the agent to use this tool before composing trait_priorities for query_field or trait_criteria for create_requirement, and even explains why those related tools are absent from the sibling listing. This is concrete, actionable usage guidance.
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 mark it read-only, idempotent, and non-destructive, but the description adds meaningful behavioral context: output is aggregate-only, non-attributable, no handle can be identified, and it requires no authentication. This goes well beyond what annotations and the empty schema 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?
Every sentence serves a purpose: purpose, use cases, return contents, scope limitation, and access requirements are packed into a compact description. It is front-loaded with the core function and avoids redundant elaboration.
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 aggregate tool, the description fully covers why an agent would call it, what it returns, its strict non-attribution guarantee, and its authentication cost. No output schema exists, but the description enumerates the return dimensions sufficiently for correct use.
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 zero parameters and 100% coverage, so there is little for the description to add. It explicitly confirms 'Takes no parameters,' which is useful reinforcement even though the schema already makes this clear.
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?
States a specific verb and resource ('Get aggregate ~alter network figures') and enumerates exact return fields (total identities, verified profiles, query volume, active agent count). It further distinguishes itself by emphasizing whole-network totals only, with nothing attributable to any member, which separates it from member-specific siblings like alter_whoami and alter_resolve_handle.
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 explicit use cases: 'check the field is answering before you rely on it, or to show how large it is.' It stops short of naming specific sibling alternatives or stating when not to use it, though the aggregate-only framing implies it is not for member-level queries.
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?
Annotations already declare readOnlyHint=true and idempotentHint=true, and the description adds useful behavioral context: no authentication required, free L0 access, live pricing via USDC over x402, and the consent path for deep data. It goes beyond the structured 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 content is largely relevant, and 'Start here' is a strong front-loaded signal. However, the third sentence is a dense run-on that packs multiple concepts — identity infrastructure, keyless tools, x402 payment, and consent — into one long parenthetical-heavy clause, which could be clearer with structured bullets.
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 onboarding call with no output schema, the description covers the essentials: prerequisites, what is returned, cost/free-tier status, and next actions. It does not describe the exact return format, but the absence of an output schema makes the prose-level explanation especially valuable and arguably sufficient.
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%, so there is nothing for the description to explain about inputs. It reinforces the no-auth, free-tier behavior, which is the only relevant parameter-like context for invocation.
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 'Start here,' establishing this as the onboarding entry point, and explains what the call returns: what ~alter is, which tools work without a key, payment context, and the consent path. This differentiates it from siblings like register_autonomous or hello_agent, though the purpose is somewhat implied rather than stated with a crisp verb+resource phrase like 'Returns an onboarding overview.'
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 directs the agent to 'Start here' and gives actionable next steps: register_autonomous_challenge then register_autonomous, with no key or human account needed. It does not explicitly name alternatives or exclusions among the sibling tools, but the 'tools which work without a key' mention helps the agent infer scope.
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 readOnlyHint, idempotentHint, and destructiveHint, and the description adds value by explicitly stating 'Reads nothing about any member and changes nothing.' It also discloses authentication behavior, including that no authentication is required and unauthenticated callers receive a real anonymous-surface response.
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 focused sentences, each earning its place: purpose, placement, return values, and side effects/authentication. The most important guidance is front-loaded, and there is 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?
Given the output schema exists and there are no parameters, the description only needs to explain when to call, what it returns, and what side effects or authentication constraints exist. It covers all of these, including the unauthenticated edge case.
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 zero parameters and an empty input schema, there is nothing meaningful to document. The description redundantly says 'Takes no parameters,' but the baseline for a zero-parameter tool is met without requiring additional semantic detail.
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 'First handshake with ~alter' and specifies the exact purpose: confirming the connection and learning what the held credential can reach. It also enumerates the concrete return items—server version, authentication status, trust tier, and tool counts—which clearly differentiates it from sibling tools like alter_whoami.
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 'Call this once at the start of a session' and frames it as a preliminary check before spending other calls. It does not name alternative tools for exclusion, but it clearly establishes when and why to use this tool.
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?
The description goes well beyond the annotations by explaining that this is 'static reference data that is the same for every caller,' and by making the boundary explicit: no member is named and no member's archetype is returned. It also discloses authentication requirements ('Free L0, no authentication required'). This is useful behavioral context that annotations alone do not provide, and it does not contradict any 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?
The description is front-loaded with the primary action and then adds only necessary context: when to use it, what it returns, what it does not return, and its access level. Every sentence contributes distinct information, and there is no filler or repetition of schema content.
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, zero-parameter, read-only reference tool, the description is fully complete. It states the output content, the static nature of the data, the usage context, the lack of member-specific data, and the authentication requirement. No output schema is provided, but the description sufficiently describes what the caller will receive.
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 no parameters and the input schema already confirms this with an empty properties object and 100% schema coverage. The description adds explicit confirmation with 'Takes no parameters,' which removes any ambiguity. For a zero-parameter tool, this is the appropriate baseline.
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 gives a specific verb ('List'), a concrete resource ('the 12 identity archetypes'), and the exact content of each entry ('name, what it describes and its protective equation'). It also distinguishes itself from calls that return a member's archetype by explicitly stating 'no member is named and no member's archetype is returned here.' This makes the tool's role clear relative to its siblings.
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 explicit timing guidance: 'Use this before you read an archetype off any other call.' This clearly tells the agent when in a workflow this tool belongs. It does not name alternative tools or state when not to use it, but the instruction is specific enough to guide correct usage.
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 mark readOnlyHint=true and destructiveHint=false, and the description adds meaningful context beyond that: it 'reads no member data,' requires no authentication, and clarifies the historical name is misleading. It also discloses exactly what is returned, making the tool's behavior fully transparent.
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 compact sentences front-load the core purpose, then cover usage, return payload, and access requirements. There is no filler, no repetition of the schema, and 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?
For a zero-parameter, read-only utility, the description covers why it exists, when to use it, what it returns, and what access is required. The absence of an output schema is compensated by explicitly listing the return contents: endpoint URL, JSON configuration snippet, and callable tool counts per tier.
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?
There are zero parameters and the schema fully documents that, so the baseline is 4. The description reinforces it with 'Takes no parameters' and adds the useful clarification that the tool 'reads no member data,' ruling out hidden inputs or side effects.
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 states a specific verb and resource: 'Get the wiring instructions for connecting an MCP client to ~alter.' It also explicitly corrects the potentially misleading name by clarifying that it returns connection details, not a recommended tool, which clearly distinguishes it from the sibling auth/status tools.
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 provides explicit use cases: 'Use it when adding ~alter to a new MCP client, or when passing the endpoint to another agent so it can connect for itself.' These trigger conditions are unambiguous and leave no doubt about when to invoke this tool.
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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
alter_whoami1 field changedInput schema / properties / target / descriptionPrevious value: -"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)."New value: +"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)."alter_verify1 field changedInput schema / properties / handle / descriptionPrevious value: -"~handle to verify (with or without leading ~). Max 64 chars."New value: +"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."golden_thread_statusthread_censushello_agent1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "_meta": {
+ "properties": {
+ "authenticated": {
+ "type": "boolean"
+ },
+ "server": {
+ "type": "string"
+ },
+ "tier": {
+ "type": "string"
+ },
+ "tools": {
+ "properties": {
+ "advertised_free": {
+ "type": "integer"
+ },
+ "advertised_premium": {
+ "type": "integer"
+ },
+ "advertised_total": {
+ "type": "integer"
+ },
+ "anon_callable": {
+ "description": "Present as an int only when authenticated is false; null when authenticated.",
+ "type": [
+ "integer",
+ "null"
+ ]
+ },
+ "callable_total": {
+ "type": "integer"
+ },
+ "free": {
+ "type": "integer"
+ },
+ "identity_query": {
+ "type": "integer"
+ },
+ "messaging": {
+ "type": "integer"
+ },
+ "premium": {
+ "type": "integer"
+ }
+ },
+ "required": [
+ "anon_callable",
+ "callable_total",
+ "identity_query",
+ "free",
+ "premium",
+ "messaging",
+ "advertised_total",
+ "advertised_free",
+ "advertised_premium"
+ ],
+ "type": "object"
+ },
+ "version": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "server",
+ "version",
+ "authenticated",
+ "tier",
+ "tools"
+ ],
+ "type": "object"
+ },
+ "content": {
+ "items": {
+ "properties": {
+ "text": {
+ "type": "string"
+ },
+ "type": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "type",
+ "text"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "content",
+ "_meta"
+ ],
+ "type": "object"
+}describe_competenciesget_network_statsregister_autonomous_challenge1 field changedInput schema / properties / agent_nameAdded value: +{
+ "description": "Optional and ignored at this step; provide it now if convenient, then pass it again to register_autonomous.",
+ "maxLength": 100,
+ "type": "string"
+}register_autonomousregister_autonomous_challengeClaiming 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, then choose Claim with GitHub. An organization namespace such as io.github.acme/server also needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.
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.
Several tools overlap in purpose: hello_agent and alter_login_status both report authentication state at session start, alter_verify and alter_resolve_handle both confirm handle existence, and golden_thread_status and thread_census both describe the same program. The descriptions are strong enough to disambiguate most cases, but the boundaries are not always obvious.
Everything uses snake_case and most names are readable, but conventions are mixed: some tools use the alter_ prefix, others use describe_, get_, register_, or standalone nouns like thread_census and golden_thread_status. recommend_tool is also explicitly misleading, since it returns connection wiring rather than a tool recommendation.
At 16 tools, the set is just above the typical well-scoped range, but each tool serves a distinct free-tier need: onboarding, registration, handle lookup, vocabulary reference, network stats, and program status. The count feels reasonable rather than bloated.
The set covers the anonymous/free surface well: registration, handle resolution, credential introspection, vocabularies, and program status are all present. However, multiple tools referenced in descriptions are absent, including alter_presence_set, verify_identity, query_field, and create_requirement, so core identity workflows around updating presence and performing paid field queries hit dead ends.
