LexQ

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

No annotations are provided, so the description carries full burden. It states the action (adjust weights) but omits critical behavioral details: whether weights must sum to 100%, if changes are immediate or gradual, validation constraints, or side effects on ongoing sessions.

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 in a single sentence. Every word earns its place with no filler, front-loading the key action and resource. Appropriate density for a simple 3-parameter tool.

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

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

Adequate for a 3-parameter primitive with simple types, but gaps remain regarding validation logic (the schema allows 1-99 for both weights without explaining sum constraints) and return value expectations. No output schema exists to compensate.

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 'traffic weights' which maps to controlWeight and challengerWeight parameters, but adds no additional semantic context, examples, or validation rules 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 a specific verb ('Adjust'), resource ('traffic weights'), and scope ('running A/B test'), clearly distinguishing it from sibling tools like lexq_ab_test_start/stop which handle lifecycle states rather than weight modification.

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 'running' implies a prerequisite state (test must be active), providing minimal implicit guidance. However, it lacks explicit when-to-use guidance versus siblings or warnings about when not to use it (e.g., during low traffic periods).

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 state whether this operation is idempotent, what happens if a test is already running, whether it immediately affects live traffic, or what the tool returns upon success/failure.

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

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

The two-sentence structure is efficient and front-loaded with the primary action. There is no redundant or wasted text, though the brevity contributes to under-specification given the lack of 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?

For a mutation tool affecting production traffic routing, with no annotations and no output schema, the description is insufficient. It omits critical context such as the relationship between control/challenger weights (should sum to 100%), the purpose of identityKey for sticky assignment, and lifecycle implications of starting a test.

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 'traffic split percentages' which aligns with controlWeight and challengerWeight, and implies the group context, but adds no semantic detail beyond the schema for the optional identityKey parameter or validation constraints.

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

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

The description clearly states the action ('Start an A/B test') and target resource ('policy group'). The verb 'Start' effectively distinguishes this from sibling tools 'adjust' and 'stop' in the lexq_ab_test_* family.

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 the description lists required parameters ('Requires a challenger version ID and traffic split percentages'), it provides no guidance on when to use this tool versus siblings like lexq_ab_test_adjust, prerequisites for the policy group state, or warnings about production traffic impact.

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 mentions keeping one version but fails to explain what happens to losing versions, whether the stop is immediate or graceful, reversibility, or side effects like traffic redistribution.

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 efficient, front-loaded sentences with zero waste. The primary action ('Stop a running A/B test') comes first, followed by the critical requirement ('Specify which version to keep').

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 moderate complexity (stopping tests has deployment implications) and lack of annotations or output schema, the description is minimally viable. It covers the core action but omits important context about deployment consequences, finalization behavior, or return values.

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%, establishing a baseline of 3. The description mentions 'Specify which version to keep,' which aligns with winnerVersionId but adds no syntax details, format examples, or clarification of groupId 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 ('Stop') and resource ('A/B test'), distinguishing it from sibling tools like lexq_ab_test_start and lexq_ab_test_adjust through the specific verb. However, it does not explicitly name siblings or clarify the relationship between stopping and deploying the winner.

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

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

The description implies usage context by mentioning 'Specify which version to keep,' suggesting this is used when a winner has been determined. However, it lacks explicit guidance on prerequisites (e.g., test must be running) or when to use lexq_ab_test_adjust instead.

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

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

With no annotations 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 provided, the description carries full burden and successfully discloses that content is stored in S3 and that a path is returned. This compensates for the missing output schema by documenting the return value. Lacks details on permissions, idempotency, or overwrite 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?

Efficiently structured with the core purpose upfront, followed by behavioral details, workflow integration, and practical examples. No redundant information; every sentence and code block serves a clear purpose.

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

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

Given the tool's simplicity (2 parameters) and lack of output schema, the description is complete. It explains the return value, provides format examples, and connects the tool to the broader simulation workflow (lexq_simulation_start).

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?

Despite 100% schema coverage (baseline 3), the description adds significant value by providing concrete CSV and JSON examples that demonstrate the expected data format and structure, helping the agent construct valid content strings.

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 (upload), resource type (simulation dataset), and input format (inline CSV or JSON). It distinguishes itself from sibling lexq_dataset_template by emphasizing 'inline' content and establishes its role in the simulation workflow.

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: 'Use this path in simulation start with dataset type UPLOADED.' This clarifies how to consume the output, though it could more explicitly contrast when to use this versus lexq_dataset_template.

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 provided, the description carries the full burden of behavioral disclosure but fails to mention read-only safety, pagination behavior, return format, or rate limiting. Only the basic operation type ('List') is implied.

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 no wasted words. However, given the lack of annotations and output schema, the description may be overly terse 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 tool with 4 parameters, no annotations, and no output schema, the description is insufficient. It fails to explain deployment types (PUBLISH, ROLLBACK, etc.), the concept of 'groups' in this domain, or what constitutes a deployment history entry.

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 'across all groups' which loosely corresponds to the optional groupId filter, but adds no additional semantic detail about the deployment type enum values or pagination strategy beyond the schema definitions.

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

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

