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

No annotations provided, so description carries full burden. It discloses caching of Anthropic auth and notes that working_directory is ignored for safety. However, it does not describe output format, error handling, or rate limits, which are gaps for a tool with no annotations.

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

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

Three sentences, no redundancy. First sentence states purpose, second gives usage context, third mentions auth. Every sentence earns its place. Front-loaded with the most critical information.

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

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

The description adequately covers purpose, usage context, auth, and one parameter note, but given no output schema and no annotations, it is missing output format, error handling, and model availability details. Adequate but not fully complete.

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

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

All 4 parameters have schema descriptions (100% coverage). The description adds value beyond the schema by explaining the authentication caching, the default timeout (60s), and that working_directory is ignored for Claude. This extra context helps the agent use parameters correctly.

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

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

The description clearly states the verb 'Send' and resource 'prompt to Claude via local Claude Code CLI'. It explicitly distinguishes from sibling tools like codex_run, gemini_run, and local_llm_run by specifying when to use: when the MCP client is not Claude or for cross-checking 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 explicit usage guidance: 'Use this when the MCP client is NOT Claude (e.g. Cursor, Windsurf, Zed) or for cross-checking results from other AI backends.' It lacks explicit when-not-to-use but the positive cases are clear and imply alternatives.

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

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

No annotations are provided, so the description carries the full burden. It discloses that the tool uses cached OpenAI auth and requires no API key, which is a useful behavioral detail. It also mentions that tasks can take longer than Gemini, setting expectations. However, it does not discuss side effects such as file modifications (sandbox behavior) or potential irreversible actions, but the sandbox parameter partially covers that. Since the sandbox parameter mentions approvals and workspace-write, the description provides decent transparency without contradicting anything.

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 efficient and front-loaded: it opens with the core purpose, then adds key differentiators (specialization and auth) in a compact form. The sentence about cached auth is useful, but the description could be slightly more structured by separating general purpose from usage notes. Overall, it is concise and clearly structured without 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?

The tool has moderate complexity (5 params, one enum, no output schema), and the description plus schema provide enough for an agent to call it correctly. It covers the key operational aspects: what it does, how to specify the model, sandbox options, timeout, and working directory. There is no explicit mention of return format, but given no output schema, that is a minor gap. The description is sufficiently complete for a coding-task 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 100%, so the schema already documents all parameters thoroughly, including the sandbox enum and the timeout's purpose. The description adds a bit of context by mentioning that Codex tasks can take longer than Gemini, which explains the timeout default, and that working_directory should be set to the project root so Codex can read/write files. This adds marginal value beyond the schema, so a baseline of 3 is appropriate.

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

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

The description clearly states the verb 'Send' and the resource 'task to OpenAI Codex via the local codex CLI', and specifies the specialization in coding tasks, file operations, and technical analysis. It distinguishes from siblings like gemini_run, claude_run, and local_llm_run by naming the specific platform (Codex) and the local CLI mechanism.

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 that this tool is for coding tasks and specifically mentions it can take longer than Gemini, which hints at when to use it relative to siblings with faster models. However, there is no explicit guidance on when NOT to use it (e.g., for non-coding tasks) or direct comparison with alternatives like gemini_run or claude_run. The specializations are mentioned but not framed as usage conditions.

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

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

With no annotations provided, the description must carry the full behavioral transparency burden. It discloses supported file types, size limit, and special download behavior, but does not mention authentication requirements, error handling, or what happens if a file already exists. More detail would improve transparency.

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

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

The description is concise: two sentences efficiently cover purpose, constraints, and a special use case. Every word adds value with no redundancy or fluff.

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 (3 parameters, simple enum action, no output schema), the description is fairly complete. It covers actions, remote path, local path optionality, file types, and size. It could mention that 'list' returns a directory listing, but that is implied by the enum.

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 already describes all three parameters with 100% coverage. The description adds value by explaining the special case for download without local_path (returns content) and the size limit, which are not in the schema. This enhances understanding beyond the schema alone.

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

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

The description clearly states the tool's purpose: to upload, download, or list files on an OpenClaw server via SSH. It specifies supported file types (text and binary), size limit (10MB), and a special behavior for download without local_path. This clearly distinguishes it from sibling tools which are mostly for running code or home automation.

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

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

The description provides clear context for when to use the tool (SSH file transfers) and gives a specific guideline for 'download' without local_path. However, it does not explicitly mention when not to use it or suggest alternative tools, though the sibling tools are quite different.

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 burden. It usefully discloses the execution mechanism ('local gemini CLI'), authentication behavior ('cached Google auth'), and the lack of an API key requirement. But it does not mention failure modes, the dependency on the CLI being installed, potential side effects from working_directory, or what the response contains.

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

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

Three short sentences with the core action front-loaded and each additional sentence conveying a distinct non-obvious fact (speed/no overhead, cached auth/no API key). It is slightly redundant because 'Fast, direct LLM call with no OpenClaw overhead' partially repeats the implications of 'via the local gemini CLI,' but overall it is tight and efficient.

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

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

