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 does disclose the important trait that the tool may return clarifying questions instead of executing a search, and that it can decompose a query into sub-queries. However, it says nothing about whether the sub-queries are executed, what the response shape looks like, or any side effects or limits on decomposition.

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 compact sentences, front-loaded with the alias disclosure and then the behavior. Nothing is redundant; the only slight weakness is that the alias sentence does not resolve how the agent should pick between the two names.

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 would need to explain the non-standard return (clarifying questions vs. split queries) and what the tool does with the sub-queries. It hints at the clarification behavior but leaves the result and execution semantics incomplete for a four-parameter planning 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%, with each of the four parameters documented in the schema, so the baseline is 3. The description adds no parameter-level meaning (e.g., how max_sub_queries interacts with multi-part splitting, or how context is used for coreference resolution).

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 concrete function: evaluating intent clarity, asking clarifying questions on ambiguity, and splitting multi-part queries into isolated searches. It also discloses that it is an alias for hyperspace_query_planner, which tells the agent what the tool really is. It stops short of saying how it differs operationally from the original, but the agent can tell what it does.

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

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

Usage is only implied: the described 'asks clarifying questions if ambiguous' and 'splits multi-part questions' behavior suggests when it applies, but there is no explicit when-to-use, when-not-to-use, or guidance on choosing this alias over hyperspace_query_planner. With a sibling that is functionally identical, the missing routing rule 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 exist, so the description carries the full burden. It usefully discloses the return shape ({delta, recommendation} with its enumerated values) and that one mode runs server-side, but it never mentions that a `samples` default of 200 implies an approximate/sampled estimate, nor cost, latency, or read-only safety of analyzing a whole collection.

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 tight sentences: the computation and its two input modes first, then the return contract. Nothing redundant, nothing buried.

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 covers the return shape well despite having no output schema, but for a 3-parameter tool with 33% schema coverage it leaves real gaps: `samples` is unexplained, the precedence between `collection` and `vectors` is undefined, and approximation behavior is undisclosed.

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 33%, with just `collection` documented there, so the description must compensate. It does add value by describing `collection` as server-side and clarifying `vectors` as an array of numeric arrays, but the `samples` parameter — which governs accuracy and runtime — is never mentioned at all.

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 a specific computation (Gromov Delta-hyperbolicity) and the two input modes (server-side `collection` or explicit `vectors`), which is far more precise than any sibling name. It does not explicitly contrast itself with neighbors like hyperspace_analyze_thought_stability or hyperspace_find_clusters, but the resource is distinctive enough that an agent can tell them 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?

The 'either for a named collection ... or over supplied vectors' phrasing does route parameter selection, which is useful. However, it never says when an agent should reach for this tool versus the other analysis siblings, nor whether `collection` and `vectors` are mutually exclusive or which wins if both 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 burden. It does disclose the return object and the sign-based interpretation (negative = stable/converging, positive = chaotic/hallucinating), which is genuinely useful behavioral context, but it says nothing about input format expectations, cost, or what the `curvature` setting changes.

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 tight sentences: the computation first, then the returned fields and their interpretation. Nothing is wasted and the key semantics (sign meaning) are 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?

With no output schema, the description does cover the return values well. However, for a tool whose only required parameter is an undocumented nested numeric array plus an unexplained `curvature` option, the agent still lacks enough information to construct a correct call.

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 compensate. It adds real meaning for `trajectory` (a Chain of Thought), but never explains that it is an array of numeric vectors or what those vectors should be, and `curvature` is entirely unaddressed.

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 ('Calculate Lyapunov Convergence of a trajectory'), names the domain concept (Chain of Thought), and even reports the return payload shape. It is clearly distinguishable from analytic siblings such as hyperspace_analyze_geometry or hyperspace_predict_momentum.

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: an agent can infer the tool is for judging whether a reasoning trace is stable or hallucinating, but there is no explicit 'use this when / not when' or comparison against alternatives like hyperspace_verify_generation or hyperspace_predict_momentum.

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 usefully scopes the blast radius ('all items in the L0 Cache') and discloses the return value ('ok/error status object'), but never states that the operation is irreversible, what happens to cached-but-unsaved data, or whether permissions or a pre-existing collection are required.

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 short sentences with the destructive action and its scope front-loaded, followed by the return contract. The 'Clear / purge' slash hedge is minor redundancy but nothing is 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 for a one-parameter tool: it names the target, the scope, and the return shape. However, with no annotations and no output schema, it should explain what the L0 cache is relative to other tiers and whether purging affects subsequent searches.

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

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

Schema coverage is 100% and the single 'collection' parameter is already documented in the schema as 'The name of the collection.' The description only restates that the clear is scoped to a specific collection, adding no format or naming-convention detail beyond the schema baseline.

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

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

States a specific verb ('clear/purge') and resource ('all items in the L0 Cache for a specific collection'), which an agent can distinguish from cache_stats or cache_config by scope. It does not name a sibling alternative explicitly, but the target is unambiguous.

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

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