The description uses a specific verb ('List') and resource ('deployment history') to clearly state the tool's function. The phrase 'across all groups' provides scope context, though it could better differentiate from similar sibling 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?

The description provides no guidance on when to use this tool versus alternatives like 'lexq_deploy_detail' or 'lexq_history_list', nor does it mention prerequisites or exclusion criteria.

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. Adds critical timing context ('Takes effect immediately') which warns about production impact. However, lacks disclosure of side effects: what happens to the previous live version, whether the operation is atomic/reversible, or failure modes.

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. Front-loaded with core action and constraint, followed by behavioral timing. 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 high-stakes deployment tool with no annotations and no output schema, the description covers the immediate effect but is thin on operational context. Should mention whether this replaces existing live traffic or reference sibling rollback tools given the 'immediate' 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 description coverage is 100% (all three parameters documented). Description adds implicit context that versionId must refer to an 'ACTIVE' version, but does not elaborate on memo format or groupId/versionId relationship beyond schema definitions. Baseline 3 appropriate given schema completeness.

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 ('Deploy') and target ('live traffic') with clear constraint that version must be 'ACTIVE (published)'. This effectively distinguishes it from sibling lexq_deploy_publish (which likely activates versions) by implying this tool requires a pre-published version.

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 prerequisite (version must already be ACTIVE/published) but does not explicitly state when to use this vs. lexq_deploy_rollback, lexq_deploy_undeploy, or the A/B testing siblings. Missing explicit 'when-not-to-use' guidance despite immediate production impact.

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?

No annotations are provided, so the description carries the full burden. It effectively discloses the state machine transition (DRAFT→ACTIVE), the locking side effect, and the validation rule. It does not cover error handling behavior, idempotency, or authorization requirements, but covers the essential mutation behavior.

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

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

Three sentences with zero waste. The first sentence establishes the core action and state change, the second discloses the locking side effect, and the third states the validation prerequisite. Front-loaded and highly efficient.

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

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

For a state-transition tool with no output schema and no annotations, the description adequately covers the operational contract (input requirements, state changes, side effects). It omits details about the response structure or specific error codes, but provides sufficient context for correct invocation given the moderate 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%, establishing a baseline of 3. The description adds valuable semantic context that 'versionId' must reference a DRAFT version (not explicit in schema) and implies the 'memo' parameter relates to deployment tracking. This additional state constraint elevates it above the baseline.

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

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

Description uses specific verb 'Publish' with clear resource 'DRAFT version' and explicitly states the state transition 'DRAFT → ACTIVE'. It distinguishes from sibling rollback/undeploy tools by specifying the forward direction and finality ('Locks the version from further edits').

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 a clear prerequisite constraint ('Must have at least one rule'), which implies when the tool can be successfully used. However, it lacks explicit guidance on when to use this versus alternatives like 'lexq_deploy_rollback' or 'lexq_versions_update', and does not state exclusions (e.g., cannot publish already-ACTIVE 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 are provided, so the description carries the full burden. While it mentions the availability constraint, it fails to disclose critical behavioral traits for a deployment mutation: whether the operation is immediate, reversible, idempotent, or what happens to the current version being replaced.

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 two-sentence structure. The first sentence defines the action, the second states the critical constraint. Zero redundant words or boilerplate.

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?

Minimum viable for a 2-parameter mutation tool with no output schema. It covers the core function and main constraint, but given the operational significance of deployment rollbacks, the description lacks richness regarding side effects, timing, or integration with the deployment history.

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 groupId and memo fully documented in the schema. The description text adds no additional parameter context (e.g., explaining what constitutes a valid Policy group ID or example memo content), 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 specific action (rollback) and target (previous deployed version). The constraint about requiring a previous version helps scope the tool's function, though it does not explicitly differentiate from siblings like 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?

Provides a clear prerequisite constraint ('Only available if there is a previous version'), which functions as a when-not-to-use guideline. However, it lacks explicit alternatives or guidance on what to do when no previous version exists (e.g., check lexq_deploy_history first).

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 that the version remains ACTIVE (important state preservation), but fails to mention reversibility (can it be re-deployed?), fallback behavior for traffic, or destructive implications beyond stopping request serving.

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 immediately; the second clarifies the critical state distinction. 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 two-parameter mutation tool with no output schema. The description covers the essential behavioral nuance (ACTIVE state preservation), but lacks guidance on reversibility, traffic fallback behavior, or relationship to the deploy/rollback lifecycle that would be expected for a deployment management 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 100% description coverage (groupId and memo are fully documented). The description adds no parameter-specific guidance, but at this coverage level, the baseline score of 3 is appropriate as the schema carries the load.

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

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

The description clearly states the action ('Remove the live version from traffic') and the resulting state ('stays ACTIVE but no longer serves requests'). However, it does not explicitly distinguish this tool from siblings like lexq_deploy_rollback or lexq_deploy_stop, which may have similar traffic-related effects.

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

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

The description implies usage through the state change explanation (ACTIVE but not serving), but provides no explicit guidance on when to choose this over alternatives like rollback or publish, nor does it mention prerequisites or side effects.

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 successfully discloses the critical safety trait ('without side effects') and the evaluation behavior ('tests how rules evaluate'). However, it omits other behavioral details like return value structure, error handling when rules fail, or performance characteristics of the dry run.

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 efficiently structured sentences: purpose statement, concrete example, and workflow guideline. Every sentence earns its place with zero redundancy. Information is front-loaded with the core action, followed by supporting 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?

Appropriate for a 4-parameter tool with 100% schema coverage and no output schema. Covers the essential workflow context (testing before publishing) and safety guarantees. Could be strengthened by explicitly contrasting with lexq_dry_run_compare or noting what the debug info contains, but adequate as-is.

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), but the description adds value through the concrete example input showing the nested structure of the facts object. This clarifies that while the schema accepts a JSON string, the content should be a structured object with domain-specific keys like 'payment_amount' and 'customer_tier'.

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?

