LexQ

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'adjust traffic rate' without describing side effects, safety considerations, or whether adjustments are reversible. For a mutation tool, this is insufficient.

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

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

The description is a single sentence with no wasted words. It is concise and front-loaded with the key action.

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

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

Given the absence of an output schema and sibling tools, the description lacks important context: it does not confirm that the test must be running (only implied), nor does it specify the outcome of the adjustment (e.g., continues running, requires restart). The completeness is low for a mutation 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 coverage is 100%, so baseline is 3. The description adds no additional meaning beyond the schema; it only mentions 'traffic rate' which is already described in the schema. No new context is provided for groupId.

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 (adjust traffic rate) and the target resource (running A/B test). It distinguishes itself from sibling tools like lexq_ab_test_start and lexq_ab_test_stop by focusing on modification of an active test.

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 for running tests through the phrase 'of a running A/B test', but does not provide explicit guidance on when to use this tool over siblings, nor does it exclude non-running tests or mention prerequisites.

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

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

No annotations provided. Description mentions it 'starts' a test but does not disclose side effects, prerequisites, or implications (e.g., impact on existing tests, rate limit enforcement).

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 purpose first, no unnecessary words. 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?

Adequate for a simple start action: states purpose and required params. Lacks details on outcome, return value, or validation, which would help given no output schema.

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 covers all 3 parameters with descriptions (100% coverage). Description merely restates requirement for challenger version ID and traffic rate, adding no new semantics beyond 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 clearly states 'Start an A/B test on a policy group' with verb and resource. Siblings include adjust and stop, so this tool is distinct in starting a test.

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?

Implied usage from naming and siblings but no explicit when/when-not or alternatives. The description only states requirements, not context for choosing this 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?

Discloses that all traffic is restored to the control version, but does not mention permissions, irreversibility, or side effects. With no annotations, more detail would be beneficial.

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, both essential and front-loaded with the primary purpose. No wasted 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 of the tool (stop action, one parameter), the description adequately explains the outcome. No output schema exists, but the effect is 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?

Schema coverage is 100% for the single parameter 'groupId', and the description adds no further semantic information beyond the schema's 'Policy group ID'. 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?

Description clearly states the verb 'stop' and the resource 'A/B test', and distinguishes from siblings like 'start' and 'adjust' by specifying the action of stopping and the effect on traffic.

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?

Implies usage for running tests but lacks explicit when-not-to-use or alternative tools. While the sibling list provides context, the description itself offers no exclusions or guidance on 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It adds valuable context that the template derives from 'required facts of a version,' implying introspection of version configuration. However, it lacks disclosure on whether this is a read-only operation, what the return payload structure looks like (file vs. string), or any rate limiting concerns.

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

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

Two sentences, zero waste. The first sentence front-loads the core functionality (generate template), while the second provides workflow context (when to use). Every word earns its place without redundancy.

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

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

Given the moderate complexity (3 parameters, simple types, no output schema), the description adequately covers the tool's purpose and workflow role. It implies the output format matches the input format parameter. Could improve by explicitly stating the return type (e.g., 'returns template content') since no output schema exists to document this.

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 100% description coverage, establishing a baseline of 3. The description adds semantic value by mapping 'CSV or JSON' to the format parameter and connecting 'version' to versionId/groupId. It does not add syntax details, validation rules, or examples beyond what the schema already provides.

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

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

The description clearly states the action ('Generate'), resource ('sample CSV or JSON template'), and scope ('based on the required facts of a version'). It effectively distinguishes this from sibling tool lexq_dataset_upload by positioning this as the preparatory template generation step versus actual data ingestion.

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

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

The second sentence provides clear temporal context: 'Use this to understand the expected data format before uploading a dataset.' This establishes the workflow sequence (template first, upload second) relative to lexq_dataset_upload. Lacks explicit 'when not to use' exclusions, but the context is sufficient.

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

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

With no annotations, the description carries the full burden. It discloses that content is uploaded to S3 and a path is returned, which is helpful. However, it lacks details on size limits, format validation, error conditions, or auth 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?

The description is concise with a front-loaded purpose statement followed by examples. The examples take space but are valuable. Structure is clear, no wasted sentences.

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

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

The tool is simple with 2 params and no output schema. The description covers the main flow but leaves gaps: it doesn't specify the return format (e.g., the path field name) or mention any validation of input. Adequate but not complete.

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

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

Schema coverage is 100% (baseline 3). The description adds value by providing clear examples of valid CSV and JSON content for the 'content' parameter, and clarifies the filename parameter expects .csv or .json extension.

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 uploads inline CSV/JSON content as a simulation dataset to S3 and returns a path. It provides specific examples and distinguishes itself from siblings like lexq_dataset_template by focusing on inline content upload.

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 tells the user to use the returned path in simulation start with dataset type UPLOADED. It provides clear context but does not mention when not to use this tool or 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?

No annotations are provided, so the description carries full burden. It clarifies that only 'ACTIVE (published)' versions are listed, which is useful behavioral context. However, it doesn't disclose other traits like pagination, rate limits, authentication needs, or error conditions, leaving gaps for a read operation.

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

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

Two sentences with zero waste: the first states the purpose and scope, the second provides usage guidance. It's front-loaded with key information and appropriately sized for the tool's complexity.

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

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

Given the tool's low complexity (1 parameter, no output schema, no annotations), the description is mostly complete. It covers purpose, usage, and scope well, but lacks details on output format or behavioral traits like pagination, which could be helpful for a list operation.

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

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

Schema description coverage is 100%, with the single parameter 'groupId' documented as a UUID for 'Policy group ID'. The description doesn't add meaning beyond this, such as explaining group types or constraints, so it meets the baseline for high 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 clearly states the verb ('List') and resource ('ACTIVE (published) versions that can be deployed for a group'), specifying the scope (active/published) and target (group). It distinguishes from siblings like lexq_deploy_live (which deploys) and lexq_deploy_history (which lists historical deployments).

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 to use this tool ('to find which versions are available before calling deploy live') and names the alternative tool ('deploy live'), providing clear context for usage versus deployment actions.

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

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

With no annotations provided, the description must carry full behavioral disclosure. It partially succeeds by mentioning specific return concepts ('snapshot hash and integrity check'), but fails to explicitly confirm read-only safety, error handling behavior, or authorization 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?

Extremely efficient single sentence of 12 words. Front-loaded with the verb 'Get' and immediately specifies what distinguishes this tool (hash and integrity details). 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 simple single-parameter lookup tool, the description adequately compensates for the missing output schema by highlighting key return fields (snapshot hash, integrity check). Reasonably complete though error case documentation would improve it further.

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 'deploymentId' already documented as 'Deployment ID'. The description mentions 'specific deployment' which aligns with the parameter but adds no additional semantic value regarding format, constraints, or usage patterns 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 specific action ('Get detailed info') and resource ('specific deployment'). The mention of 'snapshot hash and integrity check' helps distinguish this from sibling tools like lexq_deploy_overview or lexq_deploy_history, though it doesn't explicitly contrast with them.

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

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

Provides no guidance on when to use this versus alternatives like lexq_deploy_overview or lexq_deploy_history. No prerequisites or conditions are mentioned.

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

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

With no annotations provided, the description carries the full burden. It indicates this is a read-only comparison tool (implied by 'compare' and 'shows'), but doesn't disclose behavioral details like whether it requires specific permissions, how it handles large diffs, or what the output format looks like. It adds some context about the comparison scope but lacks operational specifics.

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 perfectly front-loaded with the core purpose in the first sentence, followed by a concise usage guideline. Every sentence earns its place with no wasted words, making it highly efficient for an AI 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?

For a 2-parameter comparison tool with no annotations and no output schema, the description provides adequate context about what the tool does and when to use it. However, it lacks details about the comparison output format (structured vs human-readable) and any limitations (e.g., maximum version span), which would be helpful given the absence of an output schema.

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

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