No when-to-use or when-not-to-use guidance; the description never says why an agent would purge the L0 cache versus using cache_config, cache_stats, or rebuild_index. Contextual applicability is left entirely to inference from the tool name.

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 for a mutation tool. It usefully states the return format ('Returns updated config as JSON result'), but says nothing about permission requirements, whether the change is persisted or reversible, or whether existing cached entries are invalidated when the policy changes.

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 tight sentences with zero filler: the mutation and its scope come first, the return value second. Every clause 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?

A three-parameter mutation tool with full schema coverage and no output schema, partially compensated by the stated JSON return. However, with no annotations and no mention of side effects or failure modes when an unsupported policy string is supplied, the definition is only minimally sufficient for safe 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 description coverage is 100%, so all three parameters (policy, collection, ann_threshold) are already documented in the schema. The description only restates the policy and ANN threshold fields without adding formats, valid ranges, or defaults, 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?

The description gives a specific verb and resource ('Update L0 Cache configuration') and even enumerates the two settings it touches (eviction policy, ANN threshold) scoped to a collection. It is clearly differentiable from hyperspace_cache_stats and hyperspace_cache_clear by name and semantics, though it never explicitly contrasts itself with them.

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 reach for this tool versus cache_clear, cache_stats, or collection-level tuning, and no preconditions (e.g. collection must exist, cache must be enabled, whether changing policy flushes entries). The purpose sentence only implies usage; it does not route 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?

No annotations exist, so the description carries the full burden. It does signal a non-mutating read ('Get') and discloses the return form ('stats object as JSON result'), which is useful. It says nothing about cost, permissions, or whether reading stats has any effect on cache state, leaving moderate gaps for an annotation-free 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?

