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

No annotations are provided, so the description carries the burden. It discloses what is actually checked—provider keys, snapshot directory, and disk—and the verb 'Checks' implies a non-mutating inspection. It does not explicitly state side-effect-free behavior, but nothing in the description suggests modification.

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

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

One short sentence communicates the verb, target, and specific scope without any filler. The parenthetical list of checks is compact and informative, making the description easy to scan and parse.

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

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

For a parameterless health-check tool with an output schema, this description is complete: it names the exact environmental areas inspected and implies the tool's role. No additional context is needed for an agent to select or invoke it correctly.

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

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

The tool has zero parameters, so there are no parameter semantics to clarify. The schema is empty and fully covers the input surface, so the description does not need to compensate for missing parameter documentation.

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

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

The description uses a specific verb ('Checks') and resource ('BoteX environment readiness'), then enumerates the exact components checked: provider keys, snapshot dir, and disk. This clearly distinguishes it from sibling tools that handle tasks, memory, URLs, or model recommendations.

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

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

The description gives clear context: this tool is for verifying whether the BoteX environment is properly set up. It does not explicitly state when not to use it or compare it to alternatives, but its health-check role makes the intended use obvious enough.

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

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

With no annotations provided, the description carries the full burden. It indicates this is a destructive operation ('purges') but doesn't disclose whether snapshots are permanently deleted, if there's any recovery mechanism, required permissions, or whether there are safeguards. It lacks details on the impact on the system (e.g., could it delete snapshots in use?).

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

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

The description is a single, concise sentence with no waste. It front-loads the verb and resource. It is appropriately sized for a simple tool, though it could be slightly more descriptive without losing conciseness.

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 this is a destructive maintenance tool with two parameters that control deletion criteria, and no annotations to clarify safety, the description lacks critical information about the deletion behavior, parameter interaction, and any safeguards. The output schema exists but is not shown; if it explains the outcome, that helps, but the description alone does not fully equip an agent to call this safely and correctly.

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

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

Schema description coverage is 0%, so the description must compensate. However, the description doesn't explain that max_age_days and max_total_mb are criteria for deletion. It only says 'old or excess' which loosely maps to age and size, but does not clarify how the parameters interact (e.g., are they both applied, or either/or?) or their units. The parameter names and defaults are self-explanatory, so a baseline of 3 is appropriate, but more explicit linkage would improve it.

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

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

The description states the action ('purges') and the resource ('backup snapshots'), and clarifies it removes 'old or excess' ones. However, it doesn't specify the exact criteria for what counts as 'old' or 'excess' beyond the parameters, and doesn't differentiate from any sibling tools (none appear directly related, but the description could be more precise about the scope).

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

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

The description gives no guidance on when to use this tool versus alternatives. It doesn't mention any prerequisites, conditions for invocation, or when to avoid using it. The agent is left to infer that it's for maintenance tasks, but there's no explicit context on when this should be called.

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

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

With no annotations, the description carries the full behavioral burdenmax and does a solid job: it discloses SSRF protections, redirect revalidation, content-type checks, byte limits, and secret masking. It stops short of describing exact outcomes on failure or blocked content, but the major safety behaviors are transparent.

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

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

The description is three sentences with no filler. The first sentence states the core operation, the second explains the separation from read_urlholistic, and the third lists safety constraints plus the allowlist exception. Every sentence earns its place.

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

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

The description covers purpose, safety behaviors, configuration implications, and policy restrictions, which is strong for a fetch tool. It is slightly incomplete because max_bytes is never explained in relation to the parameter, and expected failure modes are only implied. Still, the overall context is sufficient for most correct calls.

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%, so the description should compensate for the undocumented parameters. It mentions byte limits in general but never maps that to the max_bytes parameter or explains its default semantics. The URL parameter is only implicitly covered by 'public http(s)' in the purpose clause. This is a meaningful gap for a tool with only two 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 a specific verb and resource: 'Fetch one public http(s) text document for caller-side research.' It also explicitly distinguishes the tool from BoteX's internal read_url, explaining that the orchestrating agent chooses the URL. This makes the tool's role clear and differentiates it from related helpers.

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 names the alternative (read_url) and explains why fetch_url exists: arbitrary public hosts do not need to be configured in net.allowed_hosts. It also notes the allowlist policy restriction. It does not explicitly list exclusions or say 'use this when X, otherwise use Y,' but the context is clear enough for an agent to decide.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly states that only a skeleton is returned, the whole file is not read, and token savings are significant. This is strong transparency for a read-style outline operation.

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

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