Schema description coverage is 100%, so the schema already documents both parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema (e.g., it doesn't explain the significance of 'base' vs 'target' versions beyond the schema's 'typically the current live' note). Baseline 3 is appropriate 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 clearly states the specific action ('Compare rule snapshots'), resource ('between two versions'), and output ('Shows added, removed, and modified rules'). It distinguishes itself from deployment-related siblings like lexq_deploy_deployable or lexq_deploy_publish by focusing on comparison rather than execution.

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 it ('Useful for reviewing changes before deploying a new version'), which helps differentiate it from other deployment tools. However, it doesn't explicitly mention when not to use it or name specific alternatives among siblings like lexq_dry_run_compare.

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

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

With no annotations, the description bears full burden. It says 'across all groups,' which contradicts the presence of a groupId filter parameter, suggesting it may list history for all groups without filtering. This inconsistency reduces transparency.

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 superfluous words. However, brevity sacrifices important context about scope and behavior.

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 list tool with 6 parameters and no output schema, the description lacks details on return format, pagination behavior, sorting, and the meaning of 'history.' It is minimally adequate but not complete.

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

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

Schema coverage is 100%, so the description does not need to add parameter details, but the phrase 'across all groups' conflicts with the groupId parameter. This adds confusion rather than clarification, keeping the score at 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 states 'List deployment history across all groups,' which clearly identifies the resource (deployment history) and scope (all groups). It is distinct from most siblings, but does not differentiate from similar history tools like lexq_history_list.

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

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

No guidance is provided on when to use this tool versus alternatives. There is no mention of context, exclusions, or when not to use it, leaving the agent to infer based solely on the name.

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

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

No annotations provided, so description carries full burden. It discloses immediate effect and behavior regarding undefined facts, but lacks details on permissions, destructiveness, or response format.

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 efficient sentences, front-loaded with core purpose, no redundant information.

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

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

Given no output schema, the description is fairly complete for the tool's action, including timing and a related tool reference. Minor gap: no description of return value.

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 covers all parameters with descriptions. The description adds context about active version requirement but does not provide additional semantic 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 clearly states the action: deploy an active version to live traffic. It uses specific verb and resource, and distinguishes from siblings like publish, rollback, undeploy.

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 mentions when to use (for live deployment of active versions), and when not: undefined facts do not block deployment, recommending a sibling tool for review.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. 'Show' and 'current deployment status' imply a read-only operation, but the description omits details about caching, permission requirements, or whether this retrieves real-time data vs cached state.

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

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

Single sentence with zero waste. The em-dash construction efficiently separates the action ('Show current deployment status of all groups') from the specific return field details, placing the most critical information first.

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 listing the three key data fields returned (version, deployment type, deployer). However, it does not specify the response structure (e.g., whether data is returned as a list or keyed by group name).

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 contains zero parameters (empty properties object). Per the scoring rubric, 0 params warrants a baseline score of 4. The description correctly focuses on return value semantics rather than inventing parameter explanations.

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 the specific verb 'Show' with the resource 'current deployment status of all groups' and explicitly enumerates the returned data points: 'which version is live, last deployment type, and deployer.' This clearly distinguishes it from action-oriented siblings like lexq_deploy_publish or lexq_deploy_rollback.

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 scope 'of all groups' clearly positions this as a broad overview tool, distinguishing it from detail-oriented siblings like lexq_deploy_detail or lexq_groups_list. However, it lacks explicit when/when-not guidance or named alternatives for users who need specific group details rather than the full overview.

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

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

With no annotations provided, the description carries the full burden of transparency. It discloses key behaviors: locking the version from further edits and that undefined facts don't block publishing (INV-4). This is sufficient for an agent to understand the side effects. However, it could mention whether the action is reversible or what errors occur if conditions aren't met.

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 extremely concise at two sentences. The first sentence states the core action and state transition. The second adds critical behavioral details and a cross-reference. No wasted words; every sentence provides unique value.

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 (a publish action with three parameters and no output schema), the description is mostly complete. It covers the purpose, behavioral side effects (locking), and a prerequisite (at least one rule). It also references a related tool for undefined facts. A minor gap: it doesn't describe what happens on success or failure (e.g., response status). Still, it's fairly comprehensive.

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 covers all three parameters with descriptions (100% coverage). The tool description does not add additional meaning beyond the schema for the parameters themselves (memo, groupId, versionId). It mentions prerequisites like 'must have at least one rule' but that's not parameter-specific. Thus, the description adds little to parameter understanding, earning a baseline score 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 clearly identifies the tool's function: publishing a DRAFT version to ACTIVE. It uses a specific verb ('publish') and resource ('version'). While it mentions a sibling tool (lexq_facts_unregistered) for differentiation, it doesn't explicitly distinguish from other deploy tools like lexq_deploy_rollback or lexq_deploy_undeploy. Still, the purpose is well-understood.

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 when-to-use guidance: must have at least one rule, and undefined facts don't block publishing. It also recommends calling lexq_facts_unregistered first. However, it does not explicitly state when not to use this tool (e.g., if the version is already ACTIVE or if edits are still needed). Overall, it offers good contextual 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?

No annotations are present, so the description carries the full burden. It discloses the availability condition but lacks details on whether the rollback is destructive, requires permissions, or affects other aspects of the system.

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 key information. No wasted words; every sentence adds value.

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 of the tool (2 params, no output schema), the description adequately covers purpose and a key constraint. Could be slightly improved by explaining the result of rollback (e.g., overwrites current version?) but is 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 coverage is 100% with descriptions for both parameters (memo and groupId). The description adds no extra meaning beyond what the schema already provides, so 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?

Description clearly states the tool rolls back to the previous deployed version, with a specific verb ('rollback') and resource ('deployed version'). It distinguishes from sibling tools like lexq_deploy_publish and lexq_deploy_undeploy.

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 notes the condition 'Only available if there is a previous version,' giving clear usage context. However, no explicit alternatives or when-not-to-use 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?

With no annotations, the description provides important behavioral context: the version stays ACTIVE but stops serving requests. This adds value beyond the tool name. However, it does not disclose potential side effects, permissions needed, or whether the action is reversible.

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

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

Two concise sentences with no fluff. The first sentence conveys the primary action, and the second adds critical nuance. Information is front-loaded 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?

Given the simple two-parameter schema, no output schema, and no annotations, the description adequately covers purpose and key behavioral post-condition. It could be slightly more complete about operational details (e.g., any delays), but it's sufficient for an agent to understand the tool's basic effect.

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 parameters described meaningfully. The description adds no additional parameter information beyond what the schema already provides. Thus, baseline is 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 clearly states the tool's function: removing the live version from traffic while keeping the version active. This distinguishes it from sibling deployment tools like deploy_publish (which deploys) and deploy_rollback (which reverts), making 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 usage: when you want to stop serving a version but retain it. However, it does not explicitly say when to avoid using it or provide alternatives among the many sibling tools. There is no guidance on prerequisites or competing actions like rollback.

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

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

With no annotations provided, the description fully discloses key behaviors: it creates a DRAFT version, is additive (skips existing facts and never overwrites), and requires active templates. It does not mention authentication, rate limits, or what the response contains, but covers the main safety-relevant traits.

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

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

The description is four sentences, front-loaded with the main action, and every sentence adds essential information without redundancy. It is well-structured and 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?

The description covers the creation details, additive behavior, prerequisite, and activation constraint. However, it does not mention what the response contains (e.g., identifier of created policy group), which would be helpful given no output schema. Still, it is largely complete for a moderately complex 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 coverage is 100%, so baseline is 3. The description adds value by giving an example for the 'template' parameter (ECOMMERCE) and explaining that 'customName' optionally overrides the default policy group name. This goes beyond the schema 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 clearly states the verb (apply), resource (domain template), and target (current tenant). It specifies what is created (fact definitions, new policy group with sample rules as DRAFT) and distinguishes from siblings by mentioning the preview tool and the active-only constraint.

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 tells when to use (to apply a domain template) and provides a prerequisite (run lexq_domain_templates_preview first). It also notes that only active templates can be applied. However, it does not explicitly state when not to use or list alternatives beyond the preview 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?

No annotations provided, but the description clearly indicates this is a read-only listing operation with no side effects. It mentions the output fields (key, status, summary), providing good transparency.

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

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