For a simple 4-parameter tool with full schema coverage, the description covers provider, execution method, and auth context. However, because there is no output schema, the description should have mentioned what the tool returns or how errors surface, and it remains silent on exit/error behavior. This is adequate but not complete.

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

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

Schema description coverage is 100%, so the input schema already documents all four parameters with sufficient detail. The description adds no parameter-specific meaning beyond restating that a prompt is sent, so the baseline score of 3 applies.

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

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

The description opens with a specific verb and resource: 'Send a prompt to Google Gemini via the local gemini CLI,' which clearly differentiates it from sibling LLM tools like codex_run, claude_run, and local_llm_run. The extra traits, 'no OpenClaw overhead' and 'no API key required,' further distinguish this as a lightweight, direct Gemini call.

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

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

The description implies usage context with 'Fast, direct LLM call with no OpenClaw overhead' and 'Uses cached Google auth - no API key required,' suggesting it is for minimal-overhead Gemini calls or when API keys are not available. However, it does not explicitly state when to use this tool instead of siblings like local_llm_run or codex_run, nor does it mention any exclusions.

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

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

With no annotations, the description must disclose side effects and constraints. It only details the output of 'list' (state and last trigger time). For trigger, enable, disable, it does not state whether actions are immediate, reversible, or require specific permissions. This lack of transparency for mutation operations is a significant gap.

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-loaded with the tool's purpose. The second sentence could be integrated into the first, but overall it is efficient. No unnecessary words.

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

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

Given the tool's multi-action nature, no output schema, and two parameters, the description is incomplete. It does not describe the effect or output of trigger, enable, disable, nor any prerequisites or error conditions. The agent lacks full context for effective 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 coverage is 100%, so baseline is 3. The description adds meaning for the 'action' parameter by explaining the 'list' output. However, it does not elaborate on 'entity_id' beyond its schema description, nor does it clarify how the action affects entity_id for non-list operations.

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

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

The description clearly identifies the tool as managing Home Assistant automations with actions: list, trigger, enable, disable. It distinguishes from sibling tools like home_light or home_climate by focusing on automations. However, it only elaborates on the 'list' action, leaving other actions partially defined.

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 the tool is for automation management but provides no explicit guidance on when to use it vs alternatives like home_get_state or home_scene. No exclusions or conditions are stated, so usage context is implied but not explicit.

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

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

No annotations are provided, so the description carries full burden. It discloses that the tool controls (mutates) settings but does not mention side effects, permanence, authentication needs, or other behavioral traits.

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

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

The description is a single concise sentence (13 words) that is front-loaded with key information. Every word adds value; no unnecessary 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?

Given the simple tool (3 parameters, no output schema), the description is adequate for basic usage. However, it omits context like whether authentication is required, what happens on failure, or how the tool integrates with the broader home environment.

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

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

Schema description coverage is 100%, so the schema already documents all parameters. The description reinforces the purpose of parameters (e.g., 'target temperature') but adds limited new meaning. Baseline of 3 is appropriate.

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

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

The description clearly states the verb 'Control', the specific resource 'Tado thermostats', and the actions 'set target temperature or HVAC mode (heat/auto/off)'. It effectively distinguishes from sibling tools like home_light or home_vacuum.

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

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

The description implies usage for thermostat control but provides no explicit guidance on when to use this tool versus alternatives like home_automation, nor does it 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 are provided, so the description carries full burden. It indicates a read-only operation but does not disclose any additional behavioral traits such as authentication needs, error handling, or side effects.

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 that is front-loaded and contains no unnecessary words. Every part adds value.

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

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

For a simple read operation with one parameter and no output schema, the description is reasonably complete. It lists entity types, but could hint at the return format (JSON state object).

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

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

Schema coverage is 100% with the entity_id parameter clearly described. The description does not add significant meaning beyond what the schema already provides, thus baseline score of 3.

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

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

The description clearly states the verb 'Get' and the resource 'current state of a Home Assistant entity', with a list of example entity types. This distinguishes it from sibling tools like home_light or home_climate which are entity-specific.

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

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

The description implies this tool is for generic state retrieval, but it does not explicitly state when to use it versus the specific sibling tools (e.g., home_light). No exclusions or alternatives are mentioned.

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

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

No annotations are provided, so the description must fully disclose behavior. It indicates mutation by 'control' but omits side effects, error handling (e.g., setting conflicting parameters like RGB and color temperature), idempotency, or prerequisites (device availability, permissions).

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

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

A single concise sentence front-loads the core purpose and enumerates key capabilities. No redundancy or unnecessary words.

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

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

Despite good parameter coverage, the description fails to mention the required entity_id parameter or explain return behavior (no output schema). It does not address combinations of parameters or device-specific constraints, leaving gaps for an agent.

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

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

Schema coverage is 80% (4 of 5 params described). The description maps actions and parameters (e.g., 'color temperature' to color_temp_kelvin) but adds minimal meaning beyond the schema's own descriptions. The entity_id parameter is not mentioned in the description, relying on the schema.

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

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

