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

With no annotations provided, the description carries the full behavioral burden. It discloses key side effects: the server verifies the hash, publishes a dereferenceable copy, and optionally links a replacement attempt. It stops short of explaining reversibility or failure behavior, but the main behavioral profile is well communicated.

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 dense sentences each carry weight: purpose, required inputs plus verification behavior, and the optional parameter. There is no filler or repetition of the schema content.

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

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

The description explains the purpose, the verification mechanism, and the published outcome, which is helpful for a tool with no output schema and no annotations. However, it omits the precise meaning of failed_gate, the response or return behavior, and whether closing the attempt is irreversible. These gaps matter for an abort operation with six parameters.

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

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

Schema description coverage is only 33%, so the description must compensate. It maps 'typed failure' to failed_gate_kind, 'exact JSON receipt string' to preflight_receipt, and 'later replacement attempt' to successor_attempt_id. However, failed_gate remains semantically ambiguous, and attempt_id is only implied, leaving meaningful gaps for a correct call.

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

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

The description states a specific verb ('close'), a specific resource ('your open attempt'), and a precise condition ('without a measurement after a predeclared admissibility gate fires'). This clearly distinguishes it from siblings like submit_measurement or mint_attempt, even though no sibling is explicitly named.

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: after an admissibility gate fires and when there is no measurement to submit. It does not explicitly name alternatives or state when not to use it, but the intended context is clear from the wording and the sibling set.

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?

With no annotations, the description carries the full behavioral disclosure burden, and it adds useful facts: the snapshot is immutable and the integrity check is recomputed, implying deterministic results for a given digest. It does not cover errors or permissions, but for a simple get operation these are less critical.

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 one short sentence with no filler and places the most important qualifier, immutable, up front. Every word contributes meaning.

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 low-complexity single-parameter read tool, the description names the main return components and gives a clear behavioral promise. However, with no output schema and no explanation of digest provenance, an agent might still need additional context to call it confidently.

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 only parameter, digest, is completely undocumented: schema description coverage is 0% and the description never states that digest identifies which snapshot to fetch or where a valid digest comes from. The schema's hex pattern only validates format, not meaning.

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 identifies the tool as returning a single immutable adoption snapshot with a historical summary and a recomputed integrity check, which gives a clear picture of the resource. It does not explicitly name or differentiate sibling tools like get_adoption_trends, but the snapshot-specific language is enough for basic selection.

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 guidance is provided about when to choose this tool over siblings such as get_adoption_trends, get_register, or get_changelog. There is no mention of prerequisites, such as needing a digest from another tool, which weakens an agent's ability to route correctly.

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?

With no annotations, the description carries the burden. It discloses key behaviors: 'Append-only' indicates historical immutability, and 'Missing coverage is never represented as observed zero' is a critical caveat about data representation. It also lists the three output components. This is substantial behavioral context beyond what the empty schema provides.

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 two-sentence composition that front-loads the primary purpose ('append-only adoption history') and then layers supporting details (trends, alerts) with a critical caveat. No filler or 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 zero-parameter tool with no output schema, the description provides a reasonable mental model: it names the three content areas and a key data-interpretation rule. However, details like the exact time range for 'recent' or the output format are left unspecified, which could be relevant for an agent deciding whether the returned data suits a query.

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

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

There are zero parameters, so the schema imposes no burden. Per the rubric, a zero-parameter tool receives a baseline of 4. The description adds no parameter-specific meaning because none are 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 clearly states the resource ('adoption trends') and the kind of data provided: 'append-only adoption history, descriptive recent-usage trends, and explicit missing or expiring coverage alerts.' It goes beyond a tautology and implicitly distinguishes from siblings like get_adoption_snapshot by mentioning trends and alerts, but 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?

The description implies usage for adoption trends and alerts, but it does not provide explicit when-to-use or when-not-to-use guidance, nor does it reference any sibling tools (e.g., get_adoption_snapshot). The absence of comparison leaves an agent to infer the appropriate context.

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?

With no annotations, the description carries the full burden, and it provides substantive behavioral context: 'append-only' implies immutability, 'hash-chained' indicates integrity protection, and 'recompute recipe' and 'independent timestamp state' describe how the changelog is structured or reproduced. It could add explicit read-only or error behavior, but these traits are meaningful and non-generic.

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 dense sentence with no filler. However, the qualifiers are packed into a noun phrase rather than a readable tool behavior statement, which slightly reduces clarity despite the efficient length.

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 getter, the description gives enough conceptual content to understand what is returned, but it lacks an explicit statement of the return value or behavior and offers no comparison to nearby siblings. Without an output schema or annotations, a slightly more actionable description would make the tool easier to select and invoke correctly.

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

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

The tool has zero parameters and schema coverage is trivially 100%, so no parameter documentation is needed. The description adds context about the object being retrieved, which is sufficient for a parameterless getter.

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

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

The description names a specific resource, the append-only hash-chained register changelog, and the tool name 'get_changelog' implies retrieval. It is not a tautology and gives more specificity than 'changelog', but it lacks an explicit verb such as 'returns' or 'lists', so it stops short of top-tier clarity.

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?

There is no guidance on when to use this tool versus alternatives like get_history, get_register, or get_register_pack. The description does not state a preferred use case, exclusions, or any conditions that should route an agent to a sibling 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?

With no annotations provided, the description carries the full transparency burden. It uses 'Reading' and contrasts this with 'a real proposal or amendment... records' to indicate that this call has no side effects and takes no input. It does not discuss authentication or rate limits, but for a zero-parameter getter that is a minor omission.

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

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

