LexQ

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the mutation risk is known. The description adds the precondition that the test must be running, but it does not go deeper into side effects or irreversibility beyond what annotations already signal.

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 states the action and target resource immediately, making it easy to parse.

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 two-parameter tool with complete schema descriptions and annotations covering destructiveness, the description provides the key missing context: the test must already be running. No output schema exists, but that is not a major gap for this simple adjustment operation.

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

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

Schema description coverage is 100%, so both groupId and trafficRate are already documented in the input schema. The description's phrase 'traffic rate' aligns with the trafficRate parameter but adds no meaning beyond the schema.

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

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

The description states a specific verb ('Adjust') and resource ('traffic rate of a running A/B test'), making the operation unambiguous. It also differentiates from sibling tools like lexq_ab_test_start and lexq_ab_test_stop, since adjusting is neither starting nor stopping.

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 makes clear that the tool applies to a 'running' A/B test, which is a useful usage condition. It does not explicitly name alternatives or exclusion cases, but the context is clear enough for an agent to select it over start/stop 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?

Annotations already indicate a mutation (readOnlyHint=false) and non-destructive (destructiveHint=false). The description adds a critical behavioral detail about context.trafficKey and its effect on traffic splitting, which goes beyond annotations. It does not cover other side effects like overwriting an existing test, but the added detail is valuable.

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

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

Two concise sentences, front-loaded with the purpose and requirements, followed by a crucial behavioral caveat. Every sentence earns its place with no 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?

For a start operation with 3 required params and no output schema, the description covers the core function and the most important runtime behavior (trafficKey). It does not mention what happens to an existing test or success/failure responses, but given the tool's simplicity, it is largely sufficient.

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

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

Schema description coverage is 100%, so the schema already documents all three parameters. The description restates the purpose of testVersionId and trafficRate but adds no new format, constraints, or relationships beyond what the schema provides.

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

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

The description clearly states the verb 'Start' and the resource 'A/B test on a policy group', and identifies the required inputs. It does not explicitly differentiate from sibling tools like adjust or stop, but the purpose is unambiguous.

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

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

The description implies usage (start a test) but does not explicitly state when to use this versus the sibling adjust/stop tools. It mentions prerequisites (challenger version ID, traffic rate) but no exclusions or alternative routing.

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?

Annotations already declare destructiveHint=true and readOnlyHint=false, so the safety profile is covered. The description adds genuine behavioral context beyond that: it discloses the specific consequence of the destructive action ('All traffic is restored to the control (current) version'), which is exactly the kind of side-effect information an agent needs before invoking. No contradiction with the annotations.

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

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

Two short sentences with zero waste. The primary action is front-loaded in the first sentence, and the second sentence delivers the one behavioral fact that matters. Both sentences earn their place.

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

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

For a low-complexity tool (one fully documented parameter, annotations present, no nested objects), the description covers the action and its outcome. It does not describe the return value or confirmation behavior, but given the destructive hint and clear consequence statement, nothing critical for correct invocation is 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 coverage is 100% and the sole parameter (groupId) is already described as 'Policy group ID'. The description adds nothing about the parameter itself, which matches the baseline of 3 for fully schema-documented parameters. No gaps to compensate for.

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+resource ('Stop a running A/B test') and adds a precise scope qualifier ('running'), which cleanly distinguishes it from siblings lexq_ab_test_start and lexq_ab_test_adjust. The traffic-restoration clause further clarifies the tool's function rather than merely restating the 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?

Usage context is implied: an agent can infer this tool is for ending a running A/B test, and sibling naming (start/adjust/stop) supplies the alternative options. However, the description never explicitly states when to choose this over adjust or start, nor does it give any caveat or prerequisite (e.g., test must be running).

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?

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds modest context—that the template is derived from 'required facts' and is a sample (non-mutating) artifact—but contributes little beyond the annotation. No contradiction between description and annotations.

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

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

Two sentences with zero waste. The action ('Generate a sample CSV or JSON template') is front-loaded, followed by the basis ('based on the required facts of a version') and the usage guidance. Every clause earns its place.

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

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

For a simple, fully-documented 3-parameter tool with a readOnlyHint annotation, the description is largely sufficient—it explains the output type (sample CSV or JSON template) and its role before upload. It does not detail the template's column/key structure, but that is contextual and not required for an agent to invoke the tool 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 100%: format ('Template format', csv/json, default csv), groupId ('Policy group ID'), and versionId ('Version ID') are all documented in the schema. The description adds no parameter-level detail beyond the schema, so it meets the baseline but does not exceed it.

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-resource pair ('Generate a sample CSV or JSON template') and ties it to a concrete basis ('required facts of a version'). It implies differentiation from upload/data tools via the phrase 'before uploading a dataset,' but does not explicitly name the sibling (lexq_dataset_upload), which keeps it just shy 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?

'Use this to understand the expected data format before uploading a dataset' gives clear when-to-use context and positions the tool as a preparatory step in the upload workflow. It does not explicitly name alternatives or state when not to use it, but the placement before upload makes the intended usage unambiguous.

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?

Annotations indicate readOnlyHint=false and destructiveHint=false, so this is a write operation but not destructive. The description adds context by stating content is uploaded to S3 and a path is returned, which goes beyond the annotations. It doesn't cover rate limits or auth, but those are not critical for this simple 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 well-structured with a clear opening statement, a usage note for chaining with lexq_simulation_start, and concrete examples. Each sentence earns its place; there is no fluff. The front-loaded purpose makes it easy to scan.

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 two-parameter tool with no output schema, the description fully equips an agent: it states what the tool does, how to format input, what the response contains (path), and how to integrate that path into a subsequent tool call. Nothing essential is 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?

The input schema provides 100% coverage for both parameters (content and filename). The description adds value by including CSV and JSON examples that clarify the expected format for the content parameter, and notes the default for filename. This goes beyond the schema's minimal descriptions.

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 (Upload) and resource (inline CSV or JSON content as a simulation dataset), making the tool's purpose unambiguous. It also distinguishes itself from lexq_dataset_template by focusing on inline content upload rather than template retrieval.

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 explicitly explains how to use the returned path in lexq_simulation_start, including the exact dataset structure. This gives clear when-to-use context and a direct workflow example, leaving no ambiguity about its intended role.

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

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

The readOnlyHint annotation already covers safety, and the description adds the behavioral nuance of filtering to ACTIVE (published) versions, which is not in the annotation. This provides useful context about what the tool returns without contradicting the annotation.

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 concise sentences with no wasted words. The main action and scope are front-loaded, and the usage guidance follows naturally. It is well-structured and 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?

For a simple one-parameter read-only tool with no output schema, the description covers all necessary aspects: what it does, what it lists, and when to use it. There is no missing information an agent would need 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 100% for groupId, so the schema already fully documents the parameter. The description does not add any extra meaning about the parameter, so a baseline score of 3 is appropriate.

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

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

The description clearly states the tool lists ACTIVE (published) versions for a group, with a specific verb (List) and resource (deployable versions). It differentiates from siblings like lexq_deploy_live and lexq_deploy_detail by focusing on the pre-deployment lookup, making its purpose unambiguous.

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

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

The description explicitly says 'Use this to find which versions are available before calling deploy live,' giving a clear when-to-use context. It does not name alternatives or state when not to use it, but the guidance is sufficient for selecting this tool over others.

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

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

The readOnlyHint annotation already declares this a safe read operation, and the description's 'Get' wording is consistent with it — no contradiction. The description adds value beyond the annotation by hinting at the response content (snapshot hash, integrity check), which tells the agent what kind of information it will receive. It does not, however, disclose much else about behavior such as error cases or whether the integrity check is a computed or stored value.

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

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

A single sentence that front-loads the primary purpose ('Get detailed info about a specific deployment') before stating the distinguishing return items. Every word earns its place, and there is zero redundancy or filler.

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

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

For a low-complexity single-parameter read tool with a readOnlyHint annotation, this is nearly complete. The description partially answers the return-value question by naming snapshot hash and integrity check, which is useful since no output schema exists. It could be more explicit about other fields in the response (e.g., deployment status), but for a simple read operation the coverage is solid.

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

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

Schema coverage is 100%, so the deploymentId parameter is fully documented in the schema (type uuid, format, pattern, description 'Deployment ID'). The description adds nothing about the parameter, but it doesn't need to compensate for any schema gap. Baseline 3 is appropriate when the schema carries the full 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 clear verb+resource ('Get detailed info about a specific deployment') and adds concrete return specifics (snapshot hash, integrity check) that help pin down what this tool does. It differentiates from siblings via the singular 'deployment' focus and the detail-oriented return content, though it never names an alternative directly. Compared to deploy_overview, deploy_history, and deploy_diff, the intent is reasonably identifiable, but the differentiation is implicit rather than explicit.

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

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

There is no guidance on when to use this tool versus its many deploy siblings (deploy_overview, deploy_history, deploy_diff, deploy_live). The description implies a use case by mentioning 'specific deployment' but offers no exclusions, no prerequisites, and no named alternatives. Given the large sibling set, this is a notable 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?

The annotation already declares readOnlyHint=true, and the description adds that the tool shows added, removed, and modified rules. This is useful but modest context; it does not disclose limits, ordering, pagination, or how snapshots are sourced. With annotations lowering the bar, 3 is appropriate.

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

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

The description is two short sentences that lead with the primary action and output, then give the use case. There is no filler or redundancy; every word contributes.

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?

Required parameters are fully documented, the read-only safety is covered by annotations, and the description states the output scope in terms of added/removed/modified rules. Given the tool's moderate complexity, this is nearly complete; only minor expectations about the diff format or prerequisites are not 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 100% and the base/target parameter descriptions already explain their meaning. The tool description adds no additional parameter-level semantics beyond what the schema provides, so the baseline of 3 is justified.

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

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

The description clearly states a specific action — comparing rule snapshots between two versions — and names the output categories (added, removed, modified). This strongly distinguishes the tool from other deployment and comparison siblings, and the verb 'compare' precisely names the behavior.

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 'Useful for reviewing changes before deploying a new version' gives clear usage context and position in the deployment workflow. It does not explicitly exclude alternatives or mention sibling tools, but the context is sufficient for an agent to know when 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?

