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

Without annotations, the description carries the full burden and discloses that the tool is not read-only, triggers an agent turn, and auto-generates idempotencyKey. It could mention more side effects but is sufficient.

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 plus a preference note, all front-loaded and concise. Every sentence adds value 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?

No output schema, but the description mentions returns the agent's response. It covers wire format, requirements, and preferences. Could be more detailed on error behavior, but adequate given schema coverage.

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

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

Schema coverage is 100%, baseline 3. The description adds value by clarifying that idempotencyKey is logically required though not in schema's required list, and highlights key 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 sends a message to the default agent and returns the response. It distinguishes itself from sibling openclaw_sessions_send by noting this is root-level and uses the default agent.

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 recommends using openclaw_sessions_send for explicit session control, and notes this tool is not read-only and triggers an agent turn, guiding appropriate usage.

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

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

No annotations provided, but description marks it as 'Read-only', clearly indicating no side effects. Also reveals it wraps 'agent.identity.get', giving insight into the underlying behavior. Adequate for a simple getter.

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

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

Extremely concise: two sentences covering purpose and behavior with no extraneous detail. Every word 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 tool with one optional parameter and no output schema, the description provides enough context to understand what the tool does and that it returns metadata. Lacks detail on return structure, but given the simplicity, it is nearly 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%, with schema already explaining the 'instance' parameter thoroughly (fallback, env vars, listing instances). Description adds no new information beyond what is 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?

Clearly states verb 'get', resource 'gateway's agent identity', and scope 'current default agent metadata'. Distinguishes from siblings by specifying it wraps a specific internal function and is read-only.

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

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

No explicit guidance on when to use this tool versus alternatives. While it mentions read-only and the wrapped function, it does not differentiate from similar tools like 'openclaw_agent' or provide context about when not to use it.

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

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

No annotations are provided, so the description must fully disclose behavior. It mentions wrapping `agents.create` and passing parameters, but omits side effects, authorization needs, return values, or what happens when required fields are omitted. 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 two sentences with no wasted words. It front-loads the purpose and provides actionable advice concisely.

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

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

As a create tool with no output schema, the description should explain what happens on success, required permissions, or error states. It does not, leaving the agent with significant gaps in understanding the tool's behavior.

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

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

Schema coverage is 100% with clear parameter descriptions. The description summarizes key parameters and mentions extra fields, but adds no new semantic meaning beyond 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 tool creates a new agent configuration with specific verb and resource. It distinguishes from sibling tools like openclaw_agents_update and openclaw_agents_delete by name and action.

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 advises to call openclaw_agents_list first to see the full shape of an existing agent, providing context for usage. However, it lacks explicit when-not-to-use or alternatives beyond this one tip.

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 effectively discloses that the operation is destructive and that tied sessions may be orphaned, providing important behavioral context beyond the tool's name.

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 that state the action and then provide crucial warnings. 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?

The description adequately covers the core behavior and side effects for a delete tool. It could mention the return value or confirmation requirement more explicitly, but it is mostly complete for the task.

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 has 100% coverage with clear descriptions for both parameters. The tool description adds no additional parameter information, so it meets the baseline but does not enhance semantics.

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

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

The description clearly states the action ('delete') and resource ('agent configuration'), and distinguishes itself from siblings like create/update by specifying it is a deletion operation.

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

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

The description includes a destructive warning and advises to confirm before calling, but does not explicitly specify when to use versus not use this tool, nor does it mention 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?

States the tool is read-only and wraps agents.files.get, which provides basic behavioral context. However, with no annotations provided, the description should disclose more details like error handling, authentication requirements, or rate limits, but it does not.

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 clear, front-loaded sentences. The first sentence states the purpose and expected contents, the second clarifies parameter usage. No redundant or extraneous text.

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

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

Covers the core purpose and parameter constraint but lacks details about return format, error handling, and authentication. Given the absence of an output schema and annotations, the description could be more complete to aid agent decision-making.

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 75%, and the description reinforces the mutual exclusivity of path and name, which is already declared in the schema. It does not add significant new meaning beyond what the input schema provides, earning a baseline score.

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

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

Clearly states it fetches contents of a specific agent file, listing examples like system prompt and tool definitions. Differentiates from sibling tools like openclaw_agents_files_list and openclaw_agents_files_set by specifying 'specific' file and 'contents'.

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 instructs to use either path or name, not both, and marks the tool as read-only. While it doesn't explicitly state when not to use it versus alternatives, the context from sibling tool names makes the distinction 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 present, the description carries the full burden. It adds 'Read-only' and 'Wraps agents.files.list', which are useful behavioral traits. However, it does not disclose other traits like pagination, error behavior, or performance characteristics. For a simple list operation, this is 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 very concise with one sentence and a note. It front-loads the key action 'List files attached to an agent' and has no redundant text. Every word earns its place.

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

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

The tool has low complexity (2 parameters, no output schema). The description covers the core functionality and read-only nature, but does not mention the return format or error conditions. It is mostly complete for a list tool, lacking only minor 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?

Schema coverage is 100%, so the schema already documents both parameters. The description does not add any additional semantic detail beyond what's in the schema, such as format, constraints, or relationships. 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 'List files attached to an agent (instructions, system files, etc.).' It specifies the verb (list) and the resource (files attached to an agent), and distinguishes from siblings like openclaw_agents_files_get and openclaw_agents_files_set through its listing action.

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 listing usage by noting it is read-only and wraps a list API, but does not explicitly state when to use this tool versus alternatives like get or set, nor does it mention prerequisites or exclusion conditions.

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

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

No annotations are provided, so the description carries the full burden. It discloses that the tool is destructive and silently overwrites content. However, it does not mention permissions, error behavior, or return value, which are important for understanding behavior.

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

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

The description is two sentences with the purpose front-loaded. It is concise and avoids unnecessary words, though it could be more structured (e.g., separating parameter guidance).

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 large sibling set and no output schema, the description lacks information about what the tool returns (e.g., success indicator, file metadata). It adequately covers input parameters but misses output context, leaving the agent uncertain about the result.

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 83%, so the baseline is 3. The description adds clarity by grouping mutually exclusive parameters (path/name, content/body) and noting version-dependence, but this is a minor addition to already-good schema 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 writes or overwrites agent files, using a specific verb and resource. It is distinct from sibling tools like openclaw_agents_files_list and openclaw_agents_files_get which are read-only, and from agent management 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 does not explicitly state when to use this tool vs alternatives. It mentions that it wraps `agents.files.set` but does not contrast with sibling tools. Usage context is implied but not explicitly guided.

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 the description discloses the operation is read-only and wraps agents.list. This sufficiently conveys the behavioral profile for a list operation.

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

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