Three sentences, front-loaded with the main purpose, no unnecessary words. Each sentence adds value.

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 list tool with no output schema, the description fully covers purpose, output content, and usage context. No gaps.

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

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

No parameters in the input schema, so the description doesn't need to add parameter semantics. The baseline for zero-parameter tools is 4.

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 'List all domain templates' with a clear definition of what a domain template is, and distinguishes from siblings by noting to call before preview or apply.

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 to use: 'Call this before preview or apply to discover which templates can currently be applied.' This guides the agent on ordering.

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

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

The description explicitly states it is a read-only dry run with no creation, and lists what the preview includes. Since no annotations are provided, the description fully discloses 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 sentences with no waste: first sentence states purpose and outputs, second adds behavioral constraint. Every word is necessary.

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 preview tool with one parameter and no output schema, the description is complete: behavior, outputs, and constraints are all covered.

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 'template' is described both in the schema and the description with examples and guidance on finding valid keys. Schema coverage is 100%.

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's purpose: preview a domain template before applying. It specifies the exact outputs (fact definitions, sample rules, apply plan) and distinguishes from sibling tools like 'apply' and 'list'.

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

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

It implies usage before applying and states that only ACTIVE templates can be previewed. While it does not explicitly state when not to use, the sibling 'lexq_domain_templates_apply' is clearly the alternative for actual provisioning.

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

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

No annotations are provided, so the description must fully disclose behavior. It states 'without side effects' (non-destructive) and details the return fields (inputFacts, mutatedFacts, etc.). This gives good transparency, though it does not cover potential errors or prerequisites like version existence.

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 with a clear main sentence, a bullet list for return fields, and an example. Every sentence is informative and there is no redundancy. It is well-structured and 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 4 parameters (2 required) and no output schema, the description covers purpose, behavior, and return format thoroughly. It provides usage guidance and an example. Missing details like error handling or rate limits are not critical for a dry-run tool, making it fairly complete.

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

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

Schema coverage is 100% with each parameter described. The description adds value beyond the schema by providing an example input and explaining return fields, which helps the agent understand usage. Baseline 3 is increased to 4 for this added context.

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 'Execute a single dry run against a version. Tests how rules evaluate given input facts without side effects.' This clearly specifies the action (execute a dry run) and the resource (a version), distinguishing it from siblings like ab_test or deploy 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 explicitly says 'Always dry-run before publishing to validate rule behavior.', providing a clear when-to-use directive. It does not explicitly mention alternatives or when not to use, but the context is sufficient for an agent to decide.

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

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

No annotations provided. Description explains return structure (resultA/B, diff fields) but does not disclose side effects, authorization needs, or read-only nature. Adequate but could be better.

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 paragraphs with purpose first, then return fields. No fluff; every sentence adds value.

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?

Provides return type details compensating for missing output schema. For a comparison tool with no annotations, it covers purpose and expected results, though could mention version existence prerequisites.

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 covers all 3 parameters with descriptions. Description adds no extra semantic details beyond schema, meeting baseline but not exceeding.

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?

Describes comparing dry run results between two versions with same input facts, explicitly stating the verb and resource. Distinguishes from sibling tools like lexq_dry_run and deploy_diff.

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 'useful for validating changes,' implying context but lacks explicit when-to-use or alternatives. No mention of prerequisites or when not to use.

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

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

With no annotations, the description fully covers behavioral traits: it states that absent required facts throw, actions never create facts from nothing, and that the data is static and cacheable. No contradictions.

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 (3 sentences), front-loaded with the main purpose, and every sentence adds value. No unnecessary 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 no output schema, the description adequately explains the return value (fact requirements per action) and provides examples. It covers the essential information for a metadata retrieval 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 tool has 0 parameters, so the baseline is 4. The description appropriately provides context about what the tool returns without needing parameter details.

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

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

The description clearly states the tool retrieves runtime fact requirements per Action type, with specific examples (MUTATE_FACT, INCREMENT_FACT). It distinguishes itself from sibling facts tools by focusing on metadata rather than CRUD operations on 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 explains when to use the tool (to know required input facts) and provides context about fact supply and runtime behavior. However, it does not explicitly contrast with alternative tools, leaving some room for improvement.

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

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

No annotations provided, so description carries full burden. It adds validation constraints (key format pattern, type enum values) not fully explained in schema, but lacks critical behavioral details for a creation operation: error behavior on duplicate keys, return value structure, or permissions required.

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

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

Two sentences, zero waste. Front-loaded with purpose ('Register...'), followed immediately by constraints. 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?

Adequate for a simple 5-parameter creation tool with complete schema coverage, but gaps remain given no output schema or annotations: missing success/failure behavior, what is returned (ID?), and whether operation is idempotent.

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% (baseline 3). Description adds valuable concrete example ('payment_amount') and explicitly enumerates valid types, reinforcing constraints beyond raw schema. Could mention default behavior of optional parameters (e.g., isRequired defaults).

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

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

States clear action ('Register') and resource ('input variable'), with 'new' distinguishing it from sibling update/delete operations. However, it doesn't explicitly name siblings or clarify the domain-specific term 'fact' beyond 'input variable'.

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 no guidance on when to use this versus lexq_facts_update (for existing facts), prerequisites, or preconditions (e.g., checking if key exists first). No mention of idempotency or error handling.

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

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

With no annotations provided, the description carries the full burden. It discloses the system facts protection rule but omits other critical behavioral traits like irreversibility of deletion, error responses when attempting to delete system facts, or authorization 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?

Two sentences with zero redundancy: the first states the action, the second states the primary constraint. Every word earns its place with no filler or repetitive 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?

While adequate for a single-parameter tool, the description is minimal for a destructive operation with no output schema or annotations. It should disclose irreversibility or side effects on dependent rules to be fully complete.

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

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

Schema description coverage is 100% (factId is documented as 'Fact definition ID'), establishing a baseline of 3. The description does not add semantic context about the parameter format or how to obtain valid fact IDs, but none is required given complete 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 ('Delete') and resource ('fact definition') and clearly distinguishes scope from siblings via the constraint 'System facts cannot be deleted', clarifying this tool operates only on user-defined 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?

It provides one explicit when-not constraint (system facts), but lacks broader workflow guidance—such as when to use lexq_facts_update instead, or that lexq_facts_list should be used first to obtain the factId.

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?

Since no annotations are provided, the description carries full burden. It effectively discloses output contents ('Shows key, type, and required status') compensating for the missing output schema, but fails to explicitly state safety profile (read-only) or 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?

Three tightly constructed sentences: first defines the operation, second specifies return fields, third gives usage timing. Zero redundancy—every sentence delivers unique value not found in structured fields.

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 list tool with no annotations, the description adequately covers the main gaps by describing the return structure. Could be improved by noting pagination limits or read-only safety given the lack of annotation hints.

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%, establishing a baseline of 3. The description implies listing 'all' items but doesn't add semantic context about keyword filtering strategies or pagination best practices 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?

Description explicitly states the verb (List), resource (fact definitions), and scope (all), while clarifying these represent 'input variable schema' to distinguish from sibling tools like lexq_rules_list or lexq_groups_list.

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

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

Provides explicit workflow guidance ('Always check this before creating rules') establishing a prerequisite relationship with lexq_rules_create, though it doesn't explicitly state when NOT to use it or mention alternatives like lexq_facts_get for single-item retrieval.

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

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

With no annotations, description carries full burden. States read-only, non-blocking, and coverage across all rules. Discloses output fields (inferred type, suggested name, reference location). Lacks details on pagination, limits, or error handling, but sufficient for a list operation.

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

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

Two sentences, front-loaded with purpose, no unnecessary words. Efficiently communicates scope, behavior, and next steps.

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

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

No output schema, but description explains output fields (inferred type, suggested name, reference location). Lacks pagination/error info, but given simple list tool and sibling context, fairly complete.

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

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

Schema coverage is 100% with descriptions for both parameters ('Policy group ID', 'Version ID'). Description does not add further meaning beyond the schema, so baseline 3 applies.

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

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

Title and description clearly state verb 'List' and resource 'Unregistered Facts' with scope 'version-wide'. Differentiates from siblings like lexq_facts_list (registered facts) and 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?