Two sentences deliver the core return value, the no-input behavior, and the downstream fail-closed pin usage without any filler. The most important information is front-loaded.

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 zero parameters, no annotations, and no output schema, the description is complete: it specifies what is returned (text, version, digest), that no input is accepted, and why the digest matters. Nothing essential is missing for an agent to call this tool correctly.

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

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

The schema is empty, so the baseline is 4, and the description strengthens this by explicitly stating 'Reading accepts nothing,' leaving no doubt that zero arguments are expected. No additional parameter-level detail 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 first sentence identifies the exact resource (current contribution-terms text) and the returned fields (version and SHA-256 digest), making the tool's function unmistakable. It is distinct from all sibling get_* tools by its unique resource, and the second sentence reinforces that this is a read-only retrieval, not an acceptance or recording 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 explicitly says 'Reading accepts nothing,' signaling clear zero-argument invocation, and explains when the version/digest pin is relevant ('only when you want an exact fail-closed pin'). It does not name a sibling alternative or state when not to use this tool, so a small gap remains.

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?

With no annotations, the description carries the behavioral disclosure burden. It usefully indicates the record is public and lists returned content categories, implying a read-only operation. It does not explicitly state read-only behavior, error cases, or output format, but for a simple lookup the disclosure is minimally adequate.

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?

A single, front-loaded sentence states the resource, the lookup keys, and the record contents with no wasted words. Every clause contributes useful information.

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

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

Given the tool's simplicity, one parameter, and no output schema, the description is nearly complete: it explains what the record contains and how the identifier is supplied. It does not describe the output structure, but listing the content categories provides enough context for an agent to select and invoke the tool correctly.

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

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

The single parameter is already fully documented in the schema ('Colony username, sub, or display name'), and the description repeats that same identifier guidance. The description adds no new parameter-level meaning beyond what the schema provides, so the baseline of 3 applies.

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

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

The description identifies the resource as "a contributor's public record" and specifies lookup by Colony username, sub, or display name, with a clear list of included content. It lacks an explicit verb like 'retrieves' or 'gets,' but the tool name and content list make the purpose clear and distinguish it from sibling tools for measurements, proposals, and observatory data.

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

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

Use is implied: to fetch a contributor's public record using one of the accepted identifiers. However, it does not explicitly state when to prefer this tool over alternatives or when not to use it, leaving some routing decisions to the agent.

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?

There are no annotations, so the description must disclose side effects, permissions, and mutation behavior itself. It calls the operation an 'audit' but 'with typed remediation' is ambiguous about whether the tool only reports remediation or actively changes state; auth and side-effect expectations are unstated.

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?

One dense sentence with no filler and the core scope is front-loaded. The phrase 'with typed remediation' is ambiguous, which slightly weakens the structure, but the description is not bloated.

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 tool in a domain with many sibling tools, the description should clarify what the audit returns, whether remediation is applied or merely suggested, and what conditions warrant running it. None of that is present, so the agent cannot fully predict the call's result.

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 accepts zero parameters and the schema has no properties, so there is no parameter semantics for the description to add. The baseline for zero-parameter tools applies.

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

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

The description gives a specific verb ('audit') and a defined scope ('register-wide') and a precise target ('explicit accepted token bounds that contradict legacy generic token_delta prerequisite semantics'), which distinguishes it from the generic get_* retrieval siblings. It is not a tautology or vague. However, the heavy domain jargon and the unstated meaning of 'typed remediation' prevent it from being a fully plain-language purpose statement.

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 when-to-use or when-not-to-use guidance appears; the description does not name alternatives or conditions that select this tool over siblings such as get_register or get_semantic_map. 'Narrow' implies specialized scope but does not tell an agent when to invoke 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?

No annotations are provided, so the description carries the full behavioral burden—and it makes good use of that space. It explicitly discloses that edges only identify the same entry across adjacent axes and 'do not claim causation or form a score', which prevents an agent from misinterpreting the graph semantics. It also states the six receipts are 'independent', a meaningful structural guarantee. It does not describe the response format, but for a zero-parameter read-only tool the disclosed caveats are the most important behaviors.

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

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

Two sentences, no filler. The first sentence front-loads the core content and enumerates the six axes compactly; the second delivers the essential interpretive caveat. Every phrase earns its place.

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

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

For a zero-parameter get tool with no output schema, the description covers both what the map contains (six axes) and how the edges should be interpreted (identity mapping, not causation or scoring). A minor gap is the absence of sibling differentiation and the meaning of 'receipt', but the description is largely sufficient for an agent to call the tool and understand the result.

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

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

The tool takes zero parameters, so the schema fully documents the interface and the description cannot add parameter-level meaning. Per the baseline for 0-param tools, a 4 is appropriate; there is nothing semantically missing that the description would need to compensate for.

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 resource—a map with six evidence dimensions per flagship example—and enumerates the axes (editorial surface, lifecycle, evidence contract, etc.), so an agent can tell what data this tool exposes. However, it lacks an explicit verb like 'retrieve' or 'returns', relying on the 'get_' prefix to convey the operation, and it never names a sibling to distinguish itself from.

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?

There is no when-to-use guidance, no exclusions, and no mention of alternatives. Given the large sibling set including get_semantic_map, get_evidence_contract_audit, and get_adoption_trends, an agent must guess which tool covers which question. The only usage signal is the implied context of 'flagship examples' and 'evidence', which is thin.

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?

There are no annotations, so the description carries the full burden of behavioral disclosure. It describes data composition but does not state that this is a read-only listing operation, whether there are limits or pagination, how fresh the joined data is, or what the caller should expect in the response. The jargon 'claim guards' also leaves behavior unexplained.

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

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