Excellent specificity: states the action (execute a single dry run), the target (against a version), the mechanism (tests how rules evaluate given input facts), and the safety profile (without side effects). The word 'single' effectively distinguishes it from batch simulation siblings like lexq_simulation_start and lexq_dry_run_compare.

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

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

Provides clear workflow guidance ('Always dry-run before publishing to validate rule behavior') that positions the tool correctly before deployment actions. Implies when to use (pre-publish validation) but does not explicitly name alternative tools like lexq_deploy_publish or lexq_simulation_start for batch operations.

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. Fails to specify output format (diff? boolean? full results?), whether results are persisted, execution time expectations, or error conditions (e.g., version mismatch). 'Validating changes' hints at purpose without explaining what the comparison reveals.

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 tightly written sentences with zero redundancy. First sentence defines the operation; second states the value proposition. 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?

With full input schema coverage, input requirements are satisfied. However, lacks output specification critical for a comparison tool (agents need to know if they receive a diff report, pass/fail status, or detailed results). Absence of annotations increases the need for descriptive coverage of behavioral outputs.

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 with clear parameter descriptions ('Baseline version ID', 'Candidate version ID', 'JSON string of facts object'). Description reinforces the relationship (using same facts for both versions) but adds minimal semantic depth 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?

States specific action (compare), resource (dry run results), and key constraint (same input facts). Distinguishes implicitly from sibling lexq_dry_run via the comparative verb, though explicit differentiation would strengthen it further.

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 a use case ('validating changes') but lacks explicit when-not-to-use guidance, prerequisites (e.g., versions must exist), or comparison to alternatives like lexq_dry_run for single-version testing.

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 effectively describes key behavioral traits: the data is 'static and changes only on engine deployment — safe to cache in-session,' which informs caching behavior and data freshness. It doesn't mention error conditions, rate limits, or authentication requirements, but for a read-only metadata tool, the provided information is quite helpful.

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 efficiently structured in three sentences: the first states the purpose, the second provides usage guidance with an example, and the third adds behavioral context about data staticness and caching. Every sentence adds critical information without redundancy, making it front-loaded and appropriately sized.

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

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

Given the tool's complexity (metadata retrieval with no parameters) and the absence of annotations and output schema, the description does well by explaining what metadata is returned (input/output/consumed facts per action type) and providing an example output variable. It could be more complete by specifying the exact format of the returned metadata or listing all possible action types, but for a tool with 0 parameters, it provides sufficient context 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?

The input schema has 0 parameters with 100% coverage, so the baseline is 4. The description adds value by explaining that no parameters are needed because it retrieves metadata for 'each Action type' comprehensively, implying this is a bulk fetch operation. This clarifies why the schema is empty, going beyond what the schema alone indicates.

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: 'Retrieve runtime Facts metadata for each Action type' with specific examples of Action types (DISCOUNT, SEND_SMS, ADD_TAG, SET_FACT) and what the metadata shows (required input facts, produced output facts, consumed runtime facts). It distinguishes itself from sibling tools like lexq_facts_create, lexq_facts_list, etc., which handle fact data rather than metadata about action-fact relationships.

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 usage guidance: 'Use this BEFORE designing rules to understand which Action produces which output variables (e.g., DISCOUNT produces last_discount_amount).' It specifies the optimal timing (before rule design) and the alternative context (using it for metadata lookup rather than other fact-related operations). This clearly tells the agent when to use this tool versus 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 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?

No annotations provided, so description carries full disclosure burden. It successfully documents critical runtime constraints (immutable fields, system fact restrictions) not visible in schema. However, missing safety profile (destructive? reversible?), auth requirements, or side effects expected for a mutation tool.

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

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

Extremely efficient three-sentence structure: action statement followed by two critical constraint clauses. Zero redundant words. Constraints are front-loaded with clear negative formulations ('cannot be changed', 'only allow').

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 4-parameter mutation tool. Covers essential business logic constraints. However, lacks description of return value or success behavior, which would be helpful given no output schema exists to indicate what the tool returns upon completion.

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?

