Server Quality Checklist

Tool Scores

• alter_presence_readA
  4.1/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true, and the description consistently presents a read operation. It adds valuable behavioral detail beyond annotations: the response reveals only open-or-closed and never discloses the specific non-open state, and it clarifies the prerequisite conditions. No contradiction with annotations is present.

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

  Conciseness4/5

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

  The description is relatively compact and front-loaded with the core purpose, but it repeats the 'open' concept several times across four sentences. The redundancy is mild and does not obscure meaning, but a leaner wording would earn a top score.

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

  Completeness4/5

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

  For a simple one-parameter read tool with no output schema, the description provides the essential return semantics (open-or-closed only), the prerequisite state conditions, and the cost notice. It does not cover error cases or the exact output type, but that is minor for this low-complexity tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The single parameter 'handle' is already fully documented in the schema with type, max length, and an example. The description does not add new parameter semantics beyond saying the target is a ~handle, so it neither improves nor fails to compensate for schema coverage, which is already 100%.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the specific operation: reading whether a ~handle is publicly 'open', with the shop-front sign metaphor. It also distinguishes the return contract (open-or-closed only) and does not confuse the read nature with the 'alter_' prefix.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives clear context for when to call it: when you need to know if a handle is publicly open, and it notes the caller-facing condition that the handle must have enabled public presence and currently be open. It does not explicitly name alternatives or exclusions, but the tool's narrow purpose makes the usage context reasonably clear.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• get_network_statsA
  4.2/5.0
  Behavior4/5

  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 known. The description adds valuable context by listing the returned metrics and explicitly stating 'Free L0, no authentication required,' which goes beyond annotation information. It does not contradict 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.

  Conciseness5/5

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

  The description is four concise sentences, each adding independent value: what the tool does, when to use it, what it returns, and access requirements. It is front-loaded and free of redundant detail.

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

  Completeness5/5

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

  For a zero-parameter, read-only tool with no output schema, the description covers all essential information: purpose, use case, return value composition, and authentication cost. An agent has everything it needs to correctly select and invoke this tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters, so there is no parameter-level meaning needed. Per the calibration baseline, 0 params earns a 4. The description does not need to add parameter semantics because there are none.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies a specific verb ('Get'), resource ('network statistics'), and provides an enumerated result set. It also suggests use cases ('health check', 'show network scale'), making its purpose clear. However, it does not explicitly differentiate itself from sibling tools like thread_census or golden_thread_status, so it falls just short of a top score.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The phrase 'Use this for a health check or to show network scale' gives clear context about when to invoke the tool. It does not mention alternatives or when not to use it, so it earns a 4 rather than a 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• get_startedA
  4.2/5.0
  Behavior4/5

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

  Annotations already provide readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds value beyond those by clarifying that this call requires no authentication, is free at L0, and only returns orientation information rather than performing registration. No contradictions with 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.

  Conciseness3/5

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

  The content is front-loaded with 'Start here,' but the description is a dense, run-on chain of semicolon-separated clauses that covers many topics in one paragraph. There is redundancy around free/keyless/no-authentication, and the structure could be improved with bullets or shorter sentences without losing information.

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

  Completeness4/5

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

  With no output schema, the description compensates by listing what the call returns: identity infrastructure definition, pre-key callable tools, pricing/consent path. It also provides the registration flow and cost model, which is substantial context. It does not describe an exact response format, but for a parameterless onboarding tool this is adequate.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has zero properties and schema description coverage is 100%, so the baseline is 4. The description correctly adds no parameter-specific guidance because there are no parameters to document.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies this as the onboarding entry point for ~alter: 'Start here' plus an explicit list of what the call returns (identity infrastructure explanation, callable tools before holding a key, pricing model, consent path). It distinguishes itself from the registration siblings by naming register_autonomous_challenge and register_autonomous as follow-up calls rather than the purpose of this one.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  'Start here' is a strong when-to-use signal, and the description makes the context clear: use this before holding a ~alter key, since it returns the tools callable before a key and explains how to self-register. It does not explicitly state when not to use it or compare with other onboarding-like siblings, so it stops 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.