The description is a single sentence with no redundant phrasing. It front-loads the core resource and then lists the joined dimensions. However, the heavy use of domain-specific terms makes it dense and less immediately readable than it could be.

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?

Without annotations, an output schema, or parameter details, the description must supply more operational context. It mentions the joined data dimensions but not the return shape, ordering, filtering, permissions, or limitations. An agent would likely still be uncertain about what a 'flagship' or 'claim guard' is and what the response looks like.

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 there are no parameter semantics for the description to clarify. The schema already fully covers this with an empty properties object, and the description does not need to compensate for undocumented parameters.

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

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

The description identifies a specific resource — a curated human-facing flagship shortlist — and the key data dimensions it is joined to (lifecycle, evidence, qualification, adoption coverage, claim guards). While it lacks an explicit verb like 'returns' or 'lists', the intent is clear enough from the name and noun phrase, and it is not a tautology.

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 no guidance on when to use this tool instead of a sibling tool. It does not mention alternatives like get_flagship_evidence_map or get_adoption_trends, nor does it state exclusions or prefer conditions. The implied use case is only 'you want the flagship shortlist,' which is not explicit 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?

No annotations are provided, so the description carries the burden of disclosing behavior. It clearly states the return structure, the ordering, and the specific per-hop fields; this is meaningful context beyond the get-prefix. It does not mention empty results or authorization, but for a history-read tool the core behavior is sufficiently disclosed.

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?

A single dense sentence conveys the tool's purpose, ordering, and output fields without waste. The colon-delimited list front-loads the core concept (supersession chain) and then supplies per-hop specifics.

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

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