The description is two sentences with no filler. The first sentence front-loads the core purpose and deliverable, and the second adds a concrete efficiency benefit. Every part earns its place.

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

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

The tool itself is simple and the output schema likely covers return values, so the description does not need to explain returns. However, the complete lack of parameter documentation, especially workspace_dir, means the agent may still guess about path resolution. The description is adequate for purpose but not fully complete for invocation.

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

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

Schema description coverage is 0%, so the description must compensate. It implies that 'path' refers to a file, but it does not explain the meaning or relationship of 'workspace_dir', nor how paths are resolved. The parameter semantics remain largely undocumented.

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

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

The description states exactly what the tool does: it returns a lightweight file skeleton and enumerates the included elements (classes, methods, functions, headers, line numbers). This makes the tool's purpose specific and clearly differentiates it from sibling tools like fetch_url or read_memory.

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

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

The phrase 'without reading the whole file' gives a clear use case: choose this tool when you need an overview or structure and want to save tokens. It does not explicitly name alternatives or when-not-to-use cases, but the intended context is strongly implied.

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?

There are no annotations, so the description carries the behavioral disclosure burden. It reveals the aggregation dimensions and valid period values, but it does not explicitly state that the operation is read-only, has no side effects, or how the data is scoped beyond the period. This is adequate but not rich.

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

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

The description is two sentences, front-loads the core purpose, and then provides the parameter guidance needed. No filler or redundant 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?

With one optional parameter, no nested objects, and an output schema present, the description covers everything needed to call the tool correctly. The period choices are documented, and return-value details are presumably covered by the output schema.

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

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

Schema description coverage is 0%, and the description fully compensates by explaining the only parameter, period, with its allowed values and their exact meanings. This adds substantial value over the bare schema type and default.

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

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

The description names a specific verb ('Returns'), a resource ('executed BoteX tasks'), and concrete metrics (USD costs, token usage, code-line balance). It clearly differentiates this analytics tool from sibling tools like get_task_status or check_health by stating its summary scope.

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

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

The description gives clear context for when to use the tool: when an analytics summary over a period is needed. It does not explicitly contrast with alternatives or state when not to use it, so it stops short of a 5.

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

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

With no annotations provided, the description carries the full behavioral burden. It explains the task lifecycle values, clarifies the subtle meaning of DONE as 'finished' rather than 'succeeded', and details the contents of result_data. This is strong transparency beyond the bare return-type information.

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

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

The description is compact and well-structured. It leads with the primary purpose, then uses a concise bullet-like list to explain status and result fields. Every sentence adds useful information without redundancy.

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

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

For a status-retrieval tool with one parameter and an output schema, the description is complete. It covers the lifecycle semantics, the distinction between textual and structured results, and key result_data fields, so an agent has everything needed to interpret the response correctly.

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

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

The schema provides only task_id with no description, so the description must compensate. It does so by linking task_id to a task started with start_task, giving the parameter practical meaning. It could explicitly describe task_id format or source, but for a single parameter this is sufficient.

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

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

The description states a specific verb and resource: 'Return status and result for a task started with start_task.' It clearly distinguishes the tool from the sibling start_task by focusing on retrieval of task outcomes, and it enumerates the exact fields returned.

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

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

The description gives a clear context for use: it is for tasks previously started with start_task. It does not explicitly name alternative tools or exclusion cases, but the association with start_task makes the intended usage unambiguous.

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

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