• thread_censusA
  4.2/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds behavior beyond annotations by disclosing pagination (offset/limit), the returned fields, and the 'Free L0' cost tier. This gives useful operational context without contradicting 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.

  Conciseness5/5

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

  Four short sentences, each carrying distinct information: action/resource, usage intent, returned fields, pagination, and cost. It is front-loaded and contains no filler or redundancy.

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

  Completeness4/5

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

  For a simple read-only listing with two optional parameters, the description covers the key operational details: what is returned, pagination, and cost. There is no output schema, but the listed fields are sufficient for an agent to know what to expect. It could be slightly richer about the exact response format, but nothing critical is missing.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the input schema fully documents limit and offset, including defaults and max. The description only mentions 'Paginated (offset/limit)' without adding semantics beyond the schema, so the baseline of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('List') and resource ('all agents registered on the Golden Thread onboarding program'), with clear scope ('full agent directory'). It lists the returned fields, distinguishing this from siblings like list_archetypes or get_network_stats.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  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: 'Use this to browse the full agent directory.' It provides clear context, though it does not name alternatives or exclusion conditions. Given the sibling set, the purpose is clear enough for an agent to select it appropriately.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• alter_verifyA
  4.3/5.0
  Behavior5/5

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

  Beyond the annotations, the description discloses that results are returned as tier labels rather than numeric scores, that the tool requires authentication, and that credentials can be self-minted via register_autonomous_challenge and register_autonomous. It also clarifies the 'listed free at L0' cost context. No contradiction with readOnlyHint, idempotentHint, or destructiveHint.

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

  Conciseness3/5

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

  The description front-loads purpose and use cases well, but the authentication guidance is stated twice nearly verbatim: 'calling it needs a credential, which an agent can mint for itself with register_autonomous_challenge then register_autonomous' and 'Requires authentication: mint a ~handle for free with register_autonomous_challenge then register_autonomous.' This redundancy reduces conciseness.

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

  Completeness5/5

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

  With no output schema, the description enumerates the key returned fields: registration status, canonical form, account status, archetype, engagement, and attunement tier labels. It also covers when to use, authentication prerequisites, and cost/free status. For a single-parameter read tool, this is complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%: the single 'handle' parameter already documents accepted formatting, case-insensitivity, leading tilde, and max length. The description adds no significant parameter semantics beyond referencing 'a ~handle,' 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.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb ('Check whether') and resource ('a ~handle known to the ~alter identity field'), and clarifies the verification purpose versus acting on a raw typed name. It clearly differentiates this tool from a simple handle-presence or resolution operation.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It explicitly tells the agent when to use this tool: 'before you address, pay or trust someone by handle.' It does not explicitly name alternatives or give when-not-to-use conditions, but the use case is clear enough to route an agent correctly.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• golden_thread_statusA
  4.3/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds useful behavioral context beyond those annotations: the three registration steps (Knots), position affecting Strand milestones, and the L0/authentication access split. 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.

  Conciseness4/5

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

  The description is front-loaded with the main purpose and then adds relevant program mechanics and access details. Each sentence contributes useful context, though the explanation of Strand milestones could be slightly tighter.

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

  Completeness4/5

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

  For a no-argument, read-only status tool, the description covers what the tool returns, access requirements, and program mechanics. With no output schema provided, it does not specify the exact response shape, but the description gives enough functional detail for selection and invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has zero parameters, so there is no parameter burden for the description to carry. The baseline of 4 applies, and the description appropriately focuses on return-level semantics rather than parameter details.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Get') and names a clear resource ('status of ~Alter's agent registration program (the Golden Thread)'). It states exactly what information is available: number of joined agents, own position if enrolled, and how to start. This distinguishes the tool from sibling tools like get_network_stats or thread_census.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly says 'Use this to see...' and gives access context ('Free L0 to view; authentication needed to participate'). It does not name alternatives or state when not to use it, but it provides enough context for an agent to recognize the appropriate situation.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• register_autonomousA
  4.4/5.0
  Behavior5/5

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

  Beyond the annotations (readOnlyHint=false, destructiveHint=true), the description discloses key side effects: the handle is owner-less, the agent key is shown only once, there is no human session, queries go live immediately, and paid reads settle to the handle. It also clarifies authentication requirements ('Free L0, no authentication required'), substantially exceeding what annotations already provide.

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

  Conciseness4/5

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

  The description is dense and every clause carries operational information, but it is structured as one long run-on paragraph. The key action is front-loaded, yet the later stream of details (earn-eligible, paid reads, withdrawing) could be better organized for quick scanning.

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

  Completeness5/5

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

  There is no output schema, so the description carries the full burden of explaining what will happen. It covers the prerequisite challenge, the minting side effects, key visibility, query availability, earning eligibility, payment settlement, withdrawal separation, and authentication. An agent has sufficient context to invoke the tool correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema already covers 100% of the parameters with individual descriptions, including the optional requested_handle. The description adds useful context that 'challenge' comes from a specific sibling tool, but it does not add meaning to individual parameters beyond schema coverage. The baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Complete keyless self-registration') against a clearly identified resource ('your own ~alter principal') and references the prerequisite sibling 'register_autonomous_challenge'. It also delineates the minting action from withdrawal, so an agent can distinguish it 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.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It explicitly states the required precondition: submit a solved proof-of-work challenge from register_autonomous_challenge. It also notes that withdrawing is a separate step. However, it does not explicitly enumerate conditions under which one should instead use one of the sibling alternatives, so some routing inference remains.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• alter_resolve_handleA
  4.5/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so safety is covered. The description adds valuable behavioral context beyond annotations: 'Never returns PII', 'Free L0, no authentication required', and the specific return categories (canonical handle, kind, addressability).

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

  Conciseness5/5

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

  The description is compact and front-loaded: purpose comes first, followed by usage guidance, return summary, and caveats. Every sentence contributes useful information without redundancy or boilerplate.

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

  Completeness5/5

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

  For a single-parameter, read-only tool, the description covers what it returns, when to call it, how it differs from alternatives, cost tier, authentication, and privacy behavior. No output schema exists, but the stated return fields are sufficient for an agent to invoke and interpret the result correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, and the schema already thoroughly documents the parameter, including accepted formats, case-insensitivity, and max length. The description adds minimal extra semantic value beyond reinforcing what a ~handle is, so baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool resolves a ~handle to its canonical form and kind, naming a specific verb, resource, and output. It distinguishes itself from identity verification by explicitly noting 'Never returns PII; use verify_identity for that.'

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly tells the agent when to use this tool: 'Use this as your first call when you have a handle and need to confirm it exists before calling other tools.' It also points to an alternative for PII needs, giving clear decision guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• hello_agentA
  4.5/5.0
  Behavior4/5

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

  Annotations already declare readOnly, idempotent, and non-destructive behavior. The description adds useful context beyond those flags by describing the call as a handshake and outlining what it returns, which helps an agent understand it as a lightweight connection verification rather than a substantive query. It does not contradict any annotations.

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

  Conciseness5/5

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

  The description is three sentences with no filler. The core purpose is front-loaded, the return contents are listed compactly, and the usage instruction is placed before the redundant parameter note. Every sentence earns its place.

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

  Completeness5/5

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

  For a zero-parameter, read-only, idempotent handshake tool with an output schema, the description is complete: it states what the tool does, what it returns, and when to call it. No additional behavioral or prerequisite information is necessary for an agent to invoke it correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters, and the description explicitly notes 'No parameters required,' matching the empty input schema. With no parameters to document, the description is appropriately sufficient and earns the baseline for a zero-parameter tool.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific action ('first handshake with ~alter') and enumerates the concrete return contents: server version, authentication status, trust tier, and available tool counts. This clearly differentiates it from sibling identity/status tools like alter_whoami or alter_login_status by framing it as a connection-establishment check.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It gives explicit usage timing: 'Call this once to confirm your connection works before making other queries.' This is clear context for when to invoke it, though it does not explicitly name alternatives or 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.