Explicitly notes read-only nature and that it does not block publish/deploy. Provides forward guidance to register facts with lexq_facts_create. Could be more explicit about when not to use, but overall clear.

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

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

No annotations are provided, so the description carries full burden. It discloses that only provided fields are updated, key and type cannot be changed, and system facts only allow name/description changes. This is good for a mutation tool, though it does not mention any side effects or authorization needs.

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 covering the main point and constraints. No wasted words, though could be slightly more structured. Efficient for the information conveyed.

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 4 parameters, no output schema, and no annotations, the description covers the core behavior but lacks information about return values, side effects, or what happens after update. It is adequate but not fully complete 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?

Schema coverage is 100% with descriptions for each parameter. The description adds context not in schema: that key and type cannot be changed and system facts have limited fields. This adds value 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 tool updates a fact definition, specifying verb 'Update' and resource 'fact definition'. It distinguishes from create/delete/list siblings by focusing on update constraints.

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 what can be updated and constraints (key/type immutable, system facts restricted) but does not explicitly state when to use this tool vs alternatives like creating a new fact or deleting one. No when-not or alternative tool names 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?

No annotations are provided, so the description carries the full burden. It discloses auto-assignment of priority and the constraint on activationGroup. However, it does not mention side effects, error conditions, or idempotency, which would be useful for a create 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?

The description is concise with two clear sentences. It front-loads the core purpose and packs essential details without 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 parameter count and no output schema, the description covers the main behavior, optional parameters, and a critical constraint. It lacks details about the return value or error handling, but is largely complete for a create 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 coverage is 100%, but the description adds value by linking parameters to optional settings and explaining the priority auto-assignment (not a parameter). It also clarifies the relationship between activationGroup, activationMode, activationStrategy, and executionLimit.

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 'Create' and the resource 'policy group'. It distinguishes from siblings by mentioning lexq_groups_reorder for reordering, and includes key details like required name and optional fields.

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 requires name and mentions the alternative tool for reordering. It also provides a constraint about activationGroup sharing, giving contextual usage guidelines. However, it does not specify when not to use this tool or prerequisites.

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

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

No annotations provided, so description carries full burden. Discloses 'This is irreversible' which is essential for a destructive operation. However, lacks details on authorization requirements, side effects on associated rules, or whether 'archive' implies soft-delete vs permanent deletion.

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: action declaration, usage constraint, and safety warning. Front-loaded with the core verb and appropriately brief for a single-parameter 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?

For a simple 1-parameter destructive tool without output schema, covers the essential behavioral constraints (irreversibility, non-live restriction). Could mention authentication requirements or side effects, but adequate for the complexity level.

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 has 100% coverage with 'Policy group ID' description. The description implies the tool operates on policy groups, reinforcing the parameter purpose, but does not add syntax details, examples, or constraints 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 the action ('Archive') and resource ('policy group') clearly, though 'Archive' terminology slightly conflicts with the 'Delete' title/tool name. Does not explicitly differentiate from sibling group operations like lexq_groups_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?

Provides explicit constraint 'Only non-live groups can be deleted' which serves as a when-not-to-use guideline. Lacks explicit mention of alternatives (e.g., what to do with live groups instead), but the constraint is critical and clearly stated.

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

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

No annotations are provided, so the description carries full disclosure burden. It does not specify that this is a read-only operation, what happens if the groupId is not found (404 behavior), or any rate limiting concerns. The description only states the obvious action without behavioral nuance.

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?

Extremely concise at six words with zero redundancy. The sentence is front-loaded with the action and scope, earning its place by immediately communicating the tool's singular purpose without waste.

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

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

For a simple retrieval operation with 100% schema coverage and no output schema, the description is minimally adequate. However, it lacks any mention of error conditions, return value structure, or authentication requirements that would help an agent handle failures gracefully.

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

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

With 100% schema description coverage and only one parameter (groupId), the schema already fully documents the input requirements. The description adds no parameter-specific semantics, meeting the baseline expectation when the schema is self-sufficient.

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 (Get) and resource (policy group), and uses 'single' to imply this retrieves one item by ID. However, it does not explicitly distinguish from sibling tool lexq_groups_list by name, only by implication.

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

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

The word 'single' implies this is for specific ID lookups versus listing all groups, providing implied usage context. However, it lacks explicit guidance on when to use this versus lexq_groups_list or error handling scenarios (e.g., invalid UUID).

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

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

No annotations are provided, so the description carries the full burden. It discloses that the tool returns tenant-wide groups sorted by priority ascending, which is behavioral context beyond the empty schema. It does not cover permissions or performance, but for a simple list operation, this is sufficient.

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

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

The description is a single sentence that contains all essential information: the action (list), the resource (all policy groups), and key details (tenant-wide, priority ASC). There is no extraneous text.

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 (no parameters, no output schema), the description is mostly complete. It covers the scope and ordering of the returned list. It does not mention the return format or pagination, but for a tool expected to return all groups, this is 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?

The input schema has no parameters, and schema description coverage is 100% (trivially). The description adds meaning by specifying the scope (tenant-wide) and ordering (priority ASC), which aids in understanding the output. Per the rule for 0 parameters, a baseline of 4 is appropriate.

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

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

The description 'List all policy groups (tenant-wide, priority ASC)' is a specific verb+resource combination that clearly identifies the tool's function. It distinguishes itself from sibling tools like lexq_groups_create, lexq_groups_get, etc., by focusing on listing all groups with a specific ordering.

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 use for retrieving all policy groups with ascending priority order. It implies the context of when to use it (to get a comprehensive list) but does not explicitly state when not to use it or mention alternatives like lexq_groups_get for a single group.

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

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

No annotations are provided, so the description carries the full burden. It explains the priority numbering and clarifies that activationGroup is unaffected, which adds some transparency. However, it does not disclose side effects, reversibility, permissions needed, or whether the tool is safe to use at any time.

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 long, front-loads the primary action, and adds essential nuance. Every word earns its place with no fluff or irrelevant 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 tool with one parameter and no output schema, the description covers the core semantics (what priority means, what changes). However, it does not mention return values, error conditions, prerequisites (e.g., groups must exist), or idempotency, leaving some gaps for an agent to infer.

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

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

Schema coverage is 100% and the description adds no additional meaning beyond what the schema already documents for the single parameter 'groupIds'. The schema and description both note that index 0 = priority 1, so the description is redundant.

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 ('Reorder') and the resource ('policy groups'), and explains the priority system (tenant-wide, flat, continuous). It distinguishes from siblings like lexq_groups_create/update by specifying this only changes priority, not activationGroup.

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 clarifies what the tool does (reorder by priority) and what it does not affect (activationGroup), but does not explicitly state when to use it versus alternatives like lexq_groups_update or lexq_rules_reorder. There is no 'use this when' or 'do not use when' guidance.

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

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

With no annotations, the description transparently discloses the partial update behavior (only provided fields change), which is critical for correct usage. No contradictions.

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 purpose and key behavior, no fluff. 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?

While concise, it lacks context about return values, error conditions, or prerequisites (e.g., group must exist). The partial update info is sufficient but could be more complete.

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

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

Schema coverage is 100%, and the description adds the key insight that omitted parameters remain unchanged, which is not in the schema. This aids in understanding the full impact of each 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 clearly states the tool updates a policy group, with the specific behavior of only updating provided fields, distinguishing it from create and delete 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?

No explicit guidance on when to use this tool versus create or other update tools; usage is implied as updating an existing group, but no exclusions or alternatives are mentioned.

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

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

No annotations are provided, so the description carries the full burden. It lists returned fields, implying a read operation, but does not explicitly state it is read-only, disclose side effects, authentication needs, or error conditions. The information is adequate but lacks explicit behavioral guarantees.

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 purpose ('Get full execution detail') and lists key fields. No extraneous words, perfectly concise.

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

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

