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

With no annotations provided, the description carries the full behavioral burden but discloses almost nothing: no mutation semantics, side effects, permissions, idempotency, or failure behavior. The single useful detail is the requirement that geometry_repairs mode match the later conversion, but that is insufficient for a tool whose name implies applying onboarding.

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, but its two clauses are cryptic rather than informative. It avoids verbosity, yet the main clause does not clearly orient the reader before introducing the geometry_repairs constraint.

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

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

For a five-parameter tool with a nested proposal object, no annotations, and 0% schema description coverage, the description is drastically incomplete. Even though an output schema exists, the input behavior and required setup are almost entirely 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 description coverage is 0%, so the description must compensate for five undocumented parameters. It hints that source and proposal are related via "source-bound proposal" and mentions geometry_repairs mode, but project_dir, proposer, the proposal object structure, and source format are left entirely unexplained.

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 says "Compile a source-bound proposal" but does not explain what applying AI onboarding means or how this differs from sibling tools such as prepare_ai_onboarding, auto_onboard_and_convert, or run_conversion. The verb "compile" is specific, but the resource and effect on the project remain vague.

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 only guidance is the constraint that conversion must use the same geometry_repairs mode. There is no statement of when to use this tool instead of prepare_ai_onboarding or auto_onboard_and_convert, no prerequisites, and no 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?

No annotations are provided, so the description carries the full behavioral burden. It does not state whether the operation is read-only, whether it has side effects, what permissions are needed, or what the verification checks concretely cover.

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. Its brevity is appropriate, though the phrase 'delivered layer census' is jargon that reduces immediate clarity.

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

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

The tool is structurally simple and has an output schema, so return values need not be explained. However, with no annotations and no parameter explanation, the description leaves important operational context missing, including what artifacts and census checks are actually verified.

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 single required parameter, run_dir, is undocumented in structured fields. The description only implies that it identifies 'one immutable run' and does not explain the expected path or format.

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

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

The description has a clear verb, 'Verify,' and a specific resource, 'one immutable run's artifacts and delivered layer census.' It distinguishes the action from likely siblings like inspect_run, though it does not explicitly name or contrast 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?

Usage is only implied by the word 'Verify'; there is no explicit when-to-use guidance, no prerequisites, and no mention of alternatives such as inspect_run or audit_visual_conversion.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not state whether the audit is read-only or mutating, what permissions are needed, whether files are created or modified, or what side effects occur. The only clue is the word 'audit', which loosely implies read-only, but this is not explicit.

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

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

The description is a single, front-loaded sentence with no filler. It is concise and to the point, though its terseness contributes to other gaps rather than being a problem in itself.

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?

An output schema exists, so return values need not be explained. However, with 3 required parameters and 0% schema coverage, the description should provide some semantic context for those parameters. It also omits behavioral details and usage alternatives. Given the tool's complexity (4 parameters, no annotations), the description is insufficient.

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 4 parameters with 0% description coverage, and the description does not mention any parameter names or meaning. Without schema explanations, the agent must guess the purpose of 'source_run', 'run_dir', 'output_dir', and 'partition'. The description fails to compensate for the complete lack of schema documentation.

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 'audit' and a resource 'source-bound geometry, fields and labels', but the phrase 'canonical visual audit' is vague and does not distinguish this tool from the sibling 'audit_run' or explain what a 'visual audit' entails. An agent can infer it audits visual aspects but cannot confidently differentiate it from other audit tools.

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

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

The description provides no guidance on when to use this tool versus alternatives such as 'audit_run', 'inspect_run', or 'validate_project'. It also lacks any prerequisites or conditions. There is no explicit or implied usage context beyond the general term 'audit'.

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, yet it never says that this writes into project_dir and run_dir, whether the operation is idempotent or resumable, what 'provider-backed' implies (network calls, credentials, cost, latency), or what happens on partial failure mid-pipeline. 'Deterministic admission' hints at a check step but not at pass/fail consequences.

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 clause with no filler, so nothing is wasted, but that brevity comes from omission rather than precision; the three abstract nouns are packed without front-loading what the agent actually needs (required inputs, side effects).

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 an 11-parameter orchestration tool with side effects on two directories, no annotations, and no parameter documentation, one sentence is far too thin. The output schema covers return values, but nothing tells an agent how to fill required fields, what the defaults mean, or what the pipeline mutates.

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?

Eleven parameters with 0% schema description coverage means the schema provides titles only, and the description contributes nothing: source, run_dir, matching, osm_data, match_profile, svg_mode, svg_font_dirs, force_bootstrap are all undefined. This is exactly the case where the description must compensate and does not.

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 three phases (onboarding, admission, conversion) and implies an orchestrated pipeline, which is more than a tautology. But 'deterministic admission' is unexplained jargon, and it never distinguishes itself from siblings like run_conversion, bootstrap_project, or prepare_ai_onboarding/apply_ai_onboarding, which together appear to cover the same ground.

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

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

There is no statement of when to use this bundled pipeline instead of the individual onboarding/convert tools, and no prerequisites or exclusions. The only implied guidance is the conjunction 'and', which weakly suggests it does multiple steps at once.

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 hints that output is a 'draft' bound to a source, but says nothing about what happens if project_dir already exists, what the force flag overwrites/destroys, or what permissions or side effects are involved in a write 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?

One sentence, front-loaded with the verb and the deliverable, with zero filler. Nothing could be trimmed without losing content.

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

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

An output schema covers return values, but for a three-parameter write tool with no annotations and 0% schema coverage, the description leaves the force semantics, directory-collision behavior, and prerequisite workflow undocumented.

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% and the description only loosely gestures at 'source' and the project pack. The 'force' parameter, which is the riskiest to use incorrectly, is not explained anywhere, so the description fails to compensate for the coverage 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?

Specific verb ('Create') plus a specific resource ('source-bound draft project pack') with a scoping constraint ('one previously inspected DWG'). It does not name or differentiate from plausible siblings like prepare_cad_bundle_workspace or inspect_source, 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?

'previously inspected DWG' implies a prerequisite (run inspect_source first) but never states it explicitly, and there is no guidance on when to use this versus prepare_cad_bundle_workspace or how it fits the wider workflow.

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, and it does disclose non-obvious behavior: it uses the canonical QGIS subprocess, treats absent registrations as explicit non-matches rather than successes, preserves existing SVG bindings, and refuses to invent new semantic symbol assignments. It still omits overwrite/destructive behavior on output_path and any permission or failure-mode details.

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 sentences, front-loaded with the action, with no filler. The phrasing is terse and somewhat gnomic ("An absent registration stays explicit"), but each sentence carries a distinct behavioral point.

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?

Output schema exists, so return values need no explanation, and the preservation semantics are covered. But for a five-parameter build/conversion tool with no annotations, the description leaves input roles (project vs. OSM data vs. output path) and workspace preconditions unstated, which an agent needs to call 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?

Schema description coverage is 0%, so the description must compensate for five undocumented parameters, and it does not. It never mentions project_path, osm_data, output_path, standalone, or matching_context_path, leaving their meaning and required-ness entirely to the bare titles.

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 ("Build a new offline QGIS review") and adds scope ("preserve matched or uncorrected identity"). The "build/create" framing implicitly distinguishes it from verify_qgis_review and start_review_server, though it stops short of naming 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 when-to-use guidance, no prerequisites, and no alternatives named. The agent can infer this is the creation step preceding verify_qgis_review, but nothing in the text states the ordering or selection conditions.

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

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