The description clearly states the tool controls a light with specific operations (on/off/toggle, brightness, color temperature, RGB). It differentiates from sibling tools like home_climate or home_vacuum by naming the exact capability.

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

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

The description lists operations but does not explicitly state when to use this tool over alternatives like home_get_state (reading state) or home_scene (preset scenes). The context of sibling tools implies light-specific control, but no exclusionary guidance is provided.

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

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

No annotations are provided, so the description must carry the full burden of behavioral disclosure. It only states 'Activate' which implies mutation, but it does not disclose side effects, reversibility, or any prerequisites (e.g., Hue bridge). Lacks sufficient detail for a mutating 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?

Single sentence with no wasted words. Room list is parenthetically appended, making it efficient while providing essential 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?

For a simple tool with two parameters and no output schema, the description covers basic functionality. However, it lacks usage guidelines and behavioral transparency, leaving the agent with incomplete context for correct invocation among siblings.

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

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

Schema coverage is 100%, so the schema already documents both parameters. The description repeats the room enum values and gives scene examples that are also in the schema description. It adds marginal value beyond the schema, meriting the baseline score of 3.

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

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

Description clearly states verb 'Activate' and resource 'Hue scene in a room', and explicitly lists the valid room names (enum values), distinguishing it from sibling tools like home_light which target individual lights.

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 (activate a scene), but there is no explicit guidance on when to use this tool versus alternatives such as home_light or home_get_state. No exclusions or prerequisites are mentioned.

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

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

No annotations are provided, and the description does not disclose behavioral traits such as read frequency, caching, permission requirements, or side effects. For a data-reading tool, basic transparency is missing.

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

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

Single sentence, no redundant words, front-loaded with verb and resource. Efficient and to the point.

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

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

No output schema exists, but the description adequately lists what sensors are read. Could mention if data is current or historic, but for a simple read-all tool it is sufficient.

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

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

Schema has no parameters (100% coverage by default). The description adds meaning by listing the sensor types included, which is useful context beyond the empty 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 verb 'Read' and specifies the resource 'all environmental sensors' with explicit sensor types (temperature, humidity, CO2, outside temperature). It distinguishes from sibling tools like home_climate and home_get_state.

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

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

No guidance on when to use this tool versus alternatives. Sibling tools like home_climate or home_automation might overlap, but the description provides no context for choosing this 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, the description alone must disclose behavioral traits. It only lists actions without explaining side effects, prerequisites, or state implications (e.g., what happens if already cleaning).

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

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

The description is a single sentence that front-loads the purpose and efficiently lists all actions, with no extraneous 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 simple 1-parameter tool with no output schema, the description covers the main purpose and each action sufficiently, though it omits any state or prerequisite details.

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 description adds meaning beyond the enum by clarifying 'start' as 'start full clean' and naming the other actions, which helps an agent understand each option's purpose despite 0% schema description coverage.

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

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

The description clearly states the tool controls a Roborock vacuum and lists specific actions (start, stop, return to dock, get status), which distinguishes it from sibling tools like home_light or home_climate.

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; it simply describes what the tool does without any when-to-use or when-not-to-use context.

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

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

Without annotations, the description discloses basic behaviors: starting a server, using status/stop, and cache types. However, it does not detail side effects, error handling, or prerequisites for starting, which would improve transparency.

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

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

The description is two sentences, front-loaded with the core purpose, and each sentence provides essential 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?

The description covers the main workflow (start, stop, status) and key parameters, and references sibling tools. However, it lacks details on error scenarios or prerequisites like requiring model_path for start, but overall it is fairly complete for the tool's complexity.

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

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

Schema description coverage is 100%, providing a baseline of 3. The description adds value by explaining cache types in the context of TurboQuant and advising that asymmetric configuration often yields best results for cache_type_v.

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 manages a local llama.cpp server with start, stop, and status actions. It distinguishes from siblings like local_llm_run by indicating that once started, local_llm_run is used for querying.

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

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

The description provides clear context on when to use the tool (start with specific model, cache type, etc.) and mentions that it runs alongside LM Studio on a different port. It also directs to local_llm_run for queries, but lacks explicit when-not-to-use or alternative options.

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

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

The description discloses that load/unload only works with LM Studio and switches models without GUI, which is useful behavioral context. However, it lacks details on side effects (e.g., memory, time to load), error handling, or whether unloading affects running inference. As annotations are absent, the description carries the full burden and is incomplete.

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 only two sentences, front-loading the core purpose and then clarifying the LM Studio constraint. Every sentence contributes necessary information without redundancy or fluff. Very 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?

The description covers the main actions but leaves gaps: it does not describe the return format for 'list' (e.g., JSON array), nor what happens on success/failure for load/unload. With no output schema and three actions, more detail on return values and state changes would improve completeness.

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

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

All three parameters are described in the schema (100% coverage). The description adds value by explaining the action enum values ('list' shows models, 'load' loads a model) and providing an example model identifier ('microsoft/phi-4-mini-reasoning'). This supplements the schema beyond redundancy.

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

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

