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

With no annotations provided, the description carries the full burden and does well: it discloses the storage target, that state and artifacts are preserved (non-destructive/reversible), and the reason for doing it. It omits auth requirements, failure conditions for active crystals, and whether the operation is undoable via crystal_unarchive.

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 sentence, front-loaded with the action and target, and every clause earns its place by adding destination, precondition, and rationale.

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

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

For a one-parameter tool with no output schema and no annotations, the description covers purpose, precondition, destination, and side effects adequately. Only minor gaps remain, such as how to reverse the archive or what error occurs on an active crystal.

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 is a single required parameter (crystal_id) and schema coverage is 100%, so the schema already documents it fully. The description adds no syntax, format, or sourcing detail beyond the schema, so the baseline 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?

States a specific verb (archive) and resource (crystal) plus the destination path (.ccrystals/archive/) and the motivation (reduce cave bloat). The contrast with destructive siblings like crystal_delete or crystal_melt is implied by 'preserving all state and artifacts' but no sibling is named explicitly.

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?

Gives a clear selection condition: only concluded or inactive crystals should be archived, which frames when the tool applies. It stops short of naming alternatives (e.g., crystal_delete for removal, crystal_unarchive for restoration) or stating what happens if the crystal is still active.

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 supplied, so the description carries the full burden of behavioral disclosure, and it falls well short. It never states that 'register' mutates persistent state, whether registration is idempotent or overwrites existing artifacts, what the cave vs crystal registries mean, or what a failed lookup returns for a 14-parameter tool with three distinct actions.

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 with no filler or repetition. It is efficient, though for a tool with 14 parameters and three actions it is arguably thinner than the surface area warrants, which keeps it just short of a 5.

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 schema is fully documented and carries the parameter semantics, so the description is not the sole source of detail. Still, with no annotations, no output schema, and three distinct actions sharing one parameter bag, the description should have clarified which parameters apply to which action and what register actually does to persisted state.

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 every parameter is individually documented, so the baseline is 3. The description adds only marginal meaning ('virtual and physical' mirrors the substrate enum, 'cave or crystal' mirrors the cave boolean and crystal_id), offering no per-action parameter applicability beyond what the schema already states.

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 three specific verbs (register, list, inspect) against a named resource (artifacts) and adds scope qualifiers (virtual/physical, cave/crystal). It is clear enough to distinguish from generic siblings like crystal_delete or crystal_hydrate, but it never distinguishes itself from crystal_list, which plausibly overlaps with the 'list' 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?

No when-to-use guidance is provided. The agent is not told when to choose register vs inspect vs list, whether 'cave' or 'crystal' scoping should be preferred, or what preconditions exist (e.g. an id is required for register/inspect per the schema, but the description never says so).

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 exist, so the description carries the full burden. It never says whether the batch is transactional (does one failing command abort the rest?), what permissions are required, or what happens on partial failure — and the word 'atomic' is ambiguous about whether it describes each command or the whole batch.

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 the purpose stated first and the efficiency rationale second, plus an inline example. Nothing is wasted, though the example sentence is dense and could be set apart for 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-parameter tool with no output schema and no annotations, the description covers purpose and input format adequately but omits failure/ordering semantics and error behavior — the main things an agent needs to safely batch mutating commands.

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 already 100% for the single 'commands' parameter, so the baseline is 3. The description goes beyond the schema's bare 'semicolon-separated' phrasing by giving a concrete worked example showing subcommand syntax and quoting, which materially clarifies the expected format.

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 (Execute) and resource (compound semicolon-delimited atomic transition recipes), and the example makes the compound/batch nature concrete. It is distinguishable from single-transition siblings like crystal_task_transition, though it never names them explicitly.

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 clause 'Maximizes efficiency by minimizing roundtrips' implies the tool is for batching multiple commands in one call, which is useful implied guidance. However, it never states when NOT to batch, nor names the singular sibling tools as the alternative for one-off transitions.

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 yet discloses nothing about effects: whether the checkpoint is reversible, what permissions are required, how it interacts with the DAG, or what fidelity actually changes. 'Create an anchor checkpoint node' restates the operation without behavioral context.

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 efficient sentence with the core operation front-loaded and no filler. It is arguably too terse for a mutation tool, but it wastes no words.

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 no annotations, no output schema, and a rich 4-parameter surface, the description is far too thin. It omits what a checkpoint does to the DAG, side effects, and any return or error behavior an agent would need.

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 all four parameters (anchor, summary, fidelity, crystal_id) are already documented in the schema, making a baseline of 3 appropriate. The description adds no syntax, format, or meaning beyond what the schema provides.

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 (create) and resource (anchor checkpoint node) within the crystal DAG, so the basic operation is unambiguous. However, it offers no differentiation from the many crystal_* siblings such as crystal_artifact or crystal_slice_fork, and 'anchor checkpoint node' remains jargon-heavy.

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 indication of when to create a checkpoint versus using siblings like crystal_artifact, crystal_slice_fork, or the transition tools. No prerequisites, triggers, or exclusions are mentioned.

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 disclosure burden. It does usefully disclose that an acyclic invariant is enforced, implying connect can fail and disconnect may be the remedy, and that bonds feed cross-crystal context hydration. It says nothing about failure modes on cycle detection, permission requirements, or whether disconnect cascades to dependent bonds.

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 packs the operations, the resource, and the key invariant without filler. It is dense rather than padded, though the trailing 'cross-crystal context hydration' clause is the least informative part and could be trimmed.

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 7-parameter mutation-and-read tool with no annotations and no output schema, the description is adequate but thin: it omits what a list returns, what happens on cycle rejection, and how bonds behave when a referenced crystal is archived or melted by a sibling. The safety and lifecycle context an agent needs to call this confidently is partially missing.

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

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