Despite 100% schema coverage, adds valuable context: explains why key/type parameters are absent (immutable), and warns that isRequired parameter is ignored for system facts. This semantic guidance prevents incorrect assumptions about the update scope.

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 'Update a fact definition' with specific resource identification. The constraints about immutable keys/types and system fact restrictions effectively distinguish this from sibling tools like lexq_facts_create (which would set key/type) and lexq_facts_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?

Provides implicit usage guidance through constraint documentation ('Key and type cannot be changed', 'System facts only allow name and description changes'), which informs when the tool will fail or behave differently. However, lacks explicit cross-references to siblings like lexq_facts_create for initial setup.

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 deliver. It doesn't describe what the tool returns (e.g., the created group ID), whether the operation is idempotent, potential error states, or side effects like immediate activation of the group.

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 optimally concise with two efficient sentences. The first states purpose, the second outlines requirements. Every word earns its place with no redundancy or filler.

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

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

Given 7 parameters with enum constraints and conditional logic (maxSelections requirements), plus no output schema, the description is minimally adequate. It fails to mention what identifies the created resource or explain the enum values, though the schema covers parameter definitions. For a creation mutation with no annotations, it should disclose more behavioral context.

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 lists some parameters (conflict resolution, activation group, description) but conflates the two conflict resolution fields (mode and strategy) and omits maxSelections entirely. It adds no semantic context beyond the schema (e.g., explaining what 'activation group' means).

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

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

The description clearly states the action ('Create') and resource ('policy group'), distinguishing it from sibling tools like lexq_groups_update or lexq_groups_delete. However, it lacks context about what policy groups are used for (organizing rules with priorities), preventing a top score.

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 differentiates required parameters ('Requires name and priority') from optional ones, providing basic usage structure. However, it lacks guidance on when to create a new group versus updating an existing one, and doesn't mention the conditional requirement that maxSelections is required when conflictResolutionMode is MAX_N.

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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It successfully mentions pagination support, but fails to explicitly state this is a read-only/safe operation or describe the return format/structure given the absence of an output schema.

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

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

Two well-structured sentences with zero redundancy. The first states the core purpose immediately; the second lists key capabilities. Every word earns its place without extraneous filler.

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

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

For a straightforward list operation with simple parameters and no output schema, the description is reasonably complete. It covers the essential functionality, though it could briefly mention the return type (list of policy group objects) to compensate for the missing 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?

While the schema has 100% coverage with clear descriptions, the tool description adds valuable semantic grouping by categorizing parameters into 'pagination' (page/size) and 'filters' (status/keyword). It also explicitly confirms these are optional, reinforcing the schema structure.

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

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

The description clearly states the tool lists policy groups with specific verb ('List') and resource ('policy groups'). The word 'all' effectively distinguishes this from the sibling tool 'lexq_groups_get' which likely retrieves a single specific group, though it could explicitly name the sibling for clarity.

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?

Mentions pagination and filtering capabilities, which implies usage context for large datasets. However, it lacks explicit guidance on when to use this versus 'lexq_groups_get' or the other CRUD siblings (create/update/delete), leaving some ambiguity for agents deciding between list vs. get operations.

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 disclosure burden. It successfully communicates the PATCH-like partial update behavior, but omits mutation risks, error conditions (e.g., 404 if groupId missing), idempotency guarantees, or authorization requirements expected for an update 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. Front-loaded with verb ('Update') and immediately qualified with partial-update behavior. 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 standard CRUD update with complete schema coverage, but gaps remain due to zero annotations and no output schema. For a mutation tool affecting complex policy configurations (8 parameters including conflict resolution enums), missing behavioral context on failure modes or deployment implications leaves it minimally viable.

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, establishing baseline 3. The description adds crucial semantic context that optional parameters represent partial updates rather than requiring full object replacement, elevating understanding of how to construct the payload.

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 (Update) and resource (policy group) clearly. The word 'existing' effectively distinguishes from sibling lexq_groups_create. However, it assumes familiarity with 'policy group' domain concepts without brief context.

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?

Clarifies partial-update semantics ('Only provided fields are updated'), which guides the agent to treat optional parameters as patch fields. However, lacks explicit guidance on when to use this vs. lexq_groups_create or prerequisites like obtaining the groupId from list/get operations.

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 partially compensates by listing the three components of the execution detail that will be returned, which is helpful given the lack of an output schema. However, it fails to disclose safety traits (read-only vs. mutation), error conditions, or performance characteristics.

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 ten words. It is front-loaded with the action ('Get full execution detail') and follows with specific content details. There is no redundant or wasted language.

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

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

Given the tool has only one parameter and no output schema, the description partially compensates by enumerating the return components (facts, traces). However, it lacks context about what constitutes an 'execution' in this system (e.g., rule execution, workflow run) and does not clarify the relationship to the history_list tool needed to obtain the ID.

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 (executionId is described as 'Execution history ID'), so the schema carries the semantic load. The description does not add additional context about the parameter format, valid ID sources, or constraints beyond what the schema already provides, warranting the 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?