The description clearly states the verb 'List, load, or unload' and the resource 'models on the local LLM server.' It distinguishes the tool from siblings like 'local_llm_run' (which handles inference) and 'llama_server' by specifying model management. The three actions are explicitly listed, making the purpose unambiguous.

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

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

The description provides clear context for each action: list shows available models, load/unload switches models. It also notes that load/unload requires LM Studio, implying when not to use these actions. However, it does not explicitly compare to alternatives or give when-not-to-use advice beyond the LM Studio limitation.

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 key behavioral traits: the tool is free, private, requires no API key, and supports streaming via 'stream=true'. It does not mention potential side effects or prerequisites, but for a read-like operation this is adequate.

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

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

The description is extremely concise—two sentences achieving high information density. The first sentence states purpose and key attributes; the second clarifies when to use and a streaming option. No wasted words.

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

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

Given the tool's medium complexity (8 parameters, no output schema), the description covers purpose, usage scope, and a key optional feature (streaming). It provides enough context for an agent to decide and invoke correctly, though lacking details on error handling or response format.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds little beyond the schema, only reiterating the streaming hint and the default behavior for model/endpoint. No additional parameter context or examples are provided.

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 sends a prompt to a local LLM, explicitly listing supported backends (LM Studio, Ollama, etc.) and use cases (classify, format, extract, rewrite, proofread). It differentiates from siblings like claude_run, gemini_run, and llama_server by emphasizing 'Free, private, no API key needed' and 'Best for simple tasks.'

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

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

The description tells the agent this tool is 'Best for simple tasks' and lists specific task types, giving clear guidance on when to use it. However, it does not explicitly state when NOT to use it or suggest alternative tools for complex tasks, which would improve the score further.

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

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

No annotations are provided, so the description carries full burden. It does not disclose whether the tool is read-only, any side effects, or how the recommendation is generated (e.g., LLM call). For a help tool, these are typically safe, but the description lacks explicit transparency.

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

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

Two sentences, front-loaded with purpose. No redundant words, efficient and 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 a single optional parameter and no output schema, the description fully covers both modes of operation (list and recommend). No additional context is needed.

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

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

Schema coverage is 100% with a clear description for the 'task' parameter. The description adds context by mentioning sub-agent names (openclaw_run, gemini_run, etc.), which enriches the schema.

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

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

The description clearly states the tool lists available tools and optionally provides a routing recommendation based on a task description. It differentiates itself from sibling tools which are specific execution agents.

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: list tools or get a recommendation by providing a task. It does not explicitly state when not to use or alternatives, but the context makes it clear this is an introspection tool.

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

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

No annotations provided, so description carries full burden. It discloses schedule varieties, optional delivery, and the disabled state parameter. However, it does not mention side effects (e.g., overwriting existing jobs), authentication needs, or whether creation is synchronous. Adequate but not thorough.

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

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

The description is extremely concise: two sentences covering core functionality, schedule types, and delivery option. No extraneous words. Efficient 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?

Given no output schema, the description should hint at return values (e.g., job ID) or confirmation. It does not. Also omits behavior on duplicate names. But it covers key aspects: parameters, schedule syntax, and delivery. Adequate but with gaps for a creation tool.

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

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

Schema coverage is 100% with each parameter described. The description adds context on schedule formats and delivery channels, but this largely echoes the parameter descriptions. Does not add meaning beyond schema; baseline 3 is appropriate.

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

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

The description clearly states the verb (create) and resource (cron job on OpenClaw server). It distinguishes from sibling cron tools (edit, delete, list) by focusing on creation. Mentions supported schedule types and optional delivery, leaving no ambiguity about the tool's function.

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 when to use (scheduling tasks) but does not explicitly contrast with siblings like openclaw_cron_edit or openclaw_cron_delete. No guidance on when NOT to use or prerequisites (e.g., server access). Context is clear but incomplete for a new 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?

No annotations are present. The description does not disclose any behavioral traits (e.g., permanence, authorization needs) beyond the basic fact of deletion.

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

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

A single sentence of 7 words, perfectly concise with no extraneous information.

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

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

Given the simple interface (1 param, no output schema), the description minimally states the function but offers no context about effects, errors, or irreversibility.

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

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

Schema coverage is 100%, so the description adds no new meaning beyond what is already in the parameter description ('Job ID (UUID) to delete').

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

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

The description clearly states the verb 'Delete' and the resource 'cron job by its ID', effectively distinguishing it from sibling tools like create, edit, and list.

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

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

No guidance is provided on when to use this tool versus alternatives, nor 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 are provided, so the description must carry full burden. It fails to disclose whether editing is a full replacement or partial merge, what happens to unspecified fields, required permissions, or side effects. This is insufficient for a mutation tool.

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

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

The description is a single, efficient sentence with zero wasted words. It is front-loaded and easy to parse.

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

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

Given 5 parameters and no output schema, the description is somewhat incomplete. It doesn't explain the editing semantics (merge vs replace), schedule format validation, or confirm if the id must exist. Still minimally adequate.

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

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

Schema coverage is 100%, so the schema fully documents each parameter. The description mentions the editable fields but adds no extra meaning (e.g., format constraints, default behavior). Baseline 3 is appropriate.

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

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

