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 provided, the description carries the full burden and does so well: it discloses SSRF protections, redirect revalidation, content-type checks, byte limits, secret masking, and the allowlist-mode restriction. This is unusually rich behavioral context for a no-annotation 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?

Front-loads the core purpose in the opening clause and keeps the security model tight across a few sentences. Every sentence adds distinct information, though the prose could be marginally denser.

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?

An output schema exists, so return values need not be explained, and the security/policy model is well covered. The remaining gap is the undocumented max_bytes parameter, which leaves an agent guessing about truncation behavior.

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 there are two parameters, so the description must compensate. It adds some meaning to 'url' via 'public http(s) text document', but never explains max_bytes (default 0 presumably means unbounded) or its interaction with the byte limits it mentions.

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

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

States a specific verb and resource ('Fetch one public http(s) text document') plus the calling context ('caller-side research'). It explicitly distinguishes itself from BoteX's internal read_url, so an agent can tell the two apart without opening a schema.

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

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

Explains why this tool exists (the orchestrating agent chooses the URL, avoiding allowlist configuration) and gives the selecting condition for the alternative (internal read_url). It also notes the net.policy='allowlist' restriction. It stops short of an explicit when-not/exclusion statement beyond that policy note.

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 burden, and it does disclose the core behavioral trait: a lightweight, non-whole-file read that saves tokens and returns structural elements with line numbers. However, it says nothing about error behavior on unsupported file types, permissions, or size 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?

Two sentences, front-loaded with the action and return shape, then the value proposition. The parenthetical enumeration is compact and informative 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?

An output schema exists, so return values need not be explained, and the tool is simple (one required parameter). The description covers purpose, contents, and the token-saving rationale; only parameter semantics and explicit usage routing are missing.

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

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

Schema description coverage is 0% for both parameters, and the description never mentions 'path' or 'workspace_dir'. With zero coverage the description should compensate but adds no meaning for either parameter or their required/default status.

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

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

States a specific verb and resource ('Returns a lightweight file skeleton') and enumerates the concrete contents (classes, methods, functions, headers, line numbers). No sibling tool overlaps with file outlining, so the agent can place it immediately without opening the schema.

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

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

The clause 'without reading the whole file. Saves ~90% of tokens' implies the intended use case (cheap structural reconnaissance before/ instead of a full read), but no alternative tool is named and no when-not condition is given. Usage is inferable rather than 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?

With no annotations, the description carries the full burden. It does disclose what data is covered (costs, tokens, code-line balance) and that it aggregates executed tasks rather than live state, which is genuinely useful. However, it says nothing about permissions, scope of the aggregation (all-time vs. per-user), or freshness, leaving gaps for an unannotated tool.

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

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

The core purpose is front-loaded in one sentence and the parameter note is short and scoped. The 'Args:' block is slightly boilerplate but carries no wasted words.

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

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

For a single-optional-parameter analytics read tool with an output schema present, the description covers the purpose, the metric set, and the parameter's allowed values and meaning. Return-value details are correctly left to the output schema; only aggregation scope and permissions are unaddressed.

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 parameter has no enum, so the description must compensate. It does: 'period' is defined as 'week' (last 7 days) or 'month' (last 30 days), supplying both allowed values and their exact semantics, plus the default implied by the schema. This materially exceeds what the schema conveys.

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

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

States a specific verb and resource ('Returns an analytics summary of executed BoteX tasks') and enumerates the metrics returned (USD costs, token usage, code-line balance), which lets an agent distinguish it from get_task_status or check_health. It stops short of explicitly naming or contrasting with those siblings, so it is clear but not fully differentiated.

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

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

There is no when-to-use guidance: no statement of when an agent should call get_stats rather than get_task_status or check_health, no prerequisites, and no exclusions. Usage can only be inferred from the fact that it summarizes completed tasks.

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, and it delivers real behavioral insight: it warns that lifecycle DONE means 'finished' not 'succeeded' and points to result_data.status/result_data.ok for the true outcome, plus enumerates the structured fields returned. It omits operational traits like auth requirements, rate limits, or whether calling on a still-running task is cheap, keeping it short of 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?

Front-loaded one-line purpose followed by tightly scoped clarifying notes, each of which resolves a genuine ambiguity (lifecycle vs. engine status, pretty-text vs. structured result). No filler 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?

An output schema exists, so the description is not obligated to explain return values, yet its clarification of status vs. result_data.status prevents a real misread of the response. It is complete for invocation; only polling/lifecycle operational guidance 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?

One parameter at 0% schema coverage, so the description must compensate; it implies task_id is the identifier from start_task but never states the expected format or provenance explicitly. That gives the agent enough to map the argument, but not full semantic detail, so a 3 is fair.

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

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