The description uses a specific verb ('Get') and resource ('execution detail'), and lists specific components returned (request facts, result traces, decision traces). The word 'full' implicitly distinguishes this from sibling tools like lexq_history_list (likely returns summaries) and lexq_history_stats (likely returns aggregates), though it does not explicitly name alternatives.

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

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

The description lists what the tool returns but provides no guidance on when to use this tool versus siblings like lexq_history_list or lexq_history_stats. It does not indicate prerequisites (e.g., obtaining executionId from a list operation) or appropriate contexts for use.

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

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

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?

With no annotations provided, the description carries the full burden of behavioral disclosure. While 'Create or update' implies upsert semantics, it fails to explain how the distinction is made (presumably by 'name'), whether the operation is idempotent, what validation occurs, or what the response indicates (created vs. updated).

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—effectively a single sentence. It is front-loaded with the action verbs. However, it may be overly terse given the complexity of a mutation tool with 6 parameters and upsert semantics, leaving insufficient room for necessary behavioral context.

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

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

As a mutation tool (create/update) with no annotations and no output schema, the description is dangerously minimal. It omits critical context such as error handling (what if baseUrl is invalid?), the upsert resolution logic, side effects of activation/deactivation (isActive), and the return value structure or success indicators.

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, establishing a baseline score of 3. The description lists the enum values for the 'type' parameter, but this merely duplicates information already present in the schema's enum definition. It adds no additional semantic context (e.g., explaining what distinguishes a POINT from a COUPON integration or the expected structure of the 'config' JSON).

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 dual operation ('Create or update') and the target resource ('integration'). It also lists the valid integration types. However, it does not distinguish this tool from the sibling 'lexq_integrations_config_spec' tool or clarify the upsert key mechanism (likely 'name' since no ID parameter exists).

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 versus sibling tools like 'lexq_integrations_config_spec', 'lexq_integrations_delete', or when to update versus create. There are no stated prerequisites (e.g., whether the baseUrl must be pre-validated) 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 of behavioral disclosure but fails to explain what each action actually does (e.g., does RETRY resubmit the log, does RESOLVE archive it?). No mention of side effects, idempotency, 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?

Extremely concise single sentence with zero waste. Information is front-loaded with the verb 'Process' and immediately qualifies with scope and valid values. 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 simplicity (2 params, 100% schema coverage, no output schema), the description is minimally adequate. However, for a state-changing operation with three distinct behavioral modes, the description should explain what each action accomplishes.

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%, establishing a baseline of 3. The description reinforces the enum values (RETRY, RESOLVE, IGNORE) and emphasizes 'single' scope, but adds no additional semantic context about parameter formats 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?

The description clearly states the tool processes a single failure log and explicitly lists the three valid actions (RETRY, RESOLVE, IGNORE). The word 'single' effectively distinguishes this from the sibling 'lexq_logs_bulk_action' tool.

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

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

While the description implies this is for individual logs (vs bulk), it provides no guidance on when to use RETRY vs RESOLVE vs IGNORE, nor does it mention prerequisites or state conditions. Usage is implied but not explicit.

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?

With no annotations provided, the description must carry the full burden of behavioral disclosure. It successfully identifies these as 'failure' logs (distinguishing from general logs) and mentions the background task context, but omits safety information, performance characteristics, pagination behavior, 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, efficiently structured sentence with parenthetical examples. Every element earns its place—the main clause defines the operation and resource, while the examples clarify scope without verbosity.

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

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

Given the moderate complexity (8 parameters, no output schema, no annotations), the description is minimally adequate. It establishes the domain (failure logs) but does not describe the return structure, pagination behavior, or filtering best practices that would help an agent invoke the tool effectively.

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?

Although the schema has 100% description coverage, the description adds valuable semantic context by listing specific examples (webhook calls, coupon issuance) that correspond to enum values in the taskType parameter. This helps agents understand the relationship between the parameter options and real-world operations.

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

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

The description clearly states the tool lists system failure logs from background tasks, providing specific examples (webhook calls, coupon issuance) that map to the taskType enum values. However, it does not explicitly distinguish this listing tool from the sibling 'lexq_logs_get' which likely retrieves individual logs.

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 examples of background tasks covered but offers no explicit guidance on when to use this tool versus siblings like 'lexq_logs_get' or the action-oriented log tools. It lacks prerequisites, exclusion criteria, or recommendations for filter usage with the 8 available 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 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 carries full burden. Discloses critical behavioral context: operates only on DRAFT versions (not live), and extensively documents valid condition tree structures, operators, value types, and action types. However, lacks disclosure of side effects, 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?

Information-dense with no wasted words. Front-loads the core purpose and requirements. The structured JSON-like documentation of Condition and Actions schemas is efficient, though slightly dense; every sentence earns its place by providing actionable validation rules.

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

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

Given the complex nested input schema, the description adequately covers input validation requirements. However, with no output schema provided and no description of return values (e.g., rule ID, created object), it leaves a gap for a creation operation where the caller needs to know the result identifier.

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?

