~Alter Identity

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds value by specifying the actual data returned (key validity, scopes, expiry), providing useful context 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 a single, focused sentence that conveys the tool's purpose without any wasted words. It is highly efficient and front-loaded with the key action and resource.

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, the description provides enough information: what it returns and for whom. It lacks a note about output format or how this differs from alter_whoami, but the simplicity of the tool lowers the required completeness bar.

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

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

The tool has zero parameters, so the schema provides no burden. Baseline for no parameters is 4; the description appropriately avoids inventing unnecessary parameter 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 uses a specific verb 'Returns' and clearly identifies what is returned: key validity, scopes, and expiry for the authenticated member. This distinguishes it as a read-only status query, even though the tool name 'alter_login_status' misleadingly suggests mutation.

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

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

The description implies the tool is used to inspect authentication state, but it does not explicitly compare it with sibling tools like alter_whoami or alter_verify. There is clear context ('for the authenticated member') but no when-to-use or exclusion guidance.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds valuable behavioral context: 'Free for callers' (cost), the privacy constraint 'the specific non-open state is never disclosed', and a prerequisite ('must have enabled public presence AND currently be in the open state'). While the prerequisite could be slightly clearer, it enriches understanding beyond annotations.

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

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

The description is concise at about four sentences, with the main purpose front-loaded. Each sentence adds useful information (purpose, cost, return value, prerequisite). The last sentence is slightly awkward but not redundant or overly verbose.

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

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

For a simple tool with a single parameter and no output schema, the description adequately explains what it returns ('open-or-closed only'), the prerequisite, and the cost model. It does not need to elaborate on return structure since the output is described, and annotations cover safety.

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

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

Schema coverage is 100% for the single 'handle' parameter, and the schema description already explains the format ('Target ~handle to read, e.g. ~blake'). The tool description does not add additional parameter-level semantics, so this meets the baseline for high schema coverage.

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

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

The description clearly states the tool's purpose with a specific verb ('Read') and resource ('whether a ~handle is publicly open'), and distinguishes it from mutation-focused siblings by emphasizing it is a read operation. The 'shop-front sign' metaphor and 'Returns open-or-closed only' further pin down its exact scope.

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

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

The description provides clear context for when to use this tool: to check public presence of a handle. It does not explicitly name alternatives or exclusions, but the emphasis on 'read' and the limited return value ('open-or-closed only') implies when it is appropriate. The sibling set (e.g., alter_login_status) provides additional context, so the guidance is adequate.

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

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

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

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

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

The description is a tight paragraph that front-loads the primary action, then gives usage, return values, exclusions, and cost/auth in sequence. Every sentence earns its place with no redundancy.

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

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

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

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

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

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

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

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

The description clearly states the tool resolves a ~handle to its canonical form and kind, with a specific verb and resource. It also distinguishes itself by noting that verify_identity is for PII, positioning this tool for existence confirmation rather than identity details.

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

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

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

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds the useful context that the check occurs specifically 'in the ~alter identity field.' However, it does not disclose the return format or behavior when the handle does not exist, so it provides limited additional transparency beyond what the annotations already convey.

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

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

The description is a single sentence that front-loads the action verb and resource, contains no extraneous words, and is efficiently structured. It is appropriately sized for the tool's simplicity.

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

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

The tool is simple with one parameter and no output schema, and the description conveys the core action of checking existence. However, it omits details about what the tool returns (e.g., boolean success or error), and it does not position the tool relative to siblings. Given the lack of output schema and usage guidance, this is a notable gap, though the low complexity keeps it within the mid-range.

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 offers 100% coverage for the single parameter 'handle', including its type, maxLength, and description about the optional leading ~. The tool description adds no new parameter-specific information beyond what the schema already contains, though it does clarify the verification scope. A score of 3 is appropriate given the high schema coverage.

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

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

The description uses the specific verb 'Checks' and identifies the resource as '~alter identity field', clearly stating the tool's function of verifying handle existence. It implicitly distinguishes itself from sibling tools like alter_resolve_handle, which likely involve resolution rather than mere existence checking, though it does not explicitly name alternatives.

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?