The readOnlyHint annotation already covers the safety profile, and the description confirms a read operation. However, it does not disclose pagination defaults, maximum result size, ordering, or whether 'across all groups' still respects the optional groupId filter, so behavioral context is only partially fleshed out.

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 or redundancy. It states the action, resource, and scope directly, making it easy for an agent to quickly parse.

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

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

For a simple read-only list with no required parameters and a fully described schema, the description covers the basics. But there is no mention of what the response contains, how pagination behaves, or how this relates to other deploy/history sibling tools, leaving some ambiguity for an agent deciding whether this is the right 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 100%, so the schema already documents all six parameters with their formats and defaults. The description adds no parameter-level detail beyond the broad 'all groups' scope, which is acceptable but does not elevate the score above the baseline.

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

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

The description clearly states the action (list) and resource (deployment history) and adds useful scope ('across all groups'). It is more specific than the title alone, but it does not explicitly distinguish the tool from siblings like lexq_deploy_overview or lexq_deploy_live, so it misses the opportunity to prevent confusion.

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 about when to choose this tool over aliasing alternatives such as lexq_deploy_detail, lexq_deploy_overview, or lexq_history_list. 'Across all groups' implies broad scope, but no exclusions, prerequisites, or comparison with other history/list tools 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?

Annotations already declare destructiveHint=true, so the mutation profile is known. The description adds concrete behavioral details: immediate effect, rejection of future-dated versions (P-037), and that undefined facts do not block deployment (INV-4). This goes beyond 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?

Three sentences, each carrying distinct value: the action, the immediate effect, and two edge-case conditions with sibling routing. No filler, front-loaded with the core purpose.

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

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

For a destructive mutation with no output schema, the description covers all critical behavior: what is deployed, when it takes effect, what is rejected, and what does not block. An agent has everything needed to invoke 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 100% and each parameter has a description. The tool description does not add semantic nuance to the parameters themselves (e.g., what constitutes a valid 'versionId' for deployment). Baseline 3 is appropriate as the schema does the heavy lifting.

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

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

The description opens with a precise verb and resource — 'Deploy an ACTIVE (published) version to live traffic' — and immediately distinguishes it from lexq_deploy_schedule. The tool's role among the many lexq_deploy_* siblings is unambiguous.

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

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

Explicitly states when NOT to use this tool ('Versions whose effective start date has not arrived are rejected') and names the exact alternative (lexq_deploy_schedule). Also directs to lexq_facts_unregistered for reviewing undefined facts, providing clear routing guidance.

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

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

The annotation readOnlyHint=true already signals a safe read operation, and the description aligns by saying 'Show', so no contradiction. The description adds useful context about the specific deployment attributes returned (version, type, deployer), but does not disclose any potential limitations, such as pagination, performance considerations, or whether the status is real-time or cached. With the annotation covering safety, a 3 is fair.

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, terse sentence that front-loads the primary action ('Show current deployment status') and packs the specific fields into a clear list. No filler or 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?

For a parameter-less, read-only overview tool with no output schema, the description covers the essential purpose and the returned fields. It stops short of describing the exact response shape or any caveats (e.g., what happens if no groups are deployed), but these are minor given the tool's simplicity and the readOnlyHint annotation.

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 the schema carries no burden and the description doesn't need to explain parameters. Per the baseline for zero-parameter tools, a score of 4 is appropriate since the description provides no additional param semantics (there are none to provide).

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 ('Show'), a clear resource ('current deployment status of all groups'), and enumerates the exact fields returned (version, last deployment type, deployer). This clearly distinguishes it from other deploy tools like lexq_deploy_detail or lexq_deploy_history, which imply different scopes.

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 tool versus its many deployment siblings. There is no mention of alternatives, prerequisites, or context in which this overview is preferable. The agent is left to infer from the name and description 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?

Goes beyond the annotations by disclosing the state transition, that publishing locks the version from further edits, and the rule-count invariant. It does not describe auth requirements or failure behavior, but the key side effects are clearly stated.

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, all substantive: state transition, locking side effect, and prerequisite/caveat. The most important behavioral fact is front-loaded and no words are 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?

Complete enough for an agent to call correctly: it knows target state, locking consequence, the rule prerequisite, and the pre-check step. It does not explicitly describe the success response, but the absence of an output schema makes that a minor gap for a state-change 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?

Input schema covers 100% of parameters with descriptions, so the baseline is 3. The description does not add parameter-specific meaning beyond the schema, though it does provide surrounding invariants that affect when the call is valid.

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 ('Publish'), a specific resource (a DRAFT version), and the exact state transition (DRAFT → ACTIVE). The locking behavior further distinguishes it from sibling deploy/version tools without needing to infer from 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?

Provides clear prerequisites: at least one rule is required, and undefined facts do not block publishing. It explicitly directs the agent to call lexq_facts_unregistered first to review undefined facts, though it does not name alternative publish/deploy tools or state when they would be preferred.

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?

Annotations already establish the destructive nature (destructiveHint: true, readOnlyHint: false). The description adds a meaningful precondition ('previous version required') but does not elaborate on side effects—such as whether the current version is removed, archived, or if the rollback is reversible. This is acceptable but not thorough for a destructive operation.

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

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

Two short sentences with no filler or redundancy. The first states the operation; the second states a critical precondition. Information is appropriately front-loaded.

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

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

The description covers the core operation and a key precondition, which is adequate for a simple rollback tool. However, for a destructive action it does not mention consequences (e.g., what happens to the current deployment), permissions, or any expected output. Given the sparse sibling context and lack of output schema, this leaves some ambiguity for an agent.

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 parameters (groupId, memo) have descriptions in the schema, and the pattern/format details are already present there. The tool description adds no extra information about the parameters beyond what the schema provides, so it neither improves nor detracts from schema coverage.

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

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

The description uses a specific verb+resource construction: 'Rollback to the previous deployed version.' It clearly identifies the action (rollback) and the target (previous deployment), distinguishing it from related deploy/undeploy/schedule sibling tools. The added condition ('Only available if there is a previous version') further clarifies scope.

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 clear context for when the tool is valid—only when a previous version exists—which serves as an implicit exclusion for cases without one. It does not explicitly name alternative tools or provide when-not-to-use guidance beyond that condition.

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?

Annotations only indicate it's not read-only and not destructive. The description adds rich behavioral context: the snapshot hash is sealed at scheduling and re-verified at execution (fail-closed), and it enumerates actions that cancel the schedule. This goes far beyond the annotations, informing the agent of side effects and safety mechanisms.

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, each carrying essential information: the core purpose, the constraint and cancellation triggers, and the safety mechanism. Front-loaded with the primary action, no redundant phrases or filler.

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

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

For a simple 3-parameter tool with no output schema, the description covers the essential behavioral context: what it does, constraints (one per group), cancellation conditions, and the fail-closed hash verification. An agent has all the information needed to decide whether to call it and what to expect.

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

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

Schema description coverage is 100%, so each parameter already has a description. The description reinforces that versionId must be an ACTIVE version with a future effective start date, but this is already stated in the schema. No additional parameter-level meaning is added beyond what the schema provides, so the baseline 3 applies.

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

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

The description states a specific verb and resource: 'Schedule an ACTIVE version with a future effective start date to auto-deploy at that time.' It clearly distinguishes this from immediate deployment (lexq_deploy_deployable) and other deploy operations, and the title 'Schedule Deployment' matches the action.

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

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

It implicitly conveys when to use this tool by describing the scheduling behavior and constraints: one pending schedule per group, and cancellation conditions (manual deploy/rollback/undeploy, starting A/B test, archiving). It doesn't explicitly name alternatives, but the sibling names make the context clear. It gives enough guidance for an agent to decide if scheduling 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?

The readOnlyHint annotation already declares the operation safe, and the description adds valuable behavioral traits: the full set of statuses returned and the newest-first order. This prevents the agent from assuming only pending schedules are shown, exceeding what the structured annotation alone conveys.

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

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

The entire description is a single, efficient sentence. It front-loads the verb and resource, then appends the scope, status list, and ordering without filler or 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?

For a simple paginated list tool with only two fully documented parameters, the description covers scope, status coverage, and sort order. It does not describe the return item fields, but no output schema is defined and the core behavior an agent needs to invoke correctly is fully stated.

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

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

Schema description coverage is 100% for both 'page' and 'size', so the structured schema carries the full parameter meaning. The description adds no additional parameter-level guidance, and the baseline of 3 is appropriate when the schema handles the 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?

The description uses a specific verb ('List') and resource ('scheduled deployments'), then narrows scope with 'across all groups' and an explicit status enum (PENDING, EXECUTED, CANCELED, FAILED) plus an ordering rule (newest first). This fully distinguishes it from siblings like lexq_deploy_schedule (create) or lexq_deploy_history (deployment history).

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 clearly establishes its purpose as listing all scheduled deployments, with no exclusions for group or status, and states the ordering. It does not reference alternative tools for specific cases (e.g., deploy_history), but the context is clear enough that an agent knows when this list is needed.

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?

Annotations already mark destructiveHint=true, and the description adds valuable nuance by explaining the version 'stays ACTIVE but no longer serves requests.' This clarifies the destructive nature is limited to traffic removal, not deletion, which is beyond the annotation's binary hint.

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 that immediately conveys the core action and the crucial caveat. No filler or redundant wording.

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

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

For a simple tool with two documented required parameters and no output schema, the description covers the key behavioral outcome. It could mention whether the operation is immediate or reversible, but that is a minor gap given annotations already flag destructiveness.

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

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

Schema description coverage is 100%, with both params (memo and groupId) clearly described in the schema. The description adds no additional parameter meaning, so per the baseline for high coverage, a 3 is appropriate.

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

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

The description clearly states the action: 'Remove the live version from traffic' and clarifies the effect by noting the version stays ACTIVE. It distinguishes from deploy_publish and rollback by focusing on traffic removal, though it doesn't explicitly name alternatives.

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

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

No guidance is provided on when to use this tool versus related tools like deploy_publish, deploy_rollback, or deploy_schedule. The description only explains what it does, leaving the agent to infer the appropriate 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?