With no annotations, the description carries the full disclosure burden. It adds useful behavioral context by stating that CAD database bytes are preserved and that the output consists of candidate review projects, but it does not cover write behavior, output directory handling, permissions, or whether existing outputs are overwritten.

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 tightly written sentences with the main action front-loaded. The second sentence adds meaningful scope and exclusion details without wasteful 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?

An output schema exists, so return values need not be explained. However, the tool requires three directory parameters with zero schema descriptions and has no annotations, and the description does not explain how those directories relate to the build process.

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 for undocumented parameters. It references SVGs and a review package, which hints at the roles of assets and output, but it does not explain baseline_dir, assets_dir, or output_dir directly.

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: apply hash-bound source-instance SVGs to a new canonical review package. It also clarifies that the tool does not accept semantic interpretations or OSM matching revisions, which helps separate it from some sibling tools. However, it does not explicitly distinguish itself from other review/package builders in the sibling list.

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

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

The description gives a negative usage condition by saying what the tool does not accept, implying it should be used when working from hash-bound source-instance SVGs. It does not provide explicit when-to-use guidance or name the alternative sibling tools for review/package creation.

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

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

With no annotations, the description carries the full burden. It usefully discloses that execution happens on a workspace copy and preserves the source and old revisions, which signals a non-destructive-to-source operation. However, it does not explain what 'allowed' means, permission requirements, failure behavior, or the lifecycle of the workspace copy.

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 wasted words. It is concise, though for a tool of this complexity the brevity contributes to under-specification; still, from a conciseness standpoint it is efficient.

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

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

The tool is complex: it invokes arbitrary CAD tools with a nested arguments object, has no annotations, and has many siblings. The one-sentence description omits prerequisite workflow, parameter details, and behavioral edge cases, so it 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 0%, so the description must explain all three required parameters. It indirectly maps 'workspace copy' to workspace_id and 'allowed CAD tool' to tool_name, but says nothing about the nested 'arguments' object, leaving its structure and constraints undocumented.

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

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

The description states a specific verb ('Call') and resource ('allowed CAD tool on a workspace copy') and adds a scoping detail ('preserving source and old revisions'). It does not explicitly differentiate from siblings such as list_cad_bundle_tools or prepare_cad_bundle_workspace, so it earns 4 rather than 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 guidance on when to use this tool versus alternatives, no prerequisites (e.g., preparing a workspace), and no mention of related tools like list_cad_bundle_tools to discover allowed tools. The description only implies usage through its verb.

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 two meaningful traits: the cancellation is durable (persisted, not best-effort) and it fences the worker so no result is published. It does not say whether the call is idempotent, what happens if the job already completed, or what authorization is 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?

A single front-loaded sentence with no filler; the core action leads and the fencing consequence follows. Every word 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?

The output schema exists, so return values need not be explained, and the fencing/durability semantics are a real addition. But with zero annotation coverage and zero schema description coverage, the definition leaves parameter meaning and error/idempotency behavior undocumented for a state-mutating 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 0% for both required parameters, and the description never mentions job_id or semantic_store. Their names are largely self-explanatory, but nothing clarifies format, scope, or whether semantic_store must match the job's originating store.

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 ('cancel a compile job') plus the collateral effect on the worker. It is clearly distinguishable from compile_semantic_revision and reconcile_compile_jobs by verb alone, 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?

There is no when-to-use guidance, no preconditions (e.g. job must be pending/running), and no mention of alternatives such as reconcile_compile_jobs for cleaning up already-finished jobs. The only usage signal is the implicit 'cancel things you want cancelled'.

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 important behavior beyond the name: atomicity, revision CAS, and idempotency. Still, it does not explain what happens when CAS fails, how idempotency keys are scoped, or what permissions are required, leaving meaningful operational 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?

The definition is a single front-loaded sentence with no filler. Every term (atomically, validated, CAS, idempotency) is substantive, and the key mutation behavior is stated immediately.

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 mutation with six required parameters, nested object input, and no annotations. The description gives useful high-level traits but omits prerequisites, parameter meanings, and failure behavior. An output schema exists, so return values need not be explained, but the calling contract remains under-specified.

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% for six required parameters, so the description must carry the burden. It only vaguely gestures at 'patch' and 'idempotency' and implies a revision through 'CAS,' but it never explains source_run, prepare_manifest, semantic_store, or preview_hash. The parameter semantics are insufficient for a correctly formed call.

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

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

The description states a specific verb and resource: 'commit a validated semantic patch.' It adds meaningful qualifiers ('atomically,' 'revision CAS,' 'idempotency'), so an agent can tell it apart from read-only or preparation siblings. However, it does not explicitly name preview_semantic_patch or compile_semantic_revision as alternatives, so it falls short of full sibling 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?

There is no explicit guidance on when to use this tool versus preview_semantic_patch or other semantic-store operations. The word 'validated' implies a prerequisite but does not state what validation must occur first, nor does it describe when not to use the tool. Usage is only inferable from context.

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

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

No annotations are provided, so the description carries the full burden. It usefully discloses immutability and the absence of auto promotion, but says nothing about side effects, whether output_dir is written, permissions, failure/retry semantics, or why an idempotency_key is mandatory for a 7-parameter 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?

A single front-loaded sentence with no filler; the scoping qualifier 'without auto promotion' is well placed. The terseness is a completeness problem rather than a conciseness one.

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 output schema covers return values, so that need not be described. But for a complex 7-parameter, 6-required mutation with no annotations, zero schema descriptions, and an idempotency requirement, one sentence of jargon-heavy prose is far from sufficient context 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?

Schema description coverage is 0% across 7 parameters, so the description must compensate and it does not: revision, source_run, prepare_manifest, semantic_store, output_dir, idempotency_key, and retry_failed are never explained. Only the parameter names themselves carry any meaning, leaving key semantics such as idempotency behavior and retry_failed scope undocumented.

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

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

The verb 'compile' and object 'semantic candidate' give a recognizable action, and 'without auto promotion' hints at how it differs from commit_semantic_patch. However, 'immutable source-coordinate semantic candidate' is undefined jargon, so an agent cannot confidently tell what artifact is produced without consulting sibling tools.

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

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

There is no explicit when-to-use guidance, no prerequisites, and no named alternative among the many semantic siblings (prepare_semantic_batches, preview_semantic_patch, commit_semantic_patch, initialize_semantic_store). 'Without auto promotion' weakly implies the candidate must be promoted later, but the agent must infer that workflow.

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 mentions local validation, which is useful, but does not disclose side effects such as writing to output_path, overwrite behavior, required permissions, or what happens on validation failure.

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

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

The description is a single front-loaded sentence with no wasted words. It is efficient, though its brevity leaves important gaps that are better scored under completeness.

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 five required parameters, nested objects, no annotations, and no schema descriptions. While an output schema exists to explain returns, the description does not provide enough input semantics or behavioral context for an agent to invoke this complex mutation 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?

All five required parameters have 0% schema description coverage, and two are nested objects. The description does not explain graph_path, policy_id, proposer, operations structure, or output_path, leaving the agent with essentially no semantic guidance beyond the parameter names.

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 (Create) and resource (typed pack) and says it validates locally. However, 'typed pack' and 'ID-only proposals' are vague, and it does not clearly distinguish the tool from the sibling validate_decision_pack.

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 instead of validate_decision_pack or other siblings. The only implied usage is that it creates a pack and validates it locally, with no prerequisites or exclusions 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?