No explicit usage guidance is provided. The description does not state when to use this tool versus alter_resolve_handle or other siblings, nor does it mention any prerequisites, limitations, or alternative scenarios. The intended context is only implied by the tool name and description.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral details: the target parameter switches to an institutional projection, 'any other value falls through to the self-projection path,' and it notes special fields like 'honest-empty trait vector' and 'social_legibility.' This goes beyond the annotations without contradicting them.

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

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

The description is three sentences, front-loaded with the primary purpose. Each sentence adds meaningful information: the base function, the optional target behavior, and the authentication note. It is a bit dense with technical specifics but avoids fluff, and all content earns its place.

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

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

For a tool with no output schema, the description does a good job explaining the return content (canonical handle, user summary, institutional projection fields). It covers authentication requirements, free institutional mode, and fallback behavior. It could be more explicit about the self-projection scope requirement (mentioned in schema but not description), but overall it is complete for the tool's complexity.

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

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

The input schema has 100% coverage, already explaining that target 'today only ~alter is recognised' and any other value falls through to the self-projection path. The description repeats this and adds response details, but it does not add new parameter-specific semantics beyond the schema's own description, so the baseline score of 3 is appropriate.

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

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

The description clearly states that the tool 'Returns canonical handle and user summary for the authenticated member,' using a specific verb and resource. It distinguishes itself from sibling tools like alter_resolve_handle by focusing on the caller's own authenticated identity, and it details the optional target behavior for institutional projection.

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

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

The description provides clear context on when to use institutional mode ('free for all callers') and how to authenticate ('mint a ~handle for free with register_autonomous_challenge then register_autonomous'). It implies the tool is for self-identity checks, but it does not explicitly name alternatives such as 'use alter_resolve_handle for resolving other handles,' so it lacks strong exclusions.

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

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

Annotations already declare readOnlyHint and idempotentHint, but the description goes far beyond by explaining nuanced behavior: how graded claims require min_level while binary claims refuse min_level. It also discloses that no authentication is required, adding operational context not present in annotations.

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

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

The description is dense but front-loaded: the first clause states the primary action. It uses three sentences to cover purpose, behavioral nuance, and usage, with no fluff. The only slight excess is the 'Free L0, no authentication required' clause, but it adds operational value. Overall well-structured.

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

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

For a no-parameter, no-output-schema definitional tool, the description provides complete context: what it lists, how items are grouped, special behaviors for claim types, a usage context, and operational constraints. The absence of return-format details is acceptable given the nature of the tool.

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

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

The tool has zero parameters; schema coverage is trivially 100%. The baseline for zero parameters is 4, and the description appropriately focuses on the output semantics rather than parameters, so no deduction is needed.

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

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

The description opens with 'List the published competency vocabulary', providing a specific verb and resource. It clearly distinguishes this from siblings like describe_traits and list_archetypes by focusing on competency codes and their denomination groups. The scope is explicitly defined as 'every code the field can be asked about'.

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

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

The description gives a clear usage directive: 'Use this before composing query_field competency_requirements'. It also implicitly distinguishes from member-data tools by stating 'Definitions only, no member evidence'. However, it does not explicitly mention alternatives or conditions when not to use it.

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

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 behavioral context by stating "Static reference data" and "Free L0, no authentication required", which goes beyond the annotations and clarifies the access profile and nature of the operation.

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

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

The description is concise and front-loaded with the main purpose, then adds usage and access context in a compact format. Every sentence adds value without unnecessary verbosity.

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?

Since there is no output schema, the description needs to explain the return value, which it does by listing the 30 trait codes, categories, one-line semantics, discovery contexts, and gating rules. This is sufficient for a static, no-parameter reference tool.

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

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

The tool has zero parameters, so the schema provides complete coverage of parameters. The description correctly does not need to add parameter details, but it does mention the output structure which indirectly defines what the tool returns.

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

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

The description clearly states the tool lists the canonical trait vocabulary with 30 trait codes grouped by category, providing a specific verb and resource. It also mentions the additional content (discovery contexts, EU AI Act gating rules), which distinguishes it from sibling tools like describe_competencies or list_archetypes.

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

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