Schema description coverage is 100%, so the schema already documents all seven parameters, including the action/relation enums and the list-time crystal_id alias. The description adds no syntax, format, or interaction detail beyond mapping its three verbs onto the action enum. Baseline 3 is appropriate when the schema does the heavy lifting.

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 set of operations (connect, disconnect, inspect) on a specific resource (directed lattice bonds between crystals), and names the acyclic-graph constraint that governs them. The 'crystals in the cave' metaphor is domain jargon, but the verb+resource pairing is unambiguous once the reader knows the domain. It does not explicitly distinguish itself from siblings like crystal_hydrate, which it gestures at via 'cross-crystal context hydration'.

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 statement of when to use this tool versus the 17 siblings, nor any prerequisites about when a bond should be created rather than recorded some other way. 'Enforcing an acyclic graph invariant' is a behavioral constraint rather than guidance on tool selection. Usage is only weakly inferable from the action enum.

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 for what is clearly a state-mutating tool. It names the target states but says nothing about permissions required, whether transitions are reversible, whether concluding a goal affects open tasks, or what side effects 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?

One compact sentence with no redundancy, and the core action plus the outcome options are front-loaded. Slightly dense but nothing wasted.

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?

Adequate minimum for a state-transition tool: it conveys the action, the target states, and the optional summary. However, with no annotations and no output schema, the description should have covered transition legality and side effects on related tasks; those gaps leave the agent under-informed.

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 the schema already documents all three parameters and the enum values. The description adds only a loose conceptual mapping ('reopen' → in_progress, 'abandon' → concluded_abandoned), which is mild value on top of a fully-covered schema — the baseline 3.

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 — transitioning a crystal's top-level goal status — and enumerates the three transitions (conclude successfully, abandon, reopen). It implicitly distinguishes itself from crystal_task_transition by scoping to the 'top-level goal', though it never names that sibling explicitly.

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 enumerated transition options imply what the tool is for, but there is no statement of when to choose it over crystal_task_transition, no preconditions (which current statuses permit a transition), and no exclusions. Usage must be inferred.

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. 'Hydrate' implies reconstruction/read, but the description never confirms it is read-only, whether it mutates crystal state, what permissions it needs, or what the beam actually contains.

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 with no filler; the shaping options come early. It is efficient, though the dense jargon reduces readability more than length does.

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 six-parameter tool with no annotations and no output schema, the description is thin. It neither explains the returned 'context beam' nor clarifies the default traversal behavior, leaving the agent guessing about the operation's effect and output.

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 the schema already documents all six parameters with descriptions. The description's list of shaping modes loosely maps to the params but adds no syntax, defaults, or interaction rules beyond the schema, so baseline 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?