No annotations are provided, so the description carries the full behavioral burden. It implies a write/create operation and hints at immutability via 'immutable graph and visual hashes', but it does not state that a plan file is produced, where output_path writes, whether existing files are overwritten, what inputs must pre-exist, or any failure/side-effect behavior.

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

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

The single sentence is front-loaded and free of filler, but it is too terse for a 5-parameter creation tool with no annotations. Conciseness is not the problem; under-specification is.

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 absence of annotations, a 0% schema description coverage, and a create-style operation, the description is not complete enough. It omits prerequisites, plan artifact semantics, validation relationship, output behavior, and most parameter meanings, even though an output schema covers the return shape.

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% across 5 parameters. The description loosely gestures at graph_path and visual_manifest_path ('graph and visual hashes') and assignments ('scene-role rankings'), but it does not explain the format, required contents, producer semantics, or the output_path default. Two parameters are entirely unaddressed and the mapped ones remain ambiguous.

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 operation ('Bind ... rankings to ... hashes'), but it is heavily jargon-laden and never says that it creates a scene interpretation plan artifact or how it differs from the sibling validate_scene_interpretation_plan. An agent can infer the broad intent, but the core resource ('plan') is only available from the tool name, not the description.

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

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

There is no when-to-use guidance, no prerequisites (e.g., needing an existing graph, visual manifest, or prior scene-role ranking step), and no mention of the sibling validation tool or any alternative. The agent is left to infer the entire workflow context.

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

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

With no annotations, the description carries the full behavioral burden, but it only discloses the existing-run constraint and a run_dir caveat. It does not explicitly confirm read-only behavior, permissions, side effects, or what inspection entails beyond the scope labels.

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 compact sentence with no filler, and the most important constraint (EXISTING run) is front-loaded. Its brevity borders on cryptic, but it does not waste space.

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

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

An output schema exists, so return values need not be described, but the tool still has four parameters at 0% schema coverage and no annotations. The description leaves graph_path, expected_identity, and core safety expectations unexplained, making it incomplete for an agent to invoke confidently.

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

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

Schema description coverage is 0%, so the description must explain all four parameters. It maps the scope values loosely to the enum and cautions that config directories are not run_dir, but it says nothing about graph_path or expected_identity, leaving half the parameters undocumented.

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

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

The description gives a specific verb ('Inspect') and names the resources/scopes (identity, runtime, artifacts, query) tied to an existing run. It is clear what the tool does, but it does not differentiate itself from nearby siblings such as inspect_run, audit_run, or get_runtime_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?

It implies the tool is for an EXISTING run and warns that project config directories are not run_dir, which gives some usage context. However, it never states when to choose this tool over siblings or when not to use it beyond that single path caveat.

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 hints at a gated workflow and a confirmation prerequisite, but says nothing about side effects, whether a decision is reversible, what state changes on accept vs reject, or whether a prior evaluation must exist. For a state-mutating decision tool this is a substantial 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?

A single compact sentence with the action front-loaded and the prerequisite second; nothing is wasted. It is efficient, though the terseness contributes to the gaps flagged in other dimensions.

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?

An output schema exists, so return-value explanation is not required. But with 5 undocumented parameters, no annotations, and a vague notion of 'gated candidate', the agent lacks enough to call this correctly or know the workflow preconditions around the decision.

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% across 5 parameters. The description implicitly explains the verdict values (accept/reject/revise) and ties accept to user_confirmed, but session_path, candidate_id, and rationale are entirely undefined in both schema and description.

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 verb 'decide' plus the three verdict actions (accept/reject/revise) make the operation legible, but the object is only described as a 'gated candidate', which is undefined. Nothing distinguishes it from the sibling evaluate_iteration_candidate, which an agent could easily mistake for the decision step itself.

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?

'accept needs user confirmation' is a genuine usage precondition that tells the agent not to accept unilaterally. However, there is no guidance on when to pick this over evaluate_iteration_candidate, record_iteration_feedback, or prepare_iteration_context, and no when-not conditions.

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

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

No annotations are provided, so the description carries the full behavioral burden. It does add one useful trait — the operation does not promote the candidate — but it never says whether evaluation is persisted, whether it mutates session state, what happens to prior feedback, or what prerequisites (e.g. an active run must exist) 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?

A single short sentence with the key constraint ("without promoting it") front-loaded and no wasted words. Its brevity is achieved through under-specification rather than disciplined compression, so it is efficient but not adequate.

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 presence of an output schema relieves the description of explaining return values, but for a 4-required-parameter workflow tool with zero annotation and zero schema-description coverage, the description is far too thin. It omits the meaning of gating, the workflow position relative to decide_iteration_candidate, and any prerequisite or side-effect information.

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% across five parameters, and the description provides no meaning for session_path, candidate_run_dir, addressed_feedback_ids, change_summary, or changed_artifacts. An agent must guess the expected format of paths, whether run dirs are relative, and how feedback IDs are sourced.

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?

"Gate a new run against the active run without promoting it" names the verb (gate/evaluate) and the resource (a candidate run vs. the active run), which is more specific than the tool name alone. However, "gate" is domain jargon and the description never explains what gating produces (a verdict? a score? recorded evidence?), and it does not explicitly distinguish itself from sibling decide_iteration_candidate.

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 decide_iteration_candidate, record_iteration_feedback, prepare_iteration_context, or inspect_iteration, all of which sit in the same iteration workflow. The only implied guidance is the parenthetical "without promoting it," which hints at a pre-decision step but leaves the ordering of the workflow 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. 'Export' implies writing to output_path, but the description does not state whether existing files are overwritten, what permissions are required, what format the exported suggestions take, or what side effects occur. For a file-producing export tool with zero annotation coverage, this is a significant 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?

The single sentence is front-loaded with the action and contains no filler. It is appropriately sized for a description, though its brevity leaves important behavioral and parameter gaps that are not addressed elsewhere.

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?

An output schema exists, so return-value details need not be explained. However, the description does not clarify where accepted lessons come from, what 'source-bound onboarding suggestions' actually are, how the output file is written, or how this tool fits into the iteration and onboarding workflow. For a two-path export tool with no annotations and no documented parameters, it is not complete enough.

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

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

Both required parameters, session_path and output_path, have 0% schema description coverage, and the description never mentions them. It does not explain the difference between the session source and the output destination, nor what a valid session path represents. The phrase 'source-bound' gives only a marginal hint and does not compensate for the missing parameter documentation.

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 transformation: 'Export accepted lessons as source-bound onboarding suggestions.' This is clearer than a tautology and distinguishes the tool's output from siblings like record_iteration_feedback or prepare_ai_onboarding. However, it does not explicitly name alternatives or clarify what 'source-bound' means, so it stops short of full sibling 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?

There is no guidance on when to use this tool versus related siblings such as record_iteration_feedback, evaluate_iteration_candidate, or prepare_ai_onboarding. The usage is only implied by the name and description; no prerequisites, exclusions, or alternative conditions are 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?

With no annotations, the description carries the full behavioral burden. It usefully discloses that the result is an immutable snapshot and includes a CRS-evidence caution, but it does not explain permissions, overwrite behavior, run_dir effects, or other mutation semantics beyond immutability.

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

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