Discloses meaningful behavior beyond the destructiveHint: the deployed version remains unaffected)Skip and the call fails with a specific error code when no schedule exists. This is more transparent than most definitions for a mutation tool.

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

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

Two short sentences, front-loaded with the action, followed by the key caveat and error condition. No filler or repetition.

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

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

Adequate for a single-parameter tool with no output schema: the action, affected scope, non-affected scope, and failure mode are all covered. Lacks only explicit mention of when to choose this over related deploy-scheduling 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?

There is only one parameter and schema coverage is 100%, so the description adds little beyond the schema. The phrase 'for a group' does confirm the groupId semantics, but no deeper guidance is provided.

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 ('Cancel') and a specific resource ('pending scheduled deployment for a group'), making the action unmistakable. It also disambiguates scope by noting the version itself is not affected.

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 intended use is implied: cancel a group's pending scheduled deployment. The failure condition helps the agent know when not to call it, but it does not explicitly name sibling alternatives like lexq_deploy_schedule or lexq_deploy_schedules.

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

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

The description goes well beyond the annotations, explaining that the operation is additive and idempotent, never overwrites existing schema, skips existing facts, creates DRAFT versions, and requires template to be ACTIVE. This is rich behavioral disclosure that matches the non-destructive hint.

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?

Four compact sentences deliver the full operational picture: what the tool does, the DRAFT result, non-destructive idempotent behavior, the active-template constraint, and the preview prerequisite. There is no filler or repeated schema 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?

For a create-style tool with one required parameter and no output schema, the description covers the action, side effects, safety guarantees, template eligibility, and the correct preceding sibling tool. Nothing essential is 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?

The input schema already documents both parameters (template key and optional name), so the description does not need to repeat them. It adds useful semantic constraints beyond the schema, such as "Only ACTIVE templates can be applied" and the fact that existing facts are skipped.

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 opens with a specific verb and resource: "Apply a domain template to the current tenant," then explains exactly what the tool creates: fact definitions and a DRAFT policy group. It also distinguishes itself from the sibling preview tool by explicitly directing the agent to run lexq_domain_templates_preview first.

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 clear operational guidance by instructing the agent to run lexq_domain_templates_preview before applying. It also limits applicability to ACTIVE templates conditions that help the agent decide when the tool is valid. However, it does not contrast apply with list/preview beyond that one prerequisite.

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?

Annotations already provide readOnlyHint=true)Skip. The description adds concrete behavioral details: it returns all domain templates, each with key, status (ACTIVE or COMING_SOON), and a provisioning summaryikuha; it also clarifies the purpose of discovering which templates are currently applicable. No contradiction; it doesn't mention pagination/limits, but for a zero-param list tool this is not a meaningful 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?

Three sentences, each earning its place: definition, output summary, and usage guidance. Information is front-loaded with the core function and the key restriction for calling it.

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

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

With no parameters and no output schema, the description covers the essential return fields and the reason to call it. It doesn't explain filtering or pagination, but for a zero-parameter list-all endpoint, those are unlikely and not necessary 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?

Input schema has zero parameters)Skip. Baseline 4 applies: there are no params to document)Skip. Description adds value by explaining the entries' content, compensating for the absence of an output schema.

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

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

Clearly states the tool lists all domain templates and defines what a domain template is, with specific output fields. It distinguishes itself from the sibling preview/apply tools by framing list as the discovery step.

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?

Explicitly instructs when to call it: 'Call this before preview or apply to discover which templates can currently be applied.' This tells the agent the temporal relationship with siblings and helps avoid calling preview/apply for unavailable templates.

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

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

The readOnlyHint annotation is reinforced and expanded by the description: it explicitly states 'This is a read-only dry run — nothing is created', and adds the behavioral constraint that only ACTIVE templates can be previewed. This goes beyond the annotation by detailing what the preview returns and the activation requirement.

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 three short sentences, each carrying essential information: the action and its output, the read-only guarantee, and the active-template constraint. It is front-loaded with the purpose and contains no redundant words.

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

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

Given the simplicity (one parameter, no output schema) and the presence of readOnlyHint annotation, the description is fully sufficient. It explains what the tool returns, that it is non-destructive, and the precondition for use. Nothing an agent needs to invoke it correctly is 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?

The input schema already provides 100% coverage for the single 'template' parameter, including an example and a pointer to the list tool. The tool description itself does not add any parameter-specific information, so the baseline of 3 applies; the schema does the heavy lifting.

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

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

The description clearly states the verb 'Preview' and the specific resource 'domain template', and lists exactly what is previewed (fact definitions, sample rules, apply plan). It distinguishes itself from the sibling 'apply' tool by emphasizing this is a dry run, and from 'list' by focusing on previewing a single template's provisioning output.

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 explicitly says 'before applying it', indicating when to use this tool (prior to applying a template). It also notes 'Only ACTIVE templates can be previewed' and directs the user to lexq_domain_templates_list for available keys, providing concrete usage context and a clear alternative for discovering templates.

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?

Even with readOnlyHint=true already set, the description adds valuable behavioral context: 'without side effects,' normalized outputs, mutatedFacts delta keys, and per-rule traces. This goes well beyond the annotation and helps an agent understand exactly what a dry run does and returns.

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 front-loaded with the core purpose and uses a clear bulleted return-value breakdown plus an example input. Every section earns its place; it is detailed without being bloated.

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

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

With no output schema, the description fully compensates by enumerating all return fields and their meanings. It also provides an example and usage guidance, making the tool callable correctly with minimal 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?

Schema description coverage is 100%, so the schema already documents facts, versionId, and includeDebugInfo. The description contributes an example input and explains return behavior, but does not add much parameter-level meaning beyond the schema.

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

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

The description states a specific verb and resource: 'Execute a single dry run against a version.' It clearly explains what the tool does and implicitly distinguishes itself from lexq_dry_run_compare by focusing on a single execution rather than comparison.

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 explicit when-to-use guidance: 'Always dry-run before publishing to validate rule behavior.' It does not name alternative tools or state when not to use it, but the single-run framing provides enough context to separate it from compare and simulation 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?

Annotations declare readOnlyHint=true, so safety is covered. The description adds value by detailing the return structure (resultA/resultB and diff fields), which is beyond annotations. It doesn't contradict annotations; no contradictions found.

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

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

The description is concise, front-loading the purpose in the first sentence and then listing return fields. It is not overly verbose, and every sentence contributes relevant information, making it efficient for an agent to parse.

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 an output schema, the description compensates by clearly outlining the return format and what the diff contains. It covers purpose, usage context, and expected results, leaving no critical gaps for an agent 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 100%, with each parameter individually described (e.g., 'Baseline version ID' and 'Candidate version ID'). The description adds a valuable semantic that 'facts' are the same for both versions, but it doesn't provide additional syntax or format details beyond the schema.

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

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

States a specific verb ('Compare'), resource ('dry run results between two versions'), and scope ('using the same input facts'). Clearly distinguishes from lexq_dry_run (single run) and other diff tools like lexq_deploy_diff, as it is specifically for dry run comparisons.

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 includes 'Useful for validating changes,' which provides context for when to use it. However, it does not explicitly mention alternatives or conditions when not to use it, though the purpose itself is clear enough for an agent to select it over 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?

Beyond the readOnlyHint annotation, the description discloses important runtime behavior: missing required facts throw, the engine never defaults to 0, facts can come from input or prior actions, and only SET_FACT creates a fact from nothing. It also notes the data is static and safe to cache, giving the agent actionable operational knowledge.

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 front-loaded with the core purpose and uses a concrete example to clarify subtle semantics. It is somewhat long, but each sentence contributes real value—especially the factRequired flag clarification and the failure behavior—so the length is justified.

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 no-input, read-only metadata endpoint, the description is largely complete: it explains what is returned, gives an example, defines the key flag, and warns about runtime failure. Since there is no output schema, a full enumeration of the response shape would improve completeness, but the invocation path is fully clear.

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?

This tool takes zero parameters, so there is nothing for the description to clarify about arguments. The baseline for zero-parameter tools is 4, and the description appropriately focuses on the returned concept of fact requirements rather than input handling.

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 opens with a specific verb and resource: 'Retrieve runtime fact requirements per Action type.' It goes on to explain exactly what kind of information is returned, distinguishing this metadata lookup from companion fact-management tools like lexq_facts_list or lexq_facts_create.

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 makes the intended use case clear: an agent needs to know which facts must be present in an execution payload for a given Action type. It does not explicitly name an alternative tool or state when not to use it, so it stops short of a perfect score, but the context is strong enough to guide selection.

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?

Annotations already declare readOnlyHint=false and destructiveHint=false, so the mutation-safe profile is covered. The description adds the key validation rule and that casing is not enforced, which is useful, but omits behavior on duplicate keys, error modes, and any auth/permission requirements.

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

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

Three tight sentences, front-loaded with the core action. Some content (key pattern, type list) duplicates the schema, but nothing is wasted and the size matches the 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?

A 7-parameter tool with a nested valueDomain object and no output schema; the schema carries full field detail, so the description needn't explain returns. It is adequate but silent on PII/required semantics and duplicate-key behavior that a caller creating a fact would care about.

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

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

Schema description coverage is 100%, so the schema already documents key, name, type, isPii, isRequired, description, and the nested valueDomain. The description largely repeats the key pattern and type enum, adding only 'casing is not enforced' as marginal value. Baseline 3 is correct.

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

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

States a specific verb and resource ('Register a new input variable'), and the word 'new' separates it from lexq_facts_update/delete/list. It does not explicitly name a sibling alternative, but the create semantics are unambiguous.

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

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

No when-to-use guidance, no prerequisites, and no contrast with lexq_facts_update or lexq_facts_list. The agent must infer that this is the creation path and when a fact should be registered at all.

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

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

Annotations already signal destructive intent, and the description adds substantial behavioral detail beyond that: system facts are excluded, rule-referenced facts trigger a specific error code FD-006, and the error reports the count of references. This gives the agent actionable knowledge about failure modes and preconditions.

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

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

Three tight sentences each add unique value: the core operation, the excluded cases, and the required remediation step. No filler or repetition exists, and the most important behavioral constraint is front-loaded.

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

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