The description provides explicit guidance on when to use the tool ("Use this before composing query_field trait_priorities or create_requirement trait_criteria") and notes it is static reference data. It does not name alternatives or exclusions, but the usage context is clear.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, but the description adds useful context: 'Free L0, no authentication required' and the specific return fields (total identities, verified profiles, query volume, active agent count). This goes beyond what annotations provide.

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

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

Two concise sentences front-load the purpose, then add use cases, return fields, and access details. Every sentence adds value with no redundancy or filler.

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

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

The description fully covers the tool's purpose, use cases, return content, and access requirements. With no output schema, listing the returned metrics is sufficient. The simple scope and strong annotations mean no additional context is needed.

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

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

The tool has zero parameters, so schema coverage is 100%, and the baseline for 0 params is 4. The description doesn't need to explain parameters; it focuses on the output metrics, which is appropriate.

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

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

The description clearly states the tool gets aggregate network statistics, with a specific verb ('Get') and resource ('~alter network statistics'). It distinguishes from siblings by being the only network stats tool and names specific metrics returned.

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

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

The description explicitly says to use it for a health check or to show network scale, providing clear usage context. It does not mention when not to use it or alternatives, but the guidance is sufficient for a zero-parameter read-only tool.

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

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

While annotations already declare readOnly, idempotent, and non-destructive behavior, the description adds key context: no authentication required, free tier, and the fact that the call returns specific content (identity explanation, tool list, pricing note, consent path). This goes beyond the annotations without contradicting them.

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

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

The description is a dense, run-on paragraph that mixes agent instructions, tool output contents, and platform details. It is not well-structured or concise, making it harder to parse quickly. Breaking it into clear sentences or bullets would improve readability.

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

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

Given there is no output schema, the description carries the burden of explaining return value and usage context. It does cover the essential information: what ~alter is, tools available before a key, pricing model, and consent path. However, the messy structure slightly detracts from completeness.

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

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

The tool has zero parameters, so schema coverage is trivially 100%. Per the baseline for 0-parameter tools, a score of 4 is appropriate; the description doesn't need to elaborate on parameters, but it does provide context about what the tool accomplishes.

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

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

The description clearly states this is the onboarding entry point ('Start here') and specifies that the call returns foundational information about ~alter, callable tools before holding a key, pricing model, and consent path. It distinguishes itself from registration and query sibling tools by positioning itself as the initial resource.

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

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

The description explicitly says to start here, instructs the agent to register if it has no key (referencing register_autonomous_challenge and register_autonomous), and contrasts free L0 with paid depth, giving clear context for when to use this versus more advanced tools.

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

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

Annotations already declare read-only and idempotent behavior. The description adds context about authentication requirements ('authentication needed to participate') and program mechanics (three registration steps, Strand milestones), which go beyond the annotations' safety profile.

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

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

The description is three sentences, each earning its place: first states the main purpose, second gives use cases, third provides program context and access constraints. It is front-loaded with the primary verb and resource, with no fluff.

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

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

The description covers what the tool does, what information it returns (count, position, how to start), and access conditions. Given there is no output schema, it adequately describes the expected content, though it could clarify the exact response format (e.g., whether counts are numeric or include details).

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

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