The description is a single front-loaded sentence with no wasted wording. Its brevity is efficient, though it also leaves important gaps that are better captured under contextual completeness.

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 creates a persistent artifact and requires source and run_dir, but the description does not explain those required inputs or when the operation is appropriate. Output schema presence reduces the need to describe return values, but the mutation and parameter semantics remain substantially incomplete for a no-annotation 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 0% across 3 parameters, so the description must compensate. It adds valuable nuance for source_crs but leaves the required source and run_dir parameters completely unexplained in both schema and description.

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: "Create a new immutable CAD snapshot." That is clear enough to understand the operation, but it does not distinguish this tool from related siblings such as inspect_source, run_conversion, or package_qgis_delivery.

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 only guidance is a parameter-level caution: "omit CRS unless authoritative evidence exists." It does not state when to use export_source versus inspect_source, run_conversion, or other sibling tools, nor does it give prerequisites or exclusions for invoking it.

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

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

No annotations are provided, so the description carries the full behavioral burden. It does disclose a meaningful non-side-effect trait: inspection occurs without downloading or starting the sidecar. It does not mention permissions, caching, or other operational details.

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

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

The description is a single, front-loaded sentence with no wasted words. It efficiently states the core action and the key non-side-effect constraint.

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 no parameters and an output schema, so return values need not be described in detail. The description is nearly complete for a simple inspection tool, though it could better distinguish itself from closely related sibling 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?

The tool takes zero parameters, so there are no parameter semantics to explain. The baseline for a zero-parameter tool is 4, and nothing in the description undermines that.

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 ("Inspect") and resource ("optional pinned CAD sidecar") and clarifies it does not download or start the sidecar. This distinguishes it from preparation or execution siblings, though it does not explicitly name an alternative.

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 "without downloading or starting it" implies a read-only status check, which gives useful contextual guidance. However, it does not explicitly state when to choose this over siblings like get_runtime_status or prepare_cad_bundle_workspace.

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. 'Read' implies a non-mutating operation and 'source-bound facts' hints at provenance, but it omits error behavior, permission requirements, and what 'pre-semantic' means.

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, so it is structurally efficient. However, brevity comes at a cost: 'pre-semantic' and 'source-bound' are unexplained jargon, leaving the sentence cryptic rather than fully earned.

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?

Although an output schema exists to cover return values, the lack of annotations, 0% parameter coverage, and two required parameters leave too much unspecified for reliable invocation. The description does not explain how to construct a valid call or what a 'pre-semantic node' represents.

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% and neither required parameter, graph_path nor node_id, is mentioned in the description. The phrase 'one exact ... node' weakly implies a node identifier, but no semantics are given for either parameter.

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 ('Read') and singular resource ('one exact pre-semantic node'), adding a hint about return content ('source-bound facts'). It is clear enough to identify the operation, but it does not explicitly distinguish itself from siblings like list_cad_scene_nodes or get_evidence_node.

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

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

There is no guidance on when to use this tool versus alternatives such as list_cad_scene_nodes, nor any stated prerequisites or exclusions. The singular 'one exact' node implies lookup by an identifier, but that is left 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 supplied, so the description carries the full burden. "Describe" implies a read-only, informational call, but the description never confirms there are no side effects, doesn't note whether the returned protocol definition is versioned or environment-dependent, and says nothing about auth or caching. With an output schema present it needn't enumerate return values, but the behavioral profile is largely unstated.

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

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

A single short sentence with no filler, and the core noun phrase is front-loaded. It is arguably too terse rather than padded, 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?

An output schema exists and there are no parameters, which lowers the burden, but the description still leaves an agent unsure what class of information "capabilities" covers and how it differs from the adjacent status tools in this large sibling set. It is minimally adequate rather than 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?

The tool takes zero parameters, so there is no parameter semantics to explain; the baseline of 4 applies. Nothing in the description misdescribes inputs.

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 verb ("Describe") and an object ("stable CAD2GIS protocol and accuracy boundaries"), but "stable CAD2GIS protocol" is unexplained jargon and the tool's real role—reporting runtime/protocol capabilities—is only implicit. It does not distinguish itself from nearby capability/status siblings such as get_runtime_status or get_cad_bundle_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 guidance on when an agent should call this versus get_runtime_status, get_cad_bundle_status, or inspect_runtime. It states content but not the triggering condition 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 behavioral burden. It says 'without changing them', which usefully signals non-mutation, and 'bounded' hints at resource limits, but it omits pagination behavior, error handling, permissions, and the meaning of timeout/max_bytes.

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

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

The description is a single front-loaded sentence with no wasted words. Its brevity is efficient, though it contributes to the under-specification captured in other dimensions.

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 seven-parameter batch-read tool with no annotations and 0% schema description coverage, the description is too thin. Even though an output schema exists, an agent lacks enough context to understand required inputs, optional controls, or when to choose this tool over siblings.

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% for seven parameters. The description only loosely gestures at entity_keys via 'observed IDs', view via 'source or instance', and max_bytes/timeout_ms via 'bounded', leaving run_dir, cursor, fields, and the rest undocumented in both schema and description.

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 read operation over 'source or instance facts' for 'observed IDs', but the resource type is abstract and it does not distinguish this tool from siblings like query_source_entities or get_evidence_node. The verb is clear, but the scope remains vague.

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 provides no explicit when-to-use guidance, no exclusions, and no named alternatives. The only contextual clue is 'for observed IDs', which is not enough to route an agent among the many sibling tools.

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

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

No annotations are provided, so the description carries the full burden. 'Immutable reader facts' hints that the read is side-effect-free and the data fixed, but it says nothing about behavior when the node is missing, permission or graph-state requirements, or what allow_standalone 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?

A single short, front-loaded sentence with no filler. It is efficient, but the brevity is closer to under-specification than to disciplined economy.

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?

An output schema exists, so return values need no explanation, but with zero annotation coverage and 0% parameter coverage the description should compensate and does not. The agent is left without the graph scoping and standalone-flag semantics needed to call this 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?

Schema description coverage is 0% across three parameters (graph_path, node_id, allow_standalone), and the description explains none of them. Only a loose mapping between 'evidence node' and node_id can be inferred; the meaning and effect of allow_standalone is completely undocumented.

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

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

The description names a specific verb ('Read') and resource ('one exact evidence node'), and the word 'exact' signals single-node retrieval as opposed to the sibling list_evidence_nodes, which it never names. An agent can infer the purpose without opening the schema, though the sibling contrast is only implicit.

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

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

There is no explicit when-to-use guidance and no mention of the obvious alternative, list_evidence_nodes. The singular 'one exact' hints at the distinction but leaves the agent to infer when to fetch a single node versus enumerate them.

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 an important ownership/security boundary: only verify a service owned by this MCP process and never adopt another listener. However, it omits whether the operation is read-only, what happens when the session is unknown, and other basic behavioral traits for a status-check tool.

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

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

The description is a single sentence with no wasted words, but it is not front-loaded with a clear statement of what the tool does. The most informative part is the trailing constraint rather than the core action.

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?

Although an output schema exists and reduces the need to explain return values, the description still leaves the core action and the required session_id undocumented. For a tool with no annotations and 0% parameter coverage, this is not complete enough for reliable 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?

There is one required parameter, session_id, with 0% schema description coverage, and the description does not mention it at all. With the schema providing no semantic detail, the description fails to compensate for the parameter documentation 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?

The description says to 'Verify a service owned by this MCP process,' but it never states that this is the review server status tool or what 'verify' actually returns. The resource is referred to only as 'a service,' so the purpose remains vague despite the tool name.

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

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