For a single-parameter destructive operation with a clear schema and strong annotations, the description fully covers what the agent needs: the action, the key failure cases, the error code, and the required precondition. Complexity is low, and no output schema exists to explain, so nothing essential is 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 coverage is 100%, and the single parameter factId is already described as 'Fact definition ID' with a UUID format. The description does not add new parameter-level detail, but none is necessary given the complete schema coverage. This matches the baseline for schema-heavy 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 opens with the specific action and resource: 'Delete a fact definition.' This clearly distinguishes it from sibling tools like lexq_facts_create, lexq_facts_update, and lexq_facts_list. The title and description align unambiguously.

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 explicit when-not conditions: system facts cannot be deleted, and facts referenced by any rule cannot be deleted. It also provides a clear prerequisite ('Remove the references first'), indicating the proper sequence before calling. However, it does not name alternative sibling tools by identifier or explicitly state when this tool is the preferred choice.

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

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

The description clearly discloses that the tool returns file contents as text, which is not obvious from the schema or the readOnly annotation. It also explains a non-obvious behavioral detail: JSON omits fields that the batch-create endpoint does not accept, while CSV includes system facts.

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

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

The description is two sentences, front-loads the primary purpose, and packs meaningful format-specific behavior into a compact space. There is no repetition of the tool name or title and no filler.

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

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

For a tool with two parameters, a readOnly annotation, and no output schema, the description fully covers what the agent needs: what it returns (text), the two supported formats, and the behavioral difference between them. Nothing essential is missing.

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

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

Schema description coverage is 100%, but the description enriches the 'format' parameter by explaining what each format is intended for and how their contents differ. The 'keyword' parameter is not additionally explained, but the schema already covers it adequately.

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

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

The description clearly identifies the operation ('Export') and the resource ('the fact catalog'), and it explains what each format returns. However, it does not explicitly differentiate this from sibling tools like lexq_facts_list or lexq_facts_unregistered, relying on the reader to infer the distinction.

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

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

The description gives concrete usage guidance for choosing between CSV and JSON: CSV for spreadsheet reading, JSON for feeding back into the batch-create endpoint. It does not, however, explain when to choose export over other fact-related tools, so no tool-selection guidance is provided.

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

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

The annotation readOnlyHint: true already covers the safety profile, so the description adds modest value by mentioning it lists all definitions and includes PII status in the output. However, it does not add further behavioral details such as pagination behavior, rate limits, or response shape, which is acceptable given the 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 three short, purposeful sentences: what it does, what it shows, and when to use it. There is no fluff, and the most important information (lists all fact definitions) is front-loaded.

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

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

For a simple, read-only list operation with 3 optional and a well-documented schema, this description is sufficient: it defines the resource, the output highlights, and the primary usage context. It does not explain return envelope, but that aspect is not critical when the schema and annotations carry the rest.

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

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

Schema description coverage is 100%: page, size, and keyword all have descriptive text. The tool description adds no additional meaning about parameter behavior, so the baseline score of 3 is appropriate.

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

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

The description explicitly states the verb 'List' and the resource 'all fact definitions (input variable schema)', and enumerates the fields returned: key, type, required, and PII status. It distinguishes itself from sibling fact operations like create/update/delete/export by focusing on the listing dimension and the schema nature.

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 an explicit use case: 'Always check this before creating rules.' This is a clear directive for when to call the tool. It does not mention when not to call it or alternatives like lexq_facts_unregistered, but the in-context workflow guidance is solid.

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

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

The annotations already set readOnlyHint=true, and the description adds genuinely useful context beyond that: it confirms the tool does not block publish/deploy and clarifies the version-wide scope. It aligns fully with the annotation and reveals no side effects. It does not elaborate on error behavior or empty-version cases, but the read-only safety profile is well covered.

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, each carrying load: the purpose plus read-only caveat, the version-wide scope, and the output-content/next-step guidance. No filler or repetition — well front-loaded.

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

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

For a 2-required-param read-only tool, the description is notably complete: it compensates for the absent output schema by explaining what each entry contains (inferred type, suggested name, reference location), and the annotations cover safety. The only minor gap is that it does not describe empty-result or error behavior, which is a small omission given the simple input surface.

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

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

Schema description coverage is 100% — each of the two parameters already has a concise description ('Policy group ID', 'Version ID'). The description only adds marginal param meaning by tying versionId to 'a version's rules' and noting version-wide coverage, so it stays at the schema baseline of 3.

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

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

The description states a specific verb and resource: 'List facts referenced by a version's rules but not yet defined.' The 'not yet defined' qualifier clearly distinguishes it from sibling lexq_facts_list (defined facts) and lexq_facts_create (registering facts), with no need to open schemas.

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 clear context for when to use the tool (checking a version for unregistered facts before or after edits) and explicitly routes the follow-up action to lexq_facts_create to enable type validation and dry-run analysis. It does not explicitly contrast with lexq_facts_list for already-defined facts, leaving that distinction implicit in 'not yet defined.'

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?

Annotations set destructiveHint=true and readOnlyHint=false, indicating a mutation operation. The description adds valuable context: the key is immutable, type changes fail with FD-007 if rules reference the fact, only sent fields are changed, and system facts have field restrictions. This goes beyond annotations by explaining failure modes and partial update 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 description is three concise sentences with no waste, front-loading the key immutability and type change condition. Each sentence earns its place by conveying critical behavioral rules.

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 mutation nature (destructiveHint=true), the description covers key constraints like immutability, error codes, partial updates, and system fact limitations. However, it doesn't mention permissions or side effects beyond rule references. With no output schema and rich input schema, it is largely complete but could note authorization requirements.

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

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

Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds some meaning by noting that only sent fields are changed and system facts accept limited fields, but it does not provide additional parameter details beyond the schema, which already covers types, value domains, and 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 specific verb (Update) and resource (fact definition), matching the title. Sibling tools like lexq_facts_create, delete, and list are distinct from update, so differentiation isn't strictly necessary here. The purpose is clear, though it doesn't explicitly contrast with similar tools like lexq_facts_action_metadata.

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 some usage context, such as the immutability of the key and type change restrictions, but does not explicitly state when to use this tool versus alternatives like lexq_facts_create or lexq_facts_delete. It implies usage for modifying existing facts but lacks direct guidance on alternatives.

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?

Annotations are minimal (readOnlyHint=false, destructiveHint=false), so the description carries the behavioral burden. It discloses that priority is auto-assigned, explains the cluster constraint (shared activationGroup must share activationMode/activationStrategy/executionLimit), and clarifies that executionLimit counts groups, not rules. This is rich behavioral context beyond what annotations provide.

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 compact, with no wasted words. It front-loads the core action ('Create a new policy group'), then states requirements, optional fields, and a key constraint in a logical order. Every sentence adds value and clarifies usage.

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

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

For a tool with 6 parameters and no output schema, the description is comprehensive. It covers the required field, auto-assignment behavior, optional conflict resolution and activation group settings, and explains the cluster constraints and executionLimit semantics. Combined with the fully detailed schema, an agent has everything needed 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 coverage is 100%, so descriptions already exist for each parameter. The description adds significant meaning about parameter relationships: priority auto-assignment, cluster consistency requirements, and the interpretation of executionLimit as groups rather than rules. This goes beyond the schema's per-field descriptions and helps an agent understand how parameters interact.

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 'Create a new policy group' with a clear verb and resource, and it distinguishes from sibling tools like update, delete, list, and reorder. It also highlights that priority is auto-assigned and points to lexq_groups_reorder for reordering, making the purpose unmistakable.

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

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

The description clearly indicates when to use this tool (to create a new group) and implicitly when not to (reordering is handled by lexq_groups_reorder). It provides context on cluster constraints and optional fields, giving an agent enough to decide when to set activationGroup and related options, though it does not explicitly list exclusion scenarios.

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 destructiveHint=true already in annotations, the description correctly reinforces this with 'irreversible.' It also adds the non-live constraint, which is behavioral context not present in annotations. No contradiction. It could have explained the result of attempting to delete a live group, but the added irreversibility and condition go beyond the annotations.

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

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

Two short sentences with no fluff, front-loaded with the main action. The only minor issue is the inconsistent use of 'archive' vs. 'delete' which slightly mars clarity, but overall it is concise and structured well.

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

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

For a single-parameter delete with destructiveHint=true, the description covers irreversibility and a key precondition. However, it does not explain what happens when a live group is targeted (e.g., error or no-op), and the archive/delete ambiguity leaves the exact behavior unclear. Without an output schema, a brief note on success/failure would strengthen completeness, but it is mostly adequate.

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

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

Schema description coverage is 100% – the groupId is fully described in the schema as 'Policy group ID.' The description adds no extra parameter meaning. Baseline 3 is appropriate since the schema carries the full burden.

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 opens with 'Archive a policy group,' a clear verb+resource, and distinguishes this from the create/get/list/reorder/update siblings. However, 'Archive' and 'deleted' are used interchangeably, which creates slight ambiguity about whether this is a soft or hard delete, though 'irreversible' suggests the latter. The purpose is clear overall.

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?

States a specific precondition: 'Only non-live groups can be deleted.' This tells the agent when the tool can be used and implies a failure case for live groups. It does not explicitly name alternative tools, but the condition is a useful usage guideline. No mention of when not to use or alternatives, but the constraint is sufficient for a simple delete op.

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

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

The annotation readOnlyHint already describes the safety profile. The description adds no additional behavioral over that, e.g., no mention of not-found behavior, error responses, or any other edge cases. It simply repeats the 'get' conceptual, so it adds little beyond annotations.

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 sentence with no excess, the purpose is front-loaded and immediately clear. Perfect for a tool this simple.

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 extremely simple: a single parameter, a read-only annotation, no output schema needed. The description covers all that is required to call it, and nothing additional is needed to be parsed beyond the simplicity.

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

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

Schema description coverage is 100% for the single parameter groupId, which has a clear description and strong validation. The description's 'by ID' adds only a lexical echo, no deeper semantic than the schema already provides.

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

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

The description states a specific verb ('Get'), resource ('single policy group'), and key discriminator ('by ID'). This unambiguously distinguishes it from sibling create/update/delete/list/reorder group 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 clearly implies when to use: when you need one group and know its ID. The sibling list tool covers the alternative, but this description does not explicitly state 'use lexq_groups_list instead for multiple groups', so it loses the point for explicit when-not.

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

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