States a specific verb+resource ('Return status and result for a task') and immediately anchors it to the sibling tool that produces the input ('started with start_task'), which cleanly separates it from start_task and the other siblings. An agent can tell exactly what this retrieves without opening the schema.

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

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

The prerequisite is explicit: this is for a task 'started with start_task', which gives the agent the correct entry condition. It stops short of stating when-not to use it (e.g., polling cadence, terminal-state behavior, or what to do instead of repeated calls), so it is clear context without full routing guidance.

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

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

No annotations are provided, so the description carries the full burden. It conveys that this is a non-mutating retrieval of content plus metadata, but says nothing about failure behavior (e.g. unknown memory_id), permissions, or cross-workspace access. The output schema covers the return shape, so that omission is acceptable.

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?

Front-loaded one-sentence purpose followed by per-argument documentation. Slightly verbose in the workspace_dir fallback chain, but every detail there is operationally useful rather than 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?

Two parameters, both documented, one required; an output schema exists so return values need not be explained. The main remaining gap is the absence of any guidance on error/nonexistent-ID behavior, which for a no-annotation read tool would be the last thing worth adding.

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 - and it does. It documents both parameters, including an ID format example ('mem_a1b2c3d4') and the non-obvious fallback semantics of an empty workspace_dir (engine default from config, else server's current directory). That is meaningfully more than 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?

States a specific verb and resource: reads the 'full content and metadata' of a memory entry, scoped 'by ID'. This implicitly distinguishes it from the sibling search_memory (query-based) and save_memory (write), though it never names those alternatives explicitly.

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

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

Usage is implied by the 'by ID' framing - an agent infers this is the tool to call once it already holds a memory_id. However, there is no explicit statement of when to use this versus search_memory, and no prerequisites or conditions given.

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

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

With no annotations, the description carries the full burden and delivers a meaningful disclosure: include_free=True admits non-ZDR ':free' variants whose prompts may be logged/trained on, and these require allow_non_zdr or the openrouter-free provider. That is real side-effect/privacy context beyond a simple getter.

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?

Content is front-loaded and each sentence earns its place within a language, but the full EN and PL duplication roughly doubles the payload for what is a short instruction set.

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?

An output schema exists so return values need not be described, and the critical behavioral caveat (non-ZDR free variants) is covered. The gaps are the undocumented limit and task_type semantics rather than missing high-risk information.

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 include_free thoroughly (ZDR implications and the allow_non_zdr requirement) but leaves limit and task_type entirely undocumented, so only one of three parameters gains meaning.

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

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

States a specific verb and resource (fetches model recommendations from OpenRouter) and the basis (live benchmarks, cost/quality). It clearly distinguishes itself from the sibling run_subagent by being the model-selection step that precedes it.

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

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

Explicitly tells the agent to call this BEFORE run_subagent when the model ID is unknown or cost/quality optimization is wanted. Strong when-to-use guidance, though it does not state when to skip it (e.g., when the model ID is already known).

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 entire behavioral burden and does so richly: snapshot rollback on failure, pre-write syntax validation, ZDR/DLP guarantees, headless pre-authorization semantics, and the explicit warning that `allow_exec` is NOT a sandbox and runs with operator privileges. It also documents precedence (api_key > env > config) and reversibility, exactly the traits annotations would otherwise supply.

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?

Purpose is front-loaded, then a TIP, feature list, Args, and Returns — a logical order for a 21-parameter tool. The 'Key engine features' bullets lean slightly promotional (token-savings percentages) but still convey capability context, so the size is defensible though not maximally tight.

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 this complex — 21 params, no annotations, no sibling differentiation elsewhere — the description covers invocation rationale, every argument, capability modes, safety gates, and the return contract (status/ok/failure_kind), so an agent has everything needed to call it correctly.

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

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

Schema description coverage is 0% across 21 parameters, so the description must fully compensate — and it documents every one with meaning, defaults, and interaction rules (e.g. model overrides profile, empty flags fall back to config, allow_* can only widen a preset). This is exemplary compensation for an undocumented schema.

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

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

States a specific verb and resource: 'Runs BoteX — an autonomous code execution engine' that 'performs multi-step tasks on local files inside workspace_dir.' That is far more than a tautology. What keeps it from a 5 is the absence of explicit differentiation from the sibling 'start_task', which an agent might reasonably confuse with a multi-step code-execution tool.

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

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

Provides real conditional guidance: routes the agent to `recommend_models` rather than guessing a model, states that destructive ops require the user's consent, and that `allow_exec` is only for trusted workspaces. It does not, however, tell the agent when to prefer this tool over alternating siblings such as start_task, so it falls short of full when/when-not routing.

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

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

With no annotations, the description carries the full burden, and it does disclose non-obvious behaviors: automatic secret masking, directory isolation, and memory_id auto-generation when omitted. It does not say what happens on an ID/title collision (overwrite vs. error), nor anything about permissions or retention, which are important for a persistent write.

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 lead sentence front-loads purpose and destination, followed by a tight Args list where each entry is one sentence. No filler, though the multi-line block format is slightly verbose relative to the information conveyed.

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

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

An output schema exists so return values need not be explained, and all input parameters are covered along with useful side-effect notes (secret masking, isolation). The remaining gap is usage routing against the read/search siblings and collision behavior, which keeps it short of complete.

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

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

Schema description coverage is 0%, yet the description documents all six parameters with meaning beyond the bare types: it explains the kind categories, that tags are for filtering/discovery, that memory_id must be alphanumeric/hyphen/underscore and is auto-generated if omitted, and the fallback rules for workspace_dir. Strong compensation, though the markdown format of content could be stated more precisely.

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

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

States a concrete verb and resource ('Saves a persistent context note... into the workspace Memory Vault') and names the exact storage path plus the four entry categories. It clearly occupies the write slot opposite the read_memory/search_memory siblings, though it never names those alternatives explicitly.

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

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

The kind values ('context' | 'decision' | 'handoff' | 'lesson') implicitly signal when each entry type applies, which gives partial usage guidance. However, there is no explicit statement of when to use save_memory versus search_memory/read_memory, no when-not conditions, and no prerequisites.

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

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

No annotations are provided, so the description carries the full behavioral burden. It usefully discloses the storage path and the fallback chain for an empty workspace_dir (config default workspace, else server CWD), but says nothing about how filters combine, result ordering/limits, or that the call is a non-mutating read.

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?

Front-loaded with the one-line purpose before the Args block, and each parameter line earns its place. The docstring-style 'Args:' formatting is functional rather than elegant, but nothing is wasted.

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

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

An output schema exists, so return values need not be explained, and all four parameters are covered. Still missing are the filter-combination semantics (AND vs OR) and any guidance on relating this tool to read_memory/save_memory, which leaves real gaps for a discovery tool.

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

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

Schema description coverage is 0%, so the description does the full job: it explains all four parameters, gives the empty-string default semantics for workspace_dir, and enumerates the valid kind values (context, decision, handoff, lesson) that the schema fails to express as an enum.

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

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

States a specific verb and resource ('Searches the workspace Memory Vault') and names the three filter dimensions (query, tag, kind). It is clearly distinguishable in intent from save_memory and read_memory, though it never names those siblings explicitly.

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

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

Usage is implied by describing the filter modes, but there is no explicit when-to-use/when-not guidance and no routing against the obvious alternatives read_memory and save_memory. An agent must infer that this is the discovery tool and the other two are point read/write.

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 and delivers: concurrency bounds (engine.max_concurrent_tasks), queue bound with the TOO_MANY_QUEUED failure status, the widening-only authorization semantics of allow_destructive/allow_exec/allow_net, the exec.enabled prerequisite, the DONE contract for output_path, and ZDR implications of allow_non_zdr. This is unusually rich disclosure of side effects and constraints.

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?

Front-loads the one-line summary and the async/poll relationship, then groups the capability arguments. Given 21 parameters, the length is largely earned, though a few bullets defer to 'see run_subagent' and the return-value section is somewhat redundant with the existing 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 complex 21-parameter mutation-capable tool with no annotations, the description covers startup behavior, queue semantics, authorization model, contract enforcement, and polling handoff. An agent has everything needed to invoke it correctly, and the output schema carries the detailed return shape.

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% across 21 parameters, so the description must compensate, and it explains the semantically tricky ones in depth (mode presets, widening-only flags, output_path contract, verify_command, recipe personas, budget/turn defaults, net scope narrowing). It leaves several parameters unexplained (files, model, api_key, profile, provider, workspace_dir), so coverage is strong but not complete.

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

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

States a specific verb and resource ('Start a detached BoteX task') plus the immediately observable outcome ('return its task_id immediately'). It explicitly contrasts itself with the sibling run_subagent by being the fire-and-poll variant, so an agent can distinguish them without opening schemas.

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

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

Names the alternative (run_subagent), explains the defining difference (returns instantly vs. blocking), and points to the follow-up tool (get_task_status) for polling. It stops short of stating explicit selection conditions such as 'use this when the task is long-running or may exceed a request timeout,' so it is clear but not fully prescriptive.

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