Two short sentences with no redundancy. The key information (what it does, example, underlying API, read-only nature) is front-loaded.

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

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

For a list tool with no output schema, the description conveys the purpose and scope. It could mention the return format (e.g., list of agent names) but is still adequate given the 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 covers 100% of the parameter, but the description adds valuable context like fallback behavior and a cross-reference to another tool (openclaw_setup_list). This goes beyond the schema's description.

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

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

Description clearly states the verb 'list' and resource 'configured agents on the gateway', with examples like 'main'. It distinguishes from sibling tools that create, update, or delete agents. The read-only note adds clarity.

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

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

Description implicitly suggests using this tool to see available agents before modification, but does not explicitly state when to use or avoid it. No alternatives are mentioned, but none are needed given the unique purpose.

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 bears full responsibility. It mentions 'permissive schema' and that the gateway 'accepts the same shape as agents.create,' but does not disclose security requirements, side effects, idempotency, or confirmation behavior 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 three concise sentences, each serving a purpose: purpose statement, usage pattern, and schema behavior. It is front-loaded with the primary 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?

Given no output schema and no annotations, the description omits return value information, error scenarios, permission requirements, and any behavioral caveats for a mutation operation. It falls short of completeness for safe agent usage.

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

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

Schema coverage is 100% with both parameters described. The description adds value by clarifying that additional properties beyond the schema are allowed ('Schema is permissive') and that only changed fields need be passed, improving 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 action ('Update an existing agent's configuration'), names the wrapped API ('agents.update'), and emphasizes partial updates ('Pass `agentId` + only the fields you want to change'). It distinguishes from sibling tools like `agents.create` by noting the permissive schema.

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

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

The description implies when to use (update existing agent) but does not explicitly state when not to use or provide alternatives among siblings (e.g., openclaw_agents_create, openclaw_agents_delete). It lacks contextual guidance for conditional 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?

With no annotations, the description carries full burden. It discloses that the tool is long-running, uses a timeout (default 30s), and wraps `agent.wait`. However, it does not describe what happens on timeout (error vs. return), side effects, or return value. Adequate but lacks depth.

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 are efficient and front-loaded with the core action. No redundancy. Could be improved by structuring into separate points (e.g., behavior, parameters, notes), but still concise and readable.

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

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

With 4 parameters, no output schema, and no annotations, the description should provide more context about parameter usage, failure modes, and when to use. It only covers the basic blocking behavior, leaving significant gaps for effective agent selection and invocation.

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

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

Schema description coverage is only 25%, but the tool description adds no explanations for the parameters (agentId, sessionId, timeoutMs). Only implicitly mentions timeoutMs via the 'default 30s' note. The description fails to compensate for the low coverage, leaving most parameters unexplained.

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 blocks until the agent finishes its current turn or timeout, specifying the verb 'block' and resource 'agent'. It distinguishes the core action from siblings like openclaw_agent (which sends commands) but does not explicitly differentiate from other wait-type tools like openclaw_exec_approval_waitDecision.

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. Does not mention prerequisites, when not to use it, or suggest sibling tools like openclaw_agent or other wait functions. The description only states what it does, not when it's appropriate.

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

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

Emphasizes the destructive nature and user validation requirement. Lists mutating method patterns to watch for. Despite no annotations, the description fully discloses risks and constraints.

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

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

Front-loaded warning, two sentences of purpose, and clear parameter guidance. No redundant content; every word earns its place.

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

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

Given the generic nature and large sibling set, the description perfectly covers when to use, what to expect, and how to invoke safely. Lacks output schema but tool returns raw RPC response, which is adequately implied.

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?

Adds value beyond the 100% coverage schema: explains the method naming convention, warns that params must be an object, and clarifies instance fallback behavior. No gaps.

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 'call ANY JSON-RPC method on the gateway with arbitrary params' and distinguishes from typed alternatives. The phrase 'DESTRUCTIVE ESCAPE HATCH' immediately signals its role.

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 says 'Use this to operate on endpoints that don't yet have a typed wrapper' and warns to prefer typed tools for read-only inspection. Provides concrete examples of 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?

Discloses destructive behavior and its consequence (channel undeliverable until re-auth). No annotations exist, so description carries full burden and meets it well.

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 concise, front-loaded sentences. No filler; each sentence adds unique 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?

Adequately covers action, destructive nature, and parameter usage. Could mention error cases (e.g., invalid channel) but not required for basic use. No output schema 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%, so baseline is 3. Description adds no new meaning beyond schema descriptions; e.g., 'channel name' example repeats 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?

Clearly states verb (log out/disconnect) and resource (delivery channel). Distinguishes from sibling 'openclaw_channels_status' which is read-only. No tautology.

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 warns that action is destructive and channel won't deliver until re-authenticated. Provides example parameter. Lacks explicit 'when not to use' but context is 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?

No annotations provided, so the description carries full transparency burden. It states 'Read-only' which indicates no side effects, but does not disclose error handling, auth requirements, or performance implications. Adequate but minimal for a simple status check; could mention that it returns per-channel status objects.

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 unnecessary words. Clearly states purpose and key attribute (read-only). Every sentence 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 low-complexity tool with one optional parameter and no output schema, the description is minimally adequate. It tells the agent what the tool does and its safety profile, but could be improved by hinting at the response format (e.g., 'Returns status objects per channel') to fully inform agent decisions.

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 the single parameter 'instance' is well-documented in the schema (optional, fallback behavior). The tool description does not add any extra parameter semantics beyond what the schema provides, so 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 'Get the connection status of delivery channels' with examples (Telegram, email), specifies it wraps an internal command, and explicitly marks it as read-only. This provides a specific verb-resource pair and distinguishes it from sibling tools like openclaw_channels_logout or openclaw_device_status.

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

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

No explicit guidance on when to use this tool versus alternatives. The description lacks conditions for use, prerequisites, or exclusions. While the read-only hint is present, it does not help an agent decide between this and other status-related tools (e.g., openclaw_device_status, openclaw_status).

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

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

With no annotations, the description fully discloses that the tool is destructive by cancelling a running LLM call. It also mentions the wire format requires sessionKey, adding operational transparency. However, it does not detail what happens if no turn is in-flight.

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—only two sentences. The first sentence front-loads the purpose, and the second provides key operational details. 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 simplicity, the description covers the core action and destructive nature. However, it lacks context on return values, error scenarios, or prerequisites (e.g., session must exist and have an in-flight turn), making it only 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% with both parameters well-described. The description reinforces the need for sessionKey but adds no new semantic information beyond the schema. 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 tool aborts an in-flight chat turn for a session, using the verb 'abort' and specifying the resource. It distinguishes from sibling tools like openclaw_sessions_abort by focusing on the chat turn rather than the entire session.

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 when an in-flight chat turn needs to be cancelled but provides no explicit guidance on when not to use it or how it compares to alternatives like openclaw_sessions_abort.

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 and adds critical behavioral details: 'Read-only', 'Wire format (verified live)', and rejection of old parameter fields. This alerts the agent to strict parameter validation and safety, though output format is omitted.

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: first states purpose, second explains wire format, third warns about deprecated fields. Every sentence adds value, no redundancy, and structure front-loads the core purpose.

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

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

For a simple fetch tool with 3 parameters, the description covers essential constraints but lacks detail about return format or pagination (no output schema). It is adequate for basic use but leaves gaps in expected results.

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

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

Schema covers 67% of parameters with descriptions. The tool description adds a mention that sessionKey is 'Composite session key from openclaw_sessions_list' and that old fields are rejected, but does not elaborate on limit's meaning or instance's behavior beyond what the schema provides. Baseline 3 due to high schema coverage.

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

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

Description clearly states 'Fetch chat history for a session' with a specific verb and resource. It distinguishes from siblings by mentioning 'Wraps chat.history' and rejecting pre-0.5.x fields, ensuring the agent knows this is the standard way to retrieve history.

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 implies usage by stating required and accepted parameters, but lacks explicit when-to-use or when-not-to-use guidance relative to siblings like openclaw_chat_send or openclaw_chat_abort. The context is clear but exclusions are not stated.

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

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

With no annotations, the description carries full disclosure burden. It explicitly states 'Destructive — triggers an agent turn', which is a key behavioral trait. It also mentions wire format version compatibility, but does not cover rate limits or authentication needs.

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 paragraph of four sentences, front-loading the purpose and then adding essential details. Every sentence adds value; 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?

For a tool with 4 parameters, 2 required, no output schema, the description covers purpose, required parameters, idempotency, version warnings, and destructive nature. It does not mention the return format, which would be helpful given no output schema, but overall it is quite 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 coverage is 100%, so baseline is 3. The description adds value beyond schema by explaining that sessionKey is composite from openclaw_sessions_list, idempotencyKey is auto-generated if omitted, pre-0.5.x shape is rejected, and instance parameter has fallback behavior.

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

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

The description clearly states 'Send a message into a chat session via the gateway's chat layer', specifying verb (send) and resource (message into chat session). It distinguishes from sibling tools like openclaw_sessions_send and openclaw_send by referencing the chat layer and gateway specifics.

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 specifies required parameters (sessionKey, message, idempotencyKey) and warns about the deprecated pre-0.5.x shape, but does not explicitly state when to use this tool vs alternatives. However, the purpose is distinct enough that an agent can infer appropriate 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 bears full responsibility. It only states 'Read-only', which is a useful safety hint, but lacks details on authentication, rate limits, failure modes, or side effects beyond the read-only claim.

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

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

The description is two sentences with no extraneous information. The purpose is front-loaded, making it efficient and 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?

The description lacks explanation of the return format or structure, which would be helpful given the absence of an output schema. However, for a simple list operation, the agent may still infer adequately.

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 detailed description for the 'instance' parameter. The tool description does not add additional meaning beyond the schema, resulting in baseline performance.

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 slash-commands registered in the gateway, specifying the scope (agent/operator invokable) and noting it wraps `commands.list`. This distinguishes it from sibling tools like openclaw_setup_list which list instances.

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

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

The description does not explicitly state when to use this tool over alternatives. While the purpose is clear, there is no guidance on context or exclusions, leaving the agent to infer usage.

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

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

No annotations are provided, so the description bears full responsibility for behavioral disclosure. It labels the tool as 'destructive' and mentions propagating changes to running components, but fails to disclose required permissions, reversibility, error handling, or potential impact (e.g., service disruption). For a destructive operation, this is insufficient.

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

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

Two concise sentences: the first identifies the core action, the second adds critical behavioral context. Every word earns its place. No redundancy or unnecessary elaboration.

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

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

While the description covers the basic purpose and destructive nature, it lacks details about the buffering mechanism, prerequisites (e.g., pending changes must exist), and return behavior. No output schema exists, so the description should indicate what the tool returns (e.g., success/failure, list of applied changes). The sibling tools suggest a config workflow, but the description does not fully integrate this context.

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

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

The input schema has 100% description coverage for the single optional parameter `instance`. The description adds no additional semantic detail beyond what the schema provides. Per guidelines, high schema coverage yields a baseline 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 tool applies pending config changes (commit) and wraps `config.apply`. It also labels the operation as destructive and explains it propagates buffered config to running components, making the purpose unambiguous. However, it does not explicitly differentiate from sibling config tools like `openclaw_config_patch` or `openclaw_config_set`, which could cause slight confusion.

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 should be used after buffering config changes, but it does not explicitly state when to use or avoid it. Alternatives like `openclaw_config_set` (direct set) or `openclaw_config_patch` (modify without apply) are not mentioned. The context signals and sibling list hint at the config workflow, but explicit guidance is missing.

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 is read-only and that the gateway always returns the full config, with path applied client-side. No annotations exist, so the description carries the full burden; it covers key behavioral traits but omits error scenarios or auth requirements.

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

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

Two concise sentences, front-loaded with purpose, followed by essential behavioral detail. No wasted words; every sentence 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?

Given no output schema, the description adequately states it returns the full config. The two parameters are fully covered by schema and description. For a simple read tool, all necessary information is present.

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

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

With 100% schema coverage, the description adds the crucial insight that path does not filter server-side, which is not evident from the schema alone. Instance parameter is well-documented in schema; description does not add extra but does not detract.

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 reads the gateway's current configuration and explicitly marks it as read-only. It distinguishes from sibling write tools like openclaw_config_set/openclaw_config_patch by verb and usage of 'read'.

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

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

Explains that the path parameter is applied client-side and does not reduce wire traffic, which guides proper usage. Does not explicitly compare to other read operations, but given no sibling read config tools, the guidance is sufficient.

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

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

With no annotations, the description fully informs about destructive atomic replacement and optimistic locking via base hash. It also mentions the convenience flow's internal fetch-merge-submit steps. Additional details like error handling or permission requirements are absent, but the core behavioral traits are well communicated.

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 focused paragraph that front-loads the primary purpose and concisely explains the two modes of operation. Every sentence contributes useful information without excessive verbosity.

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

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

Given the complexity of 5 parameters and no output schema, the description covers usage patterns and destructive nature but omits return values, error responses, and prerequisites beyond mentioning the baseHash source. This leaves the AI agent needing to infer some aspects.

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 5 parameters are documented in the schema with descriptions, achieving 100% coverage. The description adds context about the two flows (raw/baseHash vs mergePath/mergeValue) and the role of baseHash from a previous get call, but this aligns with schema information. Thus 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 that the tool performs an 'Optimistic-locked replace of the FULL gateway config' and explains both the direct raw+baseHash flow and the convenience mergePath+mergeValue flow. This distinguishes it from sibling config tools like openclaw_config_set (likely partial updates) or openclaw_config_apply (possibly different semantics).

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 guidance on when to use each flow: the raw+baseHash approach for pre-serialized configs and the mergePath+mergeValue for targeted deep-merges. However, it does not explicitly compare with or exclude other config tools, though the destructive note implies caution.

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

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

With no annotations, the description carries the full burden and states 'Read-only' and 'Wraps config.schema', indicating no side effects. Lacks details on auth or rate limits, but sufficient for a simple read operation.

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

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

Two sentences, each essential. First sentence states core purpose, second provides usage context. 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 tool with one optional param and no output schema, the description fully covers what the tool does, when to use it, and its read-only nature. No gaps needing elaboration.

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

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

Schema description coverage is 100% for the single parameter, so baseline is 3. The tool description does not add any extra meaning beyond the schema's own parameter description.

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

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

The description clearly states the tool retrieves the JSON schema for the gateway's config structure, using specific verb 'get' and resource 'config schema'. It distinguishes from sibling tools like config_set/patch by noting it is useful before those mutations.

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 says 'Read-only — useful before openclaw_config_set/patch', providing clear context for when to use and hinting at alternatives. Minor gap: doesn't differentiate from sibling openclaw_config_schema_lookup.

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 states 'Read-only', which indicates no side effects, but does not mention authentication needs, rate limits, or error conditions. It is adequate but lacks depth.

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 short sentences. It front-loads the key action 'Look up the schema description' and adds an implementation reference ('Wraps config.schema.lookup'). 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 simplicity (no output schema, 2 params), the description is mostly adequate. However, it does not describe the return format or behavior when path is invalid, which would complete the picture.

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 no additional meaning beyond the schema's parameter descriptions. It simply restates the purpose without explaining parameter use or format.

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 looks up the schema description for a config path. It uses specific verb 'look up' and resource 'config path', distinguishing it from sibling tools like config_get (which gets values) or config_schema (which might show all schemas).

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

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

The description implies when to use it (to get schema description) but does not provide explicit when-not-to-use guidance or mention alternative tools for similar tasks, such as openclaw_config_get or openclaw_config_schema.

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?

Describes the tool as 'Destructive — overwrites the previous value,' which is a key behavioral trait. Since no annotations are provided, the description carries the full burden; it adds this critical detail but omits others like authorization requirements, side effects, or reversibility, leaving gaps.

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 concise sentences: first states the action, second adds a keyword and destructiveness, third provides an alternative. No redundant information; every sentence serves a purpose.

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

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

Given the tool's low complexity (3 params, all described) and no output schema, the description covers purpose, parameters, and usage guidelines adequately. However, it does not mention what the function returns (e.g., success indication or the new value), which is a minor gap.

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

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

Schema coverage is 100% with descriptions for all parameters, but the description adds value beyond the schema by stating that the path is dotted and that value is 'passthrough' with no schema enforced. It also explains the fallback logic for the instance parameter. This extra context justifies a score above the baseline 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?

Clear verb+resource ('Replace a config value') and distinguishes from sibling 'openclaw_config_patch' for partial updates. The description explicitly states what the tool does and how it differs from a similar tool.

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

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

Explicitly recommends preferring openclaw_config_patch for partial updates, guiding the agent away from this tool when a less destructive operation is suitable. However, no other usage scenarios or when-not-to-use conditions are mentioned beyond that.

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 behavioral traits. It mentions wrapping cron.add and clarifies field formats, but omits critical details like error handling, idempotency, side effects, or required 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?

The description is front-loaded with the purpose and efficiently uses sentences to clarify field formats and give an example. It is moderately long but every sentence serves a purpose, though it could be slightly trimmed without losing 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?

Given the complex nested input schema and no output schema, the description covers the main creation aspects and field details but lacks guidance on usage context, failure modes, or relationship to sibling tools. It is adequate but has notable gaps.

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

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

Schema coverage is 50%, and the description adds value by explaining correct field names (e.g., expr/tz instead of incorrect placeholders) and providing a concrete example. However, it does not cover all parameters (e.g., delivery, deleteAfterRun) and only partially compensates for the schema gap.

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

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

The description clearly states 'Create a new OpenClaw cron job', specifying the action (create) and resource (cron job). It distinguishes itself from sibling convenience wrappers like openclaw_cron_add_weekly by being the general-purpose version, but does not explicitly name those alternatives.

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

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

No guidance is given on when to use this tool versus its siblings (e.g., openclaw_cron_add_weekly, openclaw_cron_add_every). The description focuses solely on technical field details and does not provide context for optimal selection.

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

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

With no annotations, the description carries full burden. It discloses key behaviors: the cron schedule synthesis, agentTurn payload, parameter defaults (timezone, timeout), and optional channel delivery. However, it does not detail what happens when channel is omitted (result internal) or other side effects like overwriting existing jobs.

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 main purpose, and free of fluff. Every sentence contributes essential information, making it easy to scan.

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 12 parameters and no output schema, the description covers the core functionality, required parameters, and optional delivery. It lacks details on return values or error conditions, but given the complexity, it is reasonably complete and actionable.

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 67%, so the schema already describes many parameters. The description adds value by highlighting the most critical parameters (hour, minute, tz, message) and their role in the cron schedule and agent payload, going beyond the schema's individual 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 explicitly states the tool creates a daily cron job at a fixed local time, distinguishing it from sibling tools like openclaw_cron_add_weekly or openclaw_cron_add_once. It lists key parameters (hour, minute, tz, message) and optional channel delivery, making the purpose unmistakable.

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 daily scheduling through the tool name, but does not explicitly state when to use this vs. other cron variants (e.g., openclaw_cron_add_weekly). No direct guidance on alternatives or exclusions is provided, though the context of 'daily' is 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?

No annotations are provided, so the description must carry the full burden of behavioral disclosure. It states the tool creates a cron job and computes the interval, but does not mention side effects (e.g., duplicate handling), required authentication, rate limits, or return behavior. For a mutation tool, this is insufficient.

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

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

The description is three sentences, front-loaded with the verb and resource, and contains no fluff. Every sentence contributes useful 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 tool has 11 parameters, no output schema, and is a mutation, the description is somewhat incomplete. It doesn't explain the return value, failure modes, or integration with the broader cron system. The high schema coverage partially compensates, but more context would be beneficial.

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 high (91%), so the schema already documents most parameters. The description adds value by clarifying that either intervalMinutes or intervalHours should be passed and that the tool computes everyMs. However, it does not add meaning for required parameters like name and message beyond what the schema provides.

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

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

The description clearly states the tool creates a cron job that fires every N minutes/hours regardless of clock time, distinguishing it from wall-clock aligned cron tools. It specifies the verb 'Create', the resource 'cron job', and the scheduling pattern 'every'-kind, making the purpose unmistakable.

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: 'Pass either intervalMinutes or intervalHours' and 'Use for monitoring jobs that don't care about wall-clock alignment.' This clearly indicates when to use the tool, though it does not explicitly mention alternatives like openclaw_cron_add_daily or when not to use it.

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

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

With no annotations, the description carries the full burden. It correctly states the job fires once then auto-deletes, but omits edge cases like past timestamps or name uniqueness requirements.

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

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

Three sentences, front-loaded with the core purpose, then technical detail and parameter hint. No redundant or extraneous text.

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

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

For a scheduling tool with 10 parameters and no output schema or annotations, the description covers the essential behavior but misses guidance on timestamp validation, name uniqueness, and optional channel setup.

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 90%, so the description adds little beyond what the schema provides. It repeats the RFC3339 format for 'at' and mentions 'message', but does not explain optional parameters like 'channel' or 'deliveryMode'.

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 creates a one-shot reminder/job that fires once and auto-deletes. It specifies the schedule type and required parameters, distinguishing it from recurring cron tools like openclaw_cron_add.

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 one-shot jobs by naming it 'add_once' and describing the auto-delete behavior. However, it does not explicitly contrast with recurring variants or mention when not to use it.

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

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

No annotations provided, so description must fully convey behavior. It describes the synthesis of schedule and payload, and the call to cron.add, but does not disclose return behavior, side effects, auth requirements, or what happens if channel is omitted. Partial 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: first states purpose and mechanism, second lists parameters. No extraneous information, front-loaded with key details. Very concise and well-structured.

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 should mention return behavior; it does not. With 13 parameters, the description focuses on the core ones but omits model, agentId, instance, deliveryMode, timeoutSeconds. Schema covers them, but the lack of return info and some parameter context makes it moderately 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 coverage is 100%, so baseline is 3. The description adds value by grouping key parameters and explaining their roles (e.g., 'Pass dayOfWeek, hour, minute, tz, and message') and the optional channel delivery pair, beyond the schema's individual 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 it creates a weekly cron job at a fixed local time, specifying the schedule and payload synthesis. It distinguishes from siblings like openclaw_cron_add_daily and openclaw_cron_add_once through the name and parameter 'dayOfWeek'.

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 required parameters (dayOfWeek, hour, minute, tz, message) and optional channel delivery, implying usage for weekly tasks. However, no explicit guidance on when to use this vs. other cron add tools or when not to use it.

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

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

No annotations, so description must disclose behavior. It does not state read-only nature, authentication needs, or pagination behavior. Only lists return fields, which is minimal. Mentions internal JSON-RPC but no safety 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?

Two short sentences, front-loaded with purpose. No extraneous words. 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, but description lists return fields adequately. Lacks explanation of pagination or sorting behavior, but given 8 params and no output schema, it is mostly complete for a list 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 50%, so baseline is 3. Description adds no extra meaning beyond schema; it doesn't explain how parameters like limit, offset, sortBy filter or sort results. Only mentions filter fields in schema.

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

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

Clear verb+resource: 'List configured OpenClaw cron jobs'. Specifies return fields (name, schedule, payload kind, enabled state). Distinguishes from siblings like openclaw_cron_status or openclaw_cron_runs.

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 provided. Agent must infer from context with sibling cron tools; lacks guidance on choosing list vs. status or runs.

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 explicitly labels the operation as 'Destructive' and notes it wraps 'cron.remove', giving insight into its underlying implementation and irreversibility. This is sufficient for a deletion 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 three concise sentences, each adding value: the action, a caution, and the underlying function. No unnecessary words. Front-loaded with the key purpose.

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

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

For a simple delete tool with no output schema, the description covers the essential aspects: what it does, that it's destructive, and the underlying mechanism. It could mention the return value but is complete enough for use.

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

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

Schema coverage is 100%, meaning both parameters already have descriptions in the schema (id: 'Cron job id', instance: full description). The description adds no new semantic information beyond repeating that it deletes 'by 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 ('Delete an OpenClaw cron job by id'), the resource (cron job), and the method (by id). It distinguishes this tool from other cron tools like add, update, list, and status by being the removal operation.

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

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

The description explicitly warns that the operation is destructive and advises to confirm before calling. This provides a clear usage guideline. While it doesn't explicitly enumerate when to use alternatives, the context of sibling tools makes the purpose 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?

No annotations are provided, and the description only says it triggers a run and wraps cron.run, without disclosing side effects, idempotency, or what happens if the job is already running.

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

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

Two sentences, zero waste, front-loaded with the action verb and resource.

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

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

With no output schema and no annotation, the description lacks information on return values, synchrony, or error conditions, leaving the agent underinformed.

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 parameters; the description adds no additional meaning beyond the schema.

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

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

The description clearly states the verb 'Trigger' and resource 'OpenClaw cron job by id', and distinguishes from sibling cron tools like openclaw_cron_list and openclaw_cron_status.

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

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

The description implies use when you have a cron job id and want an immediate run, but lacks explicit when-not-to-use or alternative tool guidance.

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

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

With no annotations, the description carries full burden. It explains that the tool wraps 'cron.runs', describes the compact option's effect (adding summaryTruncated flag), and mentions the runAtAgo field. It does not explicitly state it is read-only, but the context implies no side effects. Good behavioral detail for a listing 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 concise, with three sentences each adding distinct value: main purpose, compact behavior, and output field. No fluff or redundancy. Structure is 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?

Given no output schema or annotations, the description covers the essential usage (required id, compact option, output enhancements). Missing are explicit pagination details for limit/offset and explanation of instance routing. Still fairly complete for a listing 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 67% (4 of 6 parameters have descriptions in schema). The description adds meaning beyond the schema by detailing the compact parameter (saves tokens, adds summaryTruncated flag) and explaining the runAtAgo field. It does not address limit/offset pagination, but provides sufficient context for the key 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 it lists recent runs of a specific OpenClaw cron job, using the verb 'List' and specifying the resource. While it doesn't explicitly differentiate from siblings like openclaw_cron_run (which triggers a run), the tool name and description make 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 implies usage for listing cron job runs but provides no explicit guidance on when to use this tool versus alternatives (e.g., openclaw_cron_status). No when-not or context exclusions are mentioned, which is a gap.

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 burden. It lists the returned fields, which is useful, but does not disclose any behavioral traits such as whether it is read-only, potential side effects, permissions, or error conditions. The description 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 two sentences long, front-loads the purpose, and contains no unnecessary words. It efficiently conveys the core functionality.

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 simplicity of the tool (one optional parameter, no output schema), the description is mostly complete. It lists the returned fields, which is sufficient for basic use. However, it could mention that the tool is read-only or safe to call.

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% (the single optional 'instance' parameter is fully described in the schema). The description adds no additional meaning beyond the schema, so 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 explicitly states the tool retrieves the cron scheduler status, listing specific fields (enabled flag, next-run timestamp, recent failures) and mentions it wraps `cron.status`. This clearly defines the tool's purpose and distinguishes it from sibling tools like `openclaw_cron_list` or `openclaw_cron_runs`.

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 indicates the tool is for getting scheduler status, but does not provide explicit guidance on when to use it versus alternatives (e.g., `openclaw_cron_list` for listing jobs). Usage context is implied but not elaborated.

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 the operation is an update (wraps cron.update) and mentions wire format and backward compatibility. However, it lacks details on error handling, idempotency, authorization, or return values, which are important 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 three sentences, each earning its place: purpose, benefit, details. No fluff or repetition. The structure is front-loaded with the core purpose, making it easy for an agent to quickly grasp.

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

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

Given the complexity (5 params, nested objects, no output schema), the description covers input format well but omits return value or error behavior. For an update tool, more context on what the response looks like would improve completeness, especially lacking an output schema.

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

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

Schema coverage is 100%, baseline 3. The description adds value by explaining the wire format (id|jobId + patch), clarifying alias usage, and describing the deprecated job parameter. It also explains that patch should contain only fields to change, which goes beyond the schema's per-field 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 'Update an existing OpenClaw cron job in place' with a specific verb and resource. It distinguishes from sibling tools like openclaw_cron_add and openclaw_cron_remove by noting it 'avoids the remove + re-add dance', 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 explicitly says 'when you just want to change schedule, timeout, payload, or delivery', providing clear when-to-use context. It contrasts with remove-and-re-add, implying alternatives. However, it does not explicitly state when not to use it or list alternative tools for other operations.

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

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

With no annotations provided, the description carries the full burden. It discloses the required scope and the underlying API call, but does not describe what the tool returns or whether it is idempotent. This is adequate but not thorough 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 extremely concise with three short sentences, each providing essential information. The purpose is front-loaded, and there is no redundant or extraneous text.

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

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

Given the lack of an output schema, the description does not explain what the tool returns or whether the approval is synchronous. However, it is adequate for a simple approval action. The schema fills in details about parameters, but the description could mention the outcome.

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

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

The input schema has 100% description coverage for both parameters. The description adds no additional semantic meaning beyond the schema, so it meets the baseline of 3. The schema already explains the source of requestId.

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 ('Approve') and the resource ('a pending device pairing request'). It distinguishes itself from sibling tools like openclaw_device_pair_reject and openclaw_device_pair_remove by focusing on approval. The mention of wrapping `device.pair.approve` adds context.

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

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

The description specifies a prerequisite ('Requires operator.write scope'), which helps the agent determine when the tool can be used. It does not explicitly exclude when not to use it, but the purpose is straightforward. No alternatives are compared, but the sibling list implies other actions (reject, remove).

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 states the underlying API call (`device.pair.list` (operator scope)) and that it lists both pending and paired devices. However, it does not disclose any potential side effects, authentication requirements, rate limits, or response structure. The description provides basic context but lacks depth.

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 three sentences that front-load the purpose, include a practical usage hint, and mention the underlying API. Every sentence earns its place with 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 simplicity (list operation, one optional parameter, no output schema), the description is nearly complete. It explains what is listed (pending and paired devices), suggests a workflow context, and references the underlying API. Minor gaps include lack of specification about pagination or response format, but these are not critical for a straightforward listing 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% for the single parameter 'instance', which already has a detailed description in the schema. The tool description adds no additional meaning beyond what is already in the schema, so it meets the baseline 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 tool's function: 'List pending and paired devices known to the gateway.' It uses a specific verb (list) and resource (devices), and distinguishes it from sibling tools like openclaw_device_pair_approve and openclaw_device_pair_reject by focusing on listing rather than mutating device pairings.

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 a specific use case: 'Useful for confirming that this MCP's device shows up in ''pending'' before approval.' This implies when to use the tool (before approval) but does not explicitly state when not to use it or mention alternatives beyond the implicit flow.

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 carry the burden of behavioral disclosure. It only states the action and that it wraps an internal API, without detailing side effects, idempotency, authorization requirements, or what happens to the pairing state.

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

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

The description is very concise with one sentence for purpose and a brief mention of the underlying API. It is front-loaded with the key action, avoiding 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 tool is low-complexity with 2 parameters and no output schema. The description explains the action but does not clarify the result (e.g., removal from pending list) or any state changes. A bit more detail on the outcome 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?

Schema coverage is 100%, and both parameters are well described in the schema. The description adds no additional meaning beyond what the schema provides, so a 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 ('Reject a pending device pairing request') with a specific verb and resource. It distinguishes from sibling tools like openclaw_device_pair_approve by naming the action, though it does not explicitly differentiate.

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 should be used when a device pairing request needs to be rejected, but it does not provide guidance on when not to use it or mention alternatives like openclaw_device_pair_remove for already paired devices.

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 destructive nature and consequence of re-pairing, but lacks details on prerequisites, idempotency, or behavior when device isn't paired. No annotations to supplement.

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 concise sentences: first defines action, second adds critical warning. No unnecessary words, information is front-loaded.

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

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

Adequately covers purpose and a key consequence for a simple removal tool. Could mention that device must already be paired for action to succeed, but overall 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 already describes both parameters with 100% coverage. Description adds no additional meaning beyond the schema's field 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?

Clearly states 'Remove a paired device from the gateway' with a specific verb and resource. Distinguishes from sibling tools like list, approve, reject by naming the action.

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?

Only implies usage through the destructive warning ('device will need to re-pair to reconnect'). No explicit when-to-use, alternatives, or exclusions are 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?

Since no annotations are provided, the description carries full burden. It clearly states destructive behavior, lists what gets wiped (broken device, cached tokens, keychain entries), and mentions backup creation. However, it does not mention restoration process or authorization requirements.

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

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

The description is detailed but every sentence adds necessary context. It is front-loaded with the error condition. Could be slightly more concise, but still 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 purpose, usage condition, exact actions, parameter semantics, and side effects. Given the complexity and no output schema, it provides comprehensive context for correct invocation.

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

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

Schema coverage is 100%, but the description adds significant value by noting that the instance arg is 'currently no-op' and that the local Store is shared across instances. This goes beyond the schema's description.

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

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

The description explicitly states the tool recovers from a specific failure mode ('expected Uint8Array of length 32, got length=0'). It details the actions (backup, wipe, keep configs) and the subsequent regeneration. This clearly distinguishes it from sibling tools like openclaw_device_status, which only reports status.

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

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

The description provides clear guidance: 'run only when openclaw_device_status reports the empty-private-key failure mode.' It also notes that the instance argument is currently no-op, preventing misuse in multi-instance contexts.

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 the tool triggers a fresh connect attempt, acting as a retry pairing command. This is a significant side effect. However, it doesn't detail the exact behavior of the connect attempt or any potential failures.

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 purpose, and each sentence adds value. 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?

For a simple status tool with one optional parameter and no output schema, the description effectively covers what it returns and its side effect. It is complete for its complexity.

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

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

Schema coverage is 100% for the single optional parameter 'instance', with a descriptive schema comment. The tool description does not add further meaning beyond what the schema provides, so the 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 tool shows device identity, pairing status, scopes, and pending requestId. It also explains the side effect of triggering a connect attempt, distinguishing it from other sibling tools like openclaw_device_pair_list or openclaw_status.

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

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

The description gives a specific use case: 'Use when scoped methods fail with missing scope: operator.read.' This is helpful but does not explicitly mention when not to use it or list alternative 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 provided, so the description carries the burden. It explicitly states 'Destructive' and explains the consequence. This is sufficient for behavioral disclosure. Could add more details like rate limits or auth requirements, 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?

Two concise sentences that state the action, wrapper, and key consequence. No redundant or unnecessary information. Highly efficient.

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

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

Given no output schema, the description explains the effect (revocation leads to re-pairing). It covers the main behavioral context. Could mention immediate invalidation, but it's implicit. Complete enough for a straightforward destructive action.

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

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

Schema coverage is 100%, with descriptions for both parameters. The description does not add extra meaning beyond the schema. Baseline 3 is appropriate since the schema already documents the parameters adequately.

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 (revoke) and the resource (device's authentication token). It distinguishes from siblings like 'openclaw_device_token_rotate' by mentioning the destructive consequence and the need for re-pairing.

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 warns that the tool is destructive and forces re-pairing or a new token. This helps the agent understand when to use it versus alternatives (e.g., token rotate). Does not list explicit alternative tool names but the context is 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, the description carries full burden. It discloses the destructive effect and underlying API call but omits permissions, rate limits, error conditions, or return behavior. 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 waste. The first sentence front-loads action and consequence; the second adds destructiveness and API reference. Perfectly concise.

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

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

For a simple tool with 2 params and no output schema, the description covers core behavior and safety warning. Missing return value info, but adequate for selecting and invoking 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%, so baseline is 3. The description adds little beyond the schema (e.g., instance fallback), but no additional constraints or usage context for 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 verb (rotate), resource (device's authentication token), and effect (issues new, invalidates old). It distinguishes from sibling tools like openclaw_device_token_revoke by implying a combined operation.

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

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

The description notes the destructive nature but does not explicitly state when to use this versus alternatives (e.g., revoke alone). No when-not-to-use guidance is provided, leaving the agent to infer context from sibling names.

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 bears full burden. It discloses mutation ('Mutates') and cost ('expensive in tokens'), but lacks details on specific side effects, authorization requirements, or what exactly gets changed. The description is adequate but lean 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 extremely concise with two sentences, no redundancy, and front-loaded with the primary action. Every word serves a purpose, including the wrapper reference and mutation warning.

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

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

Given the complexity of backfilling a dream diary and the lack of output schema, the description could explain return values or detailed behavior more thoroughly. While sufficient for experienced users, it leaves some gaps for new 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?

The only parameter ('instance') is fully described in the schema (100% coverage), so the description need not add much. It does not provide additional context beyond the schema, granting a 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 action ('Backfill the dream diary from past sessions') and the resource ('dream diary'), using specific verbs like 'backfill' and 're-runs dreaming on history'. It distinguishes from siblings like 'dreamDiary' and 'dedupeDreamDiary' by focusing on historical backfill.

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 guidance on when to use ('re-runs dreaming on history') and warns about cost ('can be expensive in tokens'). However, it does not explicitly mention when not to use or list alternative tools (e.g., 'dreamDiary'), though the cost warning implies careful 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?

With no annotations provided, the description is the sole source of behavioral context. It states 'Mutates' but gives no details on side effects, permissions, reversibility, or idempotency. Important traits like potential impact on data or required authorization are absent.

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?

At two sentences and 13 words, the description is short, but it sacrifices informative content for brevity. It front-loads the purpose but omits crucial details about behavior and parameters, earning a middling score for under-specification rather than efficient conciseness.

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

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

Given the complexity of deduplication, no output schema, and no annotations, the description is insufficient. It fails to explain what happens after deduplication (e.g., no return value mentioned), error conditions, or how duplicates are identified. The agent lacks context to use the tool reliably.

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 the sole defined parameter 'instance' with a clear description, achieving 100% coverage. However, the description does not mention this parameter or address the unusual 'additionalProperties: true' setting, which allows arbitrary extra parameters without explanation. The agent is left uncertain about what actual data inputs are needed for deduplication.

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 'deduplicate' and the resource 'dream diary entries'. While it distinguishes from sibling tools like 'openclaw_doctor_memory_dreamDiary' by the specific operation, it does not elaborate on what 'dream diary entries' are or provide boundaries, which is acceptable given the tool name provides context.

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

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

The description offers no guidance on when to use this tool versus alternatives (e.g., backfill, repair, reset). It does not specify prerequisites, conditions, or exclusions, leaving the agent to infer context from the tool name alone.

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

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

No annotations are provided, so the description carries the full burden. It states the tool is read-only and wraps a specific function, but does not disclose potential side effects, authorization requirements, or pagination behavior. The minimal behavioral disclosure is 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, with two short sentences that immediately state the tool's purpose. Every word adds value, and the structure is 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?

Given the lack of output schema and annotations, the description is minimally complete. It explains what the tool does but omits details on return format, error handling, and parameter usage. For a simple read operation, it may suffice, but additional context 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?

The description adds no meaning beyond the input schema for the 'limit' parameter and does not elaborate on 'instance' beyond what is in the schema. With schema description coverage at 50%, the description should compensate but does not. The 'limit' parameter's effect is left to the schema, which lacks a description.

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

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

The description clearly states the tool reads the dream diary, specifies it is read-only, and distinguishes it from sibling tools that modify or repair the diary. The verb 'Read' is specific, and the resource is clearly identified.

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 reading, but does not explicitly state when to use it over alternatives like backfill or dedupe. However, the context of sibling tools and the 'Read-only' label provides reasonable guidance.

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

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

No annotations are provided, so the description carries the full burden. It only states 'Mutates', implying destructive behavior, but does not disclose side effects, required permissions, error handling, or whether the operation is reversible. More details are needed for safe invocation.

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 with only two short sentences. It front-loads the main purpose and includes a clear mutation indicator. However, it could be formatted more clearly by separating the examples or adding a usage hint.

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 is relatively simple (one optional parameter, no output schema), the description covers the core purpose adequately. However, it omits details about return values, error states, and preconditions, which would help the agent manage expectations.

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

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

The input schema has 100% description coverage for the single optional 'instance' parameter, so the schema already documents it well. The description adds no additional meaning beyond what the schema provides, hence baseline score 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 it repairs corrupted dreaming artifacts with concrete examples (orphan files, broken JSON). The verb 'repair' is specific. However, it does not explicitly distinguish from sibling doctor_memory tools (e.g., status, dream diary), relying on context.

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

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

The description lacks guidance on when to use this tool versus alternatives (e.g., other doctor_memory tools). It only says 'Mutates', which provides minimal context about use, but no explicit when-to-use or when-not-to-use instructions.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly states that the tool is destructive, wipes the entire diary, and loses all promoted-into-memory candidates. It also mentions the underlying function it wraps, providing transparency about the implementation.

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, consisting of three short sentences that each add value: purpose, underlying function, and warnings. It is front-loaded with the core action and avoids 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?

The description adequately covers the tool's purpose and consequences, but does not explain the return value (e.g., confirmation message) despite the lack of an output schema. Given the low complexity and the inclusion of critical warnings, it is mostly 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?

The description does not mention the only parameter 'instance', but the input schema already provides a detailed description for it (100% coverage). Since the schema fully documents the parameter, the description adds no additional semantics, warranting a 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 action ('wipe the dream diary entirely') and specifies the resource ('dream diary'). It differentiates from sibling tools by emphasizing it resets the entire diary and is destructive, which sets it apart from other memory-related tools like status or backfill.

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 warns that the operation is destructive and requires confirmation before calling, and notes the loss of promoted-into-memory candidates. However, it does not explicitly state when not to use this tool or provide alternatives to similar tools, leaving some guidance to the agent.

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

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

Without annotations, the description effectively discloses the destructive nature of the tool. It mentions that agents lose recent recall, providing sufficient behavioral context.

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

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

Two sentences, front-loaded with action and a clear warning. Every word is purposeful 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?

For a simple destructive tool with one optional parameter, the description provides adequate context. It could mention if repeated calls cause issues, but not necessary.

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 the description does not add additional meaning to the single parameter beyond what the schema already provides.

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

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

The description clearly states 'Wipe the grounded short-term memory store' with a specific verb and resource, and it distinguishes itself from other memory-related siblings like resetDreamDiary.

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 warns 'DESTRUCTIVE — agents lose their recent recall' but does not provide explicit guidance on when to use or alternatives. It implies caution but lacks full 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 provided; description states it is read-only and wraps doctor.memory.status, but lacks details on potential side effects or what happens if the subsystem is unhealthy.

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, no wasted words, front-loaded with purpose. 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 the tool's simplicity (no output schema, one optional param), the description is adequate. Could mention return format but not necessary for basic understanding.

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% for the one parameter (instance), so the description adds no additional meaning. 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 it gets the memory subsystem health, specifying components (short-term store, dream diary, grounding state). It uses a specific verb 'Get' and resource, distinguishing it from sibling memory 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 checking memory health but does not explicitly state when to use it vs alternatives or provide exclusions. No guidance on when not to use it.

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

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

Explicitly states 'Read-only' and 'Wraps exec.approval.get' indicating no destructive side effects. Lacks detail on error handling, authentication, or rate limits, but adequate for a simple read operation without 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?

Two sentences: first states purpose and output fields, second notes wrapper and read-only nature. No redundancy, every sentence 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?

Covers purpose, output fields, safety, and wrapper. Lacks output schema or error behavior, but acceptable for a simple get with two parameters. Minor gap on response format if not found.

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

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

Schema coverage is 100%, baseline 3. Description adds context by listing response fields, but does not provide additional parameter semantics beyond schema 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?

Clear specific verb 'Get' and resource 'exec approval request'. Lists returned fields (command, args, agent, status). Distinguishes from siblings like list/request/resolve. Explicit 'Read-only' and wrapper reference add clarity.

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

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

Implied usage: for getting a single request. No explicit when-to-use or when-not-to-use. Does not differentiate from sibling tools like openclaw_exec_approval_list or openclaw_exec_approvals_get. Lacks explicit guidance.

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

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

The description states it is read-only and wraps exec.approval.list. Without annotations, this provides basic transparency. However, it does not disclose potential side effects, error scenarios, or permission requirements beyond the read-only hint.

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, direct and front-loaded with purpose. No unnecessary words or redundancy.

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

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

Adequate for a simple list tool, but lacks context on response format, pagination, and the meaning of status values. Given no output schema and low parameter coverage, more completeness 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 only 33% (only instance described). The description adds no details about limit or status parameters, which are essential for filtering the list. Given low schema coverage, the description should compensate but does not.

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 pending and recent exec approvals needing human OK, and marks it as read-only. However, it does not explicitly distinguish it from similar siblings like openclaw_exec_approvals_get or openclaw_exec_approval_get, which may have overlapping functionality.

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

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

No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, scenarios, or cases where another approval tool would be more appropriate.

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

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

No annotations are provided, so the description carries full responsibility for behavioral disclosure. The description only says it 'wraps exec.approval.request' but does not mention authentication requirements, side effects, rate limits, or potential failure modes. This is insufficient for a tool that submits requests.

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 short sentences that convey the core purpose and a key usage hint. Every sentence adds value without unnecessary elaboration.

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

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

With no output schema and a single parameter, the description adequately explains what the tool does but lacks details on return values, error scenarios, or the approval workflow. It is minimally complete but leaves gaps for a tool that initiates an important process.

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 is only one optional parameter 'instance' with a thorough description in the schema (100% coverage). The description adds no additional parameter meaning beyond what the schema already provides, so 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's purpose: submitting a new exec approval request. It also notes that this is a programmatic operation, normally done by agents, which differentiates it from sibling tools like openclaw_exec_approval_list or openclaw_exec_approval_resolve.

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 agents normally perform this action themselves, suggesting the AI agent might not need to call it directly. However, it does not explicitly state when to use this tool versus alternatives or what prerequisites exist (e.g., needing an active session). The guidance is minimal.

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