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 read-oriented nature of the operation ('compiles'), the content categories, and the 1–5 hop traversal. However, it does not mention whether the tool has side effects, how expensive deep traversal is, or how entity vs entity_name are resolved when both are supplied.

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

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

The entire description is one dense, front-loaded sentence. It states the main purpose first, then lists the key content categories without repetition or filler. Every phrase earns its place.

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

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

For a tool with no output schema and no annotations, the description gives a reasonable sense of the returned content, but it omits important operational details: there are zero required parameters, yet the tool is for 'an entity,' and the description does not explain what happens if no entity is provided or how the two entity parameters interact. Usage context is also left implicit.

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. The description reinforces the 'hops' semantics by mentioning multi-hop cross-references, but it does not add meaningful detail beyond the schema, such as precedence between entity and entity_name or fuzzy matching behavior.

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

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

The description uses a specific verb ('compiles') and resource ('relational knowledge graph dossier for an entity'), and enumerates concrete outputs: linked documents, timeline, transactions, and multi-hop cross-references. This clearly differentiates it from siblings like sovereign_search_vault or sovereign_node_status.

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

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

There is no explicit guidance on when to use this tool versus alternatives, nor any stated exclusions or routing conditions. The word 'complete' implies comprehensive investigation, but the description does not tell the agent when to prefer this over sovereign_search_vault or sovereign_route_and_analyze.

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 bears the full burden of behavioral disclosure. It does advertise in-memory, O_RDONLY, zero-disk-extraction behavior, which is useful, but this is potentially contradicted by the schema's extract_diagram_to_artifact/artifact_output_dir parameters that write PNGs to disk. It also does not disclose the destructive side effects of purge_prefix or the mutating nature of relocation operations.

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

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

The description is two sentences with no fluff. The primary streaming/inspection purpose is front-loaded, followed by secondary modes. It is dense with formats and actions, but every clause contributes information; the structure is efficient for the tool's breadth.

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

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

This is a complex, multi-mode tool with 14 optional parameters, no output schema, and no annotations contrary to behavior. The description omits what the tool returns, which parameters are required for each action (e.g., old_prefix/new_prefix for relocate/purge), and does not flag that some modes mutate the graph or write artifacts to disk. The rich schema helps, but the description alone is insufficient for safe and correct invocation.

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

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

Schema coverage is 100%, so baseline is 3. The description adds meaningful semantic context beyond the schema by grouping section_filter and char_offset as 'section/offset slicing' and explaining the relocation/purge actions as 'zero-reindex corpus path relocation / stale relationship cleanup'—concepts not obvious from the enum or parameter names alone.

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

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

The description clearly identifies a specific verb ('inspects') and resource ('archive containers') with an explicit list of formats, and it names the core operations (inspection, slicing, relocation, purge, stats). It does not explicitly differentiate from sibling tools, so it falls short of a 5, but the purpose is unmistakable.

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

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

The description implies usage scenarios by listing the supported operations ('section/offset slicing', 'relocate_prefix', 'purge_prefix', 'corpus_stats'), but it gives no explicit guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites. It is adequate but relies on inference.

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

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

With no annotations provided, the description carries the full burden. It states the tool inspects and reports metrics, implying a read-only operation, but doesn't disclose potential side effects, rate limits, or whether it requires any prerequisites. It doesn't contradict anything but adds only limited behavioral context beyond the action verb.

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, concise sentence that front-loads the verb and resource, covering the key aspects of health, indexing stats, and operational metrics with no fluff or repetition.

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

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

Given the tool has no parameters and no output schema, the description adequately covers what the tool does and what it reports. While it could mention return format or typical use cases, the simplicity of the tool means the description is largely sufficient for an agent to invoke it correctly.

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

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

The tool has zero parameters, which is fully documented by the empty schema. The description adds value by clarifying the tool's purpose, which compensates for the lack of parameter details. Since there are no parameters to explain, a baseline of 4 is appropriate.

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

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

The description clearly states the tool inspects health, indexing stats, and operational metrics of the node, specifying the resource and purpose. It distinguishes from siblings by focusing on node status rather than scanning, searching, or optimizing, though it doesn't explicitly name a sibling.

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

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

The description implies it's for checking node health/status, but gives no explicit guidance on when to use it over siblings like sovereign_inspect_archive. No exclusions or conditions are stated, leaving the agent to infer usage from the tool's name and the sibling list.

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

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

With no annotations, the description carries the full behavioral burden. It does disclose that the tool pre-filters, returns cited evidence chunks, and guarantees at least 40% token reduction. It does not, however, disclose read-only status, clearance enforcement behavior, failure modes, or what happens when no verified evidence is found.

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

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

Two sentences with no filler. The main function is front-loaded, and the performance benefit is stated immediately after. Every phrase earns its place.

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

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

For a 10-parameter tool with no output schema, the description gives only a high-level view: evidence chunks, citations, and token reduction. Parameter details are covered by the schema, but return structure, enum behavior, and edge cases are left unspecified, which is a notable gap for a tool this complex.

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 even without additional parameter explanation in the tool description. The description adds no parameter-level nuance 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 names a specific verb and resource: 'pre-filters large archives' into 'verified evidence chunks with citations.' It also conveys a distinct value proposition around token reduction, which separates it from sibling search/inspection tools. However, it does not explicitly name or contrast any sibling tool, so it stops just short of full differentiation.

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

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