The description clearly states the tool edits an existing cron job and lists the editable fields (name, message, schedule, model). It uses a specific verb (edit) and resource (cron job), and implicitly distinguishes from sibling tools like openclaw_cron_create and openclaw_cron_delete.

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

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

The description provides no guidance on when to use this tool versus alternatives, no prerequisites, no when-not scenarios. It only states what the tool does, leaving the agent without decision support.

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 must disclose behavior. It says 'recent execution history' but does not clarify what 'recent' means, nor does it mention ordering, pagination, or limitations. The lines parameter max is 100 but not stated. Partial transparency is provided.

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 short sentence, which is concise. However, it could be slightly more informative without being wasteful. It is well-structured 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?

Given no output schema and no annotations, the description should explain the return format (e.g., list of runs with timestamps). It does not. Also lacks permission or scope details. Incomplete for a history tool.

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

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

The input schema covers 100% of parameters with descriptions. The tool description adds no additional meaning beyond what is already in the schema. Baseline of 3 is appropriate.

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

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

The description clearly states the verb 'Show' and the resource 'recent execution history for cron jobs'. It mentions optional filtering by job ID, and the tool is distinct from sibling tools like openclaw_cron_status and openclaw_cron_list.

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

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

The description does not provide explicit guidance on when to use this tool versus alternatives. The parameter description for id suggests using openclaw_cron_list to find IDs, but there is no discussion of when not to use or other context.

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

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

No annotations provided, so the description carries full burden. It only says 'list all' but doesn't disclose return format, default behavior (e.g., whether disabled jobs are included by default), or any side effects.

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

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

Extremely concise single sentence, front-loaded with action and resource. Could be slightly more informative without sacrificing brevity.

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

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

No output schema, yet description doesn't describe what the list returns (e.g., job names, schedules). With many sibling cron tools, more context on scope (e.g., this lists only, not status) would help.

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

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

Schema coverage is 100% for the single parameter, so the description doesn't need to add much. However, it doesn't reference 'include_disabled' at all, missing an opportunity to clarify default behavior beyond schema.

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

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

The description clearly states the verb 'list' and the resource 'scheduled OpenClaw cron jobs', distinguishing it from siblings like openclaw_cron_create or openclaw_cron_delete.

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

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

No guidance on when to use this tool versus alternatives (e.g., openclaw_cron_status or openclaw_cron_history), nor any prerequisites or context 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?

No annotations are provided, so the description carries full burden. It only states 'trigger immediately' but provides no details about return values, side effects, error handling, permissions, or idempotency. This is insufficient for a mutation tool.

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

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

The description is a single, clear sentence with no wasted words. Every word contributes meaning.

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

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

For a simple tool with one parameter and no output schema, the description is minimal but lacks behavioral or error context. It is adequate but not comprehensive.

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

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

Schema description coverage is 100% (job_id described as 'Cron job ID (UUID)'), and the description adds no additional meaning beyond 'by its ID'. Baseline 3 is appropriate.

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

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

The description clearly states the action ('trigger immediately') and the resource ('OpenClaw cron job'), effectively distinguishing it from sibling tools like list, status, history, and create.

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

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

The description implies use for immediate execution, but offers no explicit guidance on when to use this tool versus alternatives like openclaw_cron_create or openclaw_cron_list, nor does it 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 are provided, so the description must disclose behavioral traits. While 'Get' implies a read operation, it does not explicitly state side effects, required permissions, or what 'status and overview' entails. The transparency is minimal.

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

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

The description is a single sentence, concise and front-loaded. It is efficient but could be slightly expanded to include more detail without becoming 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?

Given the lack of output schema and annotations, the description is incomplete. It does not specify what information the status overview contains (e.g., scheduler health, running jobs, last run times), which is essential for an agent to understand the response.

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 zero parameters with 100% schema coverage. Per guidelines, no parameters means a baseline of 4. The description does not add parameter info, which is acceptable since there are none.

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

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

The description clearly states the verb 'Get' and the resource 'OpenClaw cron scheduler status and overview'. Among sibling tools like openclaw_cron_create, delete, and list, this tool is distinct as it provides a status overview, not specific 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?

No guidance is provided on when to use this tool versus alternatives like openclaw_cron_list or openclaw_cron_history. The description does not specify the context or prerequisites for invocation.

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 full burden. It discloses that scripts are triggered and a log check is possible, and provides a prerequisite. However, it lacks details on behavior like whether deployment is synchronous, error handling, or rollback safety. Adequate but not thorough.

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 efficiently convey purpose and a key prerequisite. Every word earns its place, no 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 two parameters and no output schema, the description covers basic purpose and a prerequisite. However, for a deployment tool, additional context (e.g., idempotency, concurrency) would be helpful to ensure correct usage. Adequate given simplicity.

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

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

Schema coverage is 100% and descriptions of parameters are clear. The description adds context about the script directory, but does not enhance understanding of individual parameter values beyond the schema. Baseline 3 is appropriate.

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

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