States a specific verb ('hydrate') and resource ('context beam from a crystal') and enumerates the shaping modes. However, the domain jargon ('context beam', 'crystal') is opaque without external context, and it draws no boundary against the many crystal_* siblings such as crystal_slice_fork or crystal_checkpoint.

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 parenthetical list (tail, slice range from/to, depth, summary only) names parameter modes, not usage conditions. There is no statement of when to hydrate versus checkpointing, forking, or listing, and no prerequisites or exclusions are given.

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 discloses almost nothing. It does not say whether initialization persists state, whether the name must be unique, what happens on a duplicate name, or whether the crystal becomes active immediately. 'New' implies creation, but nothing beyond that is conveyed.

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 short sentence with zero waste and the action front-loaded. But at this length it is under-specified rather than genuinely concise, leaving the agent with no more information than the tool name alone provides.

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 five-parameter creation tool with no annotations and no output schema, the description is far too thin. It omits uniqueness constraints, side effects, and any indication of what is returned, so an agent cannot call it with confidence about outcomes.

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 all five parameters (name, goal, tasks, author, intent) are already documented in the schema. The description adds no meaning beyond it, which places it at the baseline of 3 for fully-covered schemas.

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 ('Initialize') and resource ('context crystal'), which is enough to separate it from crystal_delete, crystal_melt, and crystal_list. However, 'context crystal' is undefined domain jargon and the description offers no differentiation from creation-adjacent siblings like crystal_hydrate or crystal_slice_fork, so the agent must infer the distinction.

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, no stated prerequisites, and no mention of when it should not be used. With 15 siblings all sharing the 'crystal' prefix, the absence of routing guidance is a real gap.

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. It discloses that squashing is deterministic and Zero-LLM by default, which is useful, but it omits key mutation details: whether intermediate nodes are deleted, whether the operation is reversible, what permissions are required, and what happens to existing artifacts or transitions.

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 filler and puts the core operation first. The jargon and parenthetical are dense, but the sentence is appropriately sized for a tool definition.

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 non-trivial consolidation tool with five parameters, no annotations, and no output schema, the description is missing usage guidance and critical behavioral details about mutation and reversibility. The 100% schema coverage handles parameters, but the description should do more to explain the operation's context and consequences.

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 the input schema already documents all five parameters. The description does not add any parameter-level meaning such as format, constraints, or examples beyond what the schema provides, which matches the baseline of 3 for high schema coverage.

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

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

The description names a specific verb pair ('Melt and squash') and resource ('intermediate sub-DAG transitions'), and states the resulting artifact ('single consolidated checkpoint node with aggregated artifact links'). It does not explicitly differentiate itself from close siblings like crystal_checkpoint or crystal_task_transition, but the core operation is clear.

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 instead of alternatives, nor any prerequisites or exclusions. The parenthetical 'Zero-LLM deterministic squashing by default' hints at a default behavior but does not tell the agent when to choose this over crystal_checkpoint or crystal_task_transition.

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. It usefully flags that the operation is 'permanent' (irreversible) and that deletion cascades to entities and artifacts, which is genuinely important context for a destructive tool. It omits, however, any statement of permissions/auth requirements, confirmation behavior, or scope differences between single-crystal and batch modes.

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 sentence that front-loads the destructive nature and the resource. It is efficient, though the phrasing 'a crystal or cold storage archives' is slightly awkward and mixes singular/plural scope.

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 destructive, zero-annotation, no-output-schema tool, the description conveys permanence and cascade but leaves gaps around batch-vs-single semantics, safety parameters, and how it relates to sibling archive/melt tools. The 100% schema coverage compensates for parameter detail, keeping this at minimum viable.

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 all six parameters are already documented in the schema, and the baseline is 3. The description's 'retention policy' and 'cascade' phrasing loosely maps to older_than and the cascade behavior but adds no syntax, format, or interaction detail 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?