It provides a negative constraint ('never discover or adopt another listener') but gives no guidance on when to call this versus siblings like start_review_server, stop_review_server, or get_runtime_status. The description does not state prerequisites or appropriate contexts for use.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Report' implies a read-only operation, but the description does not state side effects, whether any runtime probing or installation occurs, what 'readiness' means operationally, or what evidence it uses. The output schema helps with return values but not with behavioral traits.

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. It is efficient, though its brevity contributes directly to the under-specification noted elsewhere rather than being a model of compact clarity.

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

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

The output schema covers return values, and a zero-parameter read-only status tool has limited surface area. Still, the description does not explain what 'portable reader' and 'GIS runtime readiness' mean or how this differs from install_runtime/get_capabilities, leaving the agent with an incomplete mental model for selection.

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, which is the baseline-4 case. There is nothing for the description to add semantically, and the empty schema is consistent with a parameterless status report.

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 verb 'Report' and the object 'readiness' are identifiable, but 'portable reader and GIS runtime' is opaque jargon that doesn't map cleanly to any sibling tool's domain. It does not distinguish itself from nearby status tools like get_capabilities, get_cad_bundle_status, or inspect_run, so an agent cannot confidently pick it from the name 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?

There is no when-to-use guidance, no prerequisites, and no named alternative. The agent is left to infer that this is a health/readiness check versus get_capabilities or install_runtime from context alone.

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

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

No annotations are provided, so the description carries the full behavioral burden. 'Read' implies a safe read, but there is no mention of permissions, whether results are paginated despite limit/cursor params, or what 'CAD facts' actually includes.

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 wasted words, but the brevity is achieved by omitting information the agent needs, making it under-specified rather than truly concise.

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?

An output schema exists so return shape needn't be explained, but with four undocumented parameters, no annotations, and no guidance on pagination or region identity, the description leaves significant gaps for a tool that requires two identifiers.

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 (manifest_path, region_id, limit, cursor) have 0% schema description coverage and the description adds no meaning for any of them — no format for manifest_path, no notion of what region_id refers to, no explanation of pagination semantics.

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

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

States a specific verb and resource: read one visual region's CAD facts. The word 'one' implicitly distinguishes it from the listing siblings (list_visual_regions, list_scene_visual_regions), though 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?

The phrase 'without sending all drawing nodes' hints at the efficiency rationale for using this over a bulk scene fetch, but it never says when to prefer it over list_scene_visual_regions or get_cad_scene_node, nor what prerequisites 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 must carry the full behavioral burden. It discloses that the ledger is 'durable' and bound to a verified source and candidate set, but it does not explain mutation effects, whether it overwrites an existing store, required permissions, or what happens if the semantic store already exists.

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

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

The description is a single, front-loaded sentence with no filler. It is efficiently structured, though given the tool's complexity and undocumented parameters it may be too terse to be fully useful.

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?

An output schema exists, so return values need not be described. However, for an initialization tool with three required but undocumented parameters and no annotations, the description is missing critical context about prerequisites, side effects, and parameter meanings.

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 three required parameters (source_run, prepare_manifest, semantic_store) have 0% schema description coverage and are not explained in the description. The phrase 'bound to a verified source and candidate set' offers only vague hints for source_run and prepare_manifest, leaving their formats and roles unclear.

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 ('Initialize') and resource ('durable revision ledger'), and implies binding to a verified source and candidate set. It is clear enough to distinguish from siblings like inspect_semantic_store or commit_semantic_patch, though it does not explicitly name those 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?

There is no explicit guidance on when to use this initialization tool versus alternatives such as prepare_semantic_batches or inspect_semantic_store. The phrase 'bound to a verified source' hints at a prerequisite, but it does not state when-not to use it or how it fits into a workflow.

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

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

No annotations are provided, so the description must carry the behavioral load. 'Inspect' implies a read-only, non-mutating call, and the output schema covers the return shape, but the text says nothing about permissions, whether inspecting consumes or advances iteration budget, or whether any state is written.

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 that lists the four things returned with zero filler. It is well-sized, though it spends its whole budget on payload contents rather than routing context.

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

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

An output schema exists, so return values need no prose. However, for a tool whose sole parameter is undocumented in both schema and description, and with no annotations to convey safety, the definition leaves real gaps an agent must guess at.

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

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

There is one required parameter, session_path, with 0% schema description coverage, and the description never mentions it. The agent gets no hint about whether it is a filesystem path, a session identifier, or what form is expected.

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 ('inspect') applied to a specific resource ('iteration'), and enumerates what is surfaced: state, budget, pending decisions, next action. It is clearly distinguishable from mutation siblings like record_iteration_feedback and decide_iteration_candidate, though it never names an alternative 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?

Usage is only implied: 'the next action' hints that this is a pre-decision orientation call, but there is no explicit when-to-use statement, no prerequisites, and no named alternative (e.g., inspect_run, get_runtime_status) that an agent should pick 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?

With no annotations, the description must carry the whole behavioral burden. 'Immutable' and 'summary' do usefully signal a read-only, non-mutating operation that returns a condensed view rather than raw manifest data, but nothing is said about failure behavior for a bad run_dir, permissions, or size limits.

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 front-loaded sentence with no filler; the operation and its scope are stated immediately. Brevity is achieved without redundancy.

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

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

An output schema exists, so return-value detail is not required. However, for a tool whose only input is opaque, the missing run_dir semantics and absent sibling routing leave real gaps an agent would hit when calling it.

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

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

Schema description coverage is 0% and the single parameter run_dir is undocumented in both schema and description. The description never says whether run_dir is a filesystem path, an ID, or a relative directory, so it fails to compensate for the coverage 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 ('Return') and resource ('immutable manifest summary for one conversion run'), which is clearly distinct from siblings like audit_run or inspect_iteration. It stops short of naming which sibling to prefer, leaving the boundary with audit_run implicit.

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

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

There is no guidance on when to use this versus audit_run, inspect_iteration, or inspect_source, and no prerequisites stated. The agent must infer usage from the name and one-line purpose alone.

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

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

No annotations are provided, so the description carries the full behavioral burden. 'Read' signals a non-mutating operation, but the description does not state permissions, side effects, error behavior, or what 'authoritative' implies in practice.

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

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

The description is a single front-loaded sentence with no wasted words. Its density is concise but borders on under-specification for a tool with three parameters.

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?

An output schema exists, so return values need not be described. However, with no annotations, 0% schema description coverage, and many closely related semantic-store tools, the description is not complete enough to tell an agent how to invoke it correctly or distinguish it from alternatives.

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 for three undocumented parameters. It only vaguely hints at optional compile job state and does not explain semantic_store, job_id, or idempotency_key.

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, 'Read', and names the resource as the authoritative semantic revision plus optional durable compile job state. This distinguishes it from mutation/compile siblings in the semantic-store group, though it does not explicitly name an alternative tool.

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

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

There is no guidance on when to use this tool versus inspect_source, initialize_semantic_store, compile_semantic_revision, cancel_compile_job, reconcile_compile_jobs, or other semantic-store siblings. Preconditions and exclusions are unstated.

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

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

No annotations are provided, so the description must disclose behavioral details itself. It says "Read and summarize" and hints at mapping isolation, but it does not explain whether it creates or stores a mapping, what permissions are required, or whether the operation has side effects.

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

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