The description clearly states the verb 'Trigger' and resource 'OpenClaw server' with specific actions (deploy, rollback, status). It distinguishes itself from sibling tools like openclaw_cron_* or openclaw_logs by focusing on deploy scripts and log checking.

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 action enum and mentions a prerequisite (scripts must exist), but does not explicitly state when to use this tool vs alternatives like openclaw_run or openclaw_logs. No guidance on when not to use or how to choose between actions.

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

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

No annotations provided, but description fully discloses behavior: it supports line count and keyword filtering, and lists all source options (gateway, agent, system, custom). It does not mention any destructive side effects, which is appropriate for a read-only log viewer.

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

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

Single sentence that is concise, front-loaded with the main action, and contains no unnecessary words. Every part of the description adds value.

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

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

Description is complete given the tool's complexity: it explains the purpose, supported sources, and filtering options. It lacks detail on output format but that is acceptable since there is no output schema. Overall, provides enough context for an AI agent to select and use the tool correctly.

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

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

Schema description coverage is 100% with all parameters described. The description reiterates the line count and keyword filtering capability but does not add significant new meaning beyond what is already 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?

Description clearly states the verb 'View' and the resource 'logs' from the OpenClaw server, listing specific log types (gateway, agent execution, system journal). It distinguishes from sibling tools like openclaw_status by focusing specifically on log viewing.

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?

Description implicitly tells when to use (to view logs from OpenClaw server) but does not explicitly state when not to use or provide alternatives. The clear context of log viewing is sufficient for most scenarios.

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

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

No annotations are provided, so the description must fully disclose behavior. It only states 'read' (non-destructive) but gives no details on output format, error handling, or what happens if no log exists for today. This is insufficient for full transparency.

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

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

Single sentence, directly to the point with no filler. Perfectly concise and front-loaded with the core action.

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

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

The tool has zero parameters and no output schema, so the description should compensate by explaining what the returned memory log looks like. It fails to do so, leaving the agent unclear on the format or content of the output.

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

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

There are no parameters, so the baseline is 4. The description correctly implies no input needed. No additional parameter information is required.

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

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