States a specific verb (prune) plus resource (crystal / cold storage archives) and mechanism (retention policy with entity/artifact cascade). However, it does not distinguish itself from close siblings like crystal_melt, crystal_archive, or crystal_unarchive, which an agent would need to tell apart.

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 or when-not-to-use guidance, and no alternative tool is named despite several plausible siblings (crystal_melt, crystal_archive). The retention-policy phrasing implies a scenario but leaves the agent to infer 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 carries the full burden. It discloses the default no-filter behavior and sort order, which is genuinely helpful, but says nothing about read-only nature, permissions, result format, or pagination limits beyond what the schema already states.

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, front-loaded with the verb and resource, with the default-behavior caveat placed second. Dense but efficient; the parenthetical enumeration is long yet earns its place by signaling breadth.

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 15-parameter read tool with no annotations and no output schema, the description covers defaults and filtering scope but omits return-value shape and result-set behavior. Adequate but leaves gaps the schema alone can't fill.

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 every parameter is already documented in the schema. The description lists filter categories that map onto those parameters but adds no syntax, defaults, or semantics beyond the schema, making the baseline 3 correct.

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 ('Search and list') and resource ('crystals'), and enumerates the filter dimensions it supports. An agent can distinguish this from crystal_stats or crystal_triage, though it doesn't explicitly name those siblings as 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?

Gives one useful context cue: called with no filters it lists active crystals, most recently active first. But it offers no when-to-use vs. alternatives guidance (e.g., when to reach for crystal_stats or crystal_hydrate instead), leaving usage largely implied.

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. It says nothing about permissions, whether the operation mutates the source crystal, what 'prune' destroys, or whether it is reversible — notable gaps for a tool whose own parameter implies data loss on the source anchor.

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 with zero redundancy, which is good. However, the brevity crosses into under-specification for a 4-parameter mutation tool, so it is efficient but too thin to earn higher marks.

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 annotations, no output schema, and a destructive-sounding 'prune' parameter, the description should explain mutation effects, permissions, and the fork/extract distinction. It provides none of that, so an agent cannot call this safely on description alone.

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 all four parameters are documented in the schema itself, which sets the baseline at 3. The description adds no syntax, format, or interpretation beyond that, so it neither helps nor hurts.

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 verb ('Extract ... fork') and a resource ('crystal fragment / sub-DAG ... into a new crystal'), but the domain jargon is dense and the description never distinguishes this from siblings like crystal_melt, crystal_batch, or crystal_hydrate. An agent knows roughly what happens but not exactly which operation this is relative to the rest of the family.

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 prerequisites, and no named alternative. The 'or' between 'extract fragment' and 'fork sub-DAG' hints at two modes but never says which parameter selects which mode, leaving the agent to infer usage entirely.

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 exist, so the description carries the full burden. 'Compute and inspect' strongly implies a non-destructive read, and the global-vs-filtered framing conveys scope, but nothing is said about cost/performance, whether results are cached, or permissions. It signals read-only behavior implicitly rather than explicitly.

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?

It is a single front-loaded sentence with the verb first, which is good. However, the clause stack ('temporal genesis', 'structural totals', 'physical disk footprints', 'quantitative prompt token savings') is jargon-heavy and overlapping, adding length without sharpening 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 13-parameter analytics tool with no annotations and no output schema, the description covers the broad purpose and scoping but omits any indication of the returned structure, which the json_output param implies is selectable. Adequate as a minimum-viable statement, but it leaves real gaps for such a complex tool.

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

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

Schema description coverage is 100%, so the 13 parameters are already fully documented in structured form, establishing a baseline of 3. The description adds only the high-level notion of 'filtered search criteria' and global scope, contributing no syntax or semantics 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 a specific verb ('compute and inspect') and resource ('workspace cave statistics'), and enumerates the metric families it returns (disk footprints, token savings, structural totals). An agent can distinguish it from crystal_search (which retrieves crystals) because this tool aggregates rather than lists. It stops short of explicitly naming siblings or contrasting scope, keeping it below a 5.

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

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

It hints at two modes ('global cave or filtered search criteria') but never states when to reach for this tool over crystal_search or crystal_triage, nor when filtering is preferable. There are no exclusions or prerequisites given. Usage must be inferred entirely from the name and param list.

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 does not meet it. It is a mutation tool (adds state, marks tasks done) yet says nothing about idempotency, whether 'done' fails on an unknown ID, who may invoke it, or what happens to the crystal on completion.

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 eight-word sentence, front-loaded with both verbs and the resource, with no filler. Its brevity borders on under-specification, but as structure goes it is clean and waste-free.

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?