The description is a single front-loaded sentence with no filler. The key action and the mapping-isolation constraint are stated immediately.

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

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

The tool is simple, with one required parameter and an output schema, and the description gives its core purpose plus a mapping constraint. Still, with no annotations and no parameter documentation, it leaves meaningful gaps about how to invoke it and how it differs from related source-inspection 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?

Schema description coverage is 0% for the single required "source" parameter. The description implies the source is a new DWG, but it does not state whether the argument is a path, file name, identifier, or another form, so it only minimally compensates for the missing schema documentation.

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: "Read and summarize a new DWG." This distinguishes it from mutation or delivery tools, but it does not explicitly name the sibling alternative such as export_source or query_source_entities.

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 phrases "new DWG" and "without reusing another source's mapping" imply this is for fresh sources with isolated mapping, giving some usage context. However, it does not state when not to use it or name the alternative tool for existing or mapped sources.

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. "Checksum-pinned" and "portable" add useful integrity/portability context, but it does not disclose whether installation downloads files, needs network/admin permissions, is idempotent, or what side effects occur.

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

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

The description is a single front-loaded sentence with no filler. Every phrase contributes to identifying the installed artifact.

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 output schema exists, so return values need not be explained, and the empty parameter set makes invocation simple. However, for an install/mutation tool with no annotations, the description should say more about prerequisites, side effects, or when to use it relative to get_runtime_status.

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

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

The tool has zero parameters, so there are no parameter semantics to document. The empty schema is self-evident, and the description does not need to add parameter details.

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: "Install" plus "portable LibreDWG runtime." It is clearly distinguishable from get_runtime_status by action, but it does not explicitly name or differentiate the sibling alternative.

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 provides no guidance on when to install versus checking runtime status first, no prerequisites, and no alternatives. The only usage signal is the implied action of installing a runtime.

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 two useful traits: only 'tested' tools are returned and schemas are path-free. It says nothing about read-only safety, permission requirements, or that results are scoped to workspace_id — gaps that matter for a tool with zero annotation coverage.

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 tight sentence with no filler, and the filtering constraint ('only tested') is front-loaded. It is slightly too terse for the information load, 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?

An output schema exists so return values needn't be explained, but the description omits the required workspace_id scoping and any usage context. For a discovery tool that gates the whole CAD bundle workflow, this leaves the agent under-equipped to call 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?

There is one required parameter (workspace_id) at 0% schema description coverage, and the description never mentions it or explains what a workspace ID selects. The only semantic added, 'path-free argument schemas', describes the output rather than the input.

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

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

States a verb ('Discover') and resource ('tested CAD tools and their path-free argument schemas'), which goes beyond a bare name restatement. However 'path-free' is unexplained jargon, and the description never says this is a workspace-scoped listing that precedes call_cad_bundle_tool, so the boundary with that sibling is only weakly implied.

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 word 'Discover' hints at pre-call exploration, but there is no explicit when-to-use statement, no mention of call_cad_bundle_tool as the follow-up, and no exclusions. An agent must infer the workflow from the tool name alone.

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

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

With no annotations at all, the description carries the full behavioral burden. It discloses only that nodes are immutable and results are paged; it says nothing about ordering, whether graph snapshots must be freshly built, error behavior for bad cursors, or the significance of the kind filter. Two traits are hinted at, but key operational behavior is missing.

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 single sentence is front-loaded and wastes no words, but it is a fragment that is terse to the point of under-specification rather than genuinely concise. Structure is fine; content density is too low for the tool's complexity.

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?

An output schema exists, so return values need not be described. However, a four-parameter, unannotated listing tool with a required graph path and a kind filter needs more prose than this one phrase to be callable safely and 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?

Schema description coverage is 0%, so the description must compensate, and it largely does not. 'Page through' hints at cursor/limit, but graph_path (the sole required parameter), kind, and the integer cursor format are never explained in prose beyond the bare schema titles.

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 verb 'page through' and resource 'CAD scene nodes' give a clear core action, but 'immutable pre-semantic' is internal jargon an agent may not interpret, and there is no explicit differentiation from the sibling get_cad_scene_node. The purpose is inferable but not crisp.

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 offers no guidance on when to use this listing tool versus get_cad_scene_node or list_scene_visual_regions, nor any prerequisites such as when graph_path must come from a prior export step. It implies listing but not the conditions that select it.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only implies a read operation via 'List' and says nothing about permissions, pagination, ordering, or what happens if the node IDs are 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?

The description is a single front-loaded sentence with no filler. It is compact, though its terseness comes at the cost of clarity for unfamiliar terms.

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?

Although an output schema exists, the description does not compensate for the absence of annotations and the 0% parameter documentation. For a tool requiring three specific path/node identifiers, an agent needs more context 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?

Schema description coverage is 0%, and the description does not explain any of the three required parameters (graph_path, left_feature_node_id, right_feature_node_id). Even the left/right pairing is only vaguely implied by 'endpoint pair IDs', leaving the agent without guidance on what each parameter means.

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?

It uses a specific verb (List) and names the resource (source-derived endpoint pair IDs) plus a condition (selectable by a decision pack). This is clear enough to distinguish from siblings like list_network_repair_candidates or list_label_candidates, though the jargon 'source-derived' and 'decision pack' could be clearer.

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, no prerequisites, and no exclusions. The phrase 'selectable by a decision pack' hints at context but does not tell an agent when this list should be called.

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 'without changing any facts' does usefully disclose that this is a non-mutating read. But it says nothing about pagination semantics, the meaning of cursor/limit beyond the words themselves, or any permission requirements, leaving significant behavioral 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?

A single front-loaded sentence with no filler; the read-only constraint is stated efficiently. It is short to the point of sparseness, 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 five-parameter tool with zero schema documentation and no annotations, one sentence is insufficient. The output schema covers return values, but the description leaves parameter meaning, pagination behavior, and usage context largely unaddressed.

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% across five parameters (kind, limit, cursor, graph_path, allow_standalone), and the description explains none of them. 'Page through' faintly gestures at limit/cursor but gives no format, default, or semantics for the required graph_path or the filtering role of kind/allow_standalone.

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 pairs the verb 'Page through' with the specific resource 'source-bound evidence nodes', making the list semantics clear and implicitly distinguishing it from the singular get_evidence_node sibling. However, it never names or contrasts the sibling explicitly, so differentiation is inferred 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?

There is no guidance on when to use this versus get_evidence_node or the other list_* siblings, nor any preconditions or exclusions. The only hint is 'Page through,' which weakly implies bulk retrieval of multiple nodes.

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, so the description carries the burden. It does assert a key behavioral trait — advisory output and no mutation of source facts — which tells the agent this is a safe read. However it says nothing about how distance is computed, cost/size of the result, or whether any prerequisites (an initialized semantic store) are 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?

One front-loaded sentence with no filler; the read-only guarantee comes last where it is easy to scan. Brevity here flirts with under-specification rather than padding, 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?

An output schema exists, so return values are covered, but the description leaves the required graph_path unexplained and gives no selection guidance among a large set of similarly named candidate-listing siblings. For a tool with zero annotation coverage, that leaves too much to inference.

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 required parameter graph_path has 0% schema description coverage and is not mentioned at all in the description. With coverage this low the description must compensate, and it does not say what a graph path refers to or how to obtain one.

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+resource ('List ... labels') with two distinguishing qualifiers: 'advisory' and 'distance-ranked'. It does separate itself from directionally similar siblings such as list_legend_catalog_candidates by the ranking claim, but it never explains what a 'label candidate' is versus those other candidate lists.

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 call this instead of query_source_entities, list_legend_catalog_candidates, or the other list_*_candidates siblings. The agent must infer the trigger condition entirely from the phrase 'advisory, distance-ranked'.

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. 'List' weakly implies a read, but nothing states whether this is read-only, requires a valid graph path, or has side effects; 'advisory' hints at non-authoritative results but is not explained. With an output schema present, return values need not be described, but safety and prerequisite behavior remain undisclosed.

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

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