For a simple tool with one parameter and no output schema, the description adequately informs about the returned fields. It could mention that the traceId must come from execution history, but the schema covers that. The listing of fields provides sufficient context for understanding the output.

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% (traceId described as 'Trace ID from execution history'). The description does not add parameter-specific semantics beyond what the schema already provides, 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 retrieves the full execution detail, listing specific fields (inputFacts, mutatedFacts, etc.), distinguishing it from siblings like lexq_history_list (list) and lexq_history_stats (statistics).

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 does not explicitly state when to use this tool versus alternatives, such as lexq_history_list for overviews. Usage can be inferred (to get detail of a specific execution), but no explicit guidance on context or exclusions 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?

Since no annotations are provided, the description carries the full burden. It adds valuable context by listing the specific fields returned (compensating for the missing output schema), but fails to disclose operational traits like read-only safety, pagination behavior, or rate limiting.

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 efficient sentences with zero redundancy. The first sentence establishes the core action, the second clarifies the payload contents. 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?

Adequate for a listing tool with no output schema, as it describes the return fields. However, gaps remain regarding pagination mechanics (despite page/size params), result ordering, and safety characteristics (read-only vs. destructive).

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

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

With 100% schema description coverage, the schema adequately documents all 8 parameters (page, size, status filters, etc.). The description does not add additional semantic context for parameters (e.g., date format examples or filter combinations), meeting the baseline expectation.

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 policy execution history and enumerates the returned fields (trace ID, group, version, status, match result, latency). However, it does not explicitly differentiate from siblings lexq_history_get and lexq_history_stats (e.g., noting this returns multiple records vs. single-record 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?

Provides no guidance on when to use this tool versus alternatives like lexq_history_get (for specific records) or lexq_history_stats (for aggregated metrics). No mention of prerequisites or filtering best practices despite having 8 optional filter parameters.

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

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

With no annotations provided, the description carries the full burden. It discloses what metrics are returned (compensating partially for the missing output schema), but lacks behavioral context such as whether this is computationally expensive, if results are cached, or how large date ranges are handled.

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 with zero waste. The information is front-loaded and every clause earns its place by specifying either the action or the specific KPIs returned.

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 three optional parameters and no output schema, the description partially compensates by listing return metrics. However, it omits whether parameters are optional, what default behavior is when no dates are provided, and that this returns aggregate data rather than individual execution records.

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 adequately documents all three parameters. The description adds no additional parameter context (e.g., explaining the date range logic, valid duration limits, or that groupId filters to a specific policy group), meriting the baseline score for high-coverage schemas.

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 retrieves execution KPIs and lists specific metrics (total executions, success/failure counts, success rate, average latency), providing specific verb + resource. However, it does not explicitly differentiate from sibling tools like lexq_history_list or lexq_history_get, which likely retrieve individual records rather than aggregates.

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 like lexq_history_list (which likely returns detailed records). No prerequisites, filtering recommendations, or exclusions are mentioned despite having three optional parameters.

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

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

No annotations provided, so description carries full burden. While 'Show' implies read-only behavior, the description lacks disclosure of return format, authentication requirements, caching behavior, or whether the spec is static/dynamic. For a metadata tool returning complex field schemas, this is insufficient.

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 of 9 words with zero waste. Front-loaded with action verb ('Show') and immediately specifies what is returned ('integration types' and 'required configuration fields').

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 zero-parameter metadata tool, explaining what content is returned. However, lacks return value description (no output schema exists to compensate) and could clarify the data structure of the 'required configuration fields'.

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 with 100% coverage trivially satisfied. Baseline score of 4 applies as per rules for zero-parameter tools.

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 specific verb 'Show' with clear resources ('integration types' and 'required configuration fields'). It effectively distinguishes from sibling tools like lexq_integrations_list by focusing on specification/metadata rather than configured instances.

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 explicit guidance on when to use this versus alternatives like lexq_integrations_list (likely lists configured integrations) or lexq_integrations_get (likely retrieves specific integration details). The agent must infer this is for discovery of available types/schemas before configuring.

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

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

No annotations are provided, so the description carries the full burden of disclosure. While 'Delete' implies a destructive operation, the description fails to specify if the action is permanent, irreversible, or has cascading effects on dependent resources.

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 extremely brief (5 words) with no wasted text. However, given the lack of behavioral context and safety warnings for a destructive operation, it is arguably under-sized rather than appropriately concise.

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

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

For a single-parameter deletion tool, the description covers the basic mechanics but is incomplete regarding safety and operational context. Without annotations or an output schema, it should explicitly state the destructive/permanent nature of the action.

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%, establishing a baseline of 3. The description mentions 'by ID' which correlates to the integrationId parameter, but adds no semantic detail (e.g., format guidance, examples, or consequences) beyond what the schema already provides.

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

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

The description states the specific action (Delete) and resource (integration) clearly. However, it does not explicitly differentiate from sibling tools like `lexq_integrations_save` or `lexq_integrations_list`, though the verb choice implies distinct functionality.

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

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

The description provides no guidance on when to use this tool versus alternatives (e.g., when to delete vs. disable), nor does it mention prerequisites or irreversibility of the operation.

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

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

No annotations provided, so description carries full burden. It fails to disclose idempotency, safety (read-only vs mutation), error behavior (404 handling), or return format. The word 'Get' implies read-only but doesn't confirm it.

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?

Extremely brief at 4 words. Front-loaded with verb-first structure. No redundant text, though brevity verges on under-specification given lack of output schema and annotations.

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?

Input parameter is documented, but with no output schema provided, the description inadequately explains return values ('detail' is vague). Missing error handling and side effect disclosure for a tool that presumably fetches external configuration data.

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

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

Input schema has 100% coverage with 'Integration ID' description. The description adds 'by ID' which aligns with the parameter but provides no additional semantic context (e.g., where to obtain the UUID, validation rules). Baseline 3 appropriate for high 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?

States the core action ('Get') and resource ('integration detail') clearly. The phrase 'by ID' distinguishes it from sibling lexq_integrations_list, but lacks specificity about what 'detail' includes (e.g., config, status, credentials).

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 no guidance on when to use this versus alternatives (e.g., 'use list to find the ID first'), nor any prerequisites or error conditions.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure but only states the basic operation. It fails to mention pagination behavior (despite page/size parameters), read-only safety, or response characteristics. The phrase 'List all' suggests comprehensive retrieval but doesn't clarify if this requires multiple calls or how pagination works.

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. The parenthetical examples add density without verbosity. 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?

Given the low complexity (3 simple parameters, no nesting) and complete schema coverage, the description is minimally adequate. However, it could improve by noting the paginated nature of the 'all' result set since no output schema exists to document the response 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?

While the schema has 100% coverage (baseline 3), the description adds valuable semantic context by mapping business concepts ('webhooks, CRM, notification') to the 'type' enum parameter values (WEBHOOK, CRM, NOTIFICATION, etc.), helping the agent understand the purpose of the filter.

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 (external integrations) with concrete examples (webhooks, CRM, notification). It implicitly distinguishes from siblings like 'get' and 'delete' through the plural 'integrations' and 'List' verb, though it doesn't explicitly contrast with lexq_integrations_get.

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

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

The description provides no guidance on when to use this tool versus alternatives like lexq_integrations_get (for specific retrieval) or lexq_integrations_save. There are no prerequisites or conditions mentioned for 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?

No annotations are provided, so the description carries the full burden of disclosing behavioral traits. It only mentions create/update mechanics but omits side effects, required permissions, rate limits, or reversibility. For a mutation tool, this is insufficient.

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

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

The description is two sentences with no redundant words. The first sentence states the core purpose, and the second provides critical context (id behavior and types). 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?

Given 7 parameters (3 required), no output schema, and no annotations, the description is too brief. It does not explain return values, security considerations, or the effect of missing optional fields. The schema covers parameter details, but behavioral context is lacking.

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 adds no new meaning beyond the schema: the id usage and types are already documented in the schema. Thus it does not enhance parameter understanding.

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 creates or updates an integration, distinguishes between create and update via the id parameter, and lists the supported types. This differentiates it from sibling tools like list, get, delete, and config_spec.

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 guidance on when to use this tool (to create or update an integration) and how to differentiate between the two operations (include id for update, omit for create). It does not explicitly state when not to use it or name alternative tools, but the sibling list allows inference.

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

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

No annotations provided, so description carries full burden. It discloses the three actions and their effects (retry=re-execute, resolve=mark fixed, ignore=skip), but omits behavioral details like idempotency, side effects, authorization needs, or return values.

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 concise sentence that front-loads the purpose and enumerates actions with parentheses qualifiers. No redundant words; every part 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 2-param tool, the description covers the core functionality and action semantics. It could be more complete by mentioning the return value (e.g., success/error) or prerequisites, but is adequate given the lack of output schema and straightforward nature.

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 covers 100% of parameters. The description adds semantic value by explaining the meaning of each enum value in the action parameter (e.g., 'RETRY (re-execute with original payload)'), which goes beyond the schema's generic 'Action to take'.

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 processes a single failure log with three explicit actions: RETRY, RESOLVE, IGNORE. It distinguishes from sibling tools like lexq_logs_bulk_action which handles multiple logs, and lexq_logs_list/get which are read-only.

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 when needing to act on a single log, but lacks explicit when-to-use or when-not-to-use guidance. It doesn't mention alternatives like lexq_logs_bulk_action for batch operations, nor prerequisites like log existence.

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

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

No annotations provided, so description carries full burden of behavioral disclosure. Fails to explain what 'process' entails (are logs deleted? retried? marked?), whether operations are reversible, or potential side effects of RETRY actions.

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, appropriately front-loaded with purpose. No redundant text, though the second sentence restates obvious schema requirements rather than adding value.

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 state-modifying tool (implied by actions like RETRY/RESOLVE) with no annotations and no output schema, the description is insufficient. Lacks critical safety context: what happens to logs post-action, whether RETRY consumes quota, or success/failure signaling.

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 has 100% coverage with descriptions for both parameters. The description adds minimal semantic value beyond the schema, merely instructing to 'provide' the parameters without explaining action semantics or log ID sources.

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 the core function (process failure logs) and distinguishes from sibling 'lexq_logs_action' by emphasizing 'multiple... at once.' However, uses the generic verb 'Process' rather than a more specific action word.

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 syntax instructions ('Provide an array...') but offers no guidance on when to use bulk vs single action (lexq_logs_action), nor when to choose RETRY vs IGNORE vs RESOLVE. No prerequisites or side effects mentioned.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure but fails to specify read-only safety, error handling for invalid IDs, or what specific fields constitute 'detail' (e.g., timestamps, error messages, stack traces). The single word 'Get' implies retrieval but lacks explicit safety guarantees.

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 exactly six words with zero redundancy, front-loading the verb and maintaining high information density appropriate for a simple retrieval tool. 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 single-parameter tool with complete schema coverage, the description is minimally viable. However, given the absence of both annotations and an output schema, it should ideally describe the structure or key fields of the returned 'detail' to be fully complete. As written, it leaves the return value opaque.

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

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

With 100% schema description coverage ('Failure log ID' for logId), the schema adequately documents the single parameter. The description references 'by ID' which aligns with the schema but adds no additional semantic context such as UUID format requirements or ID sourcing guidance, meriting the baseline score for high-coverage schemas.

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 ('Get'), resource ('failure log'), and scope ('detail by ID'), effectively distinguishing it from sibling tools like lexq_logs_list (which likely retrieves collections) and lexq_logs_action (which performs mutations). However, it stops short of being exemplary by not explicitly naming the 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?

While 'by ID' implicitly signals this requires a specific identifier likely obtained from lexq_logs_list, the description provides no explicit guidance on when to use this tool versus listing logs or performing bulk actions. No prerequisites or workflow context is provided.

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

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

No annotations are provided, so the description must compensate. It only states the tool lists logs but does not disclose pagination behavior, authorization needs, or whether results are ordered. The term 'failure logs' is somewhat inconsistent with the schema's inclusion of 'PENDING' and 'IGNORED' statuses.

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, clear sentence. It is concise and front-loaded with the key action. No unnecessary 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 8 parameters, no output schema, and no annotations, the description covers the basic purpose but lacks details on expected output format, sorting, or handling of no results. It is adequate but leaves gaps.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds general context about background tasks, but does not elaborate on parameter usage or constraints beyond what the schema already provides.

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

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

The description clearly states the verb 'List' and the resource 'system failure logs from background tasks', which conveys the tool's purpose. However, it could more precisely indicate that the logs may include non-failure statuses (PENDING, RESOLVED, IGNORED) as per 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?

There is no guidance on when to use this tool versus alternatives like lexq_logs_get or lexq_logs_action. The description does not state prerequisites or exclusions.

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

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

With no annotations provided, the description carries the full burden. It successfully discloses the return value structure ('required keys, types, and an example request body'), but fails to indicate whether this is a safe read-only operation or if it has side effects, which is critical missing context for an 'Analyze' 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 sentences with zero waste: the first states the action/purpose, the second states the return value. Information is front-loaded appropriately with no filler words or redundant phrases.

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 simple schema (2 UUID parameters, no nesting) and lack of output schema, the description compensates adequately by explaining what the tool returns. However, without annotations indicating readOnly/destructive hints, the description should have explicitly mentioned this is a safe analysis operation to be fully complete.

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

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

Schema description coverage is 100% (both groupId and versionId are described in the schema), establishing a baseline of 3. The description mentions 'a version' which implicitly maps to the versionId parameter, but adds no additional semantic context, constraints, or usage notes beyond what the schema already provides.

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

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

The description clearly states the tool 'Analyze[s] which input facts a version requires' — a specific verb (analyze) with a clear resource scope (input facts for a version). This effectively distinguishes it from siblings like lexq_versions_get (retrieves version metadata) or lexq_facts_list (lists facts globally).

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

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

The description provides no guidance on when to use this tool versus alternatives (e.g., lexq_dry_run for testing execution), nor does it mention prerequisites or conditions where this analysis is necessary. It only describes what the tool does, not when to invoke it.

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

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

No annotations provided, so description fully carries behavioral disclosure. It details priority auto-assignment, constraints like division+percentage invalidity, and that missing required facts throw errors. Does not mention side effects like triggering automations but is highly transparent overall.

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?

Description is long but well-structured: starts with core purpose, then workflow, then detailed specs for conditions and actions. Slightly verbose but justified by tool complexity; key info 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?

Thoroughly covers a complex tool: all action types, condition operators, value types, constraints, and integration examples. No output schema, but for a create operation, return value is expected (created rule). Complete for an agent 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 description coverage is 100%. Description adds significant meaning: explains the rule JSON structure with condition/action formats, provides examples, and details each action type's parameters with constraints. Greatly enriches understanding 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 tool's purpose: 'Create a rule in a DRAFT version.' It specifies required fields (name, condition tree, actions array) and distinguishes from sibling tools like lexq_rules_reorder by noting auto-assignment of priority.

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 explicit guidance: before creating rules with new fact keys, check existing facts using lexq_facts_list; if missing, confirm with user then call lexq_facts_create. Also advises using lexq_facts_unregistered after saving. Does not explicitly state when not to use, but the context is clear.

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

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

With no annotations provided, the description carries full burden. It provides critical behavioral context (DRAFT-only operation) but omits destructiveness details, permanent vs. soft delete semantics, and doesn't contextualize the 'force' parameter's role in handling the last rule deletion.

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 with zero redundancy. Front-loaded with the action verb. Appropriately brief for a 4-parameter operation with complete schema documentation, though slightly terse given the destructive nature of the 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?

Adequate but minimal. The DRAFT constraint is essential context, but the description doesn't address the special case of deleting the last rule (hinted at by the 'force' parameter in schema) or explain failure modes when attempting to delete from live versions.

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 fully documents all parameters including the 'force' flag's purpose. The description adds no explicit parameter guidance beyond implying the versionId references a DRAFT version.

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 (Delete) and resource (rule) with specific scope constraint (DRAFT version). This distinguishes it from lexq_versions_delete and implies it cannot be used on live/published versions, though it doesn't explicitly contrast with lexq_rules_update or toggle.

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 'DRAFT version' constraint provides implicit guidance on when to use (only on draft versions, not live), but lacks explicit when-not guidance, prerequisites, or named alternatives like lexq_rules_update for modifications.

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

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

No annotations provided, so description carries full burden. Mentions return content (condition tree, action definitions) but omits safety profile (read-only status), error behaviors, rate limits, or authorization 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?

Single sentence, nine words, front-loaded with key action. 'Including condition tree and action definitions' earns its place by distinguishing from list operations. Zero waste.

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

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

Adequate for a simple read operation with three flat parameters. Mentions key return components (condition tree, action definitions) compensating somewhat for missing output schema, though could clarify return format or 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 has 100% description coverage (all three UUID parameters documented). Description adds no supplemental parameter context (e.g., relationships between groupId/versionId/ruleId, or where to obtain these values), warranting baseline score.

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

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

Specific verb 'Get' with resource 'rule detail' and scope clarification ('full'). The phrase 'including condition tree and action definitions' effectively distinguishes this from sibling lexq_rules_list (which likely returns summaries) and mutation tools like lexq_rules_update/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?

Implies usage through 'full rule detail' (suggesting use when comprehensive data is needed), but lacks explicit when-to-use guidance, prerequisites, or explicit comparison to lexq_rules_list alternative.

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

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

No annotations provided, so the description carries the full burden. It discloses ordering (priority ASC) and return format (summary with conditionSummary and actionSummary). It does not mention prerequisites or side effects, but for a read-only list operation these are less critical.

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, well-structured sentence that front-loads the action and scope. Every word contributes information without redundancy.

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

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

For a simple list tool with two parameters and no output schema, the description covers the essential aspects: what it does, ordering, and return summary. It is complete given the tool's complexity.

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

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

Schema coverage is 100%, so baseline is 3. The description adds minimal extra meaning beyond the schema, only reinforcing that groupId and versionId are required for listing rules in a version.

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 specifies the action ('List all rules'), the context ('in a version'), ordering ('priority ASC'), and return fields ('summary with conditionSummary and actionSummary'). It distinguishes from sibling tools like lexq_rules_get and lexq_rules_create by focusing on listing.

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 tool is for listing rules in a version, but does not explicitly state when to use it versus alternatives like lexq_rules_get. It is clear enough for an agent given context from sibling tool names.

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

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

With no annotations, the description carries the full burden. It clearly discloses the behavioral trait that priorities become 1...N continuous based on array index, which is beyond what the schema provides. It does not cover rate limits or authorization but is transparent about the reordering logic.

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: first states the action, second explains the priority assignment. No fluff, front-loaded with key information.

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

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

Given the complexity (3 params, no output schema, no annotations), the description covers core behavior and priority mapping. It doesn't address edge cases like empty or duplicate ruleIds, but is otherwise complete for the 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 coverage is 100% but the description adds significant semantic to the ruleIds parameter by explaining how array order maps to priority (1-based, continuous, index 0 highest). This enhances understanding beyond the schema's 'Rule IDs in desired priority order'.

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 reorders rules by specifying rule IDs in desired order, distinguishing it from siblings like lexq_rules_update (which updates rule properties) and lexq_groups_reorder (which reorders groups).

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 for reordering rules but provides no explicit guidance on when to use versus alternatives like lexq_rules_update or lexq_groups_reorder. No exclusions or context are given.

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

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

With no annotations provided, the description carries the full burden. It successfully conveys that the rule persists (non-destructive), but omits other behavioral traits such as side effects (e.g., whether toggling triggers redeployment), idempotency, or return value structure.

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 of eight words. It is front-loaded with the action ('Enable or disable') and contains zero redundant information, making it maximally scannable for an agent.

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 moderate complexity of a toggle operation with four required parameters and no output schema, the description adequately covers the core function. It could be improved by mentioning the return value or side effects, but it is sufficient 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?

The input schema has 100% description coverage with clear definitions for all four parameters. The description does not add semantic details beyond what the schema already provides (e.g., specific UUID formats or business logic for 'isEnabled'), warranting the baseline score for high-coverage schemas.

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 specific verbs ('Enable or disable') and identifies the resource ('a rule'). It explicitly distinguishes this tool from the sibling 'lexq_rules_delete' by stating 'without deleting it,' clarifying the non-destructive nature of the operation.

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

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

The phrase 'without deleting it' implicitly guides the agent to use this tool for state changes rather than the sibling delete tool. However, it lacks explicit 'when to use' guidance regarding other siblings like 'lexq_rules_update' or prerequisites for the toggle operation.

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

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

With no annotations, description must carry full burden. It mentions partial update behavior but omits details on authorization requirements, side effects, error states, or consequences of modifying a rule in a draft.

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-load the key purpose and update semantics. No extraneous information, though the 'DRAFT' constraint could be emphasized more.

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 without output schema or annotations, the description lacks return value information, error conditions, and prerequisites (e.g., draft must exist). Incomplete for effective use.

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 schema already documents all parameters. Description adds no additional meaning beyond noting partial update, which is evident from schema's optional fields for 'rule'.

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 clearly states it updates an existing rule in a DRAFT version, distinguishing from create/delete/toggle. However, it does not explicitly differentiate from sibling tools like lexq_rules_toggle or lexq_rules_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?

No guidance on when to use this tool versus alternatives (e.g., create vs update, or when a draft version is required). Agent must infer context from name and description.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. While 'Cancel' implies a write operation, it fails to specify whether cancellation is immediate or graceful, whether partial results are retained, if the action is reversible, or what final state the simulation enters.

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

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

The single sentence is efficiently structured with the action verb first, zero redundancy, and every word ('running or pending') contributing essential usage context. Perfect information density.

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 tool with full schema coverage, the description adequately covers the basic contract but leaves gaps in safety profile (destructive vs. safe) and post-cancellation behavior that annotations or additional text should address.

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 has 100% description coverage for its single parameter (simulationId). The description adds no explicit parameter guidance, but this meets the baseline expectation when the schema is fully self-documenting.

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 provides a specific verb ('Cancel'), resource ('simulation'), and scope ('running or pending'), clearly distinguishing this tool from siblings like lexq_simulation_start or 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 description implicitly restricts usage to 'running or pending' simulations, but provides no explicit guidance on when not to use it (e.g., completed simulations), error conditions, or 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. While it mentions 'Returns the raw data,' it fails to disclose safety properties (read-only vs. destructive), idempotency, rate limits, or the structure/content of the returned raw 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?

The description is appropriately concise with two front-loaded sentences. Every word serves a purpose, though the brevity comes at the cost of omitting behavioral and contextual details that would be valuable for agent decision-making.

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 low complexity (2 parameters, no nested objects, 100% schema coverage) and lack of output schema, the description meets minimum viability but leaves gaps. It does not explain what 'raw data' contains or how to handle the returned payload, which would be helpful since no output schema exists.

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 has 100% description coverage (simulationId and format are documented), establishing a baseline of 3. The description reinforces the format options ('JSON or CSV') but does not add semantic depth beyond the schema, such as explaining the UUID format implications or default behavior.

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

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

The description clearly states the specific action (export), target resource (simulation results), and supported formats (JSON or CSV). It effectively distinguishes this tool from siblings like lexq_simulation_start or lexq_simulation_status through the 'export' verb.

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

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

The description provides no guidance on when to use this tool versus alternatives, nor does it mention prerequisites such as requiring a completed simulation or how it relates to lexq_simulation_list. Usage must be inferred entirely from the tool name.

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

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

With no annotations provided, the description bears full responsibility for behavioral disclosure. It only states 'list' with no details on mutability, authorization needs, rate limits, or results ordering. The operation is read-only, but this is not explicitly 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?

The description is a single, clear sentence with no fluff. It is front-loaded with the core action and resource. However, it could be slightly more informative without harming conciseness, e.g., mentioning pagination or default sort.

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 lack of output schema and annotations, the description should provide more context about the response format (e.g., fields returned, default ordering, pagination limits). It only mentions filters, leaving significant gaps 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 coverage is 100%, so the input schema already describes all five parameters with their types and constraints. The description adds no extra meaning beyond 'optional filters,' which is redundant given the schema. 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 'List simulation history with optional filters' clearly states the action (list) and resource (simulation history), distinguishing it from sibling tools like lexq_simulation_start or lexq_simulation_cancel. It is specific enough to convey the tool's function, though it misses details about default ordering or 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?

No explicit guidance is provided on when to use this tool versus alternatives such as lexq_simulation_status for a single simulation or lexq_simulation_export for downloading. The description implies listing with filters, but lacks when-not-to-use or contextual recommendations.

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

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

No annotations are provided, so the description must disclose behavioral traits. It does not mention if the simulation is asynchronous, how to check status, side effects (e.g., resource consumption), or rate limits. The example shows input structure but no behavioral context.

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: a purpose sentence, then a parameter listing, then an example body. It is concise with no filler. Could be slightly more formal (e.g., bullet points), but overall efficient and readable.

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

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

Given no output schema, the description does not explain return values or what happens after starting a simulation. The tool has many options, but the description omits output behavior (e.g., returns simulation ID, status URL). Incomplete for an action 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 input schema has only one parameter 'body' described as 'JSON string'. The description adds full meaning by listing each nested field (dataset.type, dataset.source, options.maxRecords, etc.) with types, constraints, and examples. This goes well beyond the schema and provides complete parameter 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 clearly states 'Start an Impact Simulation against historical or uploaded data.' The verb 'Start' and resource 'simulation' are specific. It distinguishes from sibling tools like lexq_simulation_cancel, lexq_simulation_status, etc., though it does not explicitly contrast with them.

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

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

The description provides no guidance on when to use this tool vs alternatives, no prerequisites (e.g., need a policy version), and no conditions where the tool should not be used. The agent is left to infer usage from context.

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

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

No annotations are provided, so the description carries full burden. It successfully discloses the polling pattern and terminal states (COMPLETED/FAILED), implying an async lifecycle. However, it omits error handling behavior, rate limits, or what occurs if the simulationId doesn't exist.

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

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

Two sentences with zero waste. First sentence states purpose; second provides critical polling instruction. Information is front-loaded and 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 single-parameter status tool without output schema, the description is reasonably complete. The polling instruction compensates for missing output schema by indicating the tool returns progressive state. Could improve by hinting at result structure or error states.

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 'simulationId' clearly documented as a UUID. The description does not add parameter-specific semantics beyond the schema, but none are needed given the complete schema coverage. 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 uses specific verb 'Get' with clear resource 'simulation status and results'. It clearly distinguishes from siblings like lexq_simulation_start (initiates), lexq_simulation_cancel (terminates), and lexq_simulation_list (enumerates) by focusing on retrieval of specific instance state.

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 instruction 'Poll until status is COMPLETED or FAILED' provides explicit usage pattern guidance for asynchronous operations. However, it lacks explicit when-not-to-use guidance contrasting with sibling tools (e.g., when to use list vs get status).

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

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

No annotations are provided, so the description bears full responsibility. It states the outcome (creates a DRAFT) but lacks details on side effects, permissions, or error conditions. Adequate but not rich; could improve with more behavioral context.

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

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

The description is two sentences with no excess. The key action and use case are front-loaded, making it efficient and easy to parse for an AI agent.

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 and the absence of an output schema, the description covers the essential purpose and usage context. However, it could briefly mention prerequisites (e.g., existence of source version) or error potential for completeness.

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 clear descriptions for both parameters (groupId, versionId). The description adds no extra meaning beyond what the schema provides, 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 clones a version to create a new DRAFT, with a specific use case when the source is published. It distinguishes from other version tools (e.g., lexq_versions_create) by emphasizing cloning rather than fresh creation.

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 context for use ('when the source version is already published'), but does not mention when not to use or list alternative tools like lexq_versions_create. It clearly implies a scenario, which is helpful for an AI agent.

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

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

With no annotations provided, the description carries the full burden. It indicates a creation action but does not disclose side effects, permissions, or behavior beyond the basic creation. It is minimal but does not contradict any 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, front-loaded sentence that efficiently conveys the tool's purpose and optional parameters. No unnecessary words or 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?

The description covers the essential purpose and optional parameters, but it lacks information on return values or any constraints. Since there is no output schema, some hint about what the tool returns would improve completeness.

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 description adds limited value beyond the schema. It summarizes that commit message and dates are optional, but the schema already provides detailed descriptions for each 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 clearly states the tool creates a new DRAFT version in a policy group, with optional commit message and date range. It uses a specific verb and resource, differentiating it from sibling tools like lexq_versions_clone or lexq_versions_delete.

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 for creating a draft version, but it does not explicitly state when to use this tool versus alternatives like lexq_versions_clone or lexq_versions_update. No exclusions or prerequisites are mentioned.

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

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

No annotations are provided, so the description carries full disclosure burden. It successfully adds the critical behavioral constraint that only DRAFT versions are deletable, but omits other important behavioral traits such as whether the deletion is permanent, if it cascades to related resources, or required authorization levels.

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 consists of two brief sentences with zero redundancy; the primary action is front-loaded in the first sentence, while the constraint follows immediately. 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?

Given the tool's narrow scope (single delete operation with two UUID parameters) and absence of an output schema, the description provides sufficient context by documenting the critical draft-only constraint. It could be improved by noting the expected outcome or error behavior for non-draft deletions.

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

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

With 100% schema description coverage ('Policy group ID', 'Version ID'), the schema already fully documents the parameters. The description adds no additional parameter semantics (e.g., format details, where to obtain IDs), meriting the baseline score for high-coverage schemas.

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 ('Delete') and resource ('DRAFT version'), with the capitalized 'DRAFT' effectively distinguishing this tool from sibling version management tools by indicating it only operates on non-live versions.

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

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

The second sentence ('Only DRAFT versions can be deleted') provides explicit exclusion criteria (when-not-to-use), preventing attempts to delete live/deployed versions. However, it does not suggest alternative tools from the sibling list (e.g., lexq_deploy_undeploy or lexq_deploy_rollback) for handling non-draft versions.

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

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

No annotations provided, so description carries full disclosure burden. It adds value by revealing what content is retrieved ('rules and fact requirements'), but lacks safety profile (read-only vs. side effects), caching behavior, or auth constraints that annotations would typically cover.

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

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

Single sentence of 10 words. Front-loaded with action and resource ('Get a single version by ID'), followed by specific inclusion details ('rules and fact requirements'). Zero 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 2-parameter retrieval tool without output schema, the description adequately compensates by disclosing what constitutes the version (rules and fact requirements). Missing only a safety confirmation (read-only) given lack of 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 clear descriptions for both UUID parameters. Description mentions 'by ID' aligning with versionId but adds no syntax, format, or usage examples beyond what the schema already provides. Baseline 3 appropriate for high-coverage schemas.

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?

Clear verb ('Get') and resource ('single version by ID'), with scope defined. Implicitly distinguishes from lexq_versions_list by specifying 'single' and 'by ID', though explicit contrast with siblings (create/delete/update/clone) is absent.

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 explicit guidance on when to use this versus alternatives (e.g., lexq_versions_list for browsing, lexq_versions_clone for copying). No mention of prerequisites like needing valid UUIDs from lexq_groups_get or lexq_versions_list.

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

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

No annotations are provided, so the description must carry the full burden of behavioral disclosure. While 'List' implies a read operation, the description fails to confirm safety, disclose pagination behavior, indicate whether results include archived/deleted versions, or describe the return format. This leaves significant behavioral gaps for an agent to infer.

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?

Extremely concise at 7 words/1 sentence with zero redundancy. However, the extreme brevity comes at the cost of missing contextual clues that would help an agent (e.g., noting pagination or differentiation from get operations), preventing a perfect score.

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

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

Given the rich domain with 8 sibling version tools (clone, create, delete, get, update, etc.) and no output schema, the description is insufficient. It fails to explain what constitutes a 'version,' how this relates to the policy group lifecycle, or what differentiates a list result from a get result. For a tool with pagination and 3 parameters in a complex API surface, more context is needed.

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

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

With 100% schema description coverage (groupId, page, and size all documented), the baseline score is 3. The description adds no parameter-specific semantics (e.g., explaining that groupId is a UUID, or typical page sizes), but the schema sufficiently covers this ground.

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