The annotation readOnlyHint=true already declares it's a read operation, so the description is not burdened with that. The description adds behavioral context beyond annotations: it specifies the scope (tenant-wide) and ordering (priority ASC). However, it does not mention pagination, result size limits, or whether it returns all fields or just summaries. With annotations covering safety, a 3 is appropriate.

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 leads with the verb and resource, then adds the two qualifiers parenthetically. Every word earns its place; it is an exemplary concise structure.

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-parameter list operation with no output schema, the description fully covers what an agent needs to know: it lists all policy groups, applies to the entire tenant, and returns them in ascending priority order. There are no missing details that would prevent 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?

There are zero parameters, so per the rubric the baseline is 4. The description adds no parameter information, but none is needed. The schema is trivial (empty object) and the description already explains the tool's behavior, so nothing is lacking.

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 the verb 'List' and resource 'policy groups' clearly, and adds specific qualifiers 'tenant-wide' and 'priority ASC' that distinguish it from other group operations like create, get, or reorder. The title reinforces this. An agent can immediately understand what this tool does and how it differs from siblings.

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 purpose implies usage (enumerate groups), but the description does not explicitly state when to use this tool versus alternatives such as lexq_groups_get for a single group or lexq_groups_update for modifications. No exclusions or alternative routing are given, so guidance is only implied by the verb 'List' and 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?

Annotations already indicate destructiveHint=true and readOnlyHint=false, so the tool is known to be a write operation. The description adds valuable context beyond annotations: priority is tenant-wide and flat (continuous), array index 0 maps to priority 1, and activationGroup is unaffected. This explains exactly what changes and what does not, which is more transparent than just the annotations.

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

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

The description is two sentences, front-loaded with the action and key constraints. Every sentence adds essential information: the reordering action, the priority model, and the exclusion of activationGroup. There is no filler or redundancy, making it highly concise and well-structured.

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

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

Given the tool's simplicity (one parameter, no output schema, no nested objects), the description covers the core requirements: what the tool does, how priority ordering works, and what is not affected. It does not explicitly state whether the groupIds array must contain all groups or if partial reordering is allowed, but this may be inferred from the continuous priority model. Overall, it is sufficiently complete for an agent to call the tool 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 100% because the sole parameter groupIds has a description: 'Group IDs in desired priority order (index 0 = priority 1)'. The description adds further meaning by clarifying that priority is continuous and tenant-wide, and that activationGroup is not affected. This goes beyond the schema's basic ordering semantics, providing useful context for constructing the array correctly.

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

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

The description clearly states the action: 'Reorder policy groups by priority.' It specifies the resource (policy groups), the operation (reorder), and the key constraint (priority is tenant-wide and flat). It also distinguishes itself from sibling tools like lexq_groups_update by clarifying that only priority changes and activationGroup is unaffected. This is specific and unambiguous.

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

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

The description provides clear context for when to use the tool: when reordering policy groups by priority. It explicitly states what it does not affect (activationGroup), which helps set expectations. However, it does not explicitly name alternative tools or conditions for choosing this over others, though the scope is so narrow that an agent can infer the appropriate usage.

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?

Annotations already declare readOnlyHint=false and destructiveHint=true, so the agent knows this is a mutating operation. The description adds the partial-update behavior ('Only provided fields are updated; omitted fields remain unchanged'), which is valuable and not in the schema. However, it doesn't disclose what happens on failure, whether changes are reversible, or any side effects on dependent entities. No contradiction with annotations.

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, efficient sentence that front-loads the action and immediately states the most important behavioral nuance (partial update). No wasted words. It could arguably add a hint about required groupId, but the schema already marks it required.

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

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

For a mutation tool with destructiveHint=true and no output schema, the description is adequate but thin. It covers the core partial-update semantics, but an agent might benefit from knowing whether the update is atomic, whether it can be undone, or what the response contains. The schema covers parameters well, and the sibling list makes the tool's role clear, so a 3 is fair.

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

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

Schema description coverage is 100%, so the schema already documents all 8 parameters. The description adds the key semantic that omitted fields are left unchanged, which is critical for update semantics. It does not add per-parameter meaning beyond the schema, but the schema descriptions are already rich (e.g., status 'DISABLED = emergency stop', executionLimit 'Counts groups, not rules'). Baseline 3 is appropriate.

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

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

The description states a clear verb and resource: 'Update a policy group.' It distinguishes itself from sibling tools like lexq_groups_create, lexq_groups_delete, and lexq_groups_get by the verb 'update.' However, it doesn't explicitly differentiate from lexq_groups_reorder or lexq_rules_update, though the resource 'policy group' is clear enough.

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

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

The description implies usage: call this when you need to modify an existing policy group. It does not state when to use alternatives like lexq_groups_create or lexq_groups_reorder, nor does it mention any prerequisites (e.g., group must exist). The partial-update semantics ('Only provided fields are updated') is a useful usage hint, but no explicit when/when-not guidance is given.

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

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

The readOnlyHint annotation already signals a safe read operation, so the description doesn't need to repeat that. It does add value by listing the exact fields returned in the detail, which is essential since there is no output schema. This goes beyond the annotation by disclosing the content of the response, though it doesn't mention any other behavioral aspects like pagination or error conditions, which are less critical for a simple fetch.

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

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

The description is a single concise sentence that efficiently conveys the tool's purpose and the key details of its output. There is no fluff or redundancy; every word adds value, and the list of fields is front-loaded, making it easy to scan.

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

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