Despite 100% schema coverage, the schema only describes 'rule' as a generic 'JSON string'. The description adds substantial value by detailing the complex nested structure of CreateRuleRequest—documenting condition types (SINGLE/GROUP), valid operators, value types, and action types—essential for constructing valid invocations.

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 verb (Create) + resource (rule) + precise scope (DRAFT version). The DRAFT qualifier effectively distinguishes from siblings like lexq_rules_update or deployment-related tools, clarifying this operates on unpublished 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?

Implies usage context via 'DRAFT version' and lists required fields (name, priority, condition tree, actions), but lacks explicit when-to-use guidance versus lexq_rules_update or prerequisites like version state validation.

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?

With no annotations provided, the description carries the full burden. It compensates partially by disclosing the return structure (conditionSummary and actionSummary), which helps absent an output schema. However, it lacks operational details like pagination behavior, idempotency, or error conditions.

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 two-sentence structure. First sentence establishes purpose; second discloses return value. No redundant or filler text. 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 list operation with 4 parameters. The description partially compensates for missing output schema by mentioning conditionSummary and actionSummary. However, it omits pagination metadata details and doesn't contextualize the groupId/versionId hierarchy available in sibling tools like lexq_groups_get.

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

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

Schema description coverage is 100%, so the schema already fully documents page, size, groupId, and versionId. The description references 'version' mapping to versionId but adds no syntax details, format constraints, or semantic relationships beyond the schema. Baseline 3 is appropriate given 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), resource (rules), and scope (in a version). It implies pagination via 'all rules' and distinguishes from siblings like lexq_rules_get by implying bulk retrieval. However, it doesn't explicitly clarify when to use this versus lexq_rules_get for single-rule 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?

No guidance provided on when to use this tool versus alternatives like lexq_rules_get (single rule details) or lexq_dry_run. No prerequisites or exclusion criteria are mentioned despite requiring specific groupId/versionId 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 provided, so description carries full disclosure burden. It successfully explains the priority direction (index 0 = highest), but omits operational context like whether changes are immediate, atomic, or require deployment, and lacks safety warnings about changing rule evaluation order.

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 establishes the action and mechanism; second sentence provides the critical constraint about priority direction. Perfectly front-loaded and dense with actionable 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?

Adequate for the input semantics given 100% schema coverage, but could clarify whether ruleIds must include all rules in the group or allows partial reordering. Missing output guidance is acceptable given no output schema, though operational side effects remain undocumented.

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

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

While schema has 100% coverage and documents 'desired priority order', the description adds crucial semantic detail that array index 0 maps to highest priority (directionality). This clarifies the ruleIds parameter behavior beyond the schema's generic description.

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

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

Specific verb 'Reorder' with clear resource 'rules' and mechanism 'specifying rule IDs and their new priorities'. The 'Array index 0 = highest priority' precisely defines the ordering semantics, distinguishing this from generic update operations like lexq_rules_update.

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

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

Implies usage through specificity of the reordering action, but lacks explicit guidance on when to use this versus editing rules, or whether this affects live traffic immediately versus requiring a separate deploy action (suggested by sibling lexq_deploy_* tools).

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

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

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?

No annotations provided, so description carries full burden. It discloses PATCH behavior and DRAFT scope constraint, but omits error handling (what if ruleId not found?), idempotency guarantees, and 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?

Two sentences, zero waste. Front-loaded with core action ('Update an existing rule'), followed by critical scope constraint ('DRAFT version'), then behavioral note ('Only provided fields are changed'). 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 no annotations and no output schema, description adequately covers the primary operation but leaves gaps in error scenarios, authentication requirements, and success return values. Sufficient for a standard CRUD update operation but not 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?

Schema coverage is 100% with detailed descriptions for all 4 parameters including the JSON structure of 'rule' field. Description adds PATCH context ('Only provided fields are changed') which reinforces how to populate the 'rule' parameter, meeting baseline expectations 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?

Specific verb 'Update' + resource 'existing rule' + scope constraint 'DRAFT version' clearly distinguishes from siblings like lexq_rules_create, lexq_rules_delete, and implies difference from potential live-version update 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?

Clarifies partial update semantics ('Only provided fields are changed') and scope limitation ('DRAFT version'), but lacks explicit guidance on what to use for live versions or prerequisites like version state verification.

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 carries the full burden of behavioral disclosure but fails to mention read-only safety, pagination behavior, rate limits, or response format. The term 'List' implies read-only, but critical behavioral traits remain undocumented.

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 at 6 words, front-loaded with the verb 'List'. While no words are wasted, the extreme brevity is inappropriate for a 5-parameter tool with no output schema or annotations, leaving significant explanatory gaps.

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

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

Given the absence of annotations and output schema, the description should provide richer context. It fails to explain what constitutes a 'simulation' in this domain, what the return payload contains, or how pagination behaves, leaving the agent under-informed for invocation.

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

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

Schema description coverage is 100%, so the schema fully documents all 5 parameters. The description adds minimal semantic value beyond the schema, merely noting 'optional filters' which maps to the date range and status parameters. Baseline score appropriate given schema completeness.

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

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

The description clearly states the tool lists 'simulation history' (specific verb + resource), and the word 'history' implicitly distinguishes it from sibling tools like 'status' (current state) or 'start' (creation). However, it lacks explicit differentiation from lexq_simulation_export or other list-like operations.

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

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