Two short sentences with no filler; the scope (specific collection's L0 Hot Tier Cache) is front-loaded. It could be slightly denser by folding the return-value note into the scope sentence, but nothing is 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?

For a one-parameter read tool this covers the essentials: what it returns and at what scope. With no output schema, however, the description should say more about the stats object's shape or stability, and it doesn't clarify the relationship to the sibling statistics/config tools.

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?

Only one parameter with 100% schema coverage, and the schema already documents 'collection' fully. The description adds the useful nuance that stats are scoped to a single collection rather than global, but gives no format hints (case sensitivity, exact-name matching) beyond the schema. 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 and resource: 'Get cache statistics (hits, misses, policy, etc.)' scoped to 'a specific collection's L0 Hot Tier Cache'. This is clearly distinct from generic siblings, but it never explicitly distinguishes itself from hyperspace_get_stats or hyperspace_cache_config, leaving the agent to infer which stats tool applies.

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 — an agent can guess this is for inspecting cache performance for a collection. There is no explicit when-to-use/when-not statement and no mention of when to prefer hyperspace_get_stats (general stats) or hyperspace_cache_config (configuration) instead.

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 the created config is returned, but omits key mutation behavior: whether duplicate collection names error, whether creation requires permissions, and whether setup is reversible or destructive to existing state.

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 core action and scope, with no wasted wording. Minor imprecision from using 'Setup' rather than a direct creation verb.

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

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

Given no annotations and no output schema, the description correctly notes a JSON return, covering output expectations. However, for a create mutation it is incomplete on uniqueness, permissions, and failure modes, leaving 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?

Schema description coverage is 80%, so the schema already documents metric, dimension, quantization, and encryption_key. The description repeats the main fields but adds no syntax or default semantics beyond what the schema provides; baseline 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?

States a specific verb and resource: creating collections with dimension, metric, and quantization. This clearly distinguishes it from list/delete collection siblings, though it doesn't explicitly name alternatives.

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

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

No guidance on when to use this versus sibling tools like hyperspace_list_collections or hyperspace_insert_text, nor any prerequisites such as the collection being absent or required before inserts.

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 must carry the full behavioral burden. It usefully discloses that deletion is permanent and destroys all vectors, and it briefly describes the return shape. It omits permissions/auth requirements, failure behavior for missing collections, and whether confirmation is needed.

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 compact sentences with zero waste. The destructive scope is front-loaded before the return value note.

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 tool with no annotations and no output schema, the description covers the essential scope and result shape. It still leaves out prerequisites, safety expectations, and edge-case behavior, which are important for an irreversible collection-level 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 the single 'collection' parameter is already fully documented. The description adds no format, naming, or validation semantics beyond what the schema provides, making baseline 3 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?

States a specific verb and resource ('Permanently delete a collection') and clarifies scope ('and all of its vectors'), which helps distinguish it from hyperspace_delete_points. It stops short of explicitly naming siblings, so it is not 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?

There is no when-to-use or when-not-to-use guidance. It does not mention alternatives such as hyperspace_delete_points or hyperspace_freeze_collection, nor any prerequisites or confirmation requirements for an irreversible operation.

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 the call returns 'ok status or error' but never states whether deletion is irreversible, whether it errors when the ID does not exist, or what permissions/collection state (e.g., frozen collections in the sibling set) are required.

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 short sentences with the destructive action front-loaded and the return shape stated second. There is no filler, though the space spent on the return object could have been spent on preconditions.

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

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

For a simple two-parameter delete with full schema coverage, the description covers purpose and return shape adequately. However, with zero annotations and no output schema, missing disclosures about irreversibility and error conditions leave a meaningful gap for a destructive 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%, with both 'id' and 'collection' documented in the schema. The description's 'by its ID' adds no syntax or format detail beyond that, 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 and resource ('Delete a single vector point from a collection by its ID'), and the word 'single' scopes it correctly. It does not explicitly distinguish itself from hyperspace_delete_collection or hyperspace_get_points, so it falls short of 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?

No guidance on when to use this instead of hyperspace_delete_collection (which also deletes) or any bulk-removal path. The agent must infer from the name alone that this removes one point rather than a collection.

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 does add real value by disclosing the return shape (nodes and links, visualization-ready), which is otherwise undocumented since there is no output schema. But it omits edge direction semantics, what happens on truncation by max_nodes, and behavior when start_id does not exist.

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 action and output format, with the prerequisite trailing. Nothing is padded, though the second sentence is nearly redundant with the schema's required array.

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 traversal tool with no output schema, the description usefully explains that results are visualization-ready nodes and links. It stops short of covering truncation behavior at max_nodes, directionality of traversal, or why one would choose this over hyperspace_graph_traverse, leaving real 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?

All four parameters are documented in the schema at 100% coverage, including defaults of 2 for max_depth and 256 for max_nodes. The description only restates the two required parameters and adds no semantics for depth or node limits, 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 concrete verb and resource — traversing a graph from a start node and returning nodes and links shaped for visualization. That is unambiguous about what the tool does. However, it never distinguishes itself from close siblings like hyperspace_graph_traverse, hyperspace_get_neighbors, or hyperspace_query_planner, so an agent cannot pick between them on the description alone.

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?

"Requires `collection` and `start_id`" is a prerequisite restatement, not usage guidance. Nothing says when a bounded traversal is preferable to graph_traverse, get_neighbors, or find_clusters, even though these overlap heavily. The agent is left to infer choice from tool names.

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 does disclose the return shape (cluster_id, members, centroid, size) and that results are filtered by min_cluster_size, but it never states whether the call is a read-only computation, how expensive it is on large collections, or whether clustering is deterministic across runs.

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 compact sentences: purpose first, return contract second. No filler, and the output shape is stated in one clause rather than a paragraph.

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?

Because there is no output schema, the inline return contract is genuinely necessary and present. However, with zero annotation coverage and an undocumented schema, the definition still leaves an agent guessing about the semantics of `collection`, compute cost, and whether the operation mutates 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 0%, so the description must compensate. It names both parameters in context and clarifies that min_cluster_size acts as a filter on returned clusters, but it never says whether `collection` is a name, ID, or handle, nor the units/effect of the threshold (minimum members per returned cluster).

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

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

States a specific verb and resource: 'Detect emergent structure/hierarchy in `collection`'. An agent can tell it is an analysis/partitioning operation, but nothing distinguishes it from sibling analyzers like hyperspace_analyze_geometry or hyperspace_get_subsumption_tree.

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 by the word 'clusters'. There is no explicit when-to-use, no mention of when a sibling (e.g. get_subsumption_tree, analyze_geometry) would be the better pick, and no prerequisites such as needing indexed points in the collection.

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 discloses the core effect (read-only, blocks inserts) and the return shape ('ok/error status object'), which is helpful since no output schema exists. It does not address reversibility, required permissions, whether existing data or other write operations (updates/deletes) are affected, or error conditions.

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 compact sentences, front-loaded with the action and effect, then the return value. No waste, though the description is on the thin side for a 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?

For a simple one-parameter mutation with no annotations and no output schema, the description covers the effect and return shape but omits reversibility, permission requirements, and collection identifier semantics. Adequate but with clear 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 single 'collection' parameter has 0% schema description coverage, so the description must compensate by explaining the identifier format (name vs UUID), and it does not. The parameter is only implicitly referenced by the phrase 'a collection'.

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

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

States a specific verb and resource ('Freeze a collection') plus the resulting effect ('make it read-only, preventing new inserts'). It does not explicitly differentiate from the sibling hyperspace_unfreeze_collection, relying on the reader to infer the inverse relationship from the verb.

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 by the stated effect (make read-only), but there is no explicit when-to-use vs when-not guidance and no mention of the unfreeze sibling or how to reverse the operation. An agent must infer the recovery path.

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 but does disclose that this is a retrieval operation returning a JSON list of parent nodes. It does not explain traversal behavior, ordering, error cases, or how the layer and limit parameters affect results.

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 front-loaded with the core action. The sentence about required parameters is slightly redundant with the schema but still useful and not verbose.

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

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

For a four-parameter read tool with no annotations and no output schema, the description covers the required inputs and return type. However, it does not explain the optional layer and limit semantics or edge cases, leaving some behavioral 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?

Schema description coverage is 100%, so all parameters are already documented. The description names the two required parameters but adds no extra semantics for layer or limit beyond what the schema provides, making 3 the appropriate baseline.

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

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

The description uses a specific verb and resource: retrieve parent concepts in a hierarchical collection. It clearly identifies the operation, though it does not explicitly contrast this tool with siblings such as get_neighbors or get_subsumption_tree.

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 states the required parameters, but gives no guidance on when to use this tool versus related graph tools. There are no exclusions, alternatives, or usage conditions beyond the basic purpose.

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 does convey that this is a read-style exploration that returns neighboring nodes as JSON, which is useful. It does not disclose permissions, behavior for a missing collection/id, what the layer parameter implies behaviorally, or any limits on traversal.

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 short sentences with the core action and prerequisites front-loaded; the return-value sentence earns its place since no output schema exists. Minimal waste.

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 for a 4-parameter read tool but leaves real gaps: no output schema, no annotations, and nothing on error conditions or what 'layer' means for results. An agent could call it, but not with high confidence about edge cases.

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 75%, so most parameters are documented in the schema already. The description only reinforces that collection and id are required and says nothing about layer or limit, so it adds little 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?

A specific verb-plus-resource ('Explore local connectivity of a concept in the vector index graph') that an agent can distinguish from search or insert siblings. It does not explicitly contrast with hyperspace_graph_traverse or hyperspace_explore_graph, which are the closest neighbors.

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?

'Explore local connectivity' implies a one-hop neighbor lookup, so usage is inferrable, but there is no explicit when-to-use, when-not, or named alternative such as hyperspace_graph_traverse for multi-hop walks.

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 must carry the full behavioral burden. It does disclose that this is a read operation returning vector coordinates and metadata, which is useful, but it says nothing about behavior for missing IDs, permissions, or error conditions.

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 definition is two sentences and front-loads the core purpose. The second sentence is somewhat redundant with the schema's required fields, but the overall size is appropriate.

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

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

For a simple read-by-ID tool with no output schema or annotations, the description covers the core purpose and return content adequately. It leaves gaps around error or missing-ID behavior, which matters more because no annotations are available to fill those in.

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 both parameters are already documented in the schema. The description repeats the required parameters but adds no format, type, or usage detail beyond what the schema already 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?

The description states a specific verb and resource ('Retrieve vector coordinate and metadata for a list of point IDs'), so the operation is unambiguous. It does not explicitly distinguish itself from read-oriented siblings such as hyperspace_search_text or hyperspace_get_neighbors, which keeps it 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?

The second sentence only restates the required parameters ('Requires collection name and ids array') rather than explaining when to use this tool versus alternatives. There is no guidance on when not to use it, or on how to obtain IDs before calling 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?

With no annotations, the description carries the full burden. It does disclose the return shape (count, dimension, metric, logical_clock, storage stats) and that multiple internal sources are merged, which is genuine added context for a read tool. However, it says nothing about cost, whether it is a point-in-time snapshot, or what happens when the collection does not exist.

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 short sentences, purpose front-loaded, with no filler. Each sentence contributes: what it does, what it returns, and what it aggregates.

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 read tool with no output schema, the description compensates well by enumerating the return fields and the merged sources. Only the omitted error/format semantics for the collection argument keep it from being fully complete.

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 explain the single `collection` parameter, and it only restates it as "the named `collection`". It never clarifies whether this is a collection name versus an ID, whether wildcards work, or the error behavior for an unknown name — the exact gap the missing schema descriptions leave open.

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

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

States a specific verb and resource ("Get detailed statistics for the named collection") and enumerates the returned fields. It partially distinguishes itself from hyperspace_cache_stats by noting it merges metadata, cache stats and WriteBuffer size, but never explicitly names that sibling as an alternative, so differentiation is implicit rather than stated.

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: an agent can infer this is the per-collection stats reader, but the description never says when to call it versus hyperspace_list_collections (discovery), hyperspace_cache_stats (cache-only) or hyperspace_get_points. No exclusions, prerequisites, or failure conditions 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?

With no annotations, the description carries the full behavioral burden. It discloses that the operation retrieves data and returns a tree as JSON, implying a read-only operation, but does not cover edge cases, permissions, missing roots, or how max_depth affects the returned tree.

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 the action and scope front-loaded. Every clause contributes to identifying the operation and return format, 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?

The tool has moderate complexity, no annotations, and no output schema. The description states the return is JSON but does not describe the tree node structure or depth behavior, leaving some contextual gaps for an agent to infer.

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 parameter meanings are already documented in the schema. The description mentions root_id and collection, adding minor contextual framing, but does not explain max_depth or traversal semantics 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?

The description uses a specific verb ('Retrieve') and resource ('Lorentz hierarchy subsumption tree'), with clear scope from a given root_id in a collection. It does not explicitly distinguish itself from sibling tools such as hyperspace_graph_traverse or hyperspace_get_concept_parents, but the resource is precise enough to identify the 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?

The description states what the tool does but gives no guidance on when to use it versus alternatives. There are no exclusions, prerequisites, or comparative hints for choosing this tool over graph_traverse, get_neighbors, or get_concept_parents.

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 it says nothing about whether this is a read-only evaluation, what the trust score represents or its scale, or whether curvature meaningfully changes results. Only the input prerequisites are 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?

Two short sentences with the core action front-loaded and prerequisites second; nothing is wasted. It is terse to the point of under-specification rather than padded.

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

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

A 3-parameter evaluation tool with no annotations and no output schema needs the description to explain what comes back and how to read the score. That information is entirely absent, leaving the agent unable to interpret results.

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 collection, trajectory_ids, and curvature; the description merely repeats the two required ones. It adds no meaning for 'curvature', which the schema undersells as 'Curvature parameter'. 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 and resource: 'Evaluate stability and trust score' for a 'thought trajectory path'. An agent can grasp the operation, but the description never distinguishes it from nearby siblings like hyperspace_analyze_thought_stability or hyperspace_analyze_geometry, so overlap risk remains.

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 names the required inputs but never says when to call this versus analyze_thought_stability, predict_momentum, or graph_traverse. There is no when-to-use, when-not-to-use, or alternative routing guidance at all.

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 burden. It does disclose output shape and that results are bounded by max_depth/max_nodes, which is useful. However, it omits whether traversal is read-only, cost/latency implications of deep exploration, or permission 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?

Three tight sentences, front-loaded with the core action, then purpose, then return contract. Little waste; the return-shape sentence is valuable rather than 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?

No output schema, so documenting the return object is a good call, and bounds are explained. But for an unannotated deep-traversal tool, gaps remain around performance cost, read-only safety, and behavior when limits are hit.

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

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

With 0% schema description coverage, the description compensates well by explaining start_id (start node), collection, and that max_depth/max_nodes bound the result. It doesn't spell out what the numeric defaults mean semantically, but all four parameters are addressed.

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+resource: 'Deep graph exploration starting from node `start_id` inside `collection`'. The word 'deep' implicitly distinguishes it from shallow siblings like hyperspace_get_neighbors, but no sibling is named directly.

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

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

It gives a use case ('complex reasoning/cross-referencing') implying when to use it, but offers no explicit when-not conditions and never routes the agent to alternatives such as hyperspace_explore_graph or hyperspace_get_neighbors.

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 never says whether induced edges persist, are recomputed on each call, replace or merge with existing edges, or what permissions are needed. For a mutation-oriented tool with zero annotation coverage these are significant gaps.

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 compact sentences with no filler, and the core action is front-loaded. The trailing parameter list is mildly redundant with the schema but low-cost.

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?

No output schema, no annotations, and a nested rules array whose item fields (field, target_field, weight, relation) are never explained. An agent can guess intent but cannot confidently construct valid rules from this 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 coverage is 50% (collection documented, rules array not), and the description restates the parameter names while surfacing the three rule_type values. It adds a little meaning by tying rule types to metadata attributes, but explains nothing about field, target_field, weight, or relation within rule objects.

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

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

States a specific verb and resource: 'Declaratively induce explicit graph edges from existing document metadata attributes'. The three named rule types give concrete scope. It doesn't explicitly differentiate itself from sibling linking tools like hyperspace_link or hyperspace_link_batch, which is the only thing keeping it 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?

No statement of when to use this versus hyperspace_link or hyperspace_link_batch, and no prerequisites or exclusions. 'Declaratively' hints at a derived/bulk approach, but the agent must infer that.

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 does well to disclose the auto-vectorization side effect and the exact return contract ({ok: true, id} / {ok: false, error}), which is valuable given there is no output schema. It omits overwrite/upsert behavior on duplicate id, whether errors are raised or returned, and any cost implications of embedding each insert.

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, zero filler, with the core action front-loaded and the return contract appended where it is useful. Nothing is repeated from the schema or title.

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, 0% parameter description coverage, and a nested object parameter, the description should explain at minimum the metadata object and duplicate-id behavior. The return-shape disclosure is a real strength, but the parameter and error-path 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 0%, so the description must compensate, and it only partly does: it clarifies that `id` is numeric and that `text` is what gets vectorized. The `metadata` parameter — a nested object, the highest-ambiguity field — is never mentioned, so an agent has no guidance on its shape or purpose.

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 concrete verb (insert/store), a concrete resource (text into a collection under a numeric id), and adds the non-obvious behavioral detail that the text is auto-vectorized. The phrasing 'new factual claim or memory' distinguishes this write path from the search/graph siblings without ambiguity.

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 versus alternatives, and no mention of prerequisites — notably that the target `collection` presumably must already exist (cf. hyperspace_create_collection). The word 'new' hints at insert-vs-update semantics but nothing tells the agent how to handle an id that already exists.

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 the data model (directed, labeled, weighted, native CSR graph) and the default relation and weight, which is real behavioral context. However, it is silent on idempotency (what happens if the edge already exists), whether missing source/target IDs error, and persistence implications of mutating the index.

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 tightly packed sentences, with the core operation front-loaded before the parameter list. The trailing parameter enumeration duplicates the schema and earns its place only marginally, but overall there is no fluff.

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

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

For a 5-parameter mutation tool with no annotations and no output schema, the description covers what is created but not the failure/duplicate behavior or what the call returns on success. Adequate for invocation, incomplete for an agent reasoning about side effects.

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 already documented in the schema; the description merely restates the names and defaults. It adds only the directional semantics (source to target), which is largely implied by the parameter names, 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 precise verb+resource: create an explicit directed, labeled, weighted edge between two entities in the CSR vector-graph. That is unambiguous about the operation, but it never names how it differs from hyperspace_link_batch, hyperspace_induce_edges, or hyperspace_unlink, so sibling differentiation is left to inference.

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 versus hyperspace_link_batch (many edges at once), hyperspace_induce_edges (automatic inference), or hyperspace_unlink. The word 'explicit' faintly hints at manual vs induced edges, but no condition or alternative is stated.

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 one meaningful trait: the insert is atomic. It says nothing about duplicate/conflict handling, whether the collection must pre-exist, required permissions, or what happens if one edge in the batch is invalid.

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 front-loaded sentences with the atomicity guarantee up front and no filler. The trailing parameter recitation is largely redundant with the schema, costing it the top score.

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 and no output schema, the description omits return information (insert count? per-edge error detail?), duplicate/conflict semantics, and prerequisites. Atomicity alone doesn't cover the gaps an agent needs before calling it on real data.

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

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

Schema coverage is only 50% — only `collection` is documented, and as 'Collection name', which adds nothing. The description recites the edge object's fields (source_id, target_id, relation, weight), all of which the schema already enumerates, and adds no meaning such as relation string conventions, weight range/defaults, or whether relation is optional.

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

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

States a specific verb and resource — bulk-insert of explicit directed edges into a CSR graph — with 'bulk' and 'explicit' implicitly separating it from single-edge linking and edge induction. It never names the sibling tools, so the differentiation is inferential 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?

'Bulk-insert' implies the batch case versus hyperspace_link for single edges, but no condition, prerequisite, or alternative is stated. An agent must infer when this is preferable to hyperspace_link or hyperspace_induce_edges.

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 return shape (JSON array of objects) which the missing output schema would otherwise hide. However, it does not explain what makes a collection 'active' — notably whether frozen collections are excluded, which matters given the freeze/unfreeze siblings — nor any ordering, size limits, or error 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?

Two short sentences, front-loaded with the action and followed by the return contract. Every clause earns its place 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?

Because there is no output schema, the description correctly supplies the return fields, but it leaves the semantics of 'active' undefined and says nothing about result size or ordering. For a simple listing tool this is close to sufficient, yet the freeze/unfreeze siblings make the 'active' filter a genuine 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a parameterless tool applies. No misleading parameter hints are present.

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

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

States a specific verb and resource ('List all active collections'), which is unambiguous and clearly distinct from mutation siblings like hyperspace_create_collection and hyperspace_delete_collection. It does not explicitly contrast itself with the other read-side tools (hyperspace_get_stats, hyperspace_get_points), but the purpose is legible on its own.

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 by the zero-parameter, read-only nature of the call, but the description never says when to reach for this versus hyperspace_get_stats or hyperspace_get_points, nor any precondition. Adequate but leaves routing 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?

No annotations are provided, so the description carries the full behavioral burden. It does not disclose whether extension actions are read-only or destructive, what permissions are required, how errors are surfaced, or that behavior varies by extension/action pairing.

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 definition is a single front-loaded sentence with no filler. The parenthetical list is dense but still concise and every part contributes an example or capability hint.

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 gateway tool that dispatches to arbitrarily many extensions, with a nested payload object, no annotations, and no output schema, the description is incomplete. It lacks guidance on discovering valid extension/action pairs, payload schemas, permissions, side effects, and expected results.

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 baseline is 3, but the description adds useful meaning by associating extension names with capabilities, such as git_ast for AST indexing/blast radius and embed for Markdown ingestion. It still does not explain how action values must pair with extensions or what payload shape each action expects.

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, 'Invoke', and a concrete resource, 'native HyperspaceDB PDK Extension', with examples such as 'git_ast' and 'embed'. It is distinguishable from core database siblings, though it never explicitly says it is the routing path for extension actions rather than those core 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 example extensions and brief capability notes imply when the tool is useful, but there is no explicit when-to-use versus when-not-to-use guidance. It does not tell the agent how this relates to sibling tools like hyperspace_search_text or hyperspace_explore_graph.

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 must carry the full behavioral burden. It discloses that this is a forecast operation returning a JSON trajectory summary, but says nothing about whether it is read-only, how expensive it is across many trajectory_ids, or whether results are deterministic for a given horizon.

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 tight sentences that lead with the purpose, then requirements, then output. Nothing is wasted, though the terminology could be simpler.

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 'predicted trajectory summary as JSON' is too vague to tell an agent what fields come back or how to read them. The role of `curvature` is also never explained, so the definition is only adequate.

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 baseline is 3. The description's 'steps sets prediction horizon' simply restates the schema's 'Steps to predict ahead', and the unexplained `curvature` parameter is left entirely to 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 and resource: forecasting future agent thought paths via Koopman momentum extrapolation. That is clearly distinct from siblings like hyperspace_analyze_thought_stability or hyperspace_graph_traverse. It stops short of 5 because the jargon ('Koopman momentum extrapolation') is never grounded in plainer terms.

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 says what is required (`collection` and `trajectory_ids`) and what `steps` controls, which implies the forecasting scenario, but gives no when-to-use versus alternatives such as analyze_thought_stability and no preconditions or exclusions.

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

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

With no annotations, the description carries the full burden but does disclose meaningful behavior: it may request multiple-choice clarification from the user and fans queries out into parallel sub-queries. It does not say whether it only plans (returning sub-queries for the caller to execute) or actually performs the search, nor whether clarification halts execution — a real behavioral ambiguity.

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 dense sentences, front-loaded with the role and then the two concrete behaviors. Nothing repeats the tool name or title and every clause carries 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, so the description should explain what comes back — presumably either a clarification request or a list of sub-queries — but it only gestures at this. For a planning tool whose output shape determines the agent's next step, that leaves a notable 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?

Schema description coverage is 100%, so all four parameters are already documented, establishing a baseline of 3. The description reinforces 'parallel sub-queries' for max_sub_queries but adds no format or constraint 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?

The description gives a specific function: pre-search intent evaluation that detects ambiguous queries and decomposes multi-part queries into parallel sub-queries. That is concrete enough to distinguish it from retrieval siblings like hyperspace_search_text, though it never acknowledges clarify_and_split_intent, which appears to overlap almost exactly.

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?

'Evaluates user intent before vector search' implies a position in the pipeline, but no explicit when-to-use/when-not rules are given. Critically, there is no guidance on when to pick this over the near-identical sibling clarify_and_split_intent, leaving the agent to guess.

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 says the operation happens on the server and returns status as JSON, but it does not disclose whether the rebuild is expensive, blocking, destructive, concurrent-safe, or permission-gated.

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 short sentences with the core action front-loaded. Every sentence contributes directly to purpose or return type, with no padding.

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 maintenance tool with no annotations and no output schema, the description is minimally sufficient for invocation: the required collection and JSON return are clear. However, it omits operational impact details that an agent would need before triggering an index rebuild.

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 100% description coverage and clearly documents the single `collection` parameter. The description adds only the phrase 'for a specific collection,' which does not go beyond what the schema already 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?

The description states a specific verb and resource: rebuild and optimize the HNSW index for a collection. It is clear what the tool does, but it does not explicitly distinguish itself from related maintenance tools such as hyperspace_vacuum.

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 versus alternatives like hyperspace_vacuum, nor does it state preconditions such as needing the collection to exist. The intended use is only implied by the tool name and the phrase 'Rebuild and optimize.'

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 disclose the return shape (JSON array of up to `top_k` items with id, score, payload) — valuable since there is no output schema. It never states that this is a non-mutating read, says nothing about behavior when the collection is missing or empty, and does not mention that lexical/hybrid modes exist.

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 operation and scope, then the return contract. No filler, no restatement of the tool name.

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 return-value description compensates for the absent output schema, which is good. But the tool is actually a hybrid lexical/semantic searcher (it exposes `bm25_options` and `hybrid_alpha`), and the description frames it as purely semantic, leaving an agent unaware of capabilities it can invoke.

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

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

Schema description coverage is only 20%, so the description must compensate — it does clarify that `text` is a natural-language query and that `top_k` bounds the result count. But `collection` gets no semantics beyond the word itself and `bm25_options` is entirely unmentioned, so the low coverage gap is only partly bridged.

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?

Specific verb ("Search") plus resource ("collection") and explicit semantic matching against a natural-language `text` query, so the core operation is unambiguous. It does not, however, distinguish itself from the sibling `hyperspace_search_wasserstein`, which is also a search, so the agent has to infer which search operator applies.

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 "(natural language query)" implies the semantic-search use case, but there is no explicit when-to-use, when-not, or named alternative among the many siblings (notably `hyperspace_search_wasserstein`). An agent choosing between the two searches gets no 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 still discloses the return shape (JSON array of top_k matches with id, score, payload) and the ranking basis (Wasserstein distance), which is real value. It omits permission/auth requirements, cost/performance profile, and whether top_k is capped or results can be empty.

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 tight sentences, front-loaded with the distinguishing method, then the return contract. No filler or repetition of the tool name.

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 3-parameter read tool with no output schema, the description does explain what comes back and how it is ranked, which is the key gap. It still leaves the agent without guidance on choosing this over sibling search tools or on limits/performance, so it is adequate but not complete.

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 compensate: it does assign roles to all three parameters (text searched, collection scope, top_k result count). However it gives no format or constraint detail (e.g., top_k bounds, collection naming, how text is embedded/compared), so the gap is only partially filled.

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 a specific verb (search) plus a distinct method (Optimal Transport / Wasserstein) and the resources it operates on (collection, text). This clearly distinguishes it from the plain-text sibling hyperspace_search_text, 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 phrase 'Compares distributions/complex concept overlap' implies when this is appropriate (fuzzy distributional similarity rather than lexical match), but there is no explicit when-to-use/when-not guidance and no named alternative such as search_text or explore_graph to route between.

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 usefully discloses the return shape ({ok, iterations, loss_before, loss_after}), which is real behavioral context given there is no output schema. But it never states cost/duration, whether the operation locks or mutates the collection irreversibly, or whether the collection must be frozen first — material gaps for a write-side 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?

Two sentences, front-loaded with the mode label followed by the action and return contract; nothing is padded. The 'AI Sleep Mode' prefix is jargon but functionally orients the agent before the details.

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 2-param mutating tool with no annotations and no output schema, describing the return object is a meaningful contribution. But the un-explained `learning_rate` and the absence of prerequisites, side effects, or cost left the definition short of what an agent needs to invoke it safely.

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 explain both parameters; it only names `collection` implicitly and adds no meaning beyond the name. `learning_rate` (default 0.1) is never mentioned, so the agent has no idea what tuning it does or what sensible values are.

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 a specific verb (trigger) and mechanism (Flow Matching optimization) scoped to a `collection`, and the word 'optimize the geometric representation' distinguishes it from read-only siblings like hyperspace_analyze_geometry. It stops short of naming the adjacent maintenance tools it could be confused with, but an agent can tell broadly what it does.

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

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

'AI Sleep Mode' hints that this is a background/maintenance operation rather than a query, which is implicitly useful usage guidance. However, there is no explicit when-to-use or when-not-to-use versus hyperspace_analyze_geometry, hyperspace_freeze_collection, or hyperspace_rebuild_index, all of which touch the same collection state.

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 full weight. It usefully discloses the return shape ('ok/error status object') and the mutation effect (inserts allowed again), but says nothing about permissions, behavior on a non-frozen collection, or whether the change is reversible.

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 short sentences, front-loaded with the action and effect, with zero filler. Every clause 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 single-parameter mutation tool with no annotations, the definition covers what it does, what it returns, and the user-visible effect. Only edge-case behavior (non-frozen collection, error conditions) is missing, which is 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?

Schema coverage is 0% for the single 'collection' parameter, and the description adds no format, naming, or ID-vs-name guidance. The parameter name is largely self-explanatory, which limits the practical damage, but the description does not compensate for the gap.

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

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

States a specific verb and resource ('Unfreeze a previously frozen collection') plus the effect (allows inserts again), so it is clearly the inverse of hyperspace_freeze_collection. It does not explicitly name that sibling, but the pairing is unambiguous.

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

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

The phrase 'previously frozen' implies the precondition, but the description never states when to call this versus other recovery options or what to do if the collection was never frozen. Usage is implied rather than directed.

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 mostly fails it. 'Zero-lag invalidation' hints at immediate cache/index effects but is never explained, and there is no statement on reversibility, idempotency, permission requirements, or whether deleting an edge affects the linked entities.

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 short sentences, front-loaded with the action. The trailing parameter list is redundant with a fully documented schema, but it costs little.

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 mutation with zero annotation coverage and no output schema, the description is too thin. An agent cannot tell whether the call errors on a missing edge, whether it is idempotent, or what the side effects of 'zero-lag invalidation' actually are.

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 already documented in structured form. The description merely enumerates the same names and adds no semantics, such as the default relation label 'OWNS' or what happens when 'relation' is omitted. 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+resource ('Delete an explicit directed relationship edge'), which is unmistakable and clearly the inverse of the sibling hyperspace_link. It does not explicitly name that sibling, so differentiation is inferable rather than stated.

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 hyperspace_link_batch, hyperspace_induce_edges, or hyperspace_delete_points. There are no prerequisites, no exclusions, and no mention of what happens if the edge does not exist.

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 does disclose the key behavioral trait that the purge is permanent and that disk space is reclaimed, which is valuable. However, it says nothing about whether the operation is long-running/blocking, whether it locks the collection, permissions required, or whether it can be interrupted — material omissions for a destructive maintenance 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?

Two tight sentences; the effect (purge + reclaim) is front-loaded and the return value follows. Every clause earns its place 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?

For a zero-param maintenance call with no output schema, the description covers what it does and roughly what it returns ('vacuum status and reclaimed-space result'). It does not cover operational risk — duration, blocking behavior, or reliability concerns — which is the missing piece an agent needs before firing a database-wide 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?

The tool takes zero parameters and the description introduces none, so there is no parameter semantics to clarify. Baseline of 4 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 and target ('perform vacuuming on the database') plus the concrete effect: purging deleted vectors and reclaiming disk space. This implicitly separates it from hyperspace_delete_points (which marks points deleted) and hyperspace_rebuild_index, though it never names those siblings 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?

No guidance on when to run this versus delete_points, rebuild_index, or cache_clear, and no prerequisites stated (e.g., run after bulk deletions, disk pressure). The agent must infer that it is a post-deletion maintenance operation purely from the phrase 'purge deleted vectors'.

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 call is read-only or mutating, what the verdict looks like (boolean, score, violating context IDs), or what happens when the answer fails the check. Only the guardrail framing implies it is a non-destructive check.

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 tool's role is stated before the technical qualifier. The 'Tribunal Router (Mathematical Anti-Hallucination Guardrail)' prefix is somewhat ornamental but short.

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 five parameters, three required, no output schema, and no annotations, the description should explain the result shape and failure semantics but does not. An agent can form the call but cannot anticipate what a verification outcome contains.

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 80%, so the baseline is 3. The description reinforces that llm_answer is the candidate text and context_ids are the retrieved anchors, and the 'geodesic boundaries' language gives loose context for check_geodesic and max_distance_threshold, which the schema leaves undescribed.

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 (verify) and a specific resource (an LLM answer against retrieved context IDs), and the 'anti-hallucination guardrail' framing makes the intent unmistakable against siblings like search or analyze_geometry. It does not explicitly name a sibling to distinguish from, and the 'entailment cones / geodesic boundaries' jargon obscures rather than sharpens the purpose.

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 call this versus alternatives such as hyperspace_get_trust_score or hyperspace_analyze_geometry, nor any prerequisite (e.g., that context_ids must come from a prior search). The agent must infer that this is a post-generation validation step.

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