Three required parameters, a mutation semantic, no annotations, and no output schema — yet the description is one clause. Nothing explains the dual-purpose description_or_id parameter or the consequences of each action, so an agent must infer behavior entirely from field names.

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 all three parameters (action enum, crystal_id, description_or_id with its dual add/done semantics) are already documented in the schema. The description adds nothing beyond that, 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?

States a specific verb pair plus resource: 'Add or complete a task in a crystal.' An agent can tell it manipulates tasks rather than goals, leases, or slices. However, it does not name crystal_goal_transition, the near-identical sibling, so the differentiation is implicit rather than explicit.

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 versus crystal_goal_transition or any other sibling, and no prerequisites or context. The description only restates the two operations without saying which situations call for each.

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 lists three actions but does not disclose what 'clean' destroys, what 'promote' changes, whether leases expire, what permissions are required, or any side effects or reversibility constraints. This leaves major behavioral questions unanswered for a mutation tool.

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, front-loaded sentence with no wasted words. It is concise, though its brevity contributes to the lack of actionable detail for a five-parameter mutation tool.

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 five parameters, three mutation actions, no annotations, and no output schema, the description is too thin. It does not explain the lease lifecycle, action-specific prerequisites, which parameters apply to which actions, or expected outcomes, leaving the agent to infer critical invocation 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?

Schema description coverage is 100%, so all five parameters are documented in the input schema, and the enum values are already fully specified. The description repeats the action names but adds no additional meaning about parameter interactions or expected values 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 resource ('transient resource lease') and three operations ('create, clean, or promote'), so the general purpose is inferable. However, it does not explain what a transient lease is or distinguish this tool meaningfully from the many other crystal_* lifecycle tools beyond the resource name.

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 such as crystal_checkpoint, crystal_slice_fork, or crystal_melt. The action enum implies three possible uses, but the description does not state when each action is appropriate or what conditions should lead an agent to choose this tool.

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

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

With no annotations, the description carries the full burden, and it does disclose the categorization rules (keep = active, cleanup = concluded/abandoned with 0 open leases, plus a review bucket), which is genuinely useful decision logic. It never states whether the operation is read-only or mutating, what permissions are needed, or whether it changes state, which is a notable gap for a triage tool.

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 that front-loads the action and then the outcome categories; no filler. It is slightly clause-heavy but every clause contributes 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?

There is no output schema and no annotations, so the description must carry more weight; it partially compensates by enumerating the three result buckets. It still omits the return format, whether any state is modified, and any safety profile, leaving the agent with an incomplete picture of a triage operation.

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 aging, json_output, and include_archived are already fully documented in the schema, establishing a baseline of 3. The description adds no additional parameter meaning beyond a passing reference to 'aging'.

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 (triage) and resource (cave crystals) and defines the three output buckets precisely, so the agent knows what the tool produces. It does not, however, differentiate itself from siblings like crystal_list or crystal_melt, leaving the agent to infer when triage is preferable.

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 'for lifecycle hygiene and aging' hints at intent but there is no explicit when-to-use statement, no prerequisites, and no named alternative among the many crystal_* siblings. The agent gets no guidance on when this tool is the right choice over crystal_list.

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 disclosure burden. It does add real behavioral context by naming the source location (.ccrystals/archive/) and the destination (active cave), i.e. a state transition, but it omits critical mutation semantics: whether restoring overwrites an existing active crystal with the same id, required permissions, and error behavior when the id is not archived.

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 sentence, zero waste, front-loaded with the verb and the resource. Nothing is padded or repeated from the title or schema.

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 single-parameter tool with a fully documented schema and no output schema, the description supplies enough to invoke it correctly: what is restored and from/to where. The only meaningful gap is the overwrite/conflict behavior on an already-active id, which is minor at this complexity level.

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% for the single parameter, so the schema already documents crystal_id ('Identifier of the crystal to restore'). The description adds no format, naming, or lookup guidance beyond that, which is the expected baseline when the schema does the work.

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 (Restore) and resource (an archived crystal), and the 'archived' qualifier plus the archive path makes the inverse relationship to crystal_archive clear without opening either schema. It stops short of naming the sibling explicitly, which is what separates a 4 from a 5.

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

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

Usage is only implied: the agent can infer 'use this to bring an archived crystal back' from the wording, but there is no explicit when-to-use, no precondition (e.g. crystal must currently be archived), and no reference to alternatives such as crystal_archive or crystal_hydrate.

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