The description provides no guidance on when to use this tool versus alternatives like lexq_simulation_status (for checking a specific simulation) or lexq_simulation_export (for extracting data). No prerequisites, exclusions, or workflow context is 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 disclosure burden but omits critical operational details. It does not indicate whether the simulation runs asynchronously (implied only by existence of status/cancel siblings), what resources it consumes, how long it typically takes, or what the response indicates upon initiation. The phrase 'Start' hints at initiation but lacks explicit 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 compact with minimal waste—one explanatory sentence followed by a practical example. However, the example block is lengthy and front-loading a brief explanation of key fields (like the difference between policyVersionId and baselinePolicyVersionId) before the raw JSON would improve scannability.

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 of batch simulation operations and the rich ecosystem of sibling management tools (cancel, export, list, status), the description is incomplete. It fails to explain the operational workflow (initiation → polling → retrieval) or mention that results require separate retrieval via lexq_simulation_export. For a tool likely initiating long-running compute, this missing lifecycle context is a significant gap.

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

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

While the schema documents the body parameter as merely a 'JSON string of SimulationRequest', the description provides a concrete example showing the expected structure including policyVersionId, dataset configuration with date ranges, and options like baselinePolicyVersionId. This example adds substantial semantic value beyond the schema's generic type definition.

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 ('Start a batch simulation') and target resource ('historical execution data'). It effectively distinguishes this from real-time or dry-run operations through the 'batch' and 'historical' qualifiers, though it could explicitly differentiate from sibling tools like lexq_dry_run or lexq_ab_test_start.

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. It fails to mention the relationship to sibling lifecycle tools (lexq_simulation_status, lexq_simulation_cancel) or when simulations are preferred over A/B tests or dry runs. No prerequisites or constraints are 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 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 provided, so description carries full burden. It successfully discloses that the operation creates a DRAFT status (not live/published), which is critical behavioral context. However, it omits other important behavioral details like required permissions, whether the source version must be accessible, or if the clone includes all associated rules/facts.

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

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

Extremely efficient two-sentence structure. First sentence establishes the core operation and result; second sentence provides usage context. No redundant or filler content.

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

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

Adequate for a 3-parameter cloning operation with no output schema. Covers the essential 'what' and 'when,' but could be strengthened by mentioning the commitMessage parameter's role in version history or indicating what identifiers are returned upon success.

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%, providing clear descriptions for groupId, versionId, and commitMessage. The description adds no additional parameter semantics beyond what the schema already documents, meeting the baseline expectation 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 ('Clone') and resource ('version') with specific outcome ('create a new DRAFT'). The phrase 'Useful when the source version is already published' effectively hints at when to prefer this over creating new versions, though it doesn't explicitly name sibling alternatives like lexq_versions_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?

Provides explicit contextual guidance with 'Useful when the source version is already published,' indicating the primary use case. However, it lacks explicit 'when not to use' guidance or direct comparison to lexq_versions_create for creating versions from scratch.

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 usefully specifies that the version is created as a 'DRAFT' (not live), but omits other critical mutation details: whether this fails if a draft already exists, idempotency guarantees, or what the return value contains.

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 efficient sentences with zero redundancy. The first sentence establishes the core purpose, while the second front-loads the required and optional parameter categories. 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 simple 4-parameter schema with no nesting and no output schema, the description covers the basics adequately. However, for a mutation operation, it should mention the draft lifecycle implications or at least hint at the return value (likely a version identifier).

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 groups effectiveFrom/effectiveTo into 'effective date range' which provides mild semantic grouping, but adds no validation rules, format details, 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 specific action (Create) and resource (DRAFT version in policy group). The inclusion of 'DRAFT' effectively distinguishes this from deployment/publish siblings like lexq_deploy_publish. However, it does not clarify when to use this versus lexq_versions_clone or lexq_versions_update.

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

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

The description provides no guidance on when to use this tool versus alternatives like cloning an existing version or updating a draft. It also fails to mention prerequisites (e.g., that the policy group must exist first) or when-not-to-use conditions.

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

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

No annotations are provided, so the description carries 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.

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

The description uses specific verb 'List' and identifies the resource as 'versions of a policy group.' The word 'all' implicitly distinguishes it from sibling lexq_versions_get (which likely retrieves a single version), though it doesn't explicitly clarify this distinction or differentiate from other version operations like create/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?

No guidance provided on when to use this versus lexq_versions_get or other version tools. No mention of pagination strategy (despite page/size parameters) or filtering capabilities. The description offers no 'when-to-use' or 'when-not-to-use' context.

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

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

No annotations are provided, so the description carries the full burden. It discloses the critical DRAFT-only constraint, but omits other behavioral details such as error responses when attempting to modify non-draft versions, whether updates are atomic, or if this creates audit trail entries.

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 establishes the action, the second establishes the critical constraint. Information is front-loaded 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 well-documented schema (100% coverage) and lack of output schema, the description is sufficiently complete. It captures the essential business logic constraint (DRAFT-only editing) that an agent needs to select this tool correctly, though it could mention error behavior for invalid version 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?