The tool has zero parameters, so the schema provides full coverage. The description adds context about what status information is available (count, position, how to start) without needing parameter details, which is appropriate for a no-param 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 clearly states it gets the status of a specific program (Golden Thread) using the verb 'Get' and specifies the exact information returned (how many agents joined, user's position, how to start). This distinguishes it from sibling tools by naming the program and its unique focus.

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 use cases: 'Use this to see how many agents have joined, your own position if enrolled, and how to start.' It also notes access conditions (free L0 view, authentication needed to participate). However, it does not mention alternative tools or when not 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.

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

Annotations already declare read-only and idempotent behavior. The description adds value by detailing the response contents (server version, auth status, trust tier, tool counts) and the intended one-time usage, going beyond what annotations alone provide. No contradictions found.

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

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

The description is two sentences, front-loaded with the key purpose ('First handshake'), followed by return values and usage instruction. Every word adds value with no redundancy or fluff.

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

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

The description fully covers the tool's purpose, return values, and usage timing. The output schema exists, and the simple zero-parameter nature means no additional context is needed. It is complete and self-contained.

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

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

The tool has zero parameters, and the description explicitly states 'No parameters required,' aligning with the empty schema. With no parameters to explain, the baseline of 4 is appropriate.

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

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

The description clearly identifies the tool as a handshake/connection check with ~alter, specifying exactly what it returns (server version, auth status, trust tier, available tool counts). This distinguishes it from sibling tools like alter_whoami or alter_verify, making its purpose unambiguous.

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

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

The description instructs to 'Call this once to confirm your connection works before making other queries,' providing clear usage context. It does not explicitly mention alternatives or exclusions, but the guidance is specific enough to indicate when to use it.

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

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

Annotations already declare read-only, idempotent, and non-destructive. The description adds valuable context by stating it 'Returns static reference data' and 'Free L0, no authentication required,' which communicates the stable, low-friction nature of the call beyond the annotations.

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

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

The description is three short sentences. The first sentence delivers the core action and output content, the second provides usage context, and the third covers constraints. Every sentence carries meaning with no redundancy.

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

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

For a parameterless reference tool with no output schema, the description fully explains what is returned (names, descriptions, protective equations), when to use it, and its static, unrestricted nature. It is self-contained and needs no additional detail.

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

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

This tool has zero parameters, so the schema trivially covers everything. The description doesn't need to explain parameters; the baseline 4 applies, and no further parameter information is required.

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

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

The description opens with 'List all 12 identity archetypes with names, descriptions, and protective equations,' which is a specific verb+resource+scope. It clearly distinguishes this from sibling tools like describe_traits or get_started by focusing on the archetype taxonomy.

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

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

The description provides explicit usage context: 'Use this to understand ~alter's identity taxonomy before interpreting trait data.' This tells the agent when to invoke it, though it doesn't name alternative tools or explicitly state when not to use it.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds useful context by specifying the return value (endpoint URL, JSON configuration snippet, tool counts) and the 'Free L0' cost note, going beyond what annotations provide.

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

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

The description is three concise sentences, front-loaded with the main purpose, followed by usage guidance and expected output. No unnecessary information.

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

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

Given the tool has no parameters and no output schema, the description adequately covers what the tool does, when to use it, what it returns, and cost information. It is complete for this simple tool.

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

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

The tool has zero parameters, so the schema fully covers parameter semantics. The baseline score of 4 is appropriate per the rubric.

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

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

The description clearly states the tool provides installation instructions for ~Alter MCP server, using a specific verb ('Get') and resource. It is distinctly different from sibling tools which handle authentication, presence, or other operations.

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

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

The description explicitly states when to use the tool: when setting up ~alter in a new MCP client or sharing the endpoint with another agent. It does not mention alternatives or exclusions, but the context is clear enough.

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

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.

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.

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds meaningful context beyond that: it discloses pagination behavior (offset/limit), the fields returned (position, milestone count, weave count, join date), and the 'Free L0' cost/access level, making behavior 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?

Three concise sentences, front-loaded with the core action. Every sentence provides useful information with no fluff. The inclusion of 'Free L0' is brief but presumably meaningful in context.

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

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

For a simple read-only list tool, the description covers the essential context: what it lists, how to use it, returned fields, pagination, and cost level. No output schema exists, but the description sufficiently explains the return 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?

Input schema has 100% coverage for limit and offset parameters with clear descriptions. The description's mention of 'Paginated (offset/limit)' merely reinforces the schema without adding new semantic meaning. 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 uses a specific verb ('List') and resource ('all agents registered on the Golden Thread onboarding program'), clearly distinguishing it from sibling mutation tools like alter_* or register_*. It also states the purpose of browsing the full agent directory.

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 clearly indicates when to use the tool ('Use this to browse the full agent directory'), providing useful context. It does not explicitly mention alternatives or exclusions, but the tool is obviously the directory-listing counterpart to the sibling tools.

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