Description clearly states the action (read), the resource (today's memory log), and the server (OpenClaw). It distinguishes itself from sibling tools like openclaw_memory_search and openclaw_memory_write by specifying a fixed temporal 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 implies usage for retrieving today's log but does not explicitly mention when to use alternatives like openclaw_memory_search for historical queries. With no parameters, the usage is simple, but lack of explicit guidance slightly limits score.

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 only states the search scope and default days, but omits safety profile (read-only implied), side effects, rate limits, or what happens on no results.

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

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

Single sentence, 12 words, no redundancy. Front-loaded with action and resource. Every word is informative.

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

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

No output schema, so description must explain return values. It does not mention output format, error behavior, or pagination. For a search tool, more context (e.g., returns file paths or snippets) is needed.

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

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

Schema coverage is 100% with descriptions for both parameters. The tool description adds minimal value beyond restating the default days. Baseline 3 is appropriate.

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

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

The description clearly states the action ('Search'), the resource ('daily memory files'), the server ('OpenClaw'), and the scope ('for a keyword, default last 14 days'). It distinguishes from sibling tools like 'openclaw_memory_read_today' by focusing on cross-day search.

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

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

No guidance on when to use this tool versus alternatives like 'openclaw_memory_read_today'. The description does not mention exclusions or prerequisites, leaving the agent to infer 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?

No annotations are present, so the description must disclose behavioral traits. It states it writes to a daily log but does not specify whether it appends or overwrites, note length limits, or persistence details. For a write operation, this lack of transparency is a significant gap.

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

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

The description is extremely concise with two sentences, no redundancy, and the core action is front-loaded. Every word adds value, making it efficient for AI parsing.

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 write tool with 2 parameters and no output schema, the description covers the main purpose and usage. However, it omits critical details like append vs. overwrite behavior and any limits, which are important for completeness. It is adequate but not fully comprehensive.

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

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

Schema coverage is 100%, achieving baseline score. The description does not add any meaning beyond the schema's parameter descriptions (e.g., 'The note to save' and 'Optional category/tag'). No additional semantic value is provided.

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

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

The description clearly specifies the verb 'Write a note' and the resource 'today's daily memory log on the OpenClaw server'. It distinguishes from sibling tools like openclaw_memory_read_today and openclaw_memory_search, leaving no ambiguity about its function.

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

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

The description provides explicit guidance on when to use the tool: 'for capturing important context, decisions, or things to remember'. While it doesn't list alternatives, sibling tool names imply read/search tools exist, making the usage context clear.

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

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

With no annotations provided, the description carries the burden of behavioral disclosure. It omits any mention of side effects, return values, error conditions, or whether the operation is synchronous. The simple statement 'Uses OpenClaw message delivery' adds minimal context.

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

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

The description consists of two concise sentences with no wasted words. It front-loads the core action and resource, making it immediately scannable.

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 (3 parameters, no output schema, no nested objects), the description is mostly adequate but lacks information about the return format or confirmation of delivery. This omission reduces completeness slightly.

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

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

Schema description coverage is 100%, so the parameters are already well-documented in the schema. The description does not add further meaning or context beyond what the schema provides, which meets the baseline.

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

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

The description clearly states the verb 'Send' and the resource 'notification', specifying the channels (WhatsApp, Telegram, last-used). It effectively distinguishes from sibling tools, none of which are notification tools.

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

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

The description implies usage for sending messages via supported channels, but lacks explicit guidance on when to use this tool versus alternatives or when not to use it. No exclusions or prerequisites are mentioned.

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

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

No annotations provided, so description must disclose behavior. It only says 'list all plugins', with no mention of side effects, authorization, rate limits, or response format.

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

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

Single sentence, front-loaded with key verb and resource, zero waste.

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

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

For a simple zero-param list tool, description is adequate but would benefit from mentioning output format (e.g., plugin names or objects). Without an output schema, a hint would improve completeness.

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

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

No parameters exist; schema coverage is 100% by virtue of being empty. Baseline for 0 params is 4; description adds nothing extra because nothing is needed.

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

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

Description uses specific verb 'List' and resource 'all plugins installed on the OpenClaw server', clearly distinguishing from sibling tools like openclaw_status or openclaw_logs.

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

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

Implied usage is when one needs to see installed plugins, but no explicit guidance on when to use vs. alternatives or when not to use.

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

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

No annotations are provided, so the description must cover behavioral traits. It mentions SSH access and agent capabilities but does not disclose behavior like synchronous waiting, error handling, or side effects. The timeout_seconds parameter implies a wait but is not explained.

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

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

The description is concise, front-loaded, and information-dense. Three sentences deliver purpose, capability, and usage guidance without unnecessary details.

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

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

Given no output schema, no annotations, and many sibling tools, the description is somewhat thin. It lacks details on return format, error scenarios, and explicit comparisons to alternatives like openclaw_cron_run. Adequate but not comprehensive.

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

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

Schema description coverage is 100% (all parameters documented). The description adds no additional meaning beyond what the schema already provides, so baseline score of 3 is appropriate.

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

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

The description clearly states the action ('Send'), the resource ('OpenClaw AI agent'), and the method ('via SSH'). It distinguishes from sibling tools like claude_run, codex_run, gemini_run, and local_llm_run by specifying that this delegates complex tasks that OpenClaw already knows how to handle.

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

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

The description explicitly says 'Use this to delegate complex tasks that OpenClaw already knows how to handle', providing a clear usage context. However, it does not explicitly state when not to use or mention alternatives among the many sibling run 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?

No annotations are provided, so the description must cover behavioral traits. It correctly implies a read-only operation, but does not explicitly confirm no side effects or mention permissions needed. For a status check, this is minimally 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?

A single sentence of 15 words that is front-loaded and direct. Every word earns its place with no 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 no output schema and no parameters, the description covers the essential purpose. It could mention what the response looks like (e.g., boolean and version string) but remains adequate for a simple tool.

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

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

The tool has zero parameters, so schema coverage is trivial. Baseline for 0 params is 4. The description adds no parameter info as none are needed, which is appropriate.

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

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

The description clearly states the tool checks if the OpenClaw daemon is running and retrieves version info. The verb 'check' and resource 'OpenClaw daemon' are specific, and it distinguishes from sibling tools like openclaw_cron_status or openclaw_run.

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 when to use or alternatives are provided. While the purpose is self-evident for a status tool, guidelines could mention situations like verifying daemon health before running commands. Lack of exclusions or context makes it adequate but not exemplary.

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 describes the output (structured plan with agent assignments, dependency ordering, prompts), the strategy parameter's behavior, and the required user review. It does not cover authorization needs or error handling, but the core behavior is 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 concise (4 sentences, ~108 words), front-loads the main purpose, and each sentence adds value. No redundant or vague phrasing.

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 (2 parameters, no output schema), the description covers the return structure, strategy options, and usage note. It could mention potential limitations (e.g., prompt length constraints), but overall it is sufficiently complete for an agent to use 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?

Both parameters are described in the schema (100% coverage). The description adds extra meaning for the 'strategy' parameter by explaining each enum value's behavior in detail, which goes beyond the schema's minimal descriptions.

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

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

The description clearly states the tool's purpose: 'Analyze a complex prompt and split it into sub-tasks with agent assignments.' It specifies the resources involved (sub-agents like gemini, codex, openclaw, local LLM) and distinguishes from sibling tools that are execution-focused (e.g., gemini_run, codex_run).

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

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

The description implies usage for decomposing complex prompts, and includes an important guideline to 'always present the plan to the user for review before executing.' However, it does not explicitly state when to use this tool versus alternatives (e.g., directly using a run tool) or provide exclusion criteria.

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

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

No annotations are provided, so the description carries full burden. It discloses that the tool runs subtasks in dependency order, dispatches to sub-agents, passes results between tasks, and enforces rate limits. It also mentions dry_run for preview. However, it doesn't explicitly state potential side effects or whether this tool is destructive.

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, efficiently front-loading the primary purpose and then covering optional inputs and dry_run. Every sentence adds unique value with no redundancy or fluff.

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 (multi-step execution, dependencies, rate limits) and absence of an output schema, the description omits crucial details about return values, error handling, or execution results. While dry_run output is hinted, the actual execution output format is not described, leaving a gap for agents.

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

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

Schema coverage is 100%, but the description adds meaningful context beyond the schema: it explains the conditional relationship between 'plan' and 'prompt' (if no plan, prompt is used to generate one), and elaborates on overrides (change agent/model/prompt per task or skip). This helps the agent understand parameter usage beyond formal definitions.

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

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

The description clearly states the tool's purpose: executing a prompt_split plan, running subtasks in dependency order, dispatching to sub-agents, and enforcing rate limits. It distinguishes from sibling tools like prompt_split (which generates plans) and direct run tools, but could be more explicit about when to use this versus individual run tools.

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

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

The description explains when to use the tool: provide a 'plan' or a 'prompt', and optionally use 'overrides' to modify per-task settings. However, it does not specify when not to use this tool (e.g., for single-step tasks) or explicitly mention alternatives among sibling tools like claude_run.

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 must fully disclose behavior. It mentions SSH and actions but omits side effects (e.g., service disruption from stop/restart) and prerequisites like SSH key authentication.

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

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

Two short, front-loaded sentences with no fluff. Every word adds value, covering purpose, mechanism, actions, and a key advantage.

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 no output schema, yet the description does not hint at return values (e.g., container lists, log lines). For a multi-action tool with conditional parameters, this omission reduces completeness.

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

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

Schema coverage is 100%, so baseline is 3. The description does not add significant meaning beyond the schema, merely listing action names without explaining parameter relationships or output.

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 manages Docker containers via SSH, listing specific actions. However, it does not explicitly differentiate from sibling tools like remote_shell or remote_service, leaving implicit contrast.

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 notes 'No Docker API or open port needed,' indicating suitable when SSH is available. However, it lacks explicit when-not-to-use guidance or comparison with alternatives.

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

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

Discloses that the tool operates over SSH, indicating network and authentication needs. However, it does not mention required permissions (e.g., root), side effects of actions, or error handling behavior. Basic transparency but incomplete for a mutating tool.

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

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

Two sentences with no redundant information. The front-loaded purpose and action list are efficiently packed, earning every sentence's keep.

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

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

Covers core functionality (systemd management via SSH) and param semantics, but omits return value format for actions like status, and does not specify error behavior. For a tool with no output schema, some description of output would be helpful.

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 descriptions cover 100% of parameters with clear enum and service name examples. The description adds no significant extra meaning beyond listing actions, which is already in the schema. Baseline score applies due to full schema coverage.

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

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

Clearly states it manages systemd services on a remote Linux server via SSH, listing all specific actions. This distinguishes it from sibling tools like remote_shell or remote_docker, making the purpose unambiguous.

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

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

Implies usage for systemd service management on a remote server, but does not provide explicit when-to-use vs when-not-to-use guidance or mention alternatives. The context is clear but lacks exclusions or comparisons.

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 tool runs commands on a remote server, but lacks details on security, error handling, or what happens on timeout. Adequate but not comprehensive.

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

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

Two sentences with no redundant information. The first sentence states the primary action, the second provides usage context. Efficient 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?

Given the simple tool (2 parameters, no output schema), the description adequately explains purpose, use cases, and defaults. Missing return value details, but this is minor for a shell command tool.

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

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

Schema coverage is 100% and parameter descriptions are clear. The description does not add significant meaning beyond the schema, so baseline score of 3 is appropriate.

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

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

Description clearly states 'Run a shell command on the configured remote Linux server' and provides specific use cases (deployments, log checks, service restarts). It distinguishes from siblings like remote_docker and remote_service by focusing on arbitrary shell commands.

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 lists when to use (deployments, log checks, service restarts, ad-hoc commands) but does not mention when not to use or alternative tools. The context is clear and helpful.

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 must disclose all behavioral traits. It describes the return as status and latency, implying a read-only operation, but does not confirm safety or mention any authorization needs or side effects. It is adequate but minimal.

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

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

The description is a single, well-structured sentence that front-loads the primary action and lists services. Every word earns its place, with no 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 no output schema, the description adequately explains the return value. It covers the main purpose but could benefit from mentioning that it is non-destructive or how to interpret latency. Overall, it is complete for a simple health check 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?

There are no parameters, so the schema covers everything. The description adds value by explaining the output structure (unified status with latency), which is sufficient for this simple tool. Baseline 4 since 0 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 clearly states the tool's purpose: checking health of all connected services (Home Assistant, OpenClaw, local LLM, Gemini CLI, Codex CLI) at once, returning a unified status overview with latency. It uses a specific verb and resource, and distinguishes itself from sibling tools like openclaw_status which likely focus on individual services.

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

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

The description implicitly suggests using this tool for a broad overview of all services, but does not provide explicit guidance on when not to use it or mention alternatives. No exclusions or context for choosing this over sibling monitoring tools.

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