With 100% schema description coverage, the baseline score applies. The description does not add semantic details beyond the schema (e.g., date formats for effectiveFrom/effectiveTo or validation rules), but the schema is sufficiently self-documenting that additional prose is not strictly necessary.

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 (Update) and resource (DRAFT version), and specifically narrows scope to DRAFT versions only. This effectively distinguishes it from sibling tools like lexq_versions_clone or lexq_versions_create by establishing the specific state requirement.

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 constraint 'Only DRAFT versions can be modified' provides explicit negative guidance (when NOT to use). However, it lacks explicit alternatives for handling non-DRAFT versions (e.g., mentioning that lexq_versions_clone should be used first to create a draft from a published version).

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 states 'Delete' which implies a destructive mutation, but doesn't disclose behavioral traits like whether deletion is permanent, requires specific permissions, has side effects (e.g., stopping webhook notifications), or what happens on success/failure. For a destructive tool with zero annotation coverage, this is a significant gap in 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, direct sentence with zero waste—it states exactly what the tool does without fluff. It's appropriately sized and front-loaded, making it easy for an agent to parse quickly.

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

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

Given this is a destructive mutation tool with no annotations and no output schema, the description is incomplete. It lacks crucial context such as what the tool returns (e.g., success confirmation, error details), behavioral implications (e.g., irreversibility), or prerequisites. The agent is left with significant gaps in understanding how to properly invoke and interpret results.

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 'id' documented as a UUID for the webhook subscription. The description adds no additional meaning beyond what the schema provides (e.g., it doesn't clarify where to get the ID or format examples). With high schema coverage, the baseline score of 3 is appropriate as the description doesn't compensate but doesn't need to heavily.

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 ('webhook subscription by ID'), making the purpose immediately understandable. It doesn't explicitly differentiate from sibling tools like 'lexq_webhook_subscriptions_get' or 'lexq_webhook_subscriptions_list', but the verb 'Delete' inherently distinguishes it as a destructive operation versus read operations.

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

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing subscription ID), when-not-to-use scenarios (e.g., if you want to modify instead of delete), or direct alternatives like 'lexq_webhook_subscriptions_save' for updates. The agent must infer usage from the tool name alone.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action ('Get') but doesn't describe traits like whether it's a read-only operation, what permissions are required, error handling for invalid IDs, or the format of the returned detail. This leaves significant gaps for an agent to understand the tool's behavior beyond the basic action.

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 directly states the tool's purpose without unnecessary words. It's front-loaded and wastes no space, making it easy to parse quickly 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 lack of annotations and output schema, the description is incomplete for a tool that retrieves detailed information. It doesn't explain what 'detail' includes, potential response formats, error cases, or authentication requirements. For a read operation with no structured output documentation, more context is needed to guide effective usage.

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

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

The schema description coverage is 100%, with the 'id' parameter documented as a UUID for the webhook subscription ID. The description adds minimal value beyond this, as it only implies the parameter's purpose without providing additional context like format examples or constraints. With high schema coverage, the baseline score of 3 is appropriate.

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

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

The description clearly states the verb ('Get') and resource ('webhook subscription detail'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'lexq_webhook_subscriptions_list' or 'lexq_webhook_subscriptions_get' (if there were multiple get variants), though the ID parameter implies it's for retrieving a single subscription by identifier.

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

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

The description provides no guidance on when to use this tool versus alternatives, such as 'lexq_webhook_subscriptions_list' for listing multiple subscriptions or 'lexq_webhook_subscriptions_save' for creating/updating. It lacks context about prerequisites, like needing a valid subscription ID, or exclusions, such as not being suitable for bulk operations.

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 mentions what the subscriptions receive but doesn't disclose behavioral traits like pagination behavior (implied by parameters but not stated), rate limits, authentication requirements, whether it's read-only, or what the output format looks like. The description adds minimal context beyond the basic purpose.

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

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

The description is two concise sentences with zero waste. The first sentence states the core purpose, and the second adds valuable context about what the subscriptions handle. Every word earns its place, and it's appropriately front-loaded.

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

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

Given no annotations and no output schema, the description is adequate for a simple list operation but has gaps. It explains what's being listed and the subscription purpose, but doesn't cover behavioral aspects like pagination, response format, or error conditions. For a tool with 2 parameters and no structured safety hints, it's minimally viable 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 description coverage is 100%, so the schema fully documents both parameters (page and size with defaults and constraints). The description adds no parameter-specific information beyond what's in the schema, meeting the baseline of 3 when schema does the heavy lifting.

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

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

The description clearly states the verb ('List') and resource ('platform event webhook subscriptions'), and specifies what these subscriptions receive ('deployment lifecycle notifications'). It doesn't explicitly differentiate from sibling webhook tools (delete, get, save, test), but the 'List' action is inherently distinct from those operations.

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

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when this listing operation is appropriate, what prerequisites might exist, or how it differs from other list operations in the sibling toolset (like lexq_groups_list or lexq_facts_list).

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