It is a single front-loaded sentence with no waste, which is structurally fine. But brevity here comes at the cost of clarity: the one sentence is dense with unexplained domain terms rather than earning its place through useful information.

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

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

Given two undocumented parameters, no annotations, and no usage context, the description is insufficient for an agent to call this correctly beyond guessing. The output schema helps with return interpretation, but input and behavioral context are missing.

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

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

Schema description coverage is 0%, so the description must compensate, and it does not mention either graph_path or route_regex. The phrase 'source-bound facts' faintly gestures at a source graph but gives no format, expected values, or regex semantics. An agent must guess what route_regex filters.

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 (List) and resource (legend/symbol-sample groups), so the general intent is inferable. However, 'advisory' and 'source-bound facts' are undefined jargon that obscure what these candidates actually are and how they differ from sibling tools like list_label_candidates. It is minimally adequate rather than clearly 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?

There is no guidance on when to call this tool, when not to, or which sibling tools it replaces or complements. With many similarly named list_* candidate tools in the sibling set, the absence of routing guidance is a real gap.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not state that the operation is read-only, whether it requires permissions, how results are paginated, or what the candidate records contain, which is a significant gap for a tool with zero annotation coverage.

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

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

The description is a single focused sentence with no wasted words and the key action is front-loaded. Its shortfall is under-specification rather than verbosity.

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

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

An output schema exists, so return values need not be explained. However, the description omits the parameter's path semantics, usage context, and any behavioral traits, leaving the tool inadequately documented for an agent encountering it among many similarly named candidate-listing siblings.

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 required parameter graph_path has 0% schema description coverage, and the description does not mention the parameter, its expected path format, or whether it must reference a specific graph artifact. The parameter name is somewhat self-explanatory, but the description adds no compensating detail.

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

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

The description gives a verb ('List') and a resource ('graph-bound crossing and collinear candidates'), but 'derived repairs' is undefined jargon, so an agent cannot confidently distinguish this from sibling candidate-listing tools such as list_endpoint_join_candidates or list_legend_catalog_candidates.

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

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

There is no guidance on when to use this tool, when not to use it, or which sibling tools are alternatives. The description merely states what is listed, leaving the agent to infer the context in which this tool is appropriate.

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 one meaningful behavioral fact — that the returned set is exhaustive and policy-bounded ('the only ... a model may propose') — but it says nothing about whether the set is static, read-only, or how it should be consumed downstream.

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

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

A single short sentence with no wasted words, and the key constraint is front-loaded. It loses a point only because the brevity shades into vagueness rather than precision.

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-argument, read-only listing tool with an output schema, the description is minimally sufficient — the return shape is covered elsewhere. What is absent is any anchoring of 'repair operations' to the surrounding CAD/review workflow or guidance on acting on the result.

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

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

The tool takes zero parameters, so the baseline is 4; there is nothing for the description to disambiguate. No param-level detail is required or missing.

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 says it enumerates the repair operations a model may propose, which is a specific resource, but the verb 'Describe' is soft and the scope ('repair operations') is never grounded in a system or artifact. It does not distinguish itself from nearby catalogue-style siblings such as list_cad_bundle_tools or list_network_repair_candidates.

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 word 'only' tells an agent this is the authoritative allowlist to consult before proposing a repair, but there is no explicit when-to-call, no exclusion, and no named alternative among the many list_* siblings.

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

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

No annotations are provided, so the description carries the full burden. It implies pagination ('page through') but says nothing about read-only nature, what a page contains, ordering, or behavior at end of results. An output schema exists, which relieves some return-value burden, but the behavioral profile of the call is essentially undisclosed.

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

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

It is a single front-loaded sentence with no filler, which is structurally fine. But the brevity comes at the cost of under-specification rather than efficiency – there is room to add routing and parameter context without bloat.

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 4-parameter tool with zero schema coverage and no annotations, one sentence is not enough. The output schema covers return shape, but an agent still lacks the manifest_path contract, paging semantics, and a reason to prefer this over list_visual_regions.

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% across 4 parameters, so the description must compensate and largely does not. 'Layout-aware' weakly hints at the layout parameter, but manifest_path (the sole required field), limit, and cursor are given no meaning beyond their names and defaults.

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

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

States a verb ('page through') and resource ('visual regions') qualified by 'layout-aware' and 'bound to a CAD Scene Graph', which distinguishes it somewhat from the sibling list_visual_regions. However, it never explicitly distinguishes itself from list_visual_regions or get_scene_visual_region_context, so the agent must infer which of the near-identical listing tools 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 description gives no when-to-use condition, no prerequisites, and no mention of the obvious alternatives (list_visual_regions, get_scene_visual_region_context). The only implied guidance is that it is a paging operation, which the schema already conveys via limit/cursor.

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

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

No annotations are provided, so the description carries the full disclosure burden. 'List' implies a read operation, but nothing states whether it is safe, whether graph_path must be an existing on-disk graph, what errors occur, or what the artifacts look like; the single sentence leaves the behavioral profile essentially unstated.

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

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

One short, front-loaded sentence with no filler. It is efficiently stated, though the terseness contributes to the missing context noted elsewhere.

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?

An output schema exists, so return values needn't be explained, but with zero annotations and a completely undocumented parameter, the description should clarify what the artifacts are and what qualifies a graph. As written, an agent knows only the tool's name-level intent.

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 parameter graph_path, so the description must compensate. 'Bound to the graph' only loosely hints that graph_path identifies the owning graph; there is no detail on format (file path vs. ID), whether it must already exist, or whether other graphs are scanned.

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 ('List') and a specific resource ('multi-scale render and hit-map artifacts bound to the graph'), so an agent can tell it enumerates artifacts rather than returning them. It does not distinguish itself from close siblings like list_scene_visual_regions or resolve_visual_hit, and the domain jargon ('hit-map artifacts') is unexplained.

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 list_scene_visual_regions, get_scene_visual_region_context, or resolve_visual_hit. The agent must infer selection from the name alone, with no exclusions or preconditions 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 does so: it discloses workspace authorization constraints, that output_dir and its sibling .zip must be new and outside the immutable run, that the consumer must download and extract the complete ZIP because the QGZ needs companion GeoPackages/styles, and the precise verification boundaries (hashes, ZIP contents, QGZ references/counts — not real QGIS rendering or surveyed accuracy). It also flags that SVG candidates are not auto-applied, which prevents a false expectation of finished output.

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?

Front-loaded with the purpose, then usage, then constraints and limits; every sentence conveys a distinct constraint. Slightly dense but 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?

An output schema exists so return values need not be explained, and the description covers preconditions, side effects, and verification limits well. The main residual gap is per-parameter meaning for a 0%-coverage schema, which would help an agent populate the two required paths 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?