With no annotations, the description carries the behavioral disclosure burden. The verb 'Reads' makes it clear this is a non-mutating operation, and 'full content and metadata' sets expectations for what is returned. It does not mention error behavior or edge cases, but for a simple read operation the main behavioral trait is adequately disclosed.

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

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

The description is compact and well-structured: a one-sentence purpose statement followed by a short Args list. Every sentence adds value, and the core action 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 two simple parameters, an output schema, and a read-only operation, the description is nearly complete. It explains what the tool does and what each parameter means. The only gap is the lack of explicit guidance on unknown IDs or alternative tool selection.

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 Args section adds real meaning beyond the input schema: memory_id is explained with an example, and workspace_dir is described as the workspace root with its default behavior. Since schema description coverage is 0%, this parameter documentation fully compensates.

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

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

The description states a clear verb ('Reads'), a specific resource ('memory entry from the workspace Memory Vault'), and the selection mechanism ('by ID'). It also says 'full content and metadata,' which distinguishes this from search_memory, which presumably finds entries without an ID.

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

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

The phrase 'specific memory entry by ID' clearly implies this tool should be used when the caller already knows the memory_id. It does not explicitly mention alternatives or state when not to use it, so it stops short of full guidance, but the context is clear and unambiguous.

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

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

With no annotations, the description carries the safety burden. It communicates a read-only external fetch from OpenRouter and that results depend on live benchmarks, which covers the main behavioral traits. It does not mention auth/rate-limit implications, but for a simple fetch the key traits are disclosed.

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 EN/PL sections are each two sentences and front-load the core action before the usage note. The duplication is minor and the labels keep it 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?

The tool has an output schema and only two optional parameters, so the main missing piece is parameter semantics. Purpose and usage are clear, but an agent cannot know what task_type values are valid or how limit affects results, leaving a real gap.

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

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

The schema has 0% description coverage and the description never explains `limit` or `task_type`, nor enumerates valid task types. The only indirect hint is the default `task_type: coding`, which is not enough to compensate.

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 and object: 'Fetches the most cost-effective and capable models from OpenRouter based on live benchmarks.' It also differentiates its role by pointing to run_subagent, making it clear this tool is a model-recommendation helper rather than a task runner.

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

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

It explicitly instructs agents to call this tool before run_subagent when uncertain about the model ID or when optimizing cost/quality. This states the condition and the alternative tool, which is sufficient guidance for selection.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure, and it does so thoroughly. It reveals snapshot rollback, pre-write syntax checks, zero-retention on OpenRouter, the non-sandbox nature of allow_exec, the output_path DONE contract, and that 'ok is true only when status == DONE.' This is far beyond minimal disclosure.

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

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

The description is long, but the tool is genuinely complex with 20 parameters and multiple safety-sensitive modes. The structure is efficient: a front-loaded TIP, a compact feature list, and a well-organized Args section. Every sentence adds operational value rather than padding.

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

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

Given the tool's complexity, the description is complete: it covers model selection, mode semantics, safety authorizations, output contracts, verification behavior, and return-value semantics. The presence of an output schema reduces the need to explain return fields, yet the description still clarifies the critical ok/status relationship.

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%, so the description must compensate entirely, and it does. Every one of the 20 parameters is explained with defaults, interactions, and warnings—for example, mode's capability presets, budget_limit_usd's negative-value semantics, and net_allowed_urls' trailing-slash subtree rule. This is exemplary parameter documentation.

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

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

The description states a specific verb and resource: 'Runs BoteX — an autonomous code execution engine' that 'performs multi-step tasks on local files inside workspace_dir.' This clearly differentiates it from sibling tools like recommend_models, fetch_url, and start_task by establishing it as the main task-execution harness.

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

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

The description gives explicit guidance for a key decision: 'If the user didn't specify a model, DO NOT guess. Use the recommend_models tool first.' It also warns about headless pre-authorization and when to grant destructive/exec permissions. It does not explicitly contrast with start_task, but the context is clear enough for an agent to know when this tool is appropriate.

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

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