The token-reduction framing implies use when an agent needs condensed, verified context before consumption. There is no explicit guidance about when not to use this tool or which sibling to prefer instead, so usage rules remain mostly implicit.

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

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

With no annotations provided, the description carries full burden for behavioral disclosure. It mentions 'NanoRunner synthesis' and 'execution_mode telemetry' but does not explain what side effects, permissions, or performance characteristics exist. It does not state whether this tool is read-only or has implications for data retrieval, error handling, or security beyond the user_clearance parameter. The description is vague about what happens when a query is routed, whether synthesis is optional, or if any state changes occur.

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

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

The description is a single, dense sentence stuffed with jargon and internal references (ADR-40, NanoRunner, MAC pushdown) that are meaningless to an agent without prior context. It lacks front-loading of the tool's core purpose; the keyword 'Routes' appears mid-sentence. Conciseness is sacrificed for technical flair, making it hard to parse quickly.

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

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

Given the tool's complexity (routing, multiple retrieval types, synthesis, telemetry), the description is inadequate. It does not explain the two-pronged routing logic in practical terms, when to set synthesize=false, or how user_clearance affects results. With no output schema, the description should clarify what the agent can expect in return, but it only mentions 'fast_summary with execution_mode telemetry' without details. The external context signals (siblings) are not leveraged, so the description is incomplete for correct 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 the schema already documents all four parameters (query, limit, synthesize, user_clearance) with descriptions. The tool description adds some context by mentioning 'explicit execution_mode telemetry' and 'NanoRunner synthesis', which hints at the synthesize parameter's purpose. However, it does not elaborate on query types beyond listing them, and the user_clearance parameter's role in 'MAC pushdown' is only mentioned in passing. The description adds minimal value beyond the schema, so 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?

The description states a specific verb and resource ('Executes... Retrieval & Resilient Intent Router'), but uses jargon ('Two-Pronged Hybrid Retrieval', 'MAC pushdown', 'multi-tier cognitive queries') that obscures what the tool actually does. It distinguishes itself from siblings only by naming internal components, not by describing its practical function. An agent could infer it routes and analyzes queries, but the description is dense and not immediately clear.

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

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

There is no explicit guidance on when to use this tool versus siblings like sovereign_search_vault or sovereign_get_entity_dossier. The description mentions routing deterministic identifiers vs cognitive queries but doesn't tell the agent which type of query should be directed here versus a sibling. The tool's role in the overall workflow is implied but not stated, 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?

The description explicitly discloses that the scan is 'strictly read-only' and uses os.scandir, which is valuable behavioral context beyond the schema. It also mentions a time budget (max_scan_seconds) and the 60-second radar concept, giving the agent a sense of bounded execution. However, it does not describe what happens on timeout or whether results are persisted.

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

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

The description is a single sentence that packs the tool's purpose, method, and scope efficiently. It is front-loaded with the action and resource. Slightly dense with the ADR-08 reference and directory list, 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 read-only discovery tool with 100% schema coverage, the description is largely complete. It explains what the tool does, how it does it (os.scandir), and its safety profile (read-only). It lacks explicit output/return format details, but since there is no output schema, a brief note on what the ranked results look like would have made it 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 100%, so the schema already documents both parameters. The description adds the 'strictly read-only' and '60-second' context but does not add new meaning about the parameters themselves. 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?

The description names a specific verb ('Runs'), a specific resource ('ADR-08 60-Second Auto-Discovery Onboarding Radar'), and the exact outcome: discover, classify, and rank domain knowledge directories. It also lists the target directory categories, which distinguishes it from sibling tools like sovereign_search_vault or sovereign_inspect_archive.

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

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

The description implies this is an onboarding/discovery scan for domain knowledge directories, but it does not explicitly state when to use it versus alternatives like sovereign_search_vault or sovereign_optimize_context. The context is clear enough for an agent to infer the use case, but no explicit when/when-not guidance is provided.

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

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

No annotations are provided, so the description carries the full burden. It discloses the hybrid dense + sparse retrieval approach, which is useful, but it doesn't state whether this is read-only, whether it requires special permissions, what the result format is, or any rate limits or side effects. For a search tool, the lack of return format and scope details is a gap.

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

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

One sentence, front-loaded with the core action and method. It's concise and to the point, though it could add a bit more context without becoming bloated.

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

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

For a search tool with no output schema and no annotations, the description is thin. It doesn't describe what results look like, how to interpret retrieval_mode, or any constraints. The sibling tools suggest a broader system, but this description doesn't position the tool within that system.

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 67% (query and limit are described, retrieval_mode is not). The description adds the 'hybrid dense + sparse' context, which helps understand the query semantics, but it doesn't explain the retrieval_mode values or how limit behaves beyond the schema. Baseline 3 is appropriate since the schema covers most parameters.

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

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

The description states a specific verb ('search') and resource ('sovereign vault') and mentions the hybrid dense + sparse vector approach, which distinguishes it from sibling tools like sovereign_get_entity_dossier or sovereign_inspect_archive. However, it doesn't explicitly name a sibling or clarify what 'sovereign vault' contains, so it's clear but not fully differentiated.

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

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

The description implies this is the tool for direct vector search across the vault, and the retrieval_mode enum hints at use cases (high_precision, legal_discovery, exact_entity). But there's no explicit when-to-use vs alternatives, no exclusions, and no mention of when to prefer a sibling tool like sovereign_route_and_analyze or sovereign_scan_onboarding_radar.

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