Schema coverage is 0%, so the description must compensate. It establishes that both parameters are paths and that output_dir is the destination whose sibling .zip must be new and outside the run, but it never names run_dir or states it is the existing completed run directory being packaged — that link is only implied.

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 dual resource (verified QGZ projects plus a portable ZIP) scoped to 'an existing run', and explicitly contrasts with run_conversion and prepare_review_workspace, which do not generate QGZ. An agent can identify this tool without opening the schema.

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

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

Gives an explicit trigger ('when the user requests QGZ or a QGIS package') and names two siblings that will not satisfy that request, routing the agent correctly. Nothing about when to select it is left 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 discloses the output artifacts but does not say whether the operation is read-only, whether it creates or mutates project state, what permissions or project state are required, or what side effects occur.

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

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

The description is a single front-loaded sentence with no filler. It states the action and outputs immediately, and every phrase contributes to the little context it provides.

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

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

The tool has an output schema, so return values do not need full explanation, but the description omits the onboarding workflow context, the relationship to apply_ai_onboarding, and the meaning of project_dir. With no annotations and no parameter descriptions, those omissions leave the agent under-equipped 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 single required parameter, project_dir, has 0% schema description coverage and is not mentioned in the description. The parameter name is somewhat self-explanatory, but the description adds no meaning about whether it expects a project root, an absolute path, or an existing validated project.

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, 'Return', and two concrete outputs: source-bound evidence and a strict proposal schema. It is clearer than a tautology, but it never mentions onboarding or distinguishes this preparation step from siblings like apply_ai_onboarding or auto_onboard_and_convert.

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 call this tool, when not to call it, or which sibling should be used instead. The phrase 'to the host AI' hints at workflow context but does not specify the triggering conditions or prerequisites.

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

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

No annotations are provided, so the description carries the full behavioral burden. It discloses that the copy is hash-bound and restricted to authorized roots, but it does not say whether existing workspaces are overwritten, what permission checks occur, or what failure 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?

The description is a single front-loaded sentence with no filler. It communicates the core action and constraint efficiently.

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?

Although an output schema exists, the lack of parameter documentation, usage guidance, and behavioral detail leaves significant gaps for a tool that creates a workspace. An agent cannot confidently determine what inputs to provide or how the tool behaves on conflicts.

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%, and the description does not explain what 'source' or 'workspace' mean, their expected formats, or whether they are paths, identifiers, or root selections. The two required parameters are effectively undocumented.

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

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

The description states a specific verb ('Create') and resource ('hash-bound DXF editing copy') with a scope constraint ('inside the authorized project roots'). It is clear enough to distinguish from most siblings, but it does not explicitly differentiate this from related workspace tools such as prepare_review_workspace.

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 this tool should be used instead of alternatives, nor are prerequisites or sequencing requirements mentioned. An agent must infer usage from the name and the phrase 'authorized project roots' alone.

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

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

No annotations are provided, so the description carries the full burden. 'Create' implies persistent state or file output, but the description never says what is written, where, whether it overwrites existing artifacts, or whether it requires a prior validated iteration — all critical for a preparation step.

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

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

It is a single front-loaded sentence with no filler, which is structurally sound, but the brevity comes at the cost of under-specification rather than being genuinely concise.

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?

An output schema exists so return values are covered, but with zero annotations, an undocumented required parameter, and no workflow context in a crowded sibling set, the definition leaves the agent without enough information to call this correctly.

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

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

The single parameter session_path has 0% schema description coverage, and the description does not mention it at all. The agent gets no indication of expected format (filesystem path? session identifier?) or what a valid session_path points to.

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 verb 'Create' is clear, but the resource is opaque domain jargon ('constrained evidence/routing pack') that an agent cannot decode without prior knowledge of the workflow. It makes no attempt to distinguish itself from closely related siblings such as inspect_iteration, evaluate_iteration_candidate, or record_iteration_feedback.

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

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

The phrase 'for the next retry' hints at timing, but there is no explicit statement of when to call this versus siblings like start_feedback_iteration or inspect_iteration, and no prerequisites or exclusions are given. Usage must be inferred entirely.

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

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

No annotations exist, so the description carries the full behavioral burden and largely fails. It implies a write side effect ('create the separate edit store') but does not say where files are written, whether existing stores are overwritten, whether it requires an initialized run, or what the returned launch command is for. Only the barest hint of mutability is conveyed.

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

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

A single front-loaded sentence with no filler, which is structurally clean. But the sentence is so terse that it omits key qualifying information rather than packing it efficiently, verging on under-specification.

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 output schema covers the return value, so that need not be described. Still, for a three-parameter mutation-adjacent setup tool with no annotations and zero schema coverage, the description is far too thin to call correctly — it never explains the required run_dir or the effect of workspace_dir.

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

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

Schema coverage is 0%, so the description must compensate, yet it explains none of run_dir, workspace_dir, or port. At best, 'separate edit store' faintly gestures at workspace_dir and 'launch command' at port, but no format, default behavior, or relationship is stated.

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 verb 'Create' and object 'separate edit store' identify the action, and 'return a local review launch command' hints at output. However, 'edit store' and 'review launch command' are internal jargon with no explanation, and the boundary versus siblings like start_review_server or prepare_cad_bundle_workspace is not made explicit. An agent can guess it is a setup step preceding the review server, but only by 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?

No when-to-use, prerequisites, or when-not guidance is given. With siblings such as start_review_server, build_qgis_review, and prepare_cad_bundle_workspace present, the description never clarifies which of these should be called first or instead. Usage must be inferred entirely from the 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?

With no annotations, the description carries the full behavioral burden. It hints that output goes to a separate new directory (implying the source is untouched), but says nothing about whether the directory must be absent/empty, whether existing files are overwritten, side effects on the semantic store, or permissions/rate considerations.

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

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

A single short sentence with no filler, and the key information (what is produced, where it goes) is front-loaded. It is efficiently written; its problem is omission, not verbosity.

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

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

An output schema exists, so return values needn't be explained, but for a mutation-style tool with zero annotation coverage, 0% parameter documentation, and a crowded sibling set of semantic-store tools, this one sentence leaves an agent unable to call it confidently.

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

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

Schema description coverage is 0%, so both required parameters (source_run, output_dir) are undocumented in structured data. The description only loosely gestures at them ('source-bound' for source_run, 'separate new directory' for output_dir) without stating expected formats, identifiers, or constraints.

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

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

States a verb ('materialize') and a resource ('semantic candidates') with a scope modifier ('source-bound') and an output location. However, 'materialize' and 'source-bound' are pipeline jargon, and the description gives no hint of how this differs from close siblings like initialize_semantic_store, inspect_semantic_store, or preview_semantic_patch.

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

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

There is no when-to-use guidance at all — no prerequisite state, no mention of what must precede it (e.g. an inspected run or initialized semantic store), and no alternative named. An agent must infer its place in the workflow purely 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 must carry the behavioral load. 'Validate' and 'preview' correctly signal a non-mutating check and it discloses the comparison basis (frozen facts, base revision), but it says nothing about permissions, whether validation mutates state, or what a failure looks like.

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 core action and comparison basis lead. It is efficient, though near the edge of under-specification for a four-parameter 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?

An output schema exists, so return values need not be explained, but a tool with four required params at 0% coverage and a nested open patch object needs far more than one sentence. The description does not let an agent assemble a valid 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% with four required parameters including a nested free-form 'patch' object. The description only hints at the patch ('ID-only'); source_run, semantic_store, and prepare_manifest — which look like pointers to run artifacts and stores — are left entirely unexplained.

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