With no output schema and no annotations, the description must stand alone, and it covers the main needed information: scope, ordering, per-hop diffs, surface-only flag, and evidence transport. Some concepts like 'supersession chain' and 'hop' are domain-specific and not defined, but for an agent familiar with the proposal domain this is complete enough.

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 describes slug as 'The proposal slug' with 100% coverage, so the baseline is 3. The description adds that the slug identifies a proposal and that a full supersession chain is returned, but it does not add format-level detail or constraints beyond the schema. It is adequate but not enriching 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 names the exact resource (a proposal's supersession chain), specifies ordering (oldest first), and enumerates the per-hop contents, making the tool's function precise. This distinguishes it from siblings like get_changelog and get_proposal by focusing on the supersession chain rather than general history.

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?

Usage is implied from the description: an agent should use this when it needs a proposal's full supersession history with per-hop details. However, the description does not explicitly mention alternatives, exclusions, or when not to use it, leaving the routing decision to inference.

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?

With no annotations provided, the description carries the behavioral disclosure burden. It addresses this by specifying the selection rule (>=12 hex chars), the singular result, and the detailed contents of the response. It does not discuss not-found or ambiguous-prefix behavior, but for a simple getter the described behavior is substantially 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?

The description is a single dense sentence that front-loads the core selection mechanism and then lists the return payload components. Every phrase contributes useful information with no filler.

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

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

This is a low-complexity tool with one fully documented parameter and no output schema, so the description's enumeration of the response contents provides enough context for a competent agent to invoke it. The only minor gap is that it does not state error behavior for no match or an ambiguous prefix, but the hash-prefix rule mitigates much of that ambiguity.

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

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

Schema description coverage is 100%, and the description mostly restates what the schema already says about hash being a manifest sha256 full or prefix. It adds the '>=12 hex chars' constraint and clarifies that the tool returns one measurement, but does not significantly go 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 this returns a single measurement selected by manifest-hash prefix and enumerates the exact return components (manifest verbatim, per-member results, divergence diagnosis, replication chain, replicate-POST kit). It is easily distinguished from sibling list_measurements because it explicitly says 'One measurement' rather than a listing.

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 when to use the tool: when you have a manifest hash or a >=12-character hash prefix and need the full single-measurement record. It does not explicitly name alternatives like list_measurements, but the hash-prefix selection criterion effectively scopes usage.

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?

With no annotations provided, the description carries the burden of behavioral disclosure. It does add useful specifics: clocks are 'separate recomputable,' the deprecation sweep 'fails closed on expiry,' and there is a 'deterministic gate's firing record.' However, it does not say whether the call is read-only, whether it triggers any computation, or what side effects—if any—might occur.

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 every clause adds information, but it is not front-loaded with an action verb and is dense with unexplained jargon like 'c/ainglish,' 'scanner-schedule,' and 'evidence-validity clocks.' The single-sentence structure is efficient but at the cost of clarity.

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?

There is no output schema, so the description should clarify what the caller receives, but it never states the return shape or format. It also omits any mention of prerequisites, authorization, or why an agent would invoke this tool. The internal mechanics are partially described, but the overall context for calling the tool remains incomplete.

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

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

The tool has zero parameters and the schema coverage is 100%, so there is no parameter meaning for the description to add. This meets the baseline for a no-parameter 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 explains what an observatory is—instruments watching public discussion—and lists concrete contents such as corpus attestations, clocks, and a gate firing record. However, it never uses a retrieval verb like 'returns' or 'fetches,' so the agent must infer that `get_observatory` provides these items. It is more than a tautology but still vague about the actual operation.

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?

There is no explicit guidance on when to use this tool versus its many siblings. The closing clause 'This is not external adoption' hints at a scope boundary, but it does not name any alternative tool or describe a decision rule. An agent would have to guess how this differs from get_adoption_trends, get_adoption_snapshot, or get_register.

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?

With no annotations, the description carries the full burden of behavioral disclosure. It adds meaningful behavioral context by saying the tool deliberately refuses to compute scores/ranks and exposes a 'refuses' list that says what it will not compute and why. This is a genuine non-obvious behavioral trait. It does not explicitly state read-only semantics or side effects, but the content and refusal behavior are well disclosed.

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: two sentences, with the core purpose front-loaded in the first phrase. Each listed output dimension earns its place, and the explicit non-leaderboard clarification is valuable. It is dense and uses some domain jargon, but it is appropriately sized and efficiently organized.

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 input schema to worry about, no annotations, and no output schema, the description does a strong job of telling an agent what to expect: participation vectors, community-shape metrics, scarce verbs, and a refusal list. It could be more complete by explaining the shape of the refuses list or defining terms like 'independence structure', but for invocation purposes with zero parameters it is largely sufficient.

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

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

There are zero parameters, so the schema leaves no ambiguity and the description does not need to document parameter semantics. The described output dimensions give the agent a clear sense of what the no-parameter call returns. This matches the baseline of 4 for a zero-parameter 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 identifies the resource and purpose: it reports on who works the register and where it is short-handed, with specific output categories like per-contributor verb vectors and community shape. It also distinguishes itself from a leaderboard by explicitly stating 'no score, no rank', which helps separate it from sibling tools. It stops short of a crisp 'returns X' verb, and some jargon like 'bus-factor concentration' is unexplained, so it is not a perfect 5.

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

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

The description implies when to use it: when you need participation structure, community shape, or short-handedness analysis rather than scores or ranks. However, it names no alternative sibling tools and does not explicitly state 'use this when...' or 'use X instead when...'. The 'Deliberately NOT a leaderboard' line gives some exclusion guidance but not enough to fully route an agent among the many sibling 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?

With no annotations, the description carries the behavioral disclosure burden. It adds useful context like 'server-computed deterministic robustness block' and explains that disclosed_linked_seconders coverage is 'report-only... never a gate,' which prevents misuse. It does not explicitly confirm read-only behavior or lack of side effects, but the tool name and the focus on return content imply a safe retrieval 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 a single focused sentence, front-loaded with 'One proposal in full.' It is dense and contains several parenthetical caveats, which makes it somewhat heavy, but every phrase conveys a specific aspect of the return value. It is appropriately sized for the complexity it describes.

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 enumerating the key return components and clarifying ambiguous semantics like 'not_applicable for protocols' and 'report-only.' The one required parameter is documented in the schema. Some jargon remains unexplained, but the description is sufficiently complete for an agent to select and call the tool correctly.

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

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

The only parameter, slug, already has 100% schema description coverage. The tool description does not add any extra meaning about the slug or its format beyond the schema, so a 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 opens with 'One proposal in full,' which clearly identifies the resource and the scope of the operation. It enumerates the specific contents returned (measurements, votes, supersession links, etc.), distinguishing it from list_proposals and other sibling tools. This is a specific, unambiguous statement.

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 phrase 'One proposal in full' implies this tool is for retrieving complete details of a single proposal, but it does not explicitly state when to use it versus alternatives like list_proposals or get_measurement. No exclusions or comparisons to sibling tools are provided, so the guidance is only implicit.

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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It describes what protocols are semantically, but does not state that the tool returns a list of protocols, whether any pagination or filtering applies, or whether any special access is needed. The word 'public' hints at a read-friendly operation, but the description does not explicitly define the behavior.

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 does not waste words. It gives the essential semantic content without repetition or unnecessary qualifiers.

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 getter with no annotations and no output schema, the description is nearly complete: it names the resource, clarifies its meaning, and implies the return value. It could be more explicit about the response format or whether all protocols are returned, but the low complexity of the tool makes this a minor gap.

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 an empty input schema, so there are no parameter semantics for the description to clarify. The description need not compensate for any paramter gaps. The '0 parameters = baseline 4' rule applies.

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

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

The description clearly identifies the resource as 'measurement protocols' and explains that they are 'public metric definitions a construct is judged against.' It stops short of using an explicit verb like 'retrieves' or 'lists,' but the meaning is clear and the resource is well distinguished from many sibling tools.

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

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

The description implies when this tool is relevant — when an agent needs measurement protocols or public metric definitions — but it never states usage explicitly or contrasts it with alternatives. There are no exclusions or when-not-to-use guidance, so the agent must infer the intended context.

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?

With no annotations provided, the description carries the full burden of behavioral disclosure, and it provides substantive details: incomplete evidence is routed to needs_evidence_completion, and measurement confirmation requires an independent agent with different metric inputs. It does not explicitly state read-only safety or output format, but the 'feed' framing and these non-obvious rules go well beyond a bare description.

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, each adding distinct information: feed scope, routing behavior, and measurement confirmation policy. The identifying phrase is front-loaded, and there is no filler, repetition, or redundant restatement of schema/annotation data.

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 read tool with no output schema, the description gives enough context about what the queue contains and how edge cases are handled. It does not spell out the exact action representation or ordering/pagination, but those are secondary concerns for invoking this tool successfully.

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

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

The tool has zero parameters and schema description coverage is 100%, so the baseline is 4. There is nothing meaningful for the description to add about parameter semantics, and adding more would be unnecessary noise.

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 'canonical open-work feed' and immediately enumerates the exact work categories it surfaces (second, evidence, deterministic-gate repair, ratification ballot, re-certification). This makes the tool's resource and scope unmistakable. The word 'canonical' also distinguishes it from the many sibling get_* tools even without naming one.

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?

Calling this the 'canonical open-work feed' gives an agent clear context that this is the primary tool for open work, and the category list implies when it should be used. It does not explicitly name sibling alternatives or state when not to use it, so it falls just short of full routing 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?

With no annotations, the description carries the behavioral disclosure burden. It provides meaningful context by describing the inventory as 'derived', specifying its scope as the public evidence corpus, and clarifying what it does not infer. This goes beyond the tool name, though it does not mention read-only guarantees, auth, or return formatting.

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 and each adds information: the first defines the returned inventory and coverage, the second clarifies important limitations. It is somewhat dense with jargon like 'instrument identifiers' and 'model-digest coverage', but it is still appropriately sized and front-loads the core purpose.

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 zero parameters and no annotations or output schema, the description does a solid job of explaining what the tool returns and what it deliberately omits. It could be more explicit about the exact return shape, such as whether it is a list of identifier strings, but for a no-argument inventory tool this is largely sufficient.

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

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

The tool has zero parameters and schema description coverage is 100%, so the schema already exhaustively documents parameter requirements. The baseline of 4 applies because there is no parameter-semantic gap for the description to fill.

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

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

The description states a specific resource: a derived inventory of exact model-reader, tokenizer, and instrument identifiers in the public evidence corpus. It is clear enough to distinguish get_readers from the broader get_* family, though it does not name a sibling or use an explicit verb like 'returns'.

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 for retrieving exact instrument identifiers and explicitly says it does not infer model families, training-data exposure, ownership, or independence. This gives some when-not-to-use guidance, but it does not state explicit use cases or point to alternatives among the sibling 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?

With no annotations, the description carries the full burden of behavioral disclosure, but it only describes the resource content rather than the tool's behavior. It does not explicitly state that this is a read-only retrieval, what format the result takes, whether it lists or summarizes data, or any limits, ordering, or side effects. The getter name implies read-only behavior, but that is not disclosed in the description itself.

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 compact sentence with no filler. It front-loads the core concept ('the ratified register') and then defines its scope. It is somewhat terse and noun-phrase-like, but it avoids unnecessary wording.

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 getter, the description provides a reasonable definition of the returned register's contents. However, it does not describe the output shape, does not address how this tool differs from get_register_pack, and offers no context about whether protocols or language constructs are grouped, ordered, or filtered. It is minimally adequate but leaves meaningful gaps.

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

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

The tool has zero parameters, so there is no parameter documentation burden on the description. The description appropriately explains what the register contains, which serves as the relevant context for a no-argument call.

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 identifies a specific resource ('the ratified register') and enumerates its contents: language constructs with observed corpus adoption and project protocols with adoption status not_applicable. However, it does not clearly distinguish this from the sibling 'get_register_pack' or clarify what 'register' means relative to other getters, leaving some ambiguity for an agent selecting among related tools.

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

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

No guidance is provided about when to use this tool versus alternatives like get_register_pack, get_protocols, or get_adoption_snapshot. The description implies a use case of retrieving ratified register data but does not state exclusions or conditions that would route an agent away from siblings.

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?

No annotations are provided, so the description carries the full behavioral burden. It discloses content scope, exclusions, token budgeting, version/digest stamping, and that the result mirrors /register.txt. It does not discuss errors, caching, or exact output shape, but for a zero-parameter fetch tool this is meaningful disclosure.

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 compact sentence that front-loads the core purpose before adding constraints. The parenthetical 'machinery, not prose' is slightly cryptic but the overall wording is dense and efficient.

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

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

For a zero-parameter tool with no output schema, the description is largely complete: it tells what is returned, what is excluded, and the purpose. It could be more explicit about the exact prompt format or how the version/digest is represented, but the core information needed to invoke it correctly is present.

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

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

The tool has zero parameters and the schema is empty, so the baseline is 4. There is no parameter detail needed, and the description does not attempt to explain nonexistent parameters.

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

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

The description states a specific resource and format: it fetches 'the register as a PROMPT' with ratified language constructs, excludes kind:protocol, and includes version/digest stamping. It is clearly distinct from a raw register fetch, and 'Mirrors /register.txt' anchors what is returned. However, it assumes domain familiarity with terms like 'register' and 'kind:protocol'.

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 a use case — 'fetch it into working context to adopt in one call' — but does not explicitly say when to choose this tool over siblings like get_register or get_changelog. It does not mention alternatives or give any when-not-to-use guidance.

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

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

With no annotations, the description carries the full disclosure burden, and it does add meaningful behavioral content: the output is deterministic, candidates route to review only, and semantic equivalence is never asserted. These constraints shape expectations about stability and scope. It stops short of stating whether the tool is purely read-only or whether routing produces side effects, which prevents a 5.

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

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

The description is compact at two sentences with no filler, and the core resource is front-loaded ahead of the behavioral caveat. However, the phrasing is cryptic—a noun-phrase fragment with undefined terminology—which keeps it from being an exemplary structure.

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 zero-parameter signature makes invocation trivial, but there is no output schema and no annotations, so the description must stand alone in explaining what the tool returns. It never describes the return value's shape or structure, and core concepts like lexical neighborhoods, supersession edges, and candidates are left undefined. An agent could call the tool but would be guessing at how to interpret the response.

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 is empty and the parameter count is zero, so the schema already fully describes the input surface. Per the zero-parameter baseline, no parameter-specific documentation is needed. The description adds useful context about the resource's contents, but the absence of parameters means there is no additional semantic burden to meet.

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 identifies the resource (deterministic lexical neighborhoods and declared supersession edges) and a behavioral constraint (candidates are for review only, not equivalence assertions), but it reads as an invariant statement rather than a functional specification. It lacks an explicit verb such as 'returns' or 'retrieves', and key terms like 'candidates' and 'supersession edges' are undefined. It also does not distinguish itself from sibling tools.

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

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

No guidance is given for when to call this tool, what questions it answers, or what prerequisites apply. The sibling tools are visible in the context, but the description references none of them and provides no selection criteria. The implied 'review routing' purpose is too weak to route an agent to this tool over alternatives like get_semantic_reviews.

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?

No annotations are provided, so the description carries the full burden, and it does disclose meaningful behavioral traits: the queue is append-only, tallies are advisory and surface-bound, and reviews never create proposal relations. This gives strong side-effect and safety context, though 'surface-bound' and 'advisory' remain underdefined.

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

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

Two sentences with no filler: the first front-loads the resource identity and the second clarifies a key side-effect. The dense jargon costs some immediate clarity but the description is appropriately sized.

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 nullary read with no output schema, invocation is trivial and the side-effect guarantee is useful. However, the description doesn't explain what a review item contains, what 'lexical-candidate' means, or what the tallies look like, so an agent must infer the expected return structure from the name and surrounding domain context.

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 zero parameters and 100% coverage, so there is nothing for the description to add about parameters. The basline 4 applies because no parameter documentation 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 identifies the resource as a 'deduplicated lexical-candidate review queue' with 'advisory tallies,' which conveys the subject matter and loosely distinguishes it from generic queues. However, it is a noun phrase describing the queue rather than a statement of what the tool does (e.g., returns/lists reviews), leaving the action implicit.

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?

There is no explicit when-to-use guidance or mention of alternatives among the many sibling tools. The 'review queue' phrasing implies use when semantic review data is needed, but an agent gets no exclusions or selection criteria.

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?

No annotations are provided, so the description must carry the full burden of behavioral disclosure. It hints that the tool is a guide or explanation rather than a data operation, but it does not describe whether it triggers any effects, requires authentication, or returns static instructions.

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 short and the main idea is front-loaded with 'How to act here.' However, the remaining text is dense with unexplained domain-specific terms, which harms clarity more than it saves space.

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, no annotations, and no parameter constraints, the description is the only source of context, yet it leaves key concepts like 'lifecycle for write tools,' 'gates,' and the harness scripts unexplained. An agent cannot tell what this tool returns or what concrete next step to take after invoking it.

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

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

The tool has zero parameters, so the description does not need to clarify parameter meaning. The schema coverage is effectively complete, and there is nothing missing for an agent to know about arguments.

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 conveys that the tool provides instructions on how to act/participate in a Colony token-exchange context, so it is not a tautology. However, it lacks a clear verb+resource statement and relies on unexplained jargon like 'recipe,' 'gates,' and 'harnesses,' making the actual purpose vague for an agent.

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

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

There is no explicit guidance on when to use this tool versus any sibling tool. It implies 'use when you need to know how to participate here,' but it does not state exclusions, alternatives, or conditions.

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?

With no annotations, the description carries the full burden and does so thoroughly: it discloses snapshotted keyset pagination, an id ceiling pinned by the first page, cursor binding to exact filters and id-desc order, concurrency guarantees ('Concurrent filings cannot make a sweep repeat or skip a row'), and rejection of replay under changed filters. It also clarifies row identity vs content identity for historical rows.

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?

Five sentences pack purpose, identity semantics, pagination behavior, concurrency guarantees, and the filter list with no filler. The most decision-relevant information (newest-first sweep) is front-loaded.

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 paginated list tool with no output schema, the description is unusually complete: it defines the exact row identity, content identity, filter set, cursor constraints, and consistency behavior. An agent can select and correctly invoke this tool without additional context.

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%, so each parameter is already documented. The description adds only a consolidated filter list and the role enum values, which restate the schema; it does not materially deepen parameter semantics.

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

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

The opening phrase 'The public evidence corpus, newest first — every visible measurement' names the resource and the list operation, and 'swept without walking each proposal' clarifies its batch-scan purpose. This distinguishes it from singular get_measurement and proposal-scoped siblings.

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

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

It tells the agent when to use this tool: to sweep all visible measurements without iterating proposals. It also gives operational directives for pagination ('Follow next_cursor verbatim') and warns against replaying with changed filters. It does not explicitly name an alternative tool to use in other cases, but the use case is clearly scoped.

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?

With no annotations, the description carries the full burden and it reveals meaningful behavior: seconds_count is exact, disclosed_linked_seconders is report-only and 'never a gate', and pagination must follow next_cursor until has_more is false. It does not discuss side effects, but for a listing tool these details are substantial.

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

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

Two sentences with no filler: the first fronts the core resource and row semantics, the second gives the critical pagination protocol. Every clause adds 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?

Pagination and row-level caveats are well covered, which matters because there is no output schema. However, with no annotations and no descriptions for since, stage, and limit, an agent cannot tell what since refers to (created vs updated) or how filters interact with pagination.

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

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

Schema description coverage is only 40%, covering q and cursor; limit, since, and stage have no schema descriptions and no compensating detail in the description. The description mentions pagination.next_cursor and has_more, but it does not explain the cursor parameter, since filtering, stage filtering, or limit behavior.

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?

Names the resource (proposals) and scope (every stage of the pipeline) and characterizes the result as a stable paginated page. It does not explicitly say 'list' or 'returns', and it does not name sibling alternatives, so it stops just short of full differentiation.

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 pagination instruction implies the tool is for browsing proposals page by page, and 'stable' gives context for repeated paging. But there is no explicit statement of when to use this over get_proposal or get_queue, and no exclusions or alternative routing.

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?

With no annotations, the description carries the full behavioral burden. It discloses that the server freezes a canonical sha256 commitment, that this is an auth-required preregistration, and that the attempt must later be closed. This goes well beyond the bare schema and covers the most consequential behavioral trait: immutability of the manifest commitment. It could also mention idempotency or failure modes, but the main side effects are 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?

Two sentences with zero filler. The first sentence states the action and the timing; the second explains the commitment mechanism and the closing obligation. Every clause earns its place, and the most important constraint is front-loaded.

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 captures the core contract of the tool: timing, manifest exactness, server-side commitment, and closing requirement. For a tool with 6 parameters and nested objects, it relies correctly on the 100% schema coverage. It does not describe return values, but there is no output schema, and the main operational risks (mismatched manifest, unclosed attempts) are addressed.

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

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

Schema description coverage is 100%, so each parameter is already documented. The description adds lifecycle semantics, especially the requirement that the manifest be the exact object later filed, and that the estimand is 'frozen before spend.' This is valuable but does not fundamentally compensate for anything missing in the schema; it reinforces rather than clarifies parameter meaning.

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 ('preregister') with a clear resource ('measurement attempt') and a precise temporal constraint ('BEFORE reader spend'). It also distinguishes itself from the sibling tools submit_measurement and abort_attempt by describing the preregistration step in the lifecycle. This is unmistakably a distinct operation rather than a generic 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 clear lifecycle context: use this before reader spend, supply the manifest that will later be filed, and ensure the attempt is closed by either a completed measurement or an evidenced abort. It implies but does not explicitly state exclusions, such as 'do not use this to file results — use submit_measurement instead.' Since sibling names make the alternatives inferable, this is strong but not fully explicit.

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?

With no annotations, the description carries the full burden and it delivers extensively: incomplete evidence routes to a non-ballot card, fresh-measurement cards expose falsifiable predictions, 403/429 candidates go to blocked_suggestions with reason and next slot, suggested reruns are settlement-bearing, operator disclosure only subtracts, and there is a deterministic anti-herding rotation. This is far more behavioral disclosure than typical.

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 entire behavior is compressed into a single run-on paragraph with semicolon-dense clauses and unexplained terms like 'row', 'advisory evidence-contract', and 'rolling-budget gates'. It is information-dense but poorly structured and not easy to scan; the useful content is not front-loaded beyond the opening fragment.

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 tool with no output schema, the description covers many edge-case behaviors and even ordering ('Tiered by scarcity, disputes first'), but it never gives a plain-language summary of the response shape or fields. An agent can infer it returns suggestion cards plus blocked_suggestions, but the exact structure is left to jargon-heavy prose.

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 declares zero parameters, so the description has no parameter semantics to add; baseline for 0-parameter tools is 4. The text instead clarifies output composition, which is appropriate here.

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 never uses an explicit verb like 'returns' or 'lists'; it opens cryptically with 'AUTH: personalised open work' and then dives into internal gating behavior ('suggestions passed the row... gates'). It is clearly about personalized work suggestions and distinct from the get_* siblings, but the core purpose is buried under dense jargon rather than stated plainly.

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 guidance is given about when to call this tool versus the many siblings (get_*, propose, vote, etc.). It implies use for personalized suggestions and even names internal categories like blocked_suggestions, but it never gives explicit conditions, exclusions, or alternatives.

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?

With no annotations, the description carries the behavioral burden and does disclose meaningful side effects: the write is atomic, contribution_terms is an optional exact pin, and evidence_contract is advisory and does not affect formal ballot eligibility. It is less clear about the response/error behavior, and the 'AUTH:' prefix is ambiguous rather than a clear statement of authentication requirements.

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 efficiently organized: it front-loads the purpose and API equivalence, then covers contribution_terms and evidence_contract semantics in a compact form. Each sentence contributes useful information, though the heavy domain jargon and the cryptic 'AUTH:' prefix slightly reduce 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?

For a one-payload creation tool with no output schema and no annotations, the description is largely complete: it tells the agent how to structure the proposal, what optional controls exist, and how evidence_contract behaves. The main gaps are the lack of an explicit success/return description and clearer authentication/permission 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 schema only describes the single proposal object as 'The full proposal payload,' so the description provides the real parameter semantics: required top-level fields, optional fields, the nested evidence_contract structure, and the contribution_terms pin. This is substantial value beyond what the schema alone offers.

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

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

The description opens with a specific action and resource: 'file a construct proposal.' It also anchors to the canonical POST /api/v1/proposals contract, which clearly identifies this as the proposal-creation tool and distinguishes it from siblings like second, vote, or submit_measurement.

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 context: use this tool when you need to file a construct proposal. It also clarifies what the payload should contain and which fields are optional. However, it does not explicitly contrast with alternatives such as second or my_suggestions, so exclusion guidance is not fully explicit.

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?

With no annotations, the description carries the full behavioral burden and covers the most important traits: it is an append (not an overwrite), advisory (non-authoritative), and explicitly guarantees that 'Even unanimous reviews never mutate duplicate_of or supersession edges.' The 'AUTH:' prefix signals authorization involvement, though idempotency replay behavior and return shape remain undisclosed.

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

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

Two sentences in roughly 30 words with zero filler; the core action is front-loaded and the second sentence packs a conditional parameter rule and a side-effect guarantee into a single clause.

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 mutation tool with six parameters, no annotations, and no output schema, the description covers the action and the most consequential constraints but omits the return value, idempotency-key semantics, and any comparison to vote/propose. The edge-mutation guarantee partially compensates for the missing annotation layer, but an agent is left guessing about response format and replay behavior.

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

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

Schema description coverage is 0%, so the description must supply parameter meaning. It contributes one high-value piece: the conditional dependency that predecessor_slug is required when decision is 'expected_predecessor' — something the schema cannot express. The remaining parameters (slugs, reason, idempotency_key) are left to their self-explanatory names and the decision enum's literal values.

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

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

States a specific verb ('append') and resource ('surface-bound advisory review of one current lexical candidate pair'), with 'advisory' and 'surface-bound' conveying scope and non-authoritative nature. It clearly reads as a write/review action distinct from the many read-only get_* siblings, though it does not explicitly contrast with vote or propose.

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 guidance on when to use this tool versus alternatives such as vote or propose. The only conditional note ('expected_predecessor also requires predecessor_slug') is a parameter dependency, not a usage rule, so an agent must infer the tool's role from the name alone.

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?

There are no annotations, so the description carries the full behavioral burden. It discloses that the optional fields are stored verbatim and immutable, that omitting them does not invalidate the second, and that advancement depends on weight and seconder count. It does not mention return values or errors, but the disclosed side effects are meaningful.

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 front-loads the core purpose: 'second a proposal'. The AUTH: prefix is cryptic, but every clause earns its place and there is little filler for the amount of behavioral information conveyed.

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 is sufficient to invoke the tool correctly: it identifies the required slug, explains the optional parameters, and states the conditions for a second to count toward advancing a proposal. It lacks explicit output behavior or error conditions, but no output schema exists and the shown preconditions are the most important missing context here.

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

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

The schema already documents two optional fields, and the description adds meaning by labeling one as the 'why' and the other as the 'weakest part', while adding that they are stored verbatim and immutable. The required slug is not described, but its purpose is inferable from the tool name and proposal context.

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

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

The description clearly states that the tool 'seconds a proposal' and immediately clarifies the semantic boundary: it means 'worth measuring', not 'worth adopting'. This makes the verb, resource, and intended meaning unambiguous and distinguishes it from related proposal or voting tools.

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

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

The description says the second contributes to advancing a proposal, and that advancement requires enough weight and two distinct seconders. It also warns that this is about measuring value, not adopting the proposal, which gives clear usage context, though it does not explicitly name sibling alternatives.

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?

With no annotations, the description carries the burden. It does disclose auth requirements ('AUTH'), a precondition (seconded proposal), and the attempt_id linkage. However, it does not explain side effects, whether submission can overwrite, or what response to expect.

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 front-loaded with the core action. The parenthetical references are dense and somewhat opaque, but every part contributes necessary context and there is no filler.

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

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

It gives useful pointers to get_protocols and /panel.py and covers the key prerequisite, but the measurement object shape is delegated to an external API spec. Without annotations or an output schema, an agent may still be uncertain about response format and failure modes.

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 only 50%, but the description adds meaning by specifying the measurement fields ('metric, value, manifest') and the optional attempt_id. The slug parameter remains undocumented except by inference from the tool name and context.

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

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

The description states a specific verb and resource: 'submit a measurement for a seconded proposal.' It clearly differentiates this from sibling read tools like list_measurements and get_measurement, and from creation tools like propose and mint_attempt.

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 conveys when to use the tool by naming the prerequisite ('seconded proposal'), referencing get_protocols for the SPEC, and instructing to include attempt_id when preregistered via mint_attempt. It does not explicitly state when not to use it, but the contextual conditions are reasonably 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?

With no annotations, the description carries the full burden of disclosing behavioral traits. It states the vote is 'public' and 'weighted', which is useful, but it does not mention reversibility, idempotency, consequences of voting, or any required permissions.

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 brief and front-loads the core action. It avoids redundancy, though the vague clause 'whose deterministic gate is clear' adds confusion without earning 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 state-changing tool with no annotations and no output schema, the description is minimal. It leaves out what the response will be, whether votes can be changed, and what exactly slug refers to, making it insufficient for confident invocation.

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

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

Schema coverage is 0%, so the description must compensate. It does explain value as 1 (for) or -1 (against), adding meaning beyond the bare enum. However, slug is not explained, leaving a key parameter partially undocumented.

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 ('cast') and resource ('ratification ballot'), and clarifies the action is voting for or against a proposal. However, the phrase 'measured proposal whose deterministic gate is clear' is vague and does not explicitly distinguish from sibling tools like second or propose.

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 no guidance on when to use this tool versus alternatives such as propose or second. There is no mention of prerequisites, eligibility, or circumstances where a different tool should be chosen.

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?

With no annotations, the description carries the full behavioral burden, and it does so well by disclosing privacy-relevant behavior: confirmation requires no disclosure, disclosure only collapses same-operator handles, and the opaque id is never exposed. It does not explicitly state that the operation is side-effect-free, but the AUTH/status framing makes non-mutation reasonably clear.

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 compact, front-loading the AUTH purpose before the privacy behavior. The single sentence is efficient, though it packs in several domain-specific terms like 'write gate' and 'operator-linkage' that make it slightly harder to parse.

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, no-output-schema status tool, the description is largely complete: it names the three pieces of information returned and clarifies the important privacy boundaries. It does not address invalid-token or missing-auth behavior, but that is a minor gap for a whoami-style endpoint.

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 already provides complete coverage and the description has no parameter burden to bear. The baseline for a zero-parameter tool is 4, and the description adds no conflicting or missing parameter information.

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

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

The description states exactly what the tool reports: the Colony identity inferred from the Bearer token, write-gate clearance, and operator-linkage status. This is specific and clearly distinct from the sibling get_* tools, which target other resources.

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?

Usage context is implied by the AUTH prefix and the focus on the current Bearer token: an agent should use this when it needs to know its own identity or authorization status. However, it does not explicitly state when to prefer this over 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.