With no annotations provided, the description carries the full burden and adds meaningful behaviors: 'Masks secrets and provides directory isolation', plus persistence to a specific vault path. It does not disclose overwrite behavior or failure modes, but the disclosed traits are genuinely useful beyond the schema.

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

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

The description is compact: one purpose sentence plus a structured Args block with no filler. It front-loads the primary action and then provides parameter details in a scannable format.

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?

All six parameters are covered, required fields are clear, and the output schema handles return values. The description gives the agent everything needed to call the tool correctly and confidently.

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

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

Schema description coverage is 0%, and the Args section compensates fully by clearly documenting every parameter, including kind's allowed values, memory_id format, tags as a list, and workspace_dir default. This is essential for correct 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 opens with a specific verb and resource: 'Saves a persistent context note, architectural decision, task handoff, or lesson into the workspace Memory Vault'. This makes the write purpose unmistakable and clearly differentiates it from read/search siblings by emphasizing persistence and a target location.

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

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

The description gives clear context for when to use the tool: whenever a persistent note, decision, handoff, or lesson needs to be stored. It does not explicitly name alternatives or say when not to use it, but the purpose is specific enough that an agent can infer the correct situation.

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

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

With no annotations, the description carries the full burden. It discloses the storage location and match semantics ('matched against title, content, and tags'), which is useful. However, it does not explicitly state whether the operation is purely read-only, how results are returned, or any limitations.

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 core purpose is front-loaded in a single precise sentence, followed by a compact Args list. Every sentence adds information: location, search dimensions, and parameter semantics. There is no filler.

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

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

The description covers the tool's purpose and all four parameters, and an output schema exists to define return values. It is sufficiently complete for invoking the tool correctly, though it could mention behavior when no filters are supplied or explicitly flag read-only status.

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%, so the description must compensate. It explains every parameter: workspace_dir's role and default, query's matching behavior, tag filtering, and kind filtering with allowed enum values. This adds substantial meaning beyond the bare 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 uses a specific verb and resource: 'Searches the workspace Memory Vault' and identifies the search dimensions ('keyword query, tag, or entry kind'). It clearly distinguishes itself from likely siblings like read_memory by focusing on search rather than direct 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 makes the use case clear: agent should use this when searching memory by query, tag, or kind. It provides relevant context about the search scope and filters, but it does not explicitly state when not to use it or name alternatives like read_memory.

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?

There are no annotations, so the description carries the full behavioral burden. It discloses detached execution, queue-full behavior, capability preset semantics, widening-only allow flags, the non-sandbox warning, output_path file requirements, verify_command authorization, default/clamping behavior, and the return payload. This is far more transparent than typical tool descriptions.

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

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

The description is long but every section earns its place: purpose, engine comparison, queue behavior, argument semantics, and return values. The bullet-list structure makes the dense parameter details scannable, and the most important decision-relevant information 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 20 parameters, no schema-level descriptions, and no annotations, the description is remarkably complete. It covers invocation semantics, concurrency and queue limits, return shape, polling route, and safety caveats, while also pointing to run_subagent for shared contracts. An output schema exists, and the description still summarizes the returned task_id/status and result_data fields.

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

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

Schema description coverage is 0%, and the description compensates with detailed bullet semantics for mode, allow_destructive/allow_exec/allow_net, output_path, verify_command, recipe, limit parameters, and net_allowed_hosts/urls. It also routes shared contracts to run_subagent. The remaining parameters are self-explanatory from their names, types, and default 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 first sentence states a specific verb and resource: 'Start a detached BoteX task and return its task_id immediately.' It also contrasts with the sibling runner run_subagent ('returns instantly'), so an agent can immediately distinguish this asynchronous submission tool from the synchronous alternative.

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

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

The description makes the usage context clear: use this tool when you want the same engine as run_subagent but need a task_id to poll via get_task_status. It also gives operational conditions such as bounded concurrency and TOO_MANY_QUEUED. It does not explicitly state a when-not-to-use rule, but the contrast with run_subagent and the polling pointer provide sufficient guidance.

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