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 critical mutation semantics—whether cancellation is graceful or immediate, if it affects client state, or error conditions (e.g., attempting to cancel completed flows). Only notes that it returns 'Cancellation status', which is minimally informative given an output schema exists.

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

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

Uses structured docstring format (Args/Returns) that is easy to parse. The Args section is necessary and valuable given schema deficiencies. The Returns section is slightly redundant given has_output_schema=true, but remains brief and does not significantly detract from overall efficiency.

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: it covers the input parameters adequately and acknowledges the return value. However, given the lack of annotations and output schema details, it omits important context about side effects, idempotency, and the distinction between synchronous cancellation requests versus asynchronous termination confirmation.

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?

Excellent compensation for 0% schema description coverage: the Args section provides concrete examples for both parameters ('C.1234567890abcdef' for client_id, 'F.1234567890' for flow_id) that clarify expected formats and prefixes, adding significant meaning beyond the bare string types in the schema.

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

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

The description clearly states the action ('Cancel') and target ('running collection flow'), providing sufficient specificity to distinguish from sibling tools like get_flow_status or list_flows. The adjective 'running' effectively scopes the intended state of the target resource.

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

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

No explicit guidance is provided on when to use this tool versus alternatives, or preconditions for use (e.g., 'only cancel stuck flows' or 'prefer waiting for completion'). The description implies usage through the 'running' qualifier but lacks explicit when/when-not instructions.

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 return value ('List of enrolled clients and their status'), but fails to explicitly state this is a read-only operation, lacks error handling details (e.g., behavior if deployment_id doesn't exist), and omits any performance or rate-limiting considerations.

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

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

Uses a structured Python-docstring format (Args/Returns) that efficiently organizes information. Front-loaded with the core purpose in the first sentence. No redundant text, though the 'Args:' and 'Returns:' labels consume space that could be narrative prose.

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 three-parameter read operation with an output schema (which excuses detailed return documentation). However, given zero annotations, the description should have explicitly confirmed the read-only nature and basic error conditions. Missing explanation of label filter logic (AND vs OR) keeps it from scoring higher.

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?

Excellent compensation for 0% schema description coverage. The Args section clearly documents all three parameters: 'deployment_id' (scope), 'client_search' (optional filter with target fields), and 'labels' (filtering mechanism). While terse, it provides essential semantic meaning entirely missing from the schema titles.

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

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

The description clearly states the tool verifies agent enrollment status using specific verbs ('Verify', 'Checks'). It effectively distinguishes from deployment-oriented siblings like 'deploy_agents_ssh' and 'destroy_deployment' by focusing on enrollment verification, though it doesn't explicitly differentiate from 'get_deployment_status' or 'validate_deployment'.

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 'get_deployment_status' or 'validate_deployment'. No prerequisites mentioned (e.g., requiring an existing deployment), and no exclusion criteria or failure modes described.

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. It successfully indicates the async nature ('Schedule,' 'Flow ID for tracking') and timeout behavior, but fails to mention safety characteristics (read-only vs. destructive), required permissions, error conditions, or resource impact on the target client.

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 docstring-style format with explicit 'Args:' and 'Returns:' sections creates clear information hierarchy. Every line provides value—either the core purpose, parameter details with examples, or return value specification. No redundant or filler text present.

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 zero schema coverage and no annotations, the description adequately covers all input parameters and the return value (Flow ID). However, it lacks operational context regarding error handling, cancellation behavior (relevant given cancel_flow sibling), or permission requirements that would be necessary for a complete safety profile.

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

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

Schema description coverage is 0%, requiring the description to compensate fully. It comprehensively documents all 5 parameters: client_id includes format examples ('C.1234567890abcdef'), artifacts explains expected content, parameters provides nested format specification, and both timeout/urgent explain semantics and defaults.

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

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

The description opens with 'Schedule artifact collection on a Velociraptor client,' providing a specific verb (Schedule), resource (artifact collection), and scope (single Velociraptor client). This clearly distinguishes it from siblings like create_hunt (mass deployment) and run_vql (ad-hoc queries).

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 explicit guidance on when to use this tool versus alternatives like create_hunt for multi-client collection, nor when to set urgent=True. It describes the mechanics but lacks 'when-to-use' versus 'when-not-to-use' guidance.

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

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

No annotations provided, but description carries weight well: discloses 'paused' safety default (True), timeout/expiration mechanics, and per-client execution model. Missing: permission requirements, failure behavior on partial client success, or whether hunt is resource-intensive.

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?

Efficient docstring structure: single-sentence purpose, bulleted Args with essential details only, minimal Returns line. 'Returns' section appropriately brief given output schema exists. No redundant text.

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

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

Comprehensive for a 9-parameter orchestration tool: covers filtering logic, safety defaults, and artifact parameterization. Minor gap: doesn't mention that hunts are asynchronous or reference sibling get_hunt_results for retrieving output, though this may be inferred.

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 0% schema description coverage, the Args block provides critical compensation: explains complex nested 'parameters' format with JSON example, lists valid 'os_filter' values, and documents defaults (timeout 600s, expires 24h). All 9 parameters semantically enriched beyond schema titles.

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

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

Opens with specific verb ('Create') and resource ('Velociraptor hunt'), explicitly scopes to 'multiple clients' which distinguishes it from siblings like collect_artifact (single client) and modify_hunt (updates existing). Clear operational domain.

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 guidance through 'multiple clients' phrasing and client filtering args (include_labels, os_filter), but does not explicitly name alternatives (e.g., 'use collect_artifact for single clients') or state prerequisites like requiring artifact pre-existence.

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

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

With no annotations provided, the description carries the full burden. It adds valuable behavioral context about the 'self-contained package' nature, the encryption option ('Encrypt collection output with a generated password'), and the offline capability. However, it lacks disclosure about whether this operation is destructive, idempotent, or requires specific server permissions/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 follows a clear docstring structure (summary, detailed explanation, Args, Returns) with zero wasted words. Information is front-loaded with the core purpose, and every sentence provides actionable information. The Args section efficiently maps parameters to semantics 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 5-parameter complexity and 0% schema coverage, the description successfully documents all inputs and summarizes the return value ('Path to generated collector package and usage instructions') despite the existence of an output schema. It could achieve a 5 by mentioning operational prerequisites (e.g., disk space requirements, execution privileges) given the forensic context and 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 description coverage is 0% (only titles present), but the Args section in the description comprehensively documents all 5 parameters. It provides specific examples (e.g., 'Windows.System.Pslist'), enumerated valid values for target_os ('windows', 'linux', 'macos'), and detailed options for artifact_set ('windows_triage', 'ransomware', etc.), fully compensating for the schema deficiency.

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

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

The description opens with a specific verb ('Create') and resource ('offline collection package'), immediately clarifying scope. The second sentence distinguishes this from online collection tools (siblings like collect_artifact) by emphasizing 'air-gapped systems' and 'without requiring network connectivity', providing clear functional differentiation.

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

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

The description strongly implies when to use the tool ('for air-gapped systems', 'without requiring network connectivity'), which provides clear contextual guidance. However, it does not explicitly name online alternatives (e.g., 'use collect_artifact when network connectivity is available') or state when NOT to use this specific tool.

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

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

With no annotations provided, the description carries the full burden. It adds valuable operational hints (key_path is 'preferred' over password, default port), but fails to disclose critical behavioral traits for a deployment tool: idempotency (can it be re-run?), failure modes (partial success behavior?), privilege requirements, or whether it overwrites existing agent installations.

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 structure is logical with a clear one-sentence purpose followed by 'Args' and 'Returns' sections. While the Args list is lengthy, it is necessary given the schema's lack of descriptions. The 'Returns' line is appropriately brief since an output schema exists to detail the structure.

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

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

For a mutative deployment tool with 8 parameters and zero annotations, the description covers parameter semantics adequately but leaves significant gaps in operational safety and prerequisites. The presence of an output schema reduces the need for return value documentation, but guidance on rollback, idempotency, or agent versioning is absent.

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?

Given 0% schema description coverage, the description compensates effectively by documenting all 8 parameters with semantic meaning (e.g., 'deployment_id' connects agents to a deployment, 'targets' accepts hostnames or IPs). It adds constraints ('linux' or 'macos') and preference indicators ('preferred') that the schema lacks.

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 ('Push'), resource ('Velociraptor agents'), target platforms ('Linux/macOS'), and method ('SSH'). It effectively distinguishes itself from the sibling tool 'deploy_agents_winrm' through OS scope and protocol specificity.

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 explicit guidance on when to use this tool versus 'deploy_agents_winrm' or other deployment methods, nor does it mention prerequisites like SSH connectivity requirements, firewall rules, or privilege escalation needs (e.g., sudo).

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 connection behavior (HTTPS default, port 5986) but fails to mention that this is a destructive/write operation requiring administrative privileges on targets, or what happens if agents already exist.

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

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

The docstring format (one-line summary, Args, Returns) efficiently organizes information with the most critical detail (WinRM method) front-loaded. The Args list is necessary given the lack of schema descriptions.

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

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

The description adequately covers parameter semantics and basic return type, but given the complexity of remote agent deployment, it is incomplete regarding error handling, credential security warnings, and prerequisite conditions (e.g., WinRM service enabled on targets).

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 0% schema description coverage, the Args section fully compensates by documenting all 7 parameters with semantic meaning, including critical format hints for username (DOMAIN\user or user@domain) and default values for use_ssl and port that are not explicit in 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 opens with a specific action ('Push'), resource ('Velociraptor agents'), target platform ('Windows systems'), and method ('via WinRM'), clearly distinguishing it from the sibling tool deploy_agents_ssh.

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 WinRM/Windows specificity implicitly guides selection, the description lacks explicit guidance on when to use this versus deploy_agents_ssh, and omits prerequisites like required target configuration or administrative privileges.

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 critical behaviors: the 'rapid' profile auto-destroys in 72 hours, admin credentials are shown only once, and return values include sensitive deployment details. Missing operational details like idempotency or required permissions prevent a 5.

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 docstring-style structure (Args/Returns) is appropriate and front-loaded with purpose. Content is information-dense without fluff, though the repetitive 'X: description' format for 8 parameters is necessary but slightly verbose.

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 complex 8-parameter deployment tool with zero schema coverage, the description comprehensively documents inputs, outputs, and critical runtime behaviors (auto-destruction, credential handling). Minor gap regarding sibling tool relationships is the only omission.

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?

Given 0% schema description coverage, the Args section fully compensates by documenting all 8 parameters: valid enum values for deployment_type (docker, binary, aws, azure) and profile (rapid, standard, enterprise), default ports, conditional requirements for SSH parameters, and the hostname's role in certificate generation.

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 deploys a Velociraptor server for incident response with specific verb and resource. However, it does not differentiate from sibling tools 'deploy_server_cloud' and 'deploy_server_docker', which appear to be specialized 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 Args section provides parameter-level guidance (e.g., target_host required for binary type, rapid profile auto-destroys), but lacks explicit guidance on when to choose this unified tool versus specialized sibling deployment 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 discloses implementation mechanism (CloudFormation/ARM templates) and return value structure ('cloud resource IDs and URLs'), but omits critical behavioral traits for a deployment tool: permission requirements, cost implications, idempotency guarantees, and timeout behavior.

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

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

The description is optimally structured with a clear one-sentence purpose statement, implementation detail, and structured Args/Returns sections. Every sentence earns its place; there is no redundant or verbose text while maintaining completeness.

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

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

The description adequately covers all 5 parameters and acknowledges return values (complemented by the presence of an output schema). However, for a cloud deployment operation of this complexity, it lacks prerequisite context such as required IAM permissions, credential configuration, or potential cost implications, preventing a perfect score.

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?

Given 0% schema description coverage, the Args section provides comprehensive compensation by documenting all 5 parameters: valid enum values for 'cloud_provider' ('aws' or 'azure') and 'profile' ('standard' or 'enterprise'), plus default behaviors for 'region', 'instance_type', and 'server_hostname'. This fully bridges the schema gap.

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

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

The description opens with a specific action ('Deploy') and resource ('Velociraptor server') scoped to 'cloud infrastructure'. It further distinguishes from siblings like 'deploy_server_docker' and 'deploy_server' by specifying the implementation technologies: 'CloudFormation (AWS) or ARM templates (Azure)', making the deployment target unambiguous.

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

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

While the description implies cloud-specific usage through the mention of AWS/Azure technologies and the 'cloud_provider' argument, it lacks explicit guidance on when to choose this over sibling tools like 'deploy_server_docker' or 'deploy_server'. The Args section provides implicit context but no explicit 'when to use' directives.

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 timing ('operational within 2-5 minutes') and return values ('URLs and one-time admin password'). However, it omits safety details like idempotency, failure modes, whether existing deployments are overwritten, or cleanup 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?

Well-structured with clear sections: purpose statement, timing estimate, Args block with param details, and Returns block. No redundant or filler text; every sentence adds specific operational 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?

Given the complexity of server deployment and presence of output schema, the description adequately covers operational parameters and return values. Minor gap: lacks mention of infrastructure prerequisites or reference to destroy_deployment for cleanup.

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 0% description coverage (only titles). The description fully compensates by documenting all 6 parameters with semantics, including enum values for 'profile' ('rapid', 'standard', 'enterprise') and default value indicators, exceeding 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 states specific action ('Deploy Velociraptor server'), method ('using Docker'), and differentiates from siblings ('fastest method'). The incident response context further clarifies the operational intent.

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 ('Optimized for rapid incident response', 'fastest method') suggesting when to choose this over alternatives. However, it does not explicitly name sibling tools like deploy_server or deploy_server_cloud as alternatives, nor does it state prerequisites (e.g., Docker installation required).

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 successfully discloses critical behavioral traits: irreversibility, total data loss, resource cleanup, and the confirmation mechanism (confirm=True required). It also notes the return value contains 'Destruction status and cleanup details.' Could mention side effects on active hunts/flows.

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?

Excellent structure: one-sentence purpose statement, prominent safety warning (appropriate for destructive tool), Args section documenting parameters, and Returns section. Every element earns its place; no fluff. Critical irreversibility warning is front-loaded.

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

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

Given the tool has 2 simple parameters (no nested objects), an output schema exists (reducing need for detailed return documentation), and the description compensates for missing annotations with safety warnings, the description is complete. Minor gap: could mention authentication/authorization requirements for such a dangerous 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?

The schema has 0% description coverage (only titles and types). The Args section compensates fully by documenting deployment_id as 'The deployment identifier to destroy' and confirm as 'Must be True to confirm destruction,' adding essential semantic meaning entirely absent from 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 opens with 'Destroy a Velociraptor deployment and clean up resources'—a specific verb (destroy) plus specific resource (Velociraptor deployment). It clearly distinguishes from sibling tools like deploy_server, list_deployments, or get_deployment_status by specifying this is a destructive cleanup 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 prominent WARNING about irreversibility and data loss provides implicit usage guidance (only use when permanent destruction is intended), but there is no explicit guidance on when to choose this over alternatives like validate_deployment or simply decommissioning resources, nor are prerequisites mentioned.

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

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

No annotations provided, so description carries full burden. It discloses what outputs are produced (documentation sections) and return type (Path), but omits critical behavioral traits: whether it overwrites existing files, disk space requirements, or if the operation is idempotent.

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?

Well-structured with clear sections (purpose, content list, args, returns). Uses bullet points for readability. No redundant text, though the docstring-style formatting (Args/Returns) is slightly unconventional for MCP descriptions.

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

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

Adequate for a 2-parameter tool with simple schema. The description covers inputs and return value (noting output schema exists). However, given this is a file-generating tool with no annotations, it lacks safety warnings or side effect disclosures that would make it 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 has 0% description coverage. The Args section compensates by describing deployment_id as 'The deployment to document' and output_path as 'Optional path for documentation files', providing basic semantic meaning. However, it lacks details on path format requirements or default behavior when output_path is null.

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 ('Generate') and resource ('deployment documentation'). Lists specific content sections (server access, agent guides, etc.) that distinguish it from sibling deployment tools like deploy_agents_ssh or generate_server_config which handle actual deployment rather than documentation.

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 vs alternatives. While the deployment_id parameter implies use after deployment exists, there is no mention of prerequisites, when to prefer this over manual documentation, or relationship to sibling tools like generate_server_config.

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 that the output is a package with 'embedded configuration' that requires no additional configuration to deploy, and that it returns a path and instructions. However, it omits critical behavioral details: whether the operation is idempotent, if it overwrites existing files, execution duration expectations, or required permissions for the generated installers.

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?

Well-structured with clear sections: summary, behavioral detail, Args, and Returns. The opening sentences are slightly redundant ('Generate...' followed by 'Creates...') but the second adds valuable context about platform-specificity and zero-config deployment. The Args section is efficiently formatted with inline value constraints.

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 output schema exists, the brief Returns summary is adequate. The 4 parameters are well-documented in the description text. However, for a tool involving artifact generation and deployment preparation, the description should mention prerequisites (deployment must exist) and storage implications. The lack of differentiation from direct deployment siblings leaves contextual gaps.

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

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

Excellent compensation for 0% schema coverage. The Args section documents all 4 parameters comprehensively: deployment_id's purpose, os_type's valid values ('windows', 'linux', 'macos'), installer_type's options ('msi', 'deb', 'rpm', 'pkg') with auto-selection logic, and labels' function. This provides complete semantic meaning missing from 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 it generates 'an agent installer package with embedded configuration' and creates 'platform-specific installers.' It specifies the resource (agent installer) and action (generate/create). However, it could better differentiate from sibling tools like deploy_agents_ssh or deploy_agents_winrm by explicitly stating this produces offline-installable packages rather than performing direct deployment.

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 lacks explicit guidance on when to use this tool versus direct deployment alternatives (ssh/winrm). It mentions the package 'can be deployed without additional configuration' but does not state prerequisites (e.g., requiring an existing deployment_id) or scenarios where this approach is preferred over other deployment methods in the sibling 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions that the tool 'Creates' a role and returns a path to the generated directory, implying file system side effects. However, it omits critical details like whether it overwrites existing files, idempotency guarantees, or validation requirements for the deployment_id.

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 docstring format with distinct Args and Returns sections is well-structured and appropriate for the complexity. The text is front-loaded with the core purpose and efficiently organized without redundant prose, though the Args section repeats information implicit in parameter names.

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 that an output schema exists, the description appropriately summarizes the return value (path and instructions) without exhaustive detail. However, for a tool that generates filesystem artifacts based on a deployment_id, it lacks operational context such as error conditions, required pre-existing state, or platform-specific behavioral differences.

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

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

The schema has 0% description coverage, so the description compensates by providing an Args section that documents all 5 parameters with basic semantics (e.g., 'Include Windows deployment tasks'). While the descriptions are concise rather than comprehensive, they successfully convey the purpose of each parameter where the schema fails to do so.

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 generates an Ansible playbook for agent deployment and creates a complete Ansible role. It specifies the resource type (Ansible playbook/role) which distinguishes it from siblings like generate_agent_installer or deploy_agents_ssh, though it could more explicitly clarify the IaC vs. direct deployment distinction.

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

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

The description lacks explicit guidance on when to use this tool versus alternatives like deploy_agents_ssh, deploy_agents_winrm, or generate_agent_installer. It does not mention prerequisites (e.g., whether the deployment_id must exist beforehand) or when Ansible automation is preferred over direct deployment methods.

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 and successfully discloses key behavioral traits: the credentials are certificate-based, returned in 'Velociraptor config file format,' and critically, 'can only be displayed once.' Missing minor details like whether this invalidates previous credentials or required permissions, but covers the essential safety-critical 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?

Uses a clean docstring structure with distinct Args and Returns sections. Every sentence earns its place: the intro establishes purpose, the Args clarify inputs, the Returns specify output format, and the final warning prevents data loss. No redundant or filler text.

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

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

Given this is a credential generation tool with 3 parameters and an output schema, the description is complete. It explains what is created (API credentials/certificate), the output format (Velociraptor config file), the critical one-time constraint, and documents all parameters. No significant gaps remain for safe and correct 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?

Completely compensates for the 0% schema description coverage by documenting all three parameters in the Args section: deployment_id ('The deployment to generate credentials for'), client_name ('Name for the API client'), and validity_days ('Certificate validity in days'). The descriptions are clear and sufficient for proper invocation.

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 ('Generate API client credentials' / 'Creates a new API client certificate') and the exact resource/target ('for connecting this MCP server to a Velociraptor deployment'). It effectively distinguishes from siblings like generate_agent_installer, generate_server_config, and generate_ansible_playbook by specifying this is for MCP API connection 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 critical usage guidance with 'IMPORTANT: Save these credentials - they can only be displayed once,' warning users about the one-time nature of the output. While it doesn't explicitly compare against sibling alternatives, the specific naming and purpose make the differentiation clear, and the warning constitutes essential usage context.

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

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

With no annotations provided, the description carries the full burden. It discloses that the tool creates files (MSI, configuration files, documentation) and returns a path, but omits critical behavioral details such as side effects (where files are written), idempotency, failure modes, or whether the deployment_id must exist beforehand.

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 docstring format with Args/Returns sections provides logical structure. The opening sentence is specific and actionable. Minor redundancy exists between the opening paragraph and the Args/Returns sections, but overall information density is appropriate without excessive 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?

For a tool with an existing output schema (per context signals), the description appropriately summarizes the return value (path and instructions) without over-specifying. However, it lacks mention of prerequisites (e.g., deployment validation requirements) or execution context that would help an agent handle errors.

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?

Given 0% schema description coverage, the Args section effectively compensates by explaining all three parameters: deployment_id (target deployment), domain_controller (for share paths), and labels (for agents). While functional, descriptions are minimal and could elaborate on formats or valid values.

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 (Generate) and target resource (GPO deployment bundle) with scope (Windows domain environments). It effectively distinguishes from sibling tools like deploy_agents_ssh or generate_ansible_playbook by explicitly mentioning GPO/Windows domain specificity.

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 usage through GPO-specific terminology (MSI installer, domain controller), it lacks explicit when-to-use guidance comparing this to alternative deployment methods (e.g., WinRM, SSH, Ansible) available in the sibling tools. No prerequisites or exclusions 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 the full burden. It mentions the return value ('Server configuration content') but fails to disclose behavioral traits like whether this is a read-only operation, if it accesses remote state, potential 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?

Uses a structured docstring format (Args/Returns) that is appropriately sized and front-loaded. No redundant sentences, though the Args section duplicates information missing from the schema due to zero coverage, which is necessary but not ideal.

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?

Adequately covers the two parameters and acknowledges the return value, which is sufficient given the presence of an output schema. However, lacks behavioral context and usage guidance that would be necessary for a tool interacting with deployment infrastructure, especially with no annotations provided.

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 0% schema description coverage, the description effectively compensates by documenting both parameters: deployment_id is explained as 'The deployment to generate config for' and output_format specifies valid values ('yaml' or 'json'). Could be improved by noting output_format is optional with a default value.

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 specific action (Generate) and resource (Velociraptor server configuration file) clearly. While the name helps distinguish from sibling 'generate' tools (agent_installer, ansible_playbook), the description itself does not explicitly differentiate use cases from deployment tools like deploy_server.

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 deploy_server or generate_agent_installer. Does not mention prerequisites such as requiring an existing deployment_id or how the generated config relates to deployment workflows.

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 describes the output structure ('parameters, sources, and VQL'), but omits operational details like read-only safety, caching behavior, or error cases (e.g., artifact not found).

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

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

Uses efficient docstring format (Args/Returns) with zero wasted words. Three sentences cover purpose, parameter format, and return value structure. Front-loaded with the core action immediately stated.

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 single-parameter retrieval tool with output schema. The description explains what the return value contains (parameters, sources, VQL), compensating for unseen output schema details. Could benefit from mentioning read-only nature, but adequate for 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 0% description coverage. The description compensates effectively with a concrete example ('Windows.System.Pslist') that clarifies the dot-notation naming convention expected for artifact_name, adding essential semantic context missing from 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?

Clear specific verb ('Get') with specific resource ('full definition of a Velociraptor artifact'). Distinguishes from sibling 'collect_artifact' (which executes artifacts) and 'list_artifacts' (which lists names only) by emphasizing 'definition' 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 explicit guidance on when to use this tool versus alternatives like 'list_artifacts' (to browse available artifacts) or 'collect_artifact' (to execute data collection). Lacks workflow context for the retrieval step.

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 nature of the return value ('Detailed client information including hardware, OS, IP addresses'), which is helpful context. However, it does not explicitly confirm this is a read-only/safe operation, mention error states, or disclose any latency/caching behavior expected for this lookup.

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 uses a clean docstring-style structure with 'Args:' and 'Returns:' sections. Every sentence earns its place: the first states purpose, the second documents the parameter with an example, and the third summarizes the return data. No extraneous text is present.

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 simple single-parameter lookup tool with an existing output schema (per context signals), the description is complete. It covers the tool's purpose, the single required input with an example, and summarizes the return data sufficiently without needing to replicate the full output schema 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?

With 0% schema description coverage, the description successfully compensates by documenting the 'client_id' parameter with a concrete example format ('C.1234567890abcdef'). This adds critical semantic meaning missing from the schema. It would achieve a 5 if it also explained where to obtain this ID or described the format constraints (e.g., that it starts with 'C.').

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 clearly identifies the resource ('detailed information about a specific Velociraptor client'). The word 'specific' effectively distinguishes this tool from the sibling 'list_clients' tool, indicating it retrieves data for one identified endpoint rather than enumerating many.

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 by requiring a 'client_id' argument, suggesting it should be used when a specific client identifier is already known. However, it does not explicitly state when to use this versus 'list_clients' (e.g., 'use after identifying a client ID from list_clients') or mention any prerequisites or exclusions.

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

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

No annotations provided, so description carries full burden. It mentions the return includes 'health checks and metrics' which adds context, but lacks explicit safety disclosure (read-only vs destructive), error handling behavior (e.g., deployment not found), or rate limiting details.

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

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

Well-structured with clear Args/Returns sections. Front-loaded with the core purpose. The Args section is necessary given 0% schema coverage. The Returns section is somewhat redundant given the output schema exists, but remains brief.

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

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

Adequate for a single-parameter read operation with an output schema (which handles return value documentation). However, gaps remain regarding error conditions and safety characteristics, which are unaddressed due to missing 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 description coverage is 0%, requiring the description to compensate. The Args section effectively documents the deployment_id parameter with a clear example format ('vr-20240115-a1b2c3d4'), explaining the expected identifier pattern that the schema omits.

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 'Check[s] the status and health of a deployment' with specific verbs and resource. It distinguishes from siblings like list_deployments (this retrieves a specific deployment by ID) and destroy_deployment (destructive action), though it could more explicitly differentiate from check_agent_deployment.

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

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

No explicit guidance on when to use this tool versus alternatives like validate_deployment or check_agent_deployment. No mention of prerequisites (e.g., obtaining deployment_id from list_deployments) or when not to use it.

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

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

With no annotations provided, the description carries the full burden but only minimally satisfies it. It states 'Returns: Collection results data' but lacks crucial behavioral details: whether the operation is read-only, what format the results take (JSON, CSV, rows), whether it blocks until completion, or pagination behavior beyond the limit parameter.

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 Args/Returns structure is clear and front-loaded. Each sentence earns its place by documenting parameters or return values. Minor deduction for the docstring-style formatting which consumes vertical space, though this is acceptable for the parameter detail provided.

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 presence of an output schema (not shown but indicated in context signals), the description appropriately avoids duplicating return value documentation. With four parameters and zero schema coverage, the description successfully documents all inputs. Minor gap: lacks guidance on flow state requirements or error handling scenarios.

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?

Excellent compensation for 0% schema description coverage. The description provides semantic meaning for all four parameters: client_id and flow_id include format examples (C.123..., F.123...), artifact explains it filters to a specific optional artifact, and limit clarifies it controls maximum result rows with the default value.

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

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

The description explicitly states 'Get results from a specific Velociraptor collection flow' with a clear verb (Get) and resource (results). It effectively distinguishes from siblings like get_flow_status (which checks status/metadata) and get_hunt_results (which retrieves hunt-level aggregates rather than individual flow data).

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 prerequisites such as needing a valid flow_id from list_flows, does not clarify whether to use get_flow_status first to check completion, and omits error conditions (e.g., querying incomplete flows).

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 return values ('state, progress, and any errors') but fails to mention if this is a safe read-only operation, if there are rate limits, or caching behavior. It adds minimal behavioral context beyond the return shape.

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 Args/Returns structure is clear and front-loaded. The purpose statement comes first, followed by parameter examples and return value description. No sentences are wasted, though the 'Returns' section is slightly redundant given the presence of an output schema.

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

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

For a 2-parameter read operation with an output schema, the description is minimally adequate. It covers the parameters via examples and hints at the return structure. However, given the complex sibling ecosystem (list_flows, get_flow_results, cancel_flow), it lacks contextual guidance on where this fits in the workflow.

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 0% schema description coverage (only titles present), the description compensates by providing concrete examples for both parameters (e.g., 'C.1234567890abcdef', 'F.1234567890'). This adds necessary semantic meaning that the bare schema lacks, though it does not explain the conceptual relationship between client_id and flow_id.

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 'Get[s] the status of a specific collection flow' with a specific verb and resource. However, it does not differentiate from the sibling tool 'get_flow_results' or explain what constitutes a 'collection flow' in this domain.

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

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

There is no guidance on when to use this tool versus alternatives like 'get_flow_results', 'list_flows', or 'cancel_flow'. It does not mention prerequisites (e.g., needing a flow_id from list_flows first) or when polling is appropriate.

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

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

With no annotations provided, the description carries the full burden. It adds valuable behavioral context by specifying results come 'from all clients', indicating scope. However, it lacks disclosure on safety (read-only vs destructive), permissions required, 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?

Uses a clean docstring format with distinct Args and Returns sections. Every sentence earns its place; the parameter descriptions are concise yet complete, and the initial purpose statement is immediately clear.

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 an output schema (per context signals), the brief return description is sufficient. With zero schema coverage, the description successfully documents all parameters. Minor gap: does not explicitly state this is a read-only operation given the lack of safety 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?

The schema has 0% description coverage, but the description excellently compensates by documenting all three parameters: hunt_id includes a format example ('H.1234567890'), artifact explains it filters to a specific artifact, and limit clarifies it controls result rows with the default value.

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

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

The description opens with the specific verb 'Get' and resource 'results from a Velociraptor hunt', clearly distinguishing it from siblings like create_hunt, list_hunts, and get_flow_results by specifying this retrieves hunt (not flow) results.

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 get_flow_results, nor does it mention prerequisites such as needing to create a hunt first. It only states what the tool does, not when to choose it.

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

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

No annotations are provided, so the description carries the full burden. It discloses that this is a mutation operation (add/remove) and documents the return value ('Updated client labels'), but lacks details on permissions required, idempotency, side effects of removal, or error behaviors.

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

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

The description is well-structured with front-loaded purpose followed by Args and Returns sections. While the Args section is verbose, this is necessary given the complete lack of schema documentation; every line provides essential parameter semantics.

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 mutation tool with no nested objects, the description is complete. It explains the operation, documents all inputs (compensating for empty schema), and describes the return value, covering all necessary context 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?

With 0% schema description coverage, the description fully compensates by documenting all three parameters in the Args section: client_id includes an example format ('C.1234567890abcdef'), labels explains the list semantics, and operation specifies allowed values and defaults.

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

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

The description opens with a clear, specific action: 'Add or remove labels from a Velociraptor client.' It identifies the specific resource (labels), the target (Velociraptor client), and the verbs (add/remove), clearly distinguishing it from sibling tools like get_client_info, quarantine_client, or list_clients.

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 'operation' parameter documentation ('add' or 'remove'), but provides no explicit guidance on when to use this tool versus alternatives, prerequisites (e.g., client must exist), or when not to use it.

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

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

With no annotations provided, the description carries the full burden. It discloses the return structure ('List of artifacts with their names, descriptions, and types'), but lacks critical operational context such as whether the operation is read-only, if there are rate limits, or how pagination works beyond the 'limit' parameter.

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 Args/Returns structure is clear and appropriately front-loaded. The content is dense with no wasted sentences, though the structured format slightly increases length, it improves scannability for the agent.

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

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

Given the tool has 3 optional parameters and an output schema exists (mentioned in the description), the provided information is sufficient. The description adequately covers filtering capabilities and return value shape without needing to duplicate the full 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?

The input schema has 0% description coverage (only titles), but the description effectively compensates by documenting all three parameters: 'search' filters by name/description, 'artifact_type' accepts specific enum values ('CLIENT', 'SERVER', or 'NOTEBOOK'), and 'limit' has a documented default of 100.

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

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

The description clearly states the tool 'List[s] available Velociraptor artifacts' with a specific verb and resource. However, it does not explicitly distinguish this listing tool from the sibling 'get_artifact' (which retrieves a single artifact) or 'collect_artifact' (which executes an artifact).

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 'get_artifact' for fetching specific artifact definitions or when to prefer filtering via 'search' versus retrieving all artifacts. No prerequisites or exclusions 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 successfully discloses the read-only nature via 'Search and list' and details the return format (ID, hostname, OS, etc.), but omits safety confirmations, pagination behavior beyond the limit parameter, or rate limiting details.

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

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

The Args/Returns structure is efficient and front-loaded. Every sentence earns its place: the opening declares purpose, the Args section details parameter semantics with examples, and the Returns section clarifies output content 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 tool's simplicity (2 optional parameters, no nesting) and existence of an output schema, the description is nearly complete. It could be improved by explicitly contrasting with 'get_client_info' to guide agent selection among the 30+ siblings, but adequately covers the core functionality.

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

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

The schema has 0% description coverage (titles only), but the description fully compensates by documenting both parameters: it explains the search syntax with specific prefix examples (label:, host:) and clarifies the limit default (100). This adds crucial semantic meaning absent from the structured 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 opens with a clear, specific verb ('Search and list') followed by the resource ('Velociraptor clients/endpoints'). It effectively distinguishes from the sibling 'get_client_info' by emphasizing the plural listing/search capability vs. single-item 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?

While the description provides helpful search syntax examples (label:, host:), it lacks explicit guidance on when to use this versus 'get_client_info' or other client-related tools. The examples imply usage patterns but do not explicitly state selection criteria or prerequisites.

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

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

With no annotations provided, the description carries the full burden. It discloses that destroyed deployments are excluded by default (via the 'include_destroyed' parameter description) and mentions return values include 'current status'. However, it lacks information about read-only safety, pagination behavior, or rate limits.

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

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

The description uses a clean Args/Returns structure that efficiently organizes information. It is appropriately sized at three sentences plus parameter specifications, with the purpose statement front-loaded and no redundant filler text.

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

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

Given the tool has only 2 optional parameters and an output schema exists (per context signals), the description adequately covers inputs and provides a high-level summary of returns. However, it lacks guidance on filtering behavior and doesn't mention if results are paginated or how to handle large deployment lists.

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% description coverage, but the description excellently compensates by documenting both parameters. It specifies that 'profile_filter' accepts specific values ('rapid', 'standard', 'enterprise') not present in the schema's anyOf definition, and clarifies 'include_destroyed' is a boolean toggle for destroyed deployment visibility.

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 'List[s] all managed Velociraptor deployments' with a specific verb and resource. However, it does not explicitly distinguish from sibling tool 'get_deployment_status' (which retrieves a specific deployment's status rather than listing all).

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 'get_deployment_status' or 'validate_deployment'. There are no prerequisites, conditions, or exclusion criteria 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 must carry the full behavioral burden. It discloses return value structure ('List of flows with their status and artifacts'), but fails to mention safety characteristics (read-only vs destructive), pagination behavior beyond the limit parameter, or permission requirements.

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

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

The Args/Returns structure is efficient and scannable. Every sentence earns its place by documenting parameters or return values. The format is slightly docstring-technical rather than conversational, but remains appropriately sized and front-loaded.

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

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

For a simple 2-parameter list operation with no nested objects, the description is adequate. It hints at output structure (status and artifacts) compensating for the lack of a formal output schema, and covers all input parameters sufficiently 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?

Given 0% schema description coverage, the description effectively compensates by providing a concrete example format for 'client_id' ('C.1234567890abcdef') and explaining the 'limit' parameter's default value of 50. Both parameters are semantically documented beyond the raw schema types.

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 verb 'List' and resource 'collection flows' for a 'Velociraptor client'. It effectively distinguishes from siblings like 'cancel_flow' (action on single flow), 'get_flow_results' (specific flow data retrieval), and 'list_clients' (different resource entirely).

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 'get_flow_status' or 'get_flow_results', or when to prefer it over 'cancel_flow'. There are no stated prerequisites, exclusions, or workflow context for the agent.

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

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

With no annotations provided, the description carries full burden. It discloses the return type ('List of hunts with their status and statistics') and pagination behavior (default limit 50), but omits safety profile (read-only vs destructive), permission requirements, or detailed error behaviors.

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?

Uses structured docstring format (Args/Returns) that is appropriately sized for a 2-parameter tool. Information is front-loaded with the one-sentence purpose statement followed by parameter details. Slightly mechanical but efficient.

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

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

Given the simple schema (2 primitives, no nesting) and existence of output schema, the description provides adequate coverage. The Args section compensates for schema deficiencies, and the Returns section provides sufficient high-level context without needing to replicate the full output schema 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?

Excellent compensation for 0% schema description coverage. The Args section documents both parameters clearly: 'state' includes specific enum values ('RUNNING', 'PAUSED', 'STOPPED', 'COMPLETED') not present in the schema, and 'limit' explains the default of 50.

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 'List Velociraptor hunts' with specific verb and resource. Distinguishes from sibling tools like 'create_hunt' (mutation) and 'get_hunt_results' (specific retrieval) by indicating bulk listing behavior, though could explicitly mention the distinction from fetching individual hunt results.

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 'get_hunt_results' or 'get_flow_results'. The Args section explains how to filter but not why to choose this tool over other hunt-related operations in the sibling 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?

With no annotations provided, the description carries the full burden. It documents the return value ('Updated hunt status') and valid action values, but omits safety-critical behavioral details like reversibility of actions, permission requirements, or side effects of 'archive' vs 'stop' operations.

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 uses a clean, structured format (purpose statement → Args → Returns) with zero wasted words. Every sentence earns its place; the example ID format and action enum are essential details delivered efficiently.

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

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

For a two-parameter state-change tool, the description is nearly complete: it documents all inputs, lists valid values, and mentions the return. It could be improved by noting error conditions (e.g., invalid state transitions) or permission requirements, but the existence of an output schema reduces the need for detailed return documentation.

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 0% schema description coverage, the Args section fully compensates by providing concrete semantics: hunt_id includes a format example ('H.1234567890') and action enumerates the four valid string values, effectively documenting both required parameters.

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

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

The description opens with the specific verb 'Modify' and resource 'Velociraptor hunt state', clearly distinguishing it from siblings like 'create_hunt' (creation), 'list_hunts' (listing), and 'get_hunt_results' (retrieval).

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

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

The description enumerates valid actions ('start', 'pause', 'stop', 'archive'), providing implied usage context for hunt lifecycle management. However, it lacks explicit guidance on when to use this versus alternatives (e.g., 'use create_hunt for new hunts') or prerequisites (e.g., hunt must exist).

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

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

With no annotations provided, the description carries the full burden and successfully discloses key behavioral traits: network isolation mechanics, reversibility (supports unquarantine), and the ability to attach messages. Missing safety/permission details prevents a 5.

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 docstring format with Args/Returns sections is slightly verbose but highly readable. Information is front-loaded with the action summary and effect explanation before parameter details, with no wasted sentences.

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

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

For a 3-parameter tool with an output schema present, the description is complete: it covers functionality, behavioral effects, all parameters with examples, and acknowledges the return value without redundant elaboration.

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 0% schema description coverage, the Args section comprehensively documents all three parameters: client_id includes a concrete example format, quarantine explains the boolean logic and default value, and message clarifies its optional nature and purpose.

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

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

The description opens with a specific verb pair ('Quarantine or unquarantine') and clear resource ('Velociraptor client'), immediately distinguishing it from sibling tools like label_client or get_client_info which handle different client 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 explains what quarantining does ('isolates it from the network while maintaining communication with the Velociraptor server'), which implies usage context, but lacks explicit when-to-use guidance or contrasts with alternatives like label_client.

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

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

No annotations provided, so description carries full burden. It discloses the critical side effect (re-enrollment required for CA rotation) and return value contents (fingerprints and instructions). Minor gap: doesn't specify if operation is atomic, asynchronous, or causes service interruption.

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?

Uses structured docstring format (Args/Returns) which is slightly formal but necessary given zero schema descriptions. Front-loaded with the core action and WARNING. Every section serves a distinct purpose: purpose statement, critical warning, parameter docs, return value docs.

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-impact cryptographic operation with 3 parameters and no annotations, coverage is strong: explains the rotation process, warns about CA implications, documents all inputs, and describes return values (complementing the existing output schema). Minor gap: lacks explicit prerequisites (e.g., deployment must be active).

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 0% description coverage (only titles), but the description fully compensates by documenting all 3 parameters in the Args section: deployment_id target, rotate_ca boolean implication, and validity_days purpose. Adds crucial semantic context that rotate_ca 'requires re-enrollment'.

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 'Rotate' with resource 'certificates' and scope 'for a deployment'. The WARNING about CA certificate rotation distinguishes this from general deployment management tools in the sibling list (like deploy_server or validate_deployment).

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

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

Provides clear context through the WARNING about re-enrollment requirements when rotating CA certificates, which guides appropriate use. Lacks explicit comparison to specific alternatives (e.g., 'use generate_agent_installer for new agents instead'), but the warning effectively signals when to exercise caution.

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 safety context about 'env' parameter enabling safe dynamic value passing vs string interpolation, documents default max_rows limit (10000), notes JSON return format, and mentions multi-tenancy support. Missing explicit notes on query side effects or resource limits.

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

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

Well-structured with front-loaded purpose statement, VQL syntax explanation, bulleted common patterns, and Args/Returns sections. Slightly verbose but justified given complexity of query language tool and need to compensate for empty schema descriptions. No 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?

Comprehensive for a complex query execution tool. Covers language basics, practical examples, all parameters (compensating for schema gaps), and return format. Output schema exists, so minimal return value description is appropriate. Addresses multi-tenant and safety considerations.

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 0% description coverage (only titles), but description fully compensates by documenting all 4 parameters with clear semantics: query syntax, env safety purpose, max_rows default, and org_id multi-tenant behavior. The env explanation adds significant value beyond basic type info.

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 opens with specific verb 'Execute' and resource 'arbitrary VQL query', clearly distinguishing it from siblings like 'collect_artifact' (predefined artifacts) and 'vql_help' (documentation). The forensic analysis context further clarifies scope.

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

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

Provides common VQL patterns and examples that implicitly guide usage, but lacks explicit 'when to use this vs alternatives' guidance. Does not clarify when to prefer 'collect_artifact' over arbitrary VQL or vice versa.

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 and successfully lists four specific behavioral aspects (accessibility, certificate, service health, security checks). It notes the return value is a validation report. Missing only safety confirmation (read-only nature) which would be critical for a security 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?

Excellent structure with clear implicit sections (purpose, checks, args, returns). Front-loaded with the main action. No redundant words; the checklist format efficiently conveys validation scope without prose bloat.

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

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

Given the single parameter (adequately documented in description despite 0% schema coverage) and existence of output schema, the description appropriately focuses on operational behavior. The return value description is sufficient since detailed schema exists separately. Could improve by noting if validation is safe to run repeatedly.

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

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

Schema coverage is 0% (no description field in JSON schema), but the description compensates by providing semantic meaning: 'deployment_id: The deployment to validate'. This clarifies the parameter's purpose beyond the schema's decorative title 'Deployment Id'.

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 runs 'comprehensive security and health validation' with specific checks listed (server accessibility, certificate validity, service health, security configuration). It effectively distinguishes from siblings like check_agent_deployment (agent-specific) and get_deployment_status (status retrieval) by emphasizing the comprehensive validation scope.

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

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

While the description implies usage through the term 'comprehensive' and the detailed checklist, it lacks explicit guidance on when to use this versus check_agent_deployment or get_deployment_status. No prerequisites or exclusions 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 discloses that the tool returns 'Help text for the requested topic,' but omits behavioral details like whether results are cached, idempotent, or if there are rate limits on help requests. It does clarify that omitting the topic parameter is valid (returns general help).

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 uses a clear structured format with 'Args:' and 'Returns:' sections. The bulleted list of topic options is efficiently presented. The opening sentence immediately establishes purpose without redundancy, though the 'Returns' statement is somewhat tautological given the context signals indicate an output schema exists.

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 simple single-parameter help tool with an output schema present, the description provides adequate coverage. It documents the parameter behavior sufficiently given the schema lacks descriptions, and does not need to elaborate on return values since the output schema handles that. It appropriately covers the tool's limited scope.

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

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

The schema has 0% description coverage (just 'type': 'string' or null). The description compensates effectively by enumerating the four valid topic values ('syntax', 'plugins', 'functions', 'examples') with brief explanations for each, adding critical semantic information absent from the structured 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 'Get help on VQL (Velociraptor Query Language)' using a specific verb and resource. Among siblings like run_vql (which executes queries), this distinguishes itself as a documentation/help tool rather than an operational command, though it doesn't explicitly contrast itself with run_vql.

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 implied usage context by listing specific topic options (syntax, plugins, functions, examples), but lacks explicit guidance on when to use this versus reading artifact documentation directly or when not to use it (e.g., for actual data collection).

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