• recommend_toolA
  4.5/5.0
  Behavior4/5

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

  Annotations already mark it readOnly and non-destructive. The description adds useful behavioral detail by listing the returned contents (endpoint URL, JSON snippet, tool counts) and the 'Free L0' cost tier, which is helpful 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.

  Conciseness5/5

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

  Three short sentences with no filler: first states what the tool does, second states when to use it, third states expected return contents. Information is front-loaded and every sentence earns its place.

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

  Completeness5/5

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

  For a zero-parameter read-only information tool, the description is fully complete: it names the return payload and the installation context. No output schema exists, but the described return items are sufficient for an agent to invoke the tool and interpret the result.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters, so there is nothing for the description to clarify; the schema coverage is trivially 100%. A baseline of 4 is appropriate because no parameter documentation burden exists.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with a specific verb and resource: 'Get ~Alter MCP server installation instructions.' This directly distinguishes it from sibling tools like alter_resolve_handle or get_network_stats, and the title reinforces the install context.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives explicit triggers: 'Use this when setting up ~alter in a new MCP client or sharing the endpoint with another agent.' It does not mention when not to use it or name alternative tools, but the stated context is clear enough to route an agent.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• register_autonomous_challengeA
  4.5/5.0
  Behavior4/5

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

  Annotations already indicate this is not read-only and is marked destructive, but the description adds meaningful behavior: a proof-of-work challenge must be solved using a specific sha256 construction, and the tool returns challenge, difficulty, expires_at, and a hint. It also discloses that it is free and requires no authentication. The description does not expand on the destructiveHint annotation, but it does not contradict it either.

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

  Conciseness5/5

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

  The description is information-dense with no wasted words. It front-loads the main action, gives the exact cryptographic step, names the next tool to call, and lists the return values—all in a compact block.

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

  Completeness5/5

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

  For a tool with no required parameters and no output schema, the description provides all necessary context: what it does, what to do with the result, what the PoW involves, and what the response contains. The workflow is complete enough for an agent to invoke this tool and proceed correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema already documents agent_name as optional and ignored, but the description reinforces and extends this by explicitly saying it should be provided again to register_autonomous. Since schema description coverage is 100%, the baseline is 3; the additional workflow guidance pushes it to 4.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's purpose: begin keyless self-registration and receive a proof-of-work challenge before calling register_autonomous. It uses an explicit verb ('Begin'), names the resource ('self-registration'), and distinguishes itself from the follow-up sibling by saying 'Call this FIRST'.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives explicit usage context: call this tool first, solve the proof-of-work, then call register_autonomous with the challenge and nonce. It also states the PoW is a Sybil defence and that no human account or authentication is required. It does not explicitly list cases where this tool should not be used, but the step-by-step workflow is sufficiently clear.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• alter_login_statusA
  4.7/5.0
  Behavior5/5

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

  Annotations already declare readOnly, idempotent, and non-destructive behavior; the description adds that a credential is required, that the call is free at L0, and exactly what authentication data is returned: member/agent role, scopes, tier, expiry, method, and an opaque key prefix. This meaningfully goes beyond the annotations.

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

  Conciseness4/5

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

  The description is well-organized and front-loaded with purpose and usage before return details. Each sentence earns its place, though the L0 pricing note and credential clarification make it slightly longer than strictly necessary.

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

  Completeness5/5

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

  With no output schema, the description carries the full burden of explaining return values, and it does so in detail. It covers when to call it, what it reports, and the credential requirement, making it complete for a zero-parameter read-only tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema has zero properties and the description explicitly reinforces this with 'Takes no parameters.' It also clarifies that the credential is not a parameter but the subject being reported on, which removes potential confusion for an agent deciding how to invoke it.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb ('Check') and resource ('the credential you are holding'), and explains that it distinguishes expired credentials from scope-based authorization failures. This clearly separates it from sibling tools like alter_verify and alter_whoami without needing to inspect their schemas.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It gives explicit trigger conditions: 'when a call has failed on authorisation, or at the start of a session.' It frames the decision as expired credential versus unreachable scopes, but does not name specific alternative tools or explicit when-not conditions, so it stops 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.