For a tool with one required parameter and no output schema, the description is fairly complete. It lists all the key returned fields and clearly indicates what the tool does. However, it omits any mention of how to interpret the response (e.g., whether it's a single object or array) or any potential error cases, which would be useful but not essential for a simple read operation. Overall, the description provides enough for an agent 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?

The input schema already fully describes the single parameter (traceId) with the explanation 'Trace ID from execution history'. The description does not add any additional semantic meaning beyond repeating that the parameter is a trace ID. Since schema coverage is 100%, a baseline of 3 is appropriate; the description provides no extra clarity beyond the schema.

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

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

The description clearly states the specific action (Get) and resource (full execution detail) and enumerates the exact fields returned (inputFacts, mutatedFacts, generatedVariables, executionTraces, decisionTraces). This distinguishes it from sibling tools like lexq_history_list (which likely lists executions) and lexq_history_stats (statistics), so an agent can immediately understand what this tool does and where it fits.

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

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

The description implies usage context by mentioning 'traceId' and 'execution detail', but it does not explicitly state when to use this tool over alternatives like lexq_history_list or lexq_replay_decision. There is no explicit 'use this when' or 'instead of' guidance, so the agent must infer the usage scenario from the name and parameter.

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

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

The description adds output-field disclosure (what the list exposes), which goes beyond the readOnlyHint annotation. However, it does not mention pagination behavior, default sorting, or response envelope, which are relevant for a list endpoint. Given annotations already declare readOnlyHint, the description provides some behavioral context but lacks richness.

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

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

The description is two short, informative sentences: the first states the action, the second lists the returned fields. Every word earns its place; it is front-loaded and efficient with no filler or 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?

For a read-only list operation with 8 optional, well-documented parameters and no output schema, the description covers the essential purpose and output content. It does not mention response format or sorting, but these are not critical given the schema defaults and readOnlyHint. Missing details like pagination limits are partially covered by the schema's page/size defaults, so the tool is sufficiently complete for an agent 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 100%, so the baseline is 3. The description does not elaborate on parameter semantics beyond what the schema already provides; it only mentions output fields. This is acceptable since the schema documents each filter, but the description adds no extra parameter-value guidance.

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

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

The description clearly states 'List policy execution history' with a specific verb and resource, and enumerates the fields shown (trace ID, group, version, status, match result, latency). This avoids tautology and provides precise scope, distinguishing it from get/provenance/replay tools without needing to open schemas.

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 is provided on when to use this tool versus alternatives such as lexq_history_get, lexq_history_stats, or lexq_logs_list. There is no mention of filters or scenarios for which listing is preferred, so the agent is left to infer usage from the 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?

Annotations declare readOnlyHint=true, so the agent knows this is a safe read operation. The description adds the specific KPI metrics returned, which is useful, but it does not disclose aggregation behavior (e.g., whether results are grouped by day, whether the date range is inclusive, or what happens with no filters). No contradiction with annotations.

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 exact KPIs. Every word earns its place; no filler or repetition of schema details.

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

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

For a read-only stats tool with fully documented optional parameters, the description is mostly sufficient. However, it does not clarify the time-range semantics (e.g., whether startDate/endDate are required together, whether the range is inclusive) or whether the stats are global or scoped to a group when groupId is omitted. These are minor gaps given the simplicity of the tool.

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

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

Schema description coverage is 100%, so the schema already documents all three parameters. The description adds no parameter-specific meaning beyond what the schema provides, which is acceptable given the high coverage.

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

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

The description states a specific verb ('Get') and resource ('execution KPIs') and enumerates the exact metrics returned (total executions, success/failure counts, success rate, average latency). It is clear and distinct from siblings like lexq_history_list or lexq_history_get, though it does not explicitly name a sibling to differentiate from.

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

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

The description implies this is for retrieving aggregate execution statistics, and the optional date/group filters suggest scoping. However, it does not explicitly state when to prefer this over lexq_history_list or lexq_history_get, nor does it mention any exclusions 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?

Annotations (readOnlyHint=false, destructiveHint=false) indicate a non-read-only operation, and the description adds the meanings of RESOLVE and IGNORE. But there is no disclosure of downstream side effects: whether RESOLVE affects replay/statistics, whether IGNORE is reversible, or whether the action is idempotent. For a state-changing tool with neutral destructiveHint, the description should explain 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?

Single sentence, front-loaded with the verb and the two action options. No filler; every word contributes.

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

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

For a simple two-parameter action the description is mostly sufficient, but it does not state side effects (e.g., whether RESOLVE affects statistics or downstream replay/decision behavior) or whether actions are reversible. Given no output schema and generic annotations, a bit more behavioral context would round it out.

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 already covers both required params and one enum. The description adds semantic meaning to the enum values — 'mark as manually fixed' vs 'skip intentionally' — which helps an agent choose the correct action. It also clarifies the log scope (single failure log) which disambiguates the logId parameter's granularity.

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 clear verb and resource: process a single failure log, with the two specific actions RESOLVE and IGNORE. It distinguishes this from sibling tools in the lexq_logs_* family by emphasizing 'single' log processing. However, it doesn't explicitly contrast with lexq_logs_bulk_action or lexq_logs_get, so it's strong but not fully differentiated.

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

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

The phrase 'Process a single failure log' implies this is for one log at a time, which lightly separates it from the bulk sibling. However, there is no explicit guidance on when to choose RESOLVE vs IGNORE, when to prefer this over lexq_logs_bulk_action, or any 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?

Annotations already establish that this is a write operation (readOnlyHint=false, destructiveHint=false), so the bar is lower. The description adds that an action is applied to the provided logs, which aligns with the annotation profile. However, it discloses nothing beyond that: no side effects, no behavior on invalid or duplicate IDs, and no statement of partial-success semantics.

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

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

Two short sentences that front-load the purpose. The second sentence ('Provide an array of log IDs and the action') is slightly redundant with the required schema but is harmless and keeps the description lean. Nearly 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?

For a bulk mutation tool with no output schema, the description gives no sense of what happens after the call — no confirmation behavior, no partial-failure handling, no indication that all logs must be in a valid state for the action to apply. The minimal instruction is enough to attempt the call, but an agent cannot predict side effects or error modes.

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

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

Schema description coverage is 100%, so the schema already fully documents logIds (UUID format) and action (IGNORE/RESOLVE enum). The description's 'Provide an array of log IDs and the action' essentially restates the schema requirements without adding new semantics, so the baseline of 3 applies.

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

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

The description uses a specific verb ('Process') with a specific resource ('failure logs') and scope ('multiple... at once'), making the core purpose clear. It differentiates from lexq_logs_action mostly through the 'bulk' naming and the 'multiple' qualifier, though it never names the sibling explicitly.

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

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

No when-to-use or when-not-to-use guidance is given. The description does not direct the agent to lexq_logs_action for single-log cases, does not explain how IGNORE versus RESOLVE should be chosen, and states no exclusions or prerequisites. Usage context must be inferred entirely from the tool name and schema.

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

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

The annotation readOnlyHint already covers the read-only safety profile, lowering the bar. The description adds only that this is a get-by-ID operation and does not mention return format, permissions, or error behavior. It does not contradict the annotation.

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 that clearly states the action. No filler words, and it earns its place entirely.

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 one required parameter and no output schema, so the description is sufficient for its simplicity. However, it does not mention what 'detail' includes or what response to expect, which could a small gap.

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

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

Schema description coverage is 100%, and the schema already documents logId as a required UUID. The description's 'by ID' adds little beyond the schema, so the baseline of 3 is appropriate.

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

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

The description uses a specific verb (Get) and naming the resource (failure log detail) with a clear scope (by ID). It distinguishes from sibling tools like lexq_logs_list (list vs get) and lexq_logs_action, but it does not name 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 implied by the phrase 'by ID' and the parameter name logId, but the description does not state when to use this tool versus alternatives, such as lexq_history_list or lexq_logs_list. No exclusion guidance is provided.

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

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

No annotation contradiction. The readOnlyHint=true annotation already signals a safe read; the description adds the source-domain context (webhooks and scheduled deployments) which narrows what the agent should expect. This is additive value beyond annotations. However, it does not disclose pagination behavior or return envelope details, but given the annotation carries the safety profile, this is a marginal gap. A strong 4.

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 single sentence, zero filler, each word earns its place. The source domain ('background tasks') is front-loaded before the parenthetical detail. Efficient and scannable.

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?

Complete enough for a filtered-list entry-point tool. It explains what data domain it covers (failure logs from two specific sources), and the schema covers all filtering parameters. It does not describe the output structure or return fields, but with no output schema present, the agent can infer log entries from context. Minor gaps only.

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

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

Schema description coverage is 100% — all 7 parameters are already described in the schema (status enum, search fields, date format, pagination bounds). The description adds no parameter-level meaning beyond what the schema provides. Baseline 3 is correct when the schema does the heavy lifting.

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

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

States a specific verb ('List'), resource ('system failure logs'), and the exact domain (background tasks: platform event webhooks, scheduled deployments). Clear and unambiguous. It is a listing tool that differentiates from sibling lexq_logs_get (single log) and lexq_logs_action/bulk_action (mutations) by scope — a list retrieval.

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?

States when to use the tool: to see failure logs from background tasks. While it names two concrete source categories, it does not explicitly exclude alternatives (e.g., when to prefer lexq_logs_get, lexq_history_list, or lexq_deploy_history instead). The naming convention and 'logs' prefix imply the domain, but no explicit when-not guidance is given. Slightly above baseline because the source scope is concrete.

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

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

The readOnlyHint annotation already signals a safe read operation, and the description adds meaningful behavioral context beyond that: it explicitly states that revealed values are never stored or returned and that only metadata is exposed. This gives the agent important privacy/security semantics that annotations alone do not convey.

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

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

The description is two sentences: the first front-loads the tool's purpose and output contents, and the second adds the privacy caveat and use cases. Every sentence earns its place with no repetition or 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?

Despite having no output schema, the description tells the agent what information appears in the audit record, confirms no sensitive values are returned, and gives concrete use cases. Combined with fully documented optional parameters and the read-only annotation, the tool definition is complete enough for correct invocation and expectations.

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

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

Schema description coverage is 100%, with all parameters already documented in the schema. The description's phrase 'which fact of which trace, and when' loosely maps to factKey, traceId, and date filters, but it does not add material parameter-specific detail beyond what the schema provides. Baseline 3 is appropriate.

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

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

The description states a specific verb ('List'), a concrete resource ('the PII reveal audit ledger'), and the exact content ('who revealed which fact of which trace, and when'). It also clarifies the non-sensitive nature of the output by saying 'Metadata only; revealed values are never stored or returned.' This clearly distinguishes it from broader list/log tools among the siblings.

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?

Explicit use cases are given: 'Use for monthly access-log inspection and SIEM collection.' This provides clear context for when the tool is appropriate. It does not name alternative sibling tools or state when not to use it, but the use-case framing is strong enough for an agent to select it correctly.

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

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

The description goes well beyond the readOnlyHint annotation, disclosing sampling behavior (deterministic 1% sample for rule detail, TOTAL for every call), display gates (n×(1−q) ≥ 3), judgment gates (n ≥ 100), INSUFFICIENT_COHORT behavior, and the slow-rule flag formula. It also explains that percentiles can be null and why. This is rich behavioral context that an agent needs to interpret results correctly.

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 dense but well-organized, front-loading the core purpose and then explaining gates and defaults. Every sentence adds value, though the density of statistical details (display gate formula, thresholds) could be slightly overwhelming. It's appropriately sized for the complexity of the tool.

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

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

For a read-only analytics tool with no output schema, the description covers the key things an agent needs: what data is returned, how it's sampled, what gates apply, what edge cases look like (INSUFFICIENT_COHORT), and defaults. The absence of an output schema is compensated by the detailed description of the result structure.

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

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

Schema coverage is 100%, so the schema already documents all parameters. The description adds context about defaults (last 24h, live version, cacheState HIT) and the cacheState meaning (HIT = compiled ruleset cache hit, MISS = deep-load + compile), which enriches the enum semantics. However, it doesn't add much beyond what the schema provides for individual parameters, so baseline 3 is appropriate.

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

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

The description clearly states it provides a per-rule latency profile of a policy group over a time window, with specific components: TOTAL distribution split by cache state, per-rule CONDITION/ACTION percentile table, and slow-rule flags. It distinguishes itself from siblings like lexq_profile_rule by focusing on group-level overview with per-rule breakdown.

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 explains the default time window, version, and cache state, and mentions the judgment gate (n ≥ 100) and display gate. It doesn't explicitly state when to use this vs alternatives like lexq_profile_rule, but the name and content make the group-vs-rule distinction clear. It also notes that absolute thresholds are intentionally not supported, which helps set expectations.

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 readOnlyHint:true already covering the read-only nature, the description adds substantial behavioral context: missing windows are genuine gaps (never interpolated), percentile withholding conditions with exact sample thresholds, and the flagged definition including the explicit note that absolute thresholds are unsupported. These details are not present in annotations or schema and are critical for interpreting results correctly.

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

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

The description is a single, dense sentence that front-loads the core purpose and then packs in critical data-handling rules. It is efficient with no filler, though the density of clauses makes it slightly harder to parse at a glance. Every piece of information earns its place, so it is highly concise, but the structural density slightly reduces readability.

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

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

Given there is no output schema, the description thoroughly explains what the tool returns: the distributions, time series, handling of missing windows, percentile reliability conditions, and the flagged definition. An agent has enough information to understand the result and its caveats without needing additional documentation. The 5-parameter tool with 2 required is well-served by this description.

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

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

The schema has 100% parameter description coverage, so all five parameters are already documented. The description adds no parameter-specific semantics beyond what the schema provides (e.g., from/to as window boundaries are already described). It does reference the 60s window granularity, which subtly reinforces the meaning of from/to, but this is not a significant addition.

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 resource ('Single-rule latency detail') and the exact data it returns (merged phase × cacheState distributions plus a per-window time series). This clearly distinguishes it from siblings like lexq_profile_overview, which is the group-level counterpart. The verb is implicit but the resource and scope are unmistakable.

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

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

The description implies usage through its name and specificity (single-rule detail vs. overview), but it does not explicitly state when to choose this over lexq_profile_overview or any other alternative. No exclusions or alternative routing are mentioned, leaving the agent to infer the intended use case from naming conventions.

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?

Goes beyond the readOnlyHint by disclosing that PII values are masked, that masking is represented via maskedKeys, and that unmasked values are only available through an audited console path. This is meaningful behavioral information for an agent handling sensitive data.

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 dense sentence front-loaded with the core action and resource, followed by a compact enumeration of response contents. All clauses add information, though the long comma-separated list slightly reduces skimmability.

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

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

With no output schema, the description compensates well by enumerating the major returned components: decision outcome, per-rule rationale, responsibility chain, masking behavior, and snapshot fingerprint. An agent can predict the response shape well enough to call the tool safely. Minor omissions like error behavior are acceptable for a simple get-by-ID 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?

The single parameter traceId is already documented in the schema, and the description adds little about how to obtain or validate a traceId. Schema coverage is effectively complete, so the baseline of 3 is appropriate.

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

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

The description opens with a specific verb and resource ('Get the lineage of a single decision') and enumerates the key components returned. It is clearly distinct from broader history or listing tools, though it does not explicitly name sibling 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?

The description implies usage: an agent should call this when it needs decision-level provenance rather than general history or logs. However, it does not explicitly state when to prefer this over lexq_history_get or lexq_logs_get, so routing to the right sibling 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?

Annotations already mark the tool as destructive, so the description adds value by narrowing behavior: only pending/running jobs are cancellable, other states are rejected, and viewer-role callers cannot invoke it. It also introduces the 'cooperative' nuance, which conveys a graceful cancellation process rather than a hard kill. This exceeds the structured 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?

Two sentences, front-loaded with the action and target, and immediately followed by the two key constraints (state and role). No filler or redundant restatement of the tool name.

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

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

A single-parameter cancellation tool is well-covered by the state and role constraints in the description. Given the destructiveHint annotation, the risks are clear. It could improve by stating what a successful cancellation means for the job's resulting state, but it is adequate for invocation.

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

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

Schema coverage is 100%, with the only parameter already described as 'Replay job ID'. The description does not add param-level detail such as format or origin. This matches the baseline for fully covered schema.

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

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

Description states a specific verb ('cancel') and resource ('replay job'), and further scopes to 'PENDING or RUNNING' states, setting it apart from replay list/start/status tools. 'Cooperatively' adds a nuance of graceful cancellation. This is clear and specific.

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 explicitly says 'PENDING or RUNNING' can be canceled and 'Other states are rejected,' which tells the agent when it should not be invoked. It also gives a role-based precondition ('VIEWER role cannot cancel'), but it does not explicitly name alternatives or when to prefer a different replay tool.

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

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

Adds valuable behavior beyond the readOnlyHint: synchronous execution, free of charge with TPS throttle, and no webhooks/events or outward side effects from rule actions. This materially informs safe invocation.

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 dense sentences, front-loaded with the core purpose and immediately followed by cost and side-effect caveats. No filler or repetition.

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

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

For a 2-parameter, read-only operation with no output schema, the description covers inputs, return contents, safety profile, cost, and sync-ness. Nothing essential is missing for selection and 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 high (both params documented). The description restates the role of traceId and candidateVersionId in context but does not add meaningful parameter detail beyond the schema.

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

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

The description names a specific verb and resource ('Re-evaluate a past execution against a candidate version') and specifies what is returned (decision diff plus determinism verdict), clearly distinguishing the action from replay list/status operations.

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?

Provides clear context for use (synchronous, read-only evaluation of a past trace against a candidate version) and adds cost/behavior notes, but does not explicitly contrast with related sibling tools like dry-run or deploy-diff.

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

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

The description goes well beyond the readOnlyHint annotation by revealing the literal return behavior: the file contents are returned as text, not as a pointer or attachment. It also explains the non-obvious semantic difference between CSV and JSON, including tenant-specific JSON keys, which is exactly the kind of behavior an agent cannot infer from the schema.

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 front-loads the most important constraint ('COMPLETED') and then spends every sentence on functional distinctions that affect agent decisions: success state, format semantics, and return shape. There is no filler or repetition of the schema's plain parameter descriptions.

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

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

For a tool with no output schema, the description compensates well by stating that the result is returned as text and explaining what the text contains per format. It still leaves some ambiguity about exact JSON/CSV structure and error handling for nonexistent jobs or bad job IDs, but an agent can decide whether 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 coverage is 100%, so the baseline is 3, but the description adds real meaning to the format parameter by explaining exactly what each format contains and by warning that JSON is not a superset of CSV. It does not add much about how to obtain a jobId, but the schema and context make that secondary.

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 resource, a 'COMPLETED window replay job', and a clear action, export, while adding the state qualifier that distinguishes it from still-running jobs. This is far more specific than the title alone and separates it from export tools for simulations or facts.

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 clearly tells the agent to export only completed jobs and explains that running jobs are rejected, with the underlying reason. It also gives concrete guidance on choosing CSV versus JSON based on what each format contains. It stops short of naming an explicit alternative for non-replay exports, so it earns a 4 rather than a 5.

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

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

The readOnlyHint annotation already conveys that this is a safe, non-mutating operation. The description adds useful context by noting reverse-chronological ordering and that items are lightweight, but it does not describe what shape the returned history entries take or touch on pagination behavior.

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

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

Two short, purposeful sentences with no wasted words. The core operation appears first, followed by ordering and the sibling-tool pointer.

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

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

For a simple paginated list with readOnlyHint and no required parameters, the description covers the essentials: what is listed, the ordering, and when to use a sibling instead. It does not spell out the exact output shape, but the tool is simple enough that this is only a minor gap.

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

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

Schema description coverage is 100%, so the page and size parameters are already fully documented. The description does not add per-parameter detail beyond the schema, though the reverse-chronological ordering indirectly clarifies how pages progress.

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 action and resource: listing window replay job history in reverse-chronological order. It also differentiates this tool from lexq_replay_status by noting its lightweight item payload.

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 explicitly directs callers to lexq_replay_status when they need a summary and changed samples, giving the agent a clear heuristic for choosing between these sibling tools. The phrase 'use lexq_replay_status for...' makes the alternative and its purpose concrete.

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?

Annotations already declare readOnlyHint=false and destructiveHint=false, so the agent knows this is a mutating but non-destructive operation. The description adds valuable behavioral context: it is async, billed per replayed record (REPLAY metric), requires VIEWER role (cannot submit), and produces a blast-radius measurement. It does not detail what the job returns or how long it takes, but the explicit 'poll with lexq_replay_status' covers the async 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?

Three sentences with zero waste. The core action and purpose are front-loaded, and the billing, role restriction, and polling instruction are packed into the remaining sentences. Every sentence earns its place.

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

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

For an async job submission with no output schema, the description covers the key operational facts: what it does, how it is billed, who can call it, and how to follow up. It does not mention cancellation (lexq_replay_cancel exists) or the maxRecords cap, but the schema documents maxRecords and the sibling list implies cancellation. The description is complete enough for an agent to invoke it correctly.

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

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

Schema description coverage is 100%, so the schema already documents all four parameters. The description adds the semantic context that candidateVersionId is the version to re-evaluate against and that from/to define the date window, but it does not add meaning beyond what the schema already provides. Baseline 3 is appropriate.

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

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

The description states a specific verb ('Submit an async job'), a specific resource ('replays a date window of past executions against a candidate version'), and a distinctive outcome ('measures the blast radius (how many decisions change)'). It clearly distinguishes this from siblings like lexq_replay_status, lexq_replay_cancel, and lexq_simulation_start by naming the async submission and the blast-radius measurement.

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 clear context: it is for replaying a date window against a candidate version, and it explicitly says to poll with lexq_replay_status. It also notes billing and role restrictions. It does not explicitly say when NOT to use it versus lexq_simulation_start or lexq_dry_run, but the async/billing/date-window framing provides enough context for an agent to 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?

With readOnlyHint=true already in annotations, the description adds substantial runtime semantics: RUNNING reports progress 0–100, COMPLETED fills summary and changedSamples, FAILED carries errorMessage, and capped=true explains partial replay. These details give an agent a complete contract for interpreting the returned state without needing an output schema.

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 deliver the core action, the status mapping, and the capped special case. Every sentence carries functional information; the task is clear in the first sentence and the remaining clauses are dense but essential.

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?

Since there is no output schema, the description must and does explain what state values mean and what fields appear in the COMPLETED and FAILED cases. The capped flag is also clarified. With a single required parameter and all runtime states disclosed, nothing an agent needs to call and interpret this tool correctly is omitted.

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 only parameter jobId already has a 100% descriptive schema reference ('Replay job ID from lexq_replay_start'), so the description adds little beyond reiterating that the tool polls a window replay job. With high schema coverage, baseline 3 applies and no compensation is required.

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 opens with a specific verb and resource ('Poll a window replay job') and names the outcome states. This clearly distinguishes the tool from action-based replay siblings like lexq_replay_start, lexq_replay_cancel, and lexq_replay_export, as well as from the parallel lexq_simulation_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?

The phrase 'Poll a window replay job' establishes the intended context: the agent is checking the progress or completion of an earlier replay job. It does not explicitly point to lexq_replay_start as the source of jobId or warn against using it for other purposes, but the role of a status poller is unambiguous and the naming matches the sibling set.

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

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

The annotation readOnlyHint=true already signals a safe read operation. The description adds that it returns required keys, types, and an example request body, which is useful but not extensive. No contradictions with annotations, but no additional depth on permissions or response 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?

Two concise sentences, front-loaded with the core purpose and immediately clarifying return value. No fluff or redundant phrasing.

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

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

For a simple read-only tool with two well-documented parameters, the description covers purpose and output. It lacks usage context (when to call it), but that is a minor gap given the straightforward nature and available annotations.

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

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

Schema coverage is 100%, with both groupId and versionId having descriptive names. The description does not add extra meaning beyond the schema, so baseline 3 is appropriate.

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

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

The description clearly states the tool analyzes which input facts a version requires, with a specific verb and resource. It also mentions return content (keys, types, example body). It does not explicitly differentiate from siblings, but the function is distinct enough among the many lexq_* 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?

No guidance on when to use this tool versus alternatives. There is no mention of exclusions, prerequisites, or sibling tools. The description only states what it does, leaving the agent to infer applicability.

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?

Annotations only declare readOnlyHint=false and destructiveHint=false, leaving the description to carry the behavioral burden — and it does so richly: priority auto-assignment (appended last), server rejection of out-of-type operators, MUTATE_FACT throwing on missing facts (no 0 default), BLOCK not halting execution with enforcement left to the caller, DIV+PERCENTAGE being invalid, and rounding defaults. The description far exceeds what annotations provide and does not contradict them (readOnlyHint=false aligns with 'create').

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 long but each section earns its place: it front-loads the core purpose and priority behavior, then layers workflow prerequisites, condition format, operator constraints, and action schemas in a logical reading order. The operator×method matrix and the HAS_* example are high-density reference material rather than padding. Not a word is wasted — this is appropriately sized for the complexity of the rule structure it documents.

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

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

Given the tool's significant complexity (nested condition trees, typed operators, multiple action schemas, no output schema) the description is exceptionally complete. It covers workflow prerequisites (fact checks), edge cases (DIV+PERCENTAGE invalid, negative percentages and >100 valid, refVar constraints, DIV+AMOUNT operand !== 0), and the operator×method matrix exhaustively. An agent receives everything needed to construct a valid rule payload and understand failure modes, with no gap requiring 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?

Schema coverage is 100%, so baseline is 3, but the description massively exceeds the schema's value. The lone 'rule' parameter (a JSON string) receives a full specification: condition tree format (SINGLE/GROUP), value types (STRING/NUMBER/BOOLEAN/LIST_*), per-fact-type operator constraints with explicit lists, HAS_* semantics with a worked example, the operator×method matrix for MUTATE_FACT, refVar usage rules, SET_FACT creation semantics, BLOCK behavior, and RoundingOption details. This is a textbook case of description compensating for and enriching an opaque JSON-string 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 opens with a specific verb+resource: 'Create a rule in a DRAFT version' and lists required components (name, condition tree, actions array). It distinguishes itself from siblings by naming lexq_rules_reorder as the alternative for priority changes, and the surrounding siblings (update, delete, toggle, get, list) are implicitly differentiable from 'create in draft.' An agent can identify this tool's role 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?

The description provides explicit workflow guidance with named alternatives: check lexq_facts_list before creating rules with new fact keys, confirm type/isRequired/description before calling lexq_facts_create, and use lexq_facts_unregistered after saving to decide what to register. It also routes priority changes to lexq_rules_reorder. This is explicit when-to-use/when-not guidance with concrete alternative tools named.

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?

Annotations already declare destructiveHint: true, so the description only needs to add context beyond that. It adds the draft-version constraint, which is useful. However, it does not disclose that deleting the last rule in a version requires confirmation, nor does it explain the role of the 'force' parameter or any side effects. The description adds some value but misses important behavioral nuances.

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

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

The description is a single, concise sentence that is entirely front-loaded with the action and the draft-version constraint. There is no fluff, and every word earns its place. It is effectively sized for a simple delete operation.

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 description covers the core requirement (deleting from a draft version) but omits the special behavior around the 'force' parameter—specifically, that deleting the last rule requires confirmation unless force is set to true. With no output schema and a special-case parameter, this missing context could lead to incorrect calls. The annotations cover the destructive nature, so the description is adequate but not complete.

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

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

The schema description coverage is 100%, with all four parameters documented. The tool description provides no additional parameter semantics beyond what the schema already states. Per the rubric, a baseline of 3 is appropriate when the schema covers all parameters and the description adds no extra 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?

The description uses a specific verb ('delete') and resource ('rule') and specifies the scope ('from a DRAFT version'), which clearly distinguishes it from other rule operations like create, update, toggle, and reorder. The draft-version constraint is a critical differentiator and is front and center.

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 clear context by restricting the operation to DRAFT versions, implicitly telling the agent when to use this tool. However, it does not explicitly mention alternatives (e.g., using lexq_rules_toggle to disable a rule instead of deleting it) or state that it should not be used on published versions. It gives clear usage context but no explicit 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?

readOnlyHint=true already discloses the non-mutating nature. The description adds what will be returned (condition tree and action definitions), which is mildly useful context but adds little behavioural disclosure beyond annotations. It does not mention auth, rate limits, or error behavior, but with the annotation present, this is acceptable and not a contradiction.

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 directly states what the tool retrieves. There is zero redundant phrasing, and the focus on the distinctive return content earns its place.

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

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

For a simple read tool with three fully documented parameters and no output schema, the description supplies what the return payload contains ('condition tree and action definitions'), which is information an agent needs to handle the result. It does not mention expected failure modes or version-interaction nuances, but given the low complexity and annotations, this is reasonably 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?

All three parameters have 100% schema description coverage with descriptive names ('ruleId', 'groupId', 'versionId') and descriptions like 'Rule ID'. The description adds no additional parameter semantics, e.g., relationship between group/version/rule or format requirements, but the baseline of 3 is appropriate when the schema covers all parameters.

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

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

The description uses a specific verb ('Get'), a precise resource ('full rule detail'), and names the concrete content ('condition tree and action definitions') that distinguishes it from sibling tools like lexq_rules_list (which lists only summaries) and lexq_rules_update (which mutates). An agent can infer this is the fetch-a-single-rule's-complete-definition operation without opening schemas.

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

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

The description implies the intended use case via 'full rule detail', which suggests it is for retrieving complete rule structure rather than a summarised list entry. However, it does not explicitly state when to prefer this over lexq_rules_list or lexq_profile_rule, nor does it give any exclusions or prerequisites beyond what the schema already states.

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?

Annotations declare readOnlyHint=true, so the agent knows this is a safe read operation. The description adds useful behavioral context: it returns a summary with conditionSummary and actionSummary, and orders by priority ASC. It does not disclose pagination, limits, or whether the summary includes rule IDs/names, but for a read-only list tool with annotations covering safety, this is adequate.

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 that states the action, resource, ordering, and return summary in under 20 words. Every word earns its place; no filler or repetition of schema details.

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

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

For a simple read-only list tool with two fully documented parameters and no output schema, the description is nearly complete. It tells the agent what it returns (summary with conditionSummary and actionSummary) and the ordering. The only minor gap is not mentioning whether the summary includes rule identifiers or how many rules are returned, but that is not essential for invoking the tool 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 100%: both groupId and versionId have descriptions ('Policy group ID', 'Version ID'). The description adds that the tool lists rules in a version, which clarifies the role of versionId, but it doesn't add meaning beyond the schema for the parameters themselves. Baseline 3 is appropriate.

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

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

The description states a specific verb ('List') and resource ('all rules in a version'), and adds ordering ('priority ASC') and return summary fields. It is clear and distinct from siblings like lexq_rules_get (which likely fetches a single rule) and lexq_rules_create/update/delete. However, it doesn't explicitly name a sibling alternative, so it doesn't fully differentiate itself from other list 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 implies usage: call this when you need all rules in a version, with required groupId and versionId. It does not state when to prefer this over lexq_rules_get, lexq_profile_rule, or lexq_rules_reorder, nor does it mention any exclusions or prerequisites. The context is clear but not explicit about alternatives.

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?

Annotations already declare readOnlyHint=false and destructiveHint=true, so the agent knows this is a mutating operation. The description adds valuable behavioral context: priorities are assigned 1...N, 1-based and continuous, and array index 0 maps to priority 1 (highest precedence). This clarifies the exact effect of the reorder operation beyond what the annotations provide.

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

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

Two sentences with no wasted words. The core action is front-loaded, and the priority assignment semantics are stated compactly. Every sentence earns its place.

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

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

For a mutation tool with no output schema, the description covers the essential behavior: what the tool does, how priorities are assigned, and the mapping from array index to priority. The annotations cover the destructive nature. The only minor gap is that it doesn't state whether the reorder is atomic or what happens to rules not listed in ruleIds, but the continuous 1...N assignment implies all rules are reordered. This is adequate for an agent to invoke the tool 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 100%, so the schema already documents all three parameters (groupId, ruleIds, versionId). The description adds meaning to ruleIds by explaining the ordering semantics (index 0 = priority 1), which is useful. However, it doesn't add detail about groupId or versionId beyond their schema descriptions. Baseline 3 is appropriate since the schema carries the parameter documentation burden.

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

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

The description clearly states the action ('Reorder rules') and the mechanism ('specifying rule IDs in desired order'), which distinguishes it from rule creation, deletion, toggling, and updating. It doesn't explicitly name a sibling alternative, but the verb 'reorder' plus the priority semantics make the purpose unambiguous.

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

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

The description implies when to use this tool: when the user wants to change rule priority order. It does not explicitly state when not to use it or name alternatives like lexq_rules_update for other rule changes. The context is clear enough for an agent to infer the use case, but explicit exclusions are missing.

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?

Annotations already declare destructiveHint=true and readOnlyHint=false, so the agent knows this mutates state. The description adds the nuance that it doesn't delete the rule, which is useful. However, it doesn't disclose whether the change is reversible, whether it affects deployed versions, or any side effects. With annotations covering the mutation profile, a 3 is appropriate.

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

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

A single sentence with zero waste. The core action (enable/disable) and the key non-destructive distinction are both front-loaded. 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?

For a simple toggle operation with full schema coverage and annotations declaring destructive intent, the description is mostly sufficient. However, it doesn't explain why versionId is required or whether toggling affects a specific version vs. the live rule, which could matter for correct invocation. The output schema is absent, but for a toggle that's acceptable.

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

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

Schema description coverage is 100%, so all four parameters (ruleId, groupId, isEnabled, versionId) are documented in the schema. The description adds no parameter-level detail beyond what the schema provides. Baseline 3 is correct when the schema does the heavy lifting.

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

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

The description 'Enable or disable a rule without deleting it' clearly states the verb (enable/disable), the resource (rule), and the key distinction from deletion. It doesn't explicitly name a sibling alternative, but the contrast with deletion helps differentiate it from lexq_rules_delete and lexq_rules_update.

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

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

The description implies when to use this tool: when you want to change a rule's active state without removing it. However, it doesn't explicitly state when not to use it or name alternatives like lexq_rules_update for other modifications. The context is clear but exclusions are not 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?

The description clearly identifies a partial-update behavior (only provided fields are changed) and scopes the operation to draft versions. The annotations already mark destructiveHint=false and readOnlyHint=false, so the description adds relevant behavioral nuance beyond what annotations provide.

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

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

Two short sentences, front-loaded with the core purpose and the key behavioral caveat. No filler or redundant restatement of the title.

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

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