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

Annotations already declare readOnlyHint=true and destructiveHint=false, so 'read-only dry run; nothing is created' is largely reinforcement. However the description adds behavior the annotations cannot express: the P-061 failure mode on apply, the factConflicts gating condition (type / allowed-value / range mismatches), and that plan is null for a non-applicable template. That failure and precondition disclosure is substantive.

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 core purpose, then the return contents, then the conflict precondition and error behavior in a logical order. Every sentence carries information, though the factConflicts sentence is dense and slightly run-on with its stacked 'or with different ... or a different' clauses.

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

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

There is no output schema, so the description carries the return-value burden — and it does, naming fact definitions with value domains, sample rules with descriptions, the apply plan, factConflicts, and the null-plan case. Combined with the P-061 gating rule, an agent has everything needed to call this correctly and interpret 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?

Only one parameter and schema coverage is 100%, with the schema itself documenting that it is a domain template key and pointing at lexq_domain_templates_list for valid values. The description adds no further semantics about the template parameter, so baseline 3 applies. The allowed-values/range detail it does provide concerns output shape, not input meaning.

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

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

States a specific verb and resource ('Preview exactly what a domain template will provision') and defines the scope as a pre-apply dry run, which cleanly separates it from the mutating sibling lexq_domain_templates_apply. The second sentence enumerates what the preview contains, so an agent knows what it gets back without opening anything else.

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 clearly framed as a step taken 'before applying it' and the description states the exact precondition for the mutating path ('While it is not empty, apply fails with P-061 ... delete those facts or change them to match the template, then apply'). It does not explicitly name lexq_domain_templates_apply or lexq_domain_templates_list as the paired tools, relying on the schema description for key discovery, so it stops short of full explicit routing.

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