• alter_whoamiA
  4.7/5.0
  Behavior5/5

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

  Annotations already declare read-only and idempotent safety. The description adds valuable behavior beyond annotations: the target parameter switches to an institutional projection, only ~alter is recognized, other values fall through to self-projection, and institutional mode is free. It also discloses the authentication prerequisite. 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.

  Conciseness5/5

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

  The description is compact and front-loaded with the primary purpose, then explains the optional parameter and authentication context. Every sentence adds useful information without padding. It manages to convey substantial behavior in a few sentences.

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

  Completeness5/5

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

  For a one-optional-parameter read-only tool with a fully described schema and annotations covering safety, the description covers the return concept, the special mode, the fallback behavior, and authentication. No output schema exists, but the description sufficiently outlines the response semantics for an agent to understand what to expect.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% and the schema already documents the target parameter. The description adds meaning beyond the schema by explaining the projection switch, the protocol-tier handle behavior, and the fall-through path requiring member_self scope. This enriches the parameter semantics beyond a mere restatement.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  States a specific verb and resource: 'Returns canonical handle and user summary for the authenticated member.' This clearly identifies the tool as a self-identity lookup and differentiates it from sibling tools like alter_resolve_handle or alter_presence_read by focusing on the authenticated member's own identity.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Provides clear context: use for the authenticated member's identity, with an optional institutional projection mode, and explicitly notes authentication requirements plus a free registration flow. It does not explicitly name alternatives or when-not-to-use conditions, but the context is strong enough for an agent to select it appropriately among siblings.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• describe_competenciesA
  4.7/5.0
  Behavior5/5

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

  Beyond the annotations, the description discloses meaningful behavior: graded claims 'take a min_level', while binary or credential claims refuse min_level, and only definitions are returned, not member evidence. It also states no authentication is required, which the annotations do not cover. 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.

  Conciseness5/5

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

  The description is dense but every sentence earns its place: purpose, claim-type behavior, intended use, content boundary, and access level. The primary purpose 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.

  Completeness5/5

  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 with no output schema, the description provides enough to decide and invoke correctly: what is returned, how results are grouped, refusal semantics, intended usage, and authentication requirements. Nothing essential is missing.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  This tool has zero parameters, so the schema carries no parameter burden; the baseline for 0-parameter tools is 4. The description adds useful context about how outputs are grouped and denominated, which is more than the empty schema could convey.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb and resource: 'List the published competency vocabulary' and adds scope ('every code the field can be asked about') and grouping behavior ('grouped by how the claim is denominated'). This clearly distinguishes it from sibling tools like describe_traits.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It explicitly instructs when to call this tool: 'Use this before composing query_field competency_requirements.' It also clarifies content scope ('Definitions only, no member evidence') and access level ('Free L0, no authentication required'). It does not name alternatives or when-not conditions, so it stops 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.

• describe_traitsA
  4.7/5.0
  Behavior5/5

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

  Beyond the readOnly/idempotent annotations, the description adds meaningful behavioral context: 'Static reference data', 'Free L0, no authentication required', and the data limitation that certain traits are never returned about a third party. These details help the agent set expectations without contradicting 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.

  Conciseness5/5

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

  The description is compact and front-loaded: it begins with the core purpose, packs the content scope into a parenthetical list, then gives usage timing and access characteristics. Every sentence carries useful information with no filler.

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

  Completeness5/5

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

  Even without an output schema, the description states what the response will cover (codes, categories, semantics, valid discovery contexts, third-party exclusions), when to use the tool, and access requirements. That is sufficient for a no-input reference tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool accepts zero parameters, and schema coverage is 100%, so there is nothing for the description to add about parameters. The baseline of 4 for a no-parameter tool is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('List') and resource ('canonical trait vocabulary'), then details the content: 30 trait codes, category names, one-line semantics per code, valid discovery contexts, and third-party exclusions. This distinguishes it clearly from sibling reference tools like list_archetypes and describe_competencies.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It explicitly instructs the agent to use this before composing query_field trait_priorities or create_requirement trait_criteria, which is strong contextual guidance. It does not explicitly name alternative tools or when-not-to-use conditions, but the intended usage is clear enough.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• list_archetypesA
  4.7/5.0
  Behavior5/5

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

  Annotations already flag read-only and idempotent behavior, and the description adds meaningful behavioral context: it returns static reference data, is free at L0, and requires no authentication. This is exactly the kind of cost/auth/behavior information that helps an agent invoke the tool safely.

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

  Conciseness5/5

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

  Three short sentences deliver the output contents, the use case, and the operational characteristics without redundancy. The most decision-relevant information is front-loaded.

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

  Completeness5/5

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

  For a zero-parameter, static, read-only tool with rich annotations, this description provides everything an agent needs to decide to call it and know what to expect. No output schema is needed because the described fixed contents are sufficient.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters, so the baseline is 4. The description appropriately avoids inventing parameter details and instead describes the fixed output content, which is all the semantic value needed for a parameterless call.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description names the specific resource ('all 12 identity archetypes') and the exact contents returned ('names, descriptions, and protective equations'), making the tool's purpose unmistakable. It clearly distinguishes itself from sibling trait/comparison tools by positioning this as the static taxonomy reference.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives explicit contextual guidance: use it to understand ~alter's identity taxonomy before interpreting trait data. It does not name specific sibling alternatives or explicit when-not-to-use conditions, but the intended usage timing is clear.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.