openclaw-control-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.7.0
Disambiguation4/5
Tools are generally well-differentiated with specific domains and actions. Some overlap exists (e.g., openclaw_send, openclaw_chat_send, openclaw_sessions_send) but descriptions clarify context. A few pairs like sessions_preview and sessions_tail might confuse an agent, but overall distinct.
Naming Consistency5/5
All tools follow the consistent pattern 'openclaw_{domain}_{action}' using snake_case. No mixing of conventions (camelCase, etc.). The pattern is maintained across all 143 tools, making it predictable.
Tool Count3/5
143 tools is very high for a single MCP server, covering many subdomains (sessions, cron, config, skills, nodes, etc.). While each subdomain has reasonable granularity, the total count may overwhelm an agent during tool selection. However, the scope is broad, so it's not entirely inappropriate.
Completeness4/5
The tool surface is extensive, covering CRUD for sessions, cron, agents, config, skills, exec approvals, nodes, TTS, and more. Minor gaps exist (e.g., channel management only has status/logout, no channel list or create), but overall the set provides comprehensive lifecycle coverage for most gateway operations.
Average 3.7/5 across 143 of 143 tools scored. Lowest: 2.4/5.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 15 community issues answered or closed in the last 6 months
- 3 commits in the last 12 weeks
- Last stable release on May 13, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description must bear the burden. It only states 'Mutates,' which indicates a write operation but omits important details such as side effects, error conditions, or permissions. The reference to 'Wraps node.rename' is uninformative.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, which is concise, but it sacrifices necessary detail. It front-loads the action but could be more structured without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (4 parameters, no output schema, no annotations, many sibling tools), the description is far from complete. It does not explain the relationship to other node tools or what the return value is.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With only 25% schema description coverage, the description fails to clarify the purpose of parameters like 'name' and 'newName'. The mention of 'display name / id' is ambiguous and not mapped to parameters. Significant gap even for basic interpretation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool renames a node, mentioning both display name and id. It distinguishes itself from sibling tools as the only rename operation. However, it is slightly vague about whether both name and id are changed simultaneously.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like openclaw_node_describe or openclaw_node_list. No prerequisites or conditions for renaming are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description only states that the tool switches the active provider/voice and wraps a function. It does not disclose side effects, authorization needs, rate limits, or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence. It is front-loaded with the verb, but the brevity comes at the cost of missing important details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 4 parameters, no output schema, and no annotations, the description is severely incomplete. It lacks details on return values, parameter constraints, and behavioral context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 25% (only instance described). The description does not explain the model, voice, or provider parameter formats, values, or relationships, beyond the schema's minimal info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'switch' and the resource 'active TTS provider / voice', distinguishing it from listing (openclaw_tts_providers) or converting (openclaw_tts_convert). However, it groups provider and voice together, which may be ambiguous given separate parameters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like openclaw_tts_convert or direct configuration. No exclusions, prerequisites, or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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.
Conciseness3/5
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.
Completeness2/5
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.
Parameters2/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must carry the burden. It only states the tool 'wraps node.event' without explaining behavioral traits like idempotency, error handling, or effect on the node.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise at two sentences, which is efficient, but it sacrifices necessary detail. It front-loads the action but lacks structured presentation of parameters or behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and three parameters, the description is incomplete. It does not mention return values or provide enough context for an agent to use the tool correctly without additional knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% (only 'instance' has a description). The tool description adds no meaning for 'event' or 'nodeId' beyond their names, and the 'instance' description is in the schema but not leveraged.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('emit an event') and the target ('toward a node or gateway-side node bus'), and references 'node.event'. However, it does not explicitly differentiate from sibling tools like openclaw_node_invoke or openclaw_system_event, which may also emit events.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 such as openclaw_sessions_send or openclaw_send. The description lacks context for appropriate usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully bears the burden of disclosure. It indicates a mutation (acknowledging completion) but provides no details on side effects, permission requirements, or what happens to the item. The agent is left guessing about the tool's impact.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, consisting of two short sentences. It is front-loaded with the core purpose. However, it may be too terse, sacrificing necessary detail for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters, no output schema, and many sibling tools with similar names, the description is incomplete. It lacks explanations of parameters, return values, and timing or conditions for use, leaving significant gaps for an agent to infer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has low description coverage (33%), with only 'instance' described. The description adds no information about the parameters: it does not explain 'nodeId' (required) or 'itemId'. The agent cannot infer their meaning from the description alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool acknowledges or commits completion of a pending work item. However, it does not differentiate from sibling tools like openclaw_node_pending_pull or openclaw_node_pending_drain, which reduces clarity for an AI agent selecting among them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 alternatives. It does not mention prerequisites, such as having pulled a pending item, or context like completing processing. This lack of usage context makes it hard for an agent to decide when to invoke it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full burden. It only says 'Update... Wraps voicewake.set' without disclosing side effects, permissions, reversibility, or behavior of additional properties. The lack of detail makes it hard to assess safety.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very brief (one sentence plus code reference), achieving conciseness but sacrificing content. It fails to earn its place by omitting critical details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations, missing output schema, and 33% schema coverage, the description is incomplete. It does not explain the configuration concept, parameter defaults, or relationship to other tools like openclaw_wake.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% (only 'instance' has a description). The tool description does not explain the parameters further. The agent must infer the meanings of 'enabled' and 'wakeWord' from names alone, which is insufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Update the voice-wake configuration', specifying the verb and resource. It distinguishes from the sibling get tool. However, it could be more explicit about what fields are updated beyond the generic 'configuration'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not mention when to use this tool vs. alternatives like openclaw_voicewake_get or openclaw_wake. No prerequisites or context are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only states the action 'Unsubscribe' without mentioning side effects, permissions, or that it terminates an active subscription.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise but lacks sufficient detail for a tool with no output schema and sibling differentiation needs. Minimal viable length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple operation and well-documented schema, the description is incomplete. It fails to mention that a prior subscription is required or that this is the counterpart to 'openclaw_sessions_messages_subscribe'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 well. The description adds no extra meaning beyond the schema, earning the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action ('Unsubscribe from session message stream') and identifies the specific resource. However, it does not differentiate from the sibling tool 'openclaw_sessions_unsubscribe', which likely has a different scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'openclaw_sessions_messages_subscribe' or 'openclaw_sessions_unsubscribe'. It does not mention prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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. It mentions mutation and confirmation, but lacks details on overwrite behavior, required permissions, network dependencies, or versioning semantics. Minimal disclosure beyond the fact it modifies state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences that efficiently convey the core purpose and a critical behavioral warning. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 3 parameters, no output schema, and missing annotations, the description omits key context like return values, error handling, and behavior for already-installed skills. Incomplete for safe agent decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 67% (id and instance have descriptions, version does not). The description does not elaborate on any parameters, such as version format or instance routing, failing to compensate for the missing version description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Install a skill') and allows for a specific version. It distinguishes from sibling tools like openclaw_skills_search or openclaw_skills_update, though the internal jargon 'Wraps skills.install' might confuse some agents.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description warns that it mutates the skill set and advises confirmation, but it does not compare to alternatives like openclaw_skills_update or explain when installation is appropriate versus other operations. No explicit when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters2/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It notes mutation potential ('mutates depending on the target method') but omits critical details: authentication requirements, rate limits, error behavior (e.g., for nonexistent nodes), or safety profile. The phrase 'RPC routed through the gateway' adds minimal transparency. The description does not warn about side effects or resource usage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at two sentences. Every word is meaningful, with no redundancy. However, it is slightly underspecified; additional context (e.g., about method validity) could be added without significant bloat. Still, it achieves front-loaded clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the large sibling tool set and absence of output schema, the description is incomplete. It does not explain what 'invoke a method' means in practice, what return values to expect, or how the tool fits into the broader workflow (e.g., prior need to list nodes with openclaw_node_list). The complexity of the tool (RPC, opaque params) demands richer context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50% (method and nodeId lack schema descriptions). The tool description adds no extra meaning for these required parameters—does not explain valid formats, sources, or constraints. For 'params', it echoes the schema's 'opaque passthrough' without elaboration. The 'instance' parameter description in schema is adequate, but overall the description fails to compensate for low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Invoke a method on a specific node (RPC routed through the gateway).' It distinguishes from sibling node tools (e.g., node_describe, node_rename) by focusing on generic method invocation, and the reference to 'RPC' differentiates it from higher-level tools like openclaw_call. The verb 'invoke' is specific and actionable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide guidance on when to use this tool versus alternatives like openclaw_node_describe or openclaw_node_rename. It mentions 'mutates depending on the target method' but does not clarify when mutation occurs or when read-only methods are appropriate. No prerequisites or context for selecting this tool over siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description only mentions wrapping `node.pair.reject` without describing side effects, required permissions, or reversibility. For a tool with no annotations, the description should provide more 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (one sentence), but it lacks essential details. While it is front-loaded, the minimalism sacrifices completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 2 parameters, no output schema, and no annotations, the description is insufficient. It does not explain what a node pairing request is, what rejecting entails, or what the return value indicates.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50%; the description adds no additional meaning for the parameters beyond what the schema provides. The required `requestId` parameter has no description in the schema, and the tool description does not clarify it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Reject) and the resource (a pending node pairing request). It distinguishes from sibling tools like openclaw_node_pair_approve and openclaw_device_pair_reject by specifying 'node'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 such as openclaw_node_pair_approve or openclaw_node_pair_request. Missing context about prerequisites or scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It only states 'Mutates' but does not explain the nature of the mutation (e.g., async queuing, side effects, response format, or whether the enqueue is guaranteed). The agent lacks critical behavioral detail 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very brief: two sentences that directly state purpose and mention the wrapped function. It is front-loaded and avoids fluff. However, it is perhaps too minimal; a bit more detail could be added without harming conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, 2 params (one undocumented), and no annotations, the description should provide more context. It does not explain return values, error states (e.g., unknown nodeId, queue full), or the effect of the 'additionalProperties' allowed in the schema. The tool's behavior is only partially described, leaving significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50% (only 'instance' has a description). The description adds no new meaning for 'nodeId' beyond what the schema provides (just minLength:1). For 'instance', the schema already describes routing; the description does not elaborate. With low coverage and no added semantics, the agent may not understand the required input for nodeId.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Enqueue a new work item for a node' with a specific verb and resource. The mention of wrapping `node.pending.enqueue` further clarifies the internal function. Among siblings like openclaw_node_pending_pull, drain, ack, this tool is distinctly for enqueuing, so purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 such as openclaw_node_invoke or other pending operations. There is no mention of prerequisites (e.g., node must be paired or active) or conditions for using enqueue over other tools. The agent is left to infer usage 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description does not disclose side effects, asynchronicity, return value, or authorization needs. Merely says 'submit' without 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no filler. However, could be slightly expanded for completeness without losing efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, no annotations, and description does not cover what the tool returns or the fact it likely requires additional data (additionalProperties: true). Incomplete for reliable agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of the single parameter with good description; description adds no additional meaning beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the verb 'Submit' and resource 'plugin approval request', and references underlying function. Distinguishes from sibling tools like list/resolve/wait.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use vs alternatives like exec_approval_request, no prerequisites or when-not-to-use mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 states 'unsubscribe', implying a mutating action, but does not describe side effects, reversibility, permission needs, or the scope of lifecycle events affected. The note about wrapping a lower-level function is helpful but insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences, no wasted words. However, it lacks structure (e.g., separate sections for usage, output) but remains clear for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 optional param, no output schema), the description covers the core purpose. However, in the context of many session-related sibling tools, additional context like the event types or link to subscription management would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%; the single parameter 'instance' is fully described in the schema. The description adds no additional meaning beyond what the schema provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'unsubscribes from session lifecycle events', providing a specific verb and resource. It also references the underlying 'sessions.unsubscribe' method. However, it does not explicitly differentiate from the similar 'openclaw_sessions_messages_unsubscribe', though the tool name and context imply the difference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 alternatives like 'openclaw_sessions_subscribe' or 'openclaw_sessions_messages_unsubscribe'. There is no mention of prerequisites, context, or conditions for unsubscription.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions the output varies by gateway config (audio vs. download URL) but lacks disclosure on side effects, idempotency, permissions, or resource implications. For a synthesis tool, minimal behavioral insight.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: first for purpose, second for implementation and output. No redundancy, every word adds value. Could be improved with a brief mention of required vs. optional parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple but the description omits important details: no output schema, no constraints on text length or voice names, no hint about expected latency or size. An agent would have to infer or experiment to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is low (33%) with only 'instance' described. The description adds context to 'instance' (routing and fallback) but provides no additional meaning for 'text' or 'voice' beyond their schema definitions. Partially compensates but leaves gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the function: 'Synthesize a piece of text to audio.' It identifies the verb and resource, and mentions it wraps `tts.convert`. While it doesn't explicitly differentiate from sibling tools like openclaw_tts_status, the purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. No mention of prerequisites, recommended contexts, or when not to use it. The description does not help the agent decide between this and other TTS or non-TTS tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It only states the basic action and that it wraps a root-level method, but fails to mention side effects, state changes, idempotency, prerequisites (e.g., session must be idle), or any potential errors. This is insufficient for a mutation operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (three sentences) and front-loads the key action. It is efficient in word count, though it lacks depth. It could be improved without much lengthening, but for conciseness it scores well.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the tool (waking an agent/session from idle) and the absence of an output schema, the description is incomplete. It does not explain what the tool returns, error conditions, or prerequisites (e.g., the session must exist and be idle). Essential context is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 33% (only instance has a description). The description says 'Pass agentId/sessionId' but does not clarify the distinction between the two parameters, when each is required, or how they interact. It adds no meaning beyond the parameter names for agentId and sessionId.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('Wake an agent / session out of idle'), specifying the verb and resource. It uniquely identifies its role among a large set of sibling tools, as no other tool explicitly targets waking an idle session or agent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides minimal usage guidance, only instructing to 'Pass agentId/sessionId'. It does not specify when to use this tool versus alternatives, such as when an agent should be woken vs. created or reset. No explicit when/when-not conditions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters2/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description partially fills the gap by stating it 'mutates gateway state', indicating side effects. However, it does not disclose destructive potential, authentication needs, rate limits, or specific behavioral traits beyond the basic mutation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences that efficiently convey purpose, examples, and a key behavioral trait (wraps message.action, mutates state). 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.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
As a mutation tool with no output schema, the description is insufficient. It does not mention return values, error conditions, prerequisites (e.g., message existence), or the meaning of 'additionalProperties: true' in the schema. The tool's complexity (4 params, mutation) demands more context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50% (action and instance have descriptions; messageId and sessionId do not). The tool description adds no parameter-level details beyond the schema; it only gives examples for 'action' but does not explain the role of messageId and sessionId, failing to compensate for undocumented parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool triggers a message-level action, provides concrete examples (retry, mark-as-handled, attach to a session), and notes it wraps 'message.action'. However, it does not distinguish itself from sibling tools like openclaw_sessions_send or openclaw_send, which also operate on messages.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 implies its purpose (message-level actions) but fails to mention when not to use it, prerequisites, or how it compares to other similar tools in the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must reveal behavioral traits but only says 'Wraps node.pair.request.' It does not mention side effects, required permissions, or what happens after the request (e.g., awaiting approval).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (two sentences) but sacrifices completeness for brevity. It could be expanded to include essential details without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
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 only one optional parameter, the description is incomplete. It does not explain the purpose of the request, expected outcomes, prerequisites, or how to proceed after the request.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single 'instance' parameter, and the description adds no extra meaning beyond what the schema already provides. Baseline score of 3 is appropriate since the description does not compensate for any gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Request pairing') and the resource ('a new node'), and it distinguishes from siblings like openclaw_node_pair_approve and openclaw_node_pair_reject by specifying it's the initial request step.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like openclaw_node_pair_approve or other node management tools. The description only states what it does without context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It mentions mutation and that the agent will proceed or not, but lacks details on reversibility, permissions, error conditions, or side effects on other approvals. The internal function name is a plus.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, all essential: action description, underlying function, and behavioral consequence. Front-loaded and efficient with no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters, no output schema, and no annotations, the description is insufficient. It doesn't explain parameter usage (e.g., approved vs decision), doesn't provide workflow context linking to sibling tools like openclaw_exec_approval_list, and doesn't describe return values or errors.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 40% (id and instance have descriptions). The tool description does not clarify the purpose or relationship of 'reason', 'approved', or 'decision' parameters. The agent is left without guidance on whether to use 'approved' or 'decision', or what 'reason' is for.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool resolves pending exec approvals (approve/reject), specifies it wraps an internal function, and indicates it mutates state. It differentiates from sibling tools like list, get, request, and waitDecision by focusing on the action of making a decision.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives (e.g., openclaw_exec_approval_list to find pending approvals, openclaw_exec_approval_get to inspect one). Does not explain that the tool should be used after retrieving an approval id, nor does it caution about prerequisites or side effects.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states 'Read-only' which indicates no side effects, but provides no further behavioral details such as what happens if the node doesn't exist, authorization requirements, or error handling. Without annotations, the agent needs more context about the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise: two sentences covering purpose and a key behavioral note (read-only). No extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with two parameters and no output schema, the description is adequate but lacks details about the return value, error conditions, and when to prefer this over sibling tools. However, given the low complexity, it is mostly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters have descriptive names and schema descriptions (nodeId: 'Node id', instance: routing info). The description adds only the wrapped function name, which is marginally helpful. Since schema coverage is 100%, the description adds little beyond what is already present.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool retrieves the per-node exec approvals policy override. The verb 'Get' and resource are explicit. However, it does not distinguish from similar sibling tools like openclaw_exec_approval_get or openclaw_exec_approvals_get, so an agent might be uncertain which to use for node-specific vs general approval retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like openclaw_exec_approval_get. The description only states what it does, not when it is appropriate or when to avoid it. This leaves the agent without decision-making support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility. It labels the operation as 'Destructive' but provides no further details on side effects, permissions required, or what constitutes a valid policy. The internal wrapper name offers no behavioral insight.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the core purpose. The 'Destructive.' tag is concise but informative. The internal wrapper reference adds minimal value and could be omitted for clarity. Still, overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lacks return value info, expected input format for policy, and any link to related tools. Given no output schema, the description should hint at what 'setting' entails. Significant gaps remain for a safe and correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (both nodeId and instance have descriptions). The description does not add additional meaning beyond the schema, so baseline 3 is appropriate. No need for compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (Set), resource (exec approvals policy), and scope (for a specific node). It distinguishes from sibling tools like openclaw_exec_approvals_set (global) and openclaw_exec_approvals_node_get (read). The internal wrapper reference and 'Destructive' tag reinforce the action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., openclaw_exec_approvals_set). No prerequisites, context, or when-not-to-use conditions provided. The agent must infer from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It only discloses the destructive nature ('overwrites the existing policy'). It does not mention that `additionalProperties: true` allows arbitrary extra parameters, nor does it detail required permissions, idempotency, or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no fluff: states the action, references implementation, and highlights destructiveness. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is minimal. It does not explain the policy format, output (no output schema), or the implication of `additionalProperties: true`. For a tool that sets a global policy, more context about scope and effect would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (only one parameter, `instance`, well-described in the schema). The description adds no further parameter detail, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sets/replaces the global exec approvals policy, using specific verbs and resource. It also notes it wraps `exec.approvals.set`. However, it does not explicitly differentiate from siblings like `openclaw_exec_approvals_get` or `openclaw_exec_approvals_node_set`, leaving some ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 (e.g., `openclaw_exec_approvals_node_set` for node-level policies). There are no prerequisites, when-to-use hints, 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility for disclosing behavior. It only states the action, omitting whether the tool is read-only or destructive, what happens on success/failure, or any side effects. This is insufficient for a tool that likely modifies state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise: two short sentences. It immediately states the purpose and references the underlying API. However, it could be more structured with headings or bullet points, but for a simple tool, this level is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the tool's simplicity (one optional param, no output schema), the description lacks essential context such as what a 'pairing handshake' is, what the verify step entails, and whether any prior steps are needed. It is insufficient for an agent to fully understand the tool's role.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'instance' is already well-described in the input schema. The tool description adds no further semantics, so it does not increase understanding beyond the schema. Baseline 3 is appropriate given 100% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Verify a node pairing handshake') and the underlying API method (`node.pair.verify`). This is a specific verb+resource that distinguishes it from sibling tools like `openclaw_node_pair_request` and `openclaw_node_pair_approve`.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It doesn't mention prerequisites, such as having initiated a pair request, or indicate when verification is needed (e.g., after pairing request is made).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must cover behavioral traits. It states 'Read-only' and wraps `skills.search`, but omits details like pagination, instance routing behavior, or response characteristics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no wasted words. Essential information is front-loaded, making it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, yet the description does not specify return values or structure. Parameter details are incomplete. For a search tool, more context on results and filtering behavior is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is low (33%), with only the `instance` parameter having a description. The description does not explain `query`, `limit`, or how they interact, failing to compensate for the schema gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the action 'Search' and the resource 'skill catalog (installed and remote)'. The verb and resource are specific, and it distinguishes from sibling tools like openclaw_skills_install or openclaw_skills_status by focusing on search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 over alternatives like openclaw_tools_catalog or openclaw_skills_detail. The description lacks usage context, exclusions, or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines3/5
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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description must disclose behavioral traits. It only mentions read-only and wraps a command, but lacks details on authentication, rate limits, or effects. The minimal info is insufficient for a mutation-free tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise with two short sentences. It is front-loaded and wastes no words, though it could benefit from slightly more context without being overly verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (1 optional param, no output schema), the description covers the essential purpose but omits details like pagination, ordering, or response format. It is minimally adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the only parameter 'instance', with a sufficient description. The tool description adds no additional parameter meaning beyond the schema, achieving the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'List node pairing requests', specifies the resource, and distinguishes itself among siblings by mentioning 'pending and resolved' and wrapping 'node.pair.list'. It also notes read-only, which adds clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool versus alternatives like openclaw_node_pair_request, openclaw_node_pair_verify, etc. It only says 'read-only', but no context on when to list versus other operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description only states 'Mutates the gateway state,' which is minimal. It does not disclose side effects (e.g., skill downtime, dependencies), required permissions, or whether the update is reversible. More context is needed 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three short sentences with no unnecessary words. It efficiently conveys the core action and a key side effect.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with three parameters, no output schema, and no annotations, the description covers the basic purpose and mutation aspect but lacks details on return values, error conditions, and potential impacts. It is minimally adequate but not fully informative.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 67%, but the description adds little beyond what the schema provides. It mentions 'latest (or a specified) version' but does not clarify the format or constraints for the 'version' parameter, which lacks a schema description. The 'instance' parameter is already well-described in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('update'), resource ('installed skill'), and the nature of change ('to its latest or specified version'). It distinguishes from siblings like openclaw_skills_install by specifying 'update an installed skill' versus installing a new one.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives (e.g., reinstall, upgrade). It mentions 'mutates the gateway state' but does not give context on prerequisites, typical use cases, 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It mentions 'set' which implies mutability, but does not clarify whether changes are reversible, require permissions, or affect other settings. The phrase 'Wraps talk.config' is ambiguous and does not detail atomicity or side effects. The agent lacks critical safety context for a mutation-capable tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that combines the operation (get/set) and the config items in parentheses. No wasted words. However, the inclusion of 'Wraps talk.config' could be seen as slightly extraneous to an agent, but overall it's efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity (1 optional param, no output schema), the description is somewhat complete. However, it omits what the tool returns on get or set. For a tool with no output schema, the description should ideally state the return format (e.g., returns config object). This missing detail lowers completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage for the single parameter (instance) is 100%, meaning the schema already fully documents it. The tool description does not add any extra meaning for parameters, 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets/sets the talk-mode config and lists three specific config items (push-to-talk, hold-to-listen, voice activity detection). This provides a specific verb+resource scope and distinguishes it from siblings like openclaw_talk_mode (likely a mode enabler) and openclaw_talk_speak.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use, when-not-to-use, or alternative tools are mentioned. The sibling openclaw_talk_mode could be confused as an alternative, but no guidance is provided. The description only states what the tool does, not when to choose it over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the burden. It only says 'Wraps tts.enable', lacking details on state changes, side effects, idempotency, or output. An enable tool should disclose if it's safe to call multiple times or requires configuration.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise: two short sentences with no redundancy. Could be slightly improved by front-loading the purpose, but it's efficient and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple toggle tool with no required params and no output schema, the description is barely adequate. It lacks information on return values, errors, or state prerequisites. More context would help, but it's not severely incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single optional parameter. The description adds no extra meaning beyond the schema, which already explains instance routing. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool enables text-to-speech output, using a specific verb and resource. It distinguishes from sibling TTS tools like openclaw_tts_disable (disable) and openclaw_tts_status (status check).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool, e.g., prerequisites (provider set?), or when not to use it (already enabled). No mention of alternatives or context relative to sibling TTS tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines3/5
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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the operation is read-and-mutate (work items leave the queue), which is useful. However, it lacks details on side effects, permission requirements, or whether the operation is reversible.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of two short sentences that convey the essential purpose and behavior with zero unnecessary words. It is well front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the basic purpose and mutation behavior, but lacks information about return values (no output schema), error conditions, prerequisites (e.g., node existence), and does not contrast with similar sibling tools. It is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and both parameters have clear descriptions in the schema. The tool description does not add any additional semantic information beyond what the schema already 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (Pull) and resource (pending work items for a node) and uses the parenthetical 'queue drain' to add context. However, it does not explicitly distinguish this from the sibling tool 'openclaw_node_pending_drain', which likely serves a similar purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like openclaw_node_pending_drain, enqueue, or ack. The description does not specify prerequisites, edge cases, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full burden. It only states it emits an event and wraps a command but does not disclose side effects, idempotency, or whether the event is persistent. The agent lacks insight into potential impacts on system state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences front-load the primary action and a secondary usage note. Every word serves a purpose with no fluff, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's audience and purpose but lacks return value information (no output schema) and does not discuss error conditions or confirmations. For a simple emission tool with three documented params, it is minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed descriptions for all three parameters. The tool description does not add substantial meaning beyond the schema, so baseline 3 applies. The description reinforces the payload is arbitrary but adds no new param-specific detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'emit' and the resource 'custom system event onto the gateway bus,' specifying the action and target. It is distinct from sibling tools, as no other tool directly emits events, and the description references wrapping an internal command for context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description notes it is 'mostly used for tooling/debug' and that 'operators rarely call this directly,' providing some guidance on when to use it. However, it does not explicitly state when not to use it or name alternative tools for production event emission.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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. It states the tool 'synthesizes + plays' audio, but omits crucial details such as whether the operation is blocking, whether it requires audio output hardware, if there are side effects (e.g., interrupting current speech), or any permission/authorization needs. This lack of transparency could lead to incorrect expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that instantly conveys the core function, followed by a concise implementation note. Every word is necessary; there is no redundancy or fluff. It is front-loaded and efficient, making it easy for an agent to quickly grasp the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (two parameters, no output schema), the description is adequate but not thorough. It misses potential contextual information such as whether the speech is played through the agent's default speaker, if it can be interrupted, or if there are rate limits. Considering the lack of annotations, the description should provide more behavioral context (e.g., async behavior, audio output requirements) to be fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has two parameters: 'text' (required) and 'instance' (optional). Schema description coverage is 50% (only 'instance' is described). The tool description clarifies that 'text' is the piece of text to speak, adding context beyond the schema's type constraint. For 'instance', the schema already provides a detailed description. Overall, the description adds moderate value to parameter understanding but does not fully compensate for the missing schema descriptions of 'text' (no minLength/maxLength details beyond the schema).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'Make the agent speak a piece of text out loud (synthesizes + plays).' It identifies the specific action on a well-defined resource (agent speech), and the inclusion of 'Wraps `talk.speak`' adds implementation context. Among sibling tools like openclaw_tts_convert (which only converts text to speech without playing) and openclaw_talk_config (which manages talk settings), this tool's purpose is distinct and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. While it mentions wrapping `talk.speak`, there is no explanation of scenarios where this tool is preferred over openclaw_tts_convert or other speech-related tools. The absence of any conditional advice or exclusion criteria leaves the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only says 'Wraps tts.disable', which is an implementation detail, not user-facing behavior. No mention of side effects, success/failure feedback, or whether it is safe.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, no fluff, front-loaded with the key action. Highly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (disable action with one optional param), the description is adequate but lacks behavioral context and error handling details. With no output schema, more detail on return value or status would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 the 'instance' parameter. The description adds no additional meaning beyond what the schema provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool disables text-to-speech output, which is a specific verb and resource. It distinguishes itself from siblings like openclaw_tts_enable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. It does not mention prerequisites, consequences, or when not to use it. The description lacks context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Declares itself as 'Read-only', a key behavioral trait. However, no annotations are provided, so the description carries the full burden. It could disclose more (e.g., no side effects, authentication requirements, rate limits) but the read-only declaration provides basic transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no fluff. The purpose is front-loaded, and every phrase adds value. Extremely concise for the information conveyed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only status tool, the description covers the basics. However, it lacks details on what exactly 'token counts', 'current period', and 'quotas' refer to, and no output schema exists to compensate. Slightly more context would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already describes the sole parameter ('instance'). The description adds no additional meaning beyond what the schema provides. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves usage status with specifics like token counts, current period, and quotas. It also notes it wraps `usage.status`. It is distinct enough from sibling tools like `openclaw_status` and `openclaw_health`, but 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.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like `openclaw_status` or `openclaw_usage_cost`. The description implies its use for token/quotas but lacks 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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only says 'Read-only' but does not disclose pagination, rate limits, auth needs, or any side effects. The mention of wrapping `node.list` is vague.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with only two lines, front-loaded with the key action, and no wasted words. Every sentence serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
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 is too brief. It does not explain the return format, pagination behavior, or how to interpret the list of nodes. This is insufficient for a list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameter 'instance' is well-described in the schema. The description does not add additional meaning, but baseline is 3 due to high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists nodes registered with the gateway, specifying types (worker / canvas / sub-gateway nodes). It distinguishes from sibling tools like openclaw_node_describe and openclaw_node_invoke by being a general list read-only operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing nodes, but does not explicitly state when to use it versus alternatives like openclaw_node_describe. No exclusions or when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only mentions 'Mutates' without detailing side effects, permissions, or any behavioral traits. Since no annotations are provided, the description should disclose what happens on approval/rejection, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. Efficiently conveys the action and mutability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 4 parameters, no annotations, and no output schema, the description is too sparse. It does not explain return values, prerequisites, or fully clarify the role of all parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50%, with only id and instance described. The description adds no additional meaning beyond stating approve/reject, which partially clarifies the decision enum but not the approved boolean. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it resolves a pending plugin approval (approve/reject), which is a specific verb+resource. It distinguishes itself from sibling tools like openclaw_plugin_approval_list and openclaw_plugin_approval_request.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says 'Resolve a pending plugin approval (approve / reject)' but does not explicitly state when to use it versus alternatives like list or request. It implies usage after a pending approval exists but lacks clear when-to-use or when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description alone must disclose behavior. It states the tool 'blocks' and is 'long-running,' which is helpful. However, it does not mention what happens on timeout, cancellation, or if the approval is never decided. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loading the core purpose. Every sentence adds value: first states what it does, second provides context (wraps a specific API and notes long-running). No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (blocking call with timeout) and lack of output schema, the description should explain the return value (e.g., the decision result) and timeout behavior. It fails to provide this, leaving the agent uncertain about what to expect after the call completes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 67% (2 of 3 params documented). The description adds no new parameter information beyond the schema's descriptions for 'id' and 'instance'. The undocumented 'timeoutMs' parameter is not explained, so the description does not compensate for the gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Block until a plugin approval gets a decision.' It specifies the resource ('plugin approval') and the operation ('wait for decision'), and differentiates from siblings like 'openclaw_exec_approval_waitDecision' by using 'plugin approval' explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives (e.g., when to use exec vs plugin approval wait). It does not state when not to use it or any prerequisites. The only hint is 'Long-running', but no explicit usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It states the tool re-registers capabilities, implying state mutation, but lacks disclosure on side effects, permissions, rate limits, or impact on ongoing operations. Some behavioral context is provided but insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: one for purpose, one for implementation reference. No redundant words, efficient and clear structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains the action and its underlying API wrapper, but given the lack of output schema and behavioral details, more context on what the refresh entails and when to use it would improve completeness for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 single parameter 'instance'. The tool description does not add any additional meaning beyond what the schema already provides, resulting in a baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Refresh the canvas capability map for nodes') and the specific resource and operation. It distinguishes from sibling tools like openclaw_node_describe or openclaw_node_list by focusing on re-registering capabilities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor any conditions or prerequisites. It does not mention when a refresh is needed or what scenarios warrant its use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description only says 'Wraps sessions.create' with no detail on side effects, idempotency, or auth requirements. Inadequate for a potentially mutating action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, no irrelevant details. Front-loaded with action verb.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Describes creation but omits return value (no output schema). No mention of errors, prerequisites, or behavioral nuances for a moderate-complexity tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all 3 parameters (100% coverage). Description adds defaults for agentId and clarifies title's role, but does not significantly extend schema info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Create a new agent session' – specific verb and resource. Distinguishes from sibling session tools like openclaw_sessions_list, openclaw_sessions_delete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage for creating sessions but lacks explicit when-to-use or when-not-to-use guidance. No exclusion of alternatives; reliance on tool name and sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 only states 'Toggle / configure heartbeat emission' without detailing side effects, prerequisites, or whether changes are reversible, leaving significant gaps for an AI agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, using two sentences to convey purpose and parameter guidance with no extraneous text. Every sentence is informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and low parameter coverage, the description lacks important context such as return values, success/failure behavior, and prerequisites, making it incomplete for an agent to use reliably.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is low (33%), and the description merely names 'enabled' and 'cadence params' without adding meaning beyond what the schema property names already convey. The 'instance' parameter is not mentioned despite having a schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('Toggle / configure') and resource ('heartbeat emission from the gateway'), distinguishing it from sibling tools like openclaw_last_heartbeat (read-only) and other configuration tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context by noting parameters to pass ('enabled' and cadence params), but lacks explicit guidance on when to use this tool versus alternatives 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that tokens are not printed and that the default instance is used if not specified. However, it does not state whether the operation is read-only or what happens if the instance does not exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. The first sentence front-loads the main purpose, and the second adds a critical behavioral note and usage hint. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description could have explained the return format or error behavior. It only says 'gateway configuration', which is vague. For a simple show tool with one parameter, it is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 the parameter. The description adds that passing 'instance' inspects a non-default one, which is redundant with the schema. No additional parameter meaning is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Show' and resource 'currently resolved gateway configuration'. It distinguishes itself from token-related tools by explicitly saying 'Does NOT print tokens', but does not differentiate from sibling setup tools like openclaw_setup_list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides context on default behavior and how to inspect non-default instances, but gives no explicit when-to-use or when-not-to-use guidance relative to siblings like openclaw_setup_list or openclaw_setup_select_default.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly states the tool is read-only, which is the primary behavioral trait. Since no annotations are provided, this is adequate. It does not elaborate on other behavioral aspects like response format or side effects, but the read-only nature is clearly communicated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences, no redundancy, and efficiently conveys the tool's purpose and nature.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lacks details about the output format or content of the catalog. Since there is no output schema, the description should clarify what the return value contains. It is adequate for a simple list tool but could be more informative.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50% (only 'instance' is documented in the schema). The description does not mention any parameters or add meaning beyond the schema. For a tool with low schema coverage, the description should compensate but it does not, leaving the 'agentId' parameter underexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists the catalog of agent-facing tools, specifying it wraps `tools.catalog` and is read-only. However, it does not differentiate from the sibling `openclaw_tools_effective`, which might have a similar but distinct purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the tool lists tools available to agents, implying its use for discovery. It does not provide explicit when-to-use or when-not-to-use guidance, nor does it mention alternatives like `openclaw_tools_effective`.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses that the tool cancels without applying changes and wraps 'wizard.cancel', which is adequate for a simple cancellation. However, it does not detail side effects, prerequisites, or error scenarios.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with only two sentences, front-loading the purpose. Every word earns its place, and there is no unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
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 the core functionality but lacks context on what happens when no wizard is active, error handling, or relationship to other wizard tools. It is minimally adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The tool description does not add any parameter-specific information beyond what the schema already provides. The description of the 'instance' parameter is entirely in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'cancel' and the resource 'active wizard flow', and specifies 'without applying its changes', which distinguishes it from other wizard-related tools like openclaw_wizard_next or openclaw_wizard_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, such as when there is no active wizard or how it compares to other cancellation methods. The description only states the action without usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 action (advancing) but does not mention what happens on failure, invalid answers, no active wizard, or side effects. This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded, with two sentences that cover the core action and method without unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and lack of output schema, the description covers the basic action but omits error conditions, return values, and prerequisites. More context would improve agent decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single optional parameter 'instance', which is described in the schema. The tool description adds no extra parameter meaning, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool advances the active wizard to its next step with the user's answer, using a specific verb and resource. It distinguishes from sibling wizard tools like start, cancel, and status, and references the underlying method.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use after starting a wizard and with a user answer, but does not explicitly state prerequisites, when not to use, or alternatives. No exclusion or context is provided beyond the basic action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It only states 'Read-only', which indicates safety but fails to disclose other behavioral traits such as idempotency, required permissions, handling of missing policy, or return format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two short sentences. It is front-loaded with the primary purpose, includes a parenthetical clarification, and wastes no words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional parameter, no output schema), the description adequately states the action and read-only nature. However, it lacks details on the return value structure, which would be helpful since no output schema exists.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% coverage for the single optional parameter 'instance', with a detailed description in the schema. The tool description adds no additional parameter semantics beyond what the schema provides, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it gets the global exec approvals policy, specifying verb 'get' and resource 'global exec approvals policy'. It differentiates from sibling tools like openclaw_exec_approval_get (singular) and openclaw_exec_approvals_set by emphasizing 'global' scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions 'Read-only' and wraps a specific function, but provides no explicit guidance on when to use this tool versus alternatives like openclaw_exec_approval_list or openclaw_exec_approvals_set. Usage context is implied but not clearly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description declares the tool is read-only and wraps `gateway.identity.get`, which implies no side effects. However, with no annotations provided, it lacks details on error conditions, authentication requirements, or rate limits, which would enhance transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two short, front-loaded sentences. Every word adds value, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one optional parameter, the description adequately specifies the returned fields (id, version, owner, region) and notes the wrapper function. It is sufficiently complete given the tool's low complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the `instance` parameter well-documented in the schema. The tool description does not add parameter details but the schema suffices, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the gateway's identity (id, version, owner, region) and explicitly labels it as read-only. It is a specific verb+resource combination that effectively communicates its functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide guidance on when to use this tool versus alternatives such as `openclaw_agent_identity_get` or other identity retrieval methods. No context is given for exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool mutates state and grants gateway access, which is important as no annotations exist. However, it omits details like error conditions, idempotency, or permission requirements, leaving some behavioral aspects unclear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loads the purpose, and every sentence provides value. It is concise without being under-specified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with 2 parameters and no output schema, the description covers purpose and mutation. However, it does not address the requestId semantics or possible return values, and with no annotations, it is only moderately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50% (only instance is described). The description does not add meaning to the requestId parameter, which has no schema description. It fails to clarify what the requestId represents, leaving a gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'approve' and the resource 'pending node pairing request', with the outcome 'node gains gateway access'. It distinguishes itself from sibling tools like openclaw_node_pair_list or openclaw_node_pair_reject by specifying the approval action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use (when a pending request needs approval) but does not explicitly mention when not to use or provide alternatives like reject. It lacks direct guidance on usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses that compaction creates a snapshot and keeps the session live, which is key. However, it does not mention potential side effects (e.g., performance impact), error conditions, or whether the operation is asynchronous.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise—a single sentence with a parenthetical and a mention of the underlying API. Every part is relevant, though slightly more structure (e.g., a separate section for behavior) could improve readability without added length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple trigger action, the description is adequate but lacks details on return values (e.g., compaction ID), error handling, or prerequisites (e.g., session must be active). Given the richness of sibling compaction tools, more context would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 no further meaning to the parameters beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Trigger' and the resource 'compaction of a session's history', and distinguishes from sibling compaction tools (list, get, restore, branch) by specifying it creates a new snapshot while keeping the session live.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for creating a new compaction but offers no explicit guidance on when to use this versus alternatives like openclaw_sessions_compaction_restore or openclaw_sessions_compaction_branch. No when-not or prerequisite information is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Only mentions server-side limitation, but no disclosure of side effects, event handling, or authentication requirements. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two succinct sentences: purpose and key limitation. Front-loaded and no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
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, event delivery mechanism, and side effects. Incomplete for an agent to use effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed parameter descriptions. Description adds no additional parameter semantics 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states verb 'Subscribe', resource 'streaming session messages', and event type 'session.message'. Distinguishes from siblings like openclaw_sessions_messages_unsubscribe.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides a crucial constraint: MCP stdio cannot stream events to Claude Code; subscription is server-side only. However, does not explicitly guide when to use vs. alternatives like openclaw_sessions_tail.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description correctly declares the tool as read-only and mentions it wraps 'skills.status'. However, it lacks detail on what exactly the status looks like, any permissions required, or rate limits. The disclosure is minimal but accurate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences that front-load the purpose and then provide an implementation detail. Every word earns its place, making it efficient for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one optional parameter and no output schema, the description covers the essential purpose and behavior. It hints at output content (installed, enabled, recently updated) but could explicitly state the return format. Overall, it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides a detailed description for the 'instance' parameter, achieving 100% coverage. The tool description adds no additional semantic value beyond what the schema offers, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves the skills subsystem status, including installed, enabled, and recently updated skills. The verb 'Get' and the explicit 'Read-only' mark the intent. It distinguishes from sibling skills tools like openclaw_skills_search, which searches, and openclaw_skills_install, which installs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide guidance on when to use this tool versus alternatives, nor does it mention prerequisites or exclusions. It only states the function without context for selection among many sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It states 'Read-only' which is a behavioral trait, but lacks details on side effects, error conditions, or permissions. Minimal disclosure beyond basic read-only nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: one sentence plus a keyword. No unnecessary words, yet includes purpose and read-only note. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one optional parameter and no output schema, the description covers the key points: what it returns (connected devices and last spoke time). Could mention return format but adequate given simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 includes a detailed description in the input schema. The tool description adds no additional parameter meaning, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states action 'Get', resource 'presence info', and specifics: connected devices and last spoke time. It also mentions it's a wrapper and read-only, distinguishing it from sibling tools like openclaw_device_status or openclaw_health.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description provides clear purpose but no explicit guidance on when to use vs alternatives. It does not mention exclusions or comparisons to sibling tools like openclaw_device_status. Usage is implied but not detailed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses blocking nature, long-running duration, and timeout bounded by request timeout. No annotations provided, so description carries burden; it effectively conveys key behaviors. However, does not specify error handling (e.g., what happens on timeout or cancellation).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no redundant information. Front-loaded with action and result. Each sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, no annotations, and description omits return value behavior (e.g., what does it return on timeout? error? null?). For a blocking wait, missing details on timeout handling and response structure makes it incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 67% (id and instance described). Description adds no new meaning for id or instance beyond schema, and fails to describe timeoutMs parameter which lacks schema description. Baseline for high coverage is 3 but one param ignored, reducing score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool blocks until an exec approval gets a decision or times out, distinguishing it from siblings like openclaw_exec_approval_get (non-blocking) and openclaw_exec_approval_request (creates requests). Verb 'Block until' plus resource 'exec approval decision' is specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description implies use when waiting for a decision by stating it blocks, but does not explicitly contrast with alternatives like openclaw_exec_approval_get for non-blocking checks or mention when not to use. Lacks explicit when-not and alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly states it is 'read-only' and wraps a specific API, which provides basic behavioral transparency. However, with no annotations present, it lacks details on authentication requirements, rate limits, or the exact scope of 'pending and recent'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no unnecessary words. It front-loads the purpose and adds a read-only clarification, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with two optional parameters and no output schema, the description provides adequate context: the resource type (plugin approvals), read-only nature, and internal API. It lacks details on return format or pagination, but the simplicity of the tool reduces the need.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50% (only 'instance' is described). The description does not clarify the 'status' parameter, which has no schema description, and does not add value beyond what the schema already provides for 'instance'. The agent lacks guidance on how to use the status filter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'pending and recent plugin approval requests', with added context that it involves skills/plugins asking for permissions. It distinguishes itself from sibling tools like openclaw_exec_approval_list through the explicit mention of 'plugin'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for viewing pending and recent approvals but does not provide explicit guidance on when to use this versus alternatives (e.g., openclaw_plugin_approval_request for creating approvals). No exclusion criteria or scenarios are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
States 'Read-only' which is a key behavioral trait, especially with no annotations. However, lacks further details like idempotency, rate limits, or side effects. Acceptable for a list operation but could be more complete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the verb and resource. No redundant information. Highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, and description doesn't specify return format (e.g., array of snapshot objects, fields). Missing info on pagination or filtering. Adequate for a simple list but could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters. Description adds no extra meaning beyond schema. Baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states action ('List'), resource ('compaction snapshots for a session'), and distinguishes from sibling compaction tools like get/restore/branch. Also notes it's read-only, providing immediate clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implied use case (listing snapshots for a session) but no explicit when-to-use or when-not-to-use guidance. No alternatives mentioned among siblings, e.g., when to use this vs openclaw_sessions_compaction_get.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must disclose behavioral traits. It indicates mutation ('update') but omits details on idempotency, error behavior, permissions, or return values. The note about id ambiguity is helpful but 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at two sentences, but includes a technical wrapper reference ('Wraps sessions.patch') that adds little value for an agent. Slightly structured but could be tighter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema and annotations, the description should cover return values and error scenarios. It does not. The id handling guidance is good, but overall, the tool's response and failure modes are unresolved.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers both parameters with descriptions, and the description adds significant value by clarifying the id parameter's ambiguous format (UUID vs. composite key) and suggesting a retry strategy. This exceeds what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool updates session metadata, specifying fields like title, displayName, and tags. It distinguishes itself from other session tools like create, delete, and list by focusing on partial updates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description instructs to pass the id and only the fields to change, and notes the permissive schema. However, it does not explicitly contrast with alternative tools or provide when-not-to-use guidance, though the purpose is clear from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 the tool 'starts a setup wizard flow' and 'wraps wizard.start', but does not disclose side effects, required permissions, or whether it is stateful or destructive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the purpose, no wasted words. Efficient and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool, the description is adequate but leaves gaps: no return value information, no mention of statefulness, and the instance parameter is well-documented but id and kind remain vague. Without output schema or annotations, more context would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 33% (only instance has a description). The description adds meaning for id and kind by saying 'Pass the wizard id / kind', but it does not specify formats, allowed values, or whether they are required. This partially compensates for the missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool starts a setup wizard flow, provides examples like agent onboarding and channel pairing, and distinguishes from sibling tools like wizard_next, wizard_cancel, and wizard_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives the direct instruction to pass the wizard id/kind and provides context with examples. However, it does not explicitly state when to use this tool vs alternatives 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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Declares 'Read-only' which is key behavioral info, and mentions it wraps node.describe. With no annotations, this is helpful but does not cover authorization, rate limits, or side effects fully.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with purpose and key output details. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple nature (2 params, no output schema), the description adequately covers what the tool does and what it returns. Could mention relation to openclaw_node_list for completeness, but still effective.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description does not add additional meaning beyond what is already in the schema for the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Describe a specific node' and lists returned information: capabilities, host, version, last heartbeat. Distinguishes from siblings like openclaw_node_list (list all) and openclaw_node_invoke (execute action).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implicitly suggests use for detailed info on a single node, but lacks explicit guidance on when to prefer over alternatives (e.g., openclaw_node_list for enumeration) 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses read-only nature via description, but no annotations exist; does not detail error conditions, authentication needs, or behavior for incomplete invocations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no waste; action and resource are front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, so description should hint at return format; it does not. Prerequisites (prior invoke) are implied but not explicit.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50%; description adds no parameter details, leaving 'invocationId' undocumented in both schema and description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Describes fetching the result of a node invocation using a specific verb 'fetch' and resource 'result', and distinguishes from sibling 'openclaw_node_invoke' which issues invocations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Clearly states used after a node invocation, but lacks explicit when-not or alternative tool comparisons beyond the implicit sibling context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description clearly indicates the tool is read-only and explains its merging behavior. It does not cover potential errors (e.g., missing agent) or authorization requirements, but for a simple read operation, the transparency 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loading the core purpose and culminating with a read-only declaration. No extraneous information is present; every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations and output schema, the description covers the basic purpose and behavior but leaves gaps: it does not explain how to use parameters (especially agentId and sessionId), what the return value structure is, or how to handle agent-not-found cases. It is minimally adequate but lacks detail for a complete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no additional meaning to the parameters beyond what the schema provides. Only one of three parameters (instance) has a schema description; the others (agentId, sessionId) lack descriptions, and the tool description does not clarify their purpose or necessity. Schema coverage is low (33%), and the description fails to compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the effective merged tool set for an agent, listing its components (base catalog, skill-provided, per-agent overrides). It explicitly marks the operation as read-only and differentiates from siblings like openclaw_tools_catalog by specifying the merging of overrides.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for obtaining the effective tool set but does not explicitly state when to use this tool versus alternatives (e.g., openclaw_tools_catalog) or provide any 'when not to use' guidance. No prerequisites or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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 warns 'Destructive — discards queued work,' a critical behavioral trait. It also mentions the underlying API wrapper, but does not cover auth or other side effects, still adequate for a clear operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the primary action. Every word is necessary; no fluff. Efficiently conveys purpose and key warning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the essential action and destructive nature, but there is no output schema and no mention of return values or confirmation. For a clear operation, it is somewhat complete, but additional context (e.g., what happens after draining) would help.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 no additional meaning to the parameter schema descriptions ('Node id', 'Optional OpenClaw instance...'). The tool's purpose implies the nodeId identifies the node, but no extra context is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Drain (clear) all pending work items for a node.' This uses a specific verb (drain/clear) and identifies the resource (pending work items for a node). It distinguishes from sibling tools like openclaw_node_pending_pull and openclaw_node_pending_enqueue, which handle pending items differently.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes 'Destructive — discards queued work,' which implies when to use it (to clear pending work) and when not (if preservation is needed). However, there is no explicit guidance on when to choose this tool over related siblings like pull or enqueue.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 mentions the tool is destructive and interrupts running work, but lacks details on side effects, reversibility, authentication requirements, or any return value. This is insufficient for a mutation tool with no annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The main description is two concise sentences that state the purpose and key behavioral note. The parameter descriptions are thorough but within the schema. Every sentence earns its place; no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple action tool (abort with id and optional instance), the description covers purpose, parameter semantics, and destructiveness. However, it omits what the tool returns on success or failure, and does not mention prerequisites (e.g., session must be in-flight). Given low complexity, these gaps are minor.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description for the 'id' parameter adds significant context: it explains that most session methods accept UUIDs but some accept composite keys, and provides a fallback strategy ('try UUID first, if rejected with NOT_FOUND retry with key from openclaw_sessions_list'). The 'instance' parameter description also adds routing context. This goes well beyond the schema's basic type and required fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states its purpose: 'Abort the in-flight agent turn for a session (cancels the current LLM call / tool loop).' The verb 'Abort' and resource 'in-flight agent turn for a session' are specific, and it distinguishes from sibling tools like sessions_reset (which resets state) and sessions_delete (which removes sessions).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says 'Destructive — interrupts running work,' implying use when stopping a running turn is needed. However, it does not provide explicit when-to-use or when-not-to-use guidance, nor does it compare to alternatives like sessions_reset or sessions_delete. The guidance is present but minimal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Given no annotations, the description discloses that the operation is destructive and wraps `sessions.delete`. This is basic transparency but lacks details on permissions, side effects, or whether the action is reversible. It adds some value beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one sentence plus a warning. Every word is meaningful, and the action is front-loaded. No unnecessary details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the tool is simple, the description does not mention return values or confirm the result of deletion. No output schema exists, so the description should at least hint at what the agent can expect. It is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both `id` and `instance` having detailed descriptions. The tool description adds no new parameter meaning; it only states the overall action. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Delete a session permanently' with a specific verb and resource. It distinguishes from sibling session tools like list, create, patch, abort, etc., by focusing on deletion. The note about being destructive reinforces the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The tool warns 'Destructive — confirm before calling,' which is an explicit usage guideline. However, it does not compare with alternatives like `openclaw_sessions_abort` or `openclaw_sessions_reset`, so it's slightly less comprehensive than ideal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears the full burden. It correctly states the tool is destructive and preserves the session id, but it does not detail what 'working state' entails (e.g., messages, context). Also missing are potential authorization requirements or side effects beyond state clearing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the primary purpose. Every word earns its place; no redundancy. The description is extremely concise yet informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema is provided, so the description must cover return values, but it does not. The tool is simple, yet the description omits what is returned (e.g., confirmation, success). The destructive warning is helpful, but overall completeness is adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the parameters are well-documented in the schema. The description adds no additional meaning to the parameters beyond the overall behavior. Baseline score applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Reset' and the resource 'a session'. It distinguishes from sibling tools by specifying that it clears working state but keeps the session id, and it mentions wrapping `sessions.reset`. This ensures the agent understands the specific action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear warning 'Destructive — confirm before calling.' This indicates when caution is needed. However, it does not explicitly compare with alternatives like `openclaw_sessions_abort` or `openclaw_sessions_delete`, leaving the agent to infer when to use this tool over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description states 'Read-only', which is the key behavioral trait. No annotations provided, so the description carries the burden. However, no additional details on return format, error conditions, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, no unnecessary words. Efficiently conveys purpose and nature.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given simple parameter set (no required params, no output schema, no nested objects), description is fully sufficient for an AI agent to understand and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Single optional parameter 'instance' is already well-described in schema (100% coverage). Description adds no extra semantic detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states action ('List'), resource ('TTS providers'), and additional detail ('their voices / models'). Distinguishes from sibling tools like openclaw_tts_setProvider and openclaw_tts_convert.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance. Implied by purpose and sibling context, but lacks exclusions compared to other TTS tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the burden of behavioral disclosure. It declares the tool as 'Read-only,' which is critical, and indicates it wraps an internal API (`usage.cost`). However, it omits details like error handling, pagination, response format, or rate limits, which are important 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences, each adding value. The main action is front-loaded ('Get usage cost breakdown'), followed by clarifying details. No fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema and low schema coverage, the description provides a high-level overview but lacks detail about the returned data structure, how filters combine, or what 'cost breakdown' entails. For a tool with 4 parameters and no explicit output specification, more completeness would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25% (only 'instance' documented). The description compensates by clarifying that 'agentId', 'sinceMs', and 'untilMs' serve as agent and period filters, adding semantics beyond the raw schema. It does not fully detail parameter interactions or constraints, but significantly improves understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a usage cost breakdown, specifying dimensions (per agent, per model, per period). It uses a specific verb ('Get') and resource ('usage cost breakdown'), and distinguishes from siblings like openclaw_usage_status by focusing on costs. The mention of wrapping `usage.cost` adds transparency.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides basic guidance on passing period and agent filters, but does not explicitly specify when to use this tool over alternatives (e.g., openclaw_usage_status) or when not to use it. The phrase 'if supported' implies conditional behavior but lacks full context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It clearly states the tool is read-only ('Read-only') and wraps a specific command, which conveys safety. However, it lacks details on rate limits, authentication requirements, or data format of the response.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the purpose. Every phrase earns its place without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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 parameter) and the presence of sibling tools, the description adequately covers the purpose and behavior. It could mention the return type but is sufficient for an agent to select and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% as the single 'instance' parameter is fully described in the input schema. The description does not add additional meaning beyond what the schema already provides, so baseline score is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get', the resource 'last heartbeat info', and adds context 'latest tick processed by the gateway'. It also mentions wrapping the underlying command, making the purpose unambiguous. Among siblings like openclaw_health and openclaw_set_heartbeats, this tool is distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates 'Read-only' but does not explicitly state when to use this tool versus alternatives like openclaw_health or openclaw_status. Usage is implied but no exclusions or alternative guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey safety and side effects. It mentions wrapping an internal function and the purpose but omits potential failure modes or permissions required.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences, no redundant information, and the primary action stated first.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the operation and no output schema, the description covers the essential information. It could mention what happens on failure, but it is sufficiently complete for the tool's purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the schema includes a detailed description for the only parameter. The tool description does not add further value beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Reload') and resource ('gateway's secret store from disk'), clearly distinguishing it from sibling tools like openclaw_secrets_set or openclaw_secrets_resolve.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to use ('after editing the secrets file out-of-band') and the benefit ('picks up new values without a restart'). No alternatives are mentioned, but the use case is narrow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries burden. It mentions creating a new session and preserving current state, implying non-destructive behavior. Lacks details on side effects, auth, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, each earning its place: first defines what it does, second gives usage guidance. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (4 params, no output schema, no annotations), description covers purpose and use case adequately. Missing return value description but acceptable for a create tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and parameter descriptions are already in the schema. The tool description does not add additional meaning beyond stating it starts from a 'previous compaction snapshot'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it creates a new session from a compaction snapshot, using the verb 'Create' and specific resource. Distinguishes from siblings like openclaw_sessions_compact by focusing on branching.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use: 'explore an alternative continuation without losing the current session state.' Does not specify when not to use or list alternatives, but the use case is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It declares 'Read-only', which is a key behavioral trait. However, it does not describe potential errors, permissions, or exactly what the snapshot data contains.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: three short sentences (or fragments) that immediately convey purpose, wrapper nature, and read-only trait. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description does not specify the return value, but the tool's simplicity (fetching a snapshot) makes this acceptable. Overall, it is nearly complete for a read-only retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the description adds no extra parameter detail beyond what is already in the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Fetch a specific compaction snapshot by id' and 'Read-only', clearly identifying the action and resource. Among siblings like list, restore, branch, this tool is uniquely the getter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The parameter description for 'id' instructs to get the id from openclaw_sessions_compaction_list, providing clear context to use list first. However, no explicit when-not or alternative guidance is given beyond this.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden and does well: it explains that the `status` filter is applied client-side after fetch (with a note validating this against the gateway), details key formats, and describes instance routing fallback. It does not cover pagination beyond limit/offset or error behavior, but it adds meaningful context beyond the raw function name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences plus a parenthetical, efficiently stating purpose, key format, usage context, and a behavioral note. It is front-loaded with the core action. Minor improvement would be to remove redundancy or tighten the parenthetical, but overall it is concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description does not explain the return structure (e.g., array of session objects, pagination metadata). It describes key formats but omits details like response fields or how limit/offset affects results. It is adequate for a simple list operation but could be more complete regarding expected output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 60% (3 of 5 parameters documented in schema: status, agentId, instance). The description adds value for `status` (client-side behavior), `instance` (fallback logic), and explains key formats. However, `limit` and `offset` receive no additional explanation, and the description does not fully compensate for the 40% undocumented parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states its purpose: 'List active OpenClaw agentic sessions.' It provides specific details about session key formats and explicitly positions itself as a tool to use before preview/patch/abort/compact/reset, distinguishing it from sibling session tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use to find a session before preview/patch/abort/compact/reset,' providing clear context for when to use this tool. It also warns about the client-side status filter behavior, though it does not explicitly mention when not to use it relative to alternative list tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the side effect of closing the matching client connection and re-handshaking, and mentions env var override. However, it does not discuss error handling, validation, or authorization requirements, which are important for a setup tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a concise paragraph of five sentences, each adding valuable information. It front-loads the main purpose and avoids redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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 covers the essential aspects: purpose, instance naming, env var override, and side effect. However, it omits return value and error behavior, which would improve completeness for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already explains each parameter. The description adds minor context about default instances and env var precedence, but does not significantly enhance understanding beyond the schema's descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'persist' and the resource 'named OpenClaw gateway config (URL + token) to local store'. It distinguishes from sibling tools like openclaw_setup_show and openclaw_setup_list, which are for viewing/deleting, by focusing on saving/creation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use the tool: to persist config, manage multiple instances, and leverage env var fallback. It implicitly distinguishes from siblings via naming, but does not explicitly state when not to use or name alternatives like openclaw_setup_show for viewing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden. It mentions 'Read-only', which is valuable behavioral information, but does not disclose potential side effects, prerequisites, or other behavioral traits beyond the basic 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences with no wasted words. The purpose is front-loaded, and the mention of the underlying wrapped function is helpful for context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional parameter, no output schema), the description provides enough context for an agent to understand what it does. It could mention that the output is a list of paths or names, but it's not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description does not add any additional meaning to the optional 'instance' parameter beyond what the schema already describes.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists binaries/executables from installed skills, with a specific verb and resource. The name 'openclaw_skills_bins' distinguishes it from sibling tools like 'openclaw_skills_status' or 'openclaw_skills_search'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing binaries, and notes it's read-only, but does not explicitly state when to use it vs. other skills-related tools. However, the context is clear enough for an agent to select it appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It states 'Read-only' and wraps skills.detail, but lacks details on error handling, return format, or permissions. Adequate for a simple read operation, but could be richer.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise: one sentence plus 'Wraps skills.detail. Read-only.' No redundant information, front-loaded with action and purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, description mentions return fields (manifest, version, dependencies, install state) which is helpful. It lacks details on pagination or structure, but for a detail endpoint this is acceptable. Could mention what 'install state' means, but overall sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema covers both parameters with descriptions (id: skill id/slug, instance: optional routing). Description adds context by mentioning the fields returned, but does not clarify parameter constraints beyond schema. Baseline score due to high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it retrieves detailed info on a specific skill, listing the fields (manifest, version, dependencies, install state). Distinguishes from sibling tools like skills_search or skills_install by focusing on a single skill's detail.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description implies use when you need detailed info on a specific skill, but does not explicitly contrast with alternatives (e.g., skills_status for summary, skills_search to find skills). The 'Read-only' tag provides some guidance on safety.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description explicitly states 'Read-only', which is a key behavioral trait indicating no mutations. It also mentions it wraps a JSON-RPC method, adding technical context without contradicting any annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences: the first clearly states the purpose and contents, the second adds relevant technical detail. No redundant or unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only status tool with one optional parameter and no output schema, the description covers the essential aspects: what it returns (overview of uptime, agents, sessions, queues) and that it is safe. Could optionally mention the return format, but not required.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter 'instance', and its description in the schema is sufficient. The tool description does not add additional meaning beyond the schema, but that is acceptable given full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get overall gateway status' and lists the key components (uptime, agents, sessions, queues), distinguishing it from more specific status tools like openclaw_device_status or openclaw_skills_status by using 'overall'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies it is for a high-level overview but does not explicitly guide when to use this tool versus alternatives like openclaw_health or openclaw_usage_status. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full disclosure burden. It declares the operation as read-only and lists returned fields, which is adequate for a simple status check. However, it omits potential edge cases (e.g., behavior if TTS subsystem is unavailable, permission requirements, or side effects). The basic transparency warrants a 3.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences that directly convey purpose and behavioral trait. It is front-loaded with the action and resource, and every word serves a purpose: 'Get', fields in parentheses, command reference, and read-only note. No wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one optional parameter, the description covers what the tool returns (enabled, provider, voice) and its read-only nature. No output schema exists, so description must provide return context, which it does at a high level. Could be more complete by specifying the exact structure or format of the response, but sufficient for typical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% coverage with a detailed description for the sole 'instance' parameter, covering its role, fallback behavior, and how to list instances. The tool description adds no additional parameter information beyond the schema. Therefore, the description meets the baseline expectation for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves TTS subsystem status with specific fields (enabled, provider, voice). The verb 'Get' and explicit listing of returned data differentiate it from sibling tools like openclaw_tts_enable, openclaw_tts_disable, etc., making purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies read-only use via 'Read-only' and the nature of a status check. It does not explicitly state when to avoid this tool versus alternatives, but the sibling tool names (e.g., openclaw_tts_enable) clearly indicate modification roles. Lacks explicit exclusion guidance but sufficient for context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It declares 'Read-only' indicating non-mutating behavior and mentions the underlying API call. However, lacks details on permissions, error conditions, or response structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, each essential: the first states purpose and payload, the second adds behavioral context and internal reference. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with one optional parameter and no output schema, the description covers core functionality and safety. Could mention expected return format but not critical given simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description does not add parameter-specific information beyond what the schema already provides (instance routing description).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description explicitly states the verb 'Get', the resource 'voice-wake configuration', and lists the attributes (wake word, sensitivity, enabled). It distinguishes from siblings by noting it is read-only, contrasting with a likely setter sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly indicates usage for retrieving configuration via 'Get' and 'Read-only'. It does not explicitly state when not to use or name alternatives, but the read-only nature provides clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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 explicitly declares the tool as read-only and reveals it wraps an existing API (`models.list`). This is informative, though additional details like pagination or default result limits would enhance transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. The first sentence states purpose and scope; the second provides implementation context. Information is front-loaded and highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with one optional parameter and no output schema, the description is complete. It specifies what is listed, read-only behavior, and the underlying API. No missing details for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with one parameter (`instance`). The schema already describes the parameter well, including fallback behavior and cross-referencing other tools. The description adds no further meaning, so baseline score 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists models available to the gateway, specifies the scope (Anthropic, OpenAI, etc.), mentions output includes IDs and provider metadata, and notes it wraps `models.list`. This distinguishes it from sibling tools like `openclaw_tools_catalog` or `openclaw_agents_list`.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing gateway models but does not explicitly state when to use this tool versus alternatives, nor provide exclusions or prerequisites. The read-only note offers some guidance, but lacks direct comparisons to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It explicitly states that passwords/tokens are never returned (only presence indicators), and discloses the secrets location (file vs OS keychain). This is good transparency for a read-only 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences that front-load the primary purpose and then add two key additional pieces of information (active default, secrets location). Every word adds value, no waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and no output schema, the description provides all necessary information: what is listed (instances with specific fields) and what additional data is included. It is complete for a list tool without requiring pagination or ordering details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so schema coverage is 100%. The description does not need to explain parameters, and the baseline of 3 is appropriate per guidelines.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists all persisted gateway instances with specific fields (name, URL, token/password status) and additional information about active default and secrets location. It effectively distinguishes from sibling tools like openclaw_setup_show (likely single instance) and openclaw_setup_select_default (set default).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that this tool is used for obtaining an overview of gateways, but it does not explicitly mention when to use it versus alternatives like openclaw_setup_show. No usage exclusions or context are provided, so the guidance is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses destructive behavior and potential session interruption, filling the gap due to missing annotations. Could elaborate on return value or async behavior, but current disclosure is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences: purpose, wrapping detail, and warning. Efficiently front-loaded with no unnecessary content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Lacks return value description (no output schema). Does not explain if it prompts for confirmation or returns a status. Could be more complete for a destructive operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 minimal value beyond schema: references 'latest version' aligns with `version` param. No extra semantics for `instance` param.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool triggers an update by pulling the latest version and restarting components. Specifies it wraps `update.run`, and among sibling tools, none perform the same function, making its purpose distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly warns that the call is destructive and may interrupt sessions, advising confirmation. No explicit comparison to alternative tools, but the warning sufficiently guides appropriate use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 read-only and mentions the wire format, but does not disclose error behavior or side effects. This is 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the main purpose, and every sentence adds value. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with a clear purpose, the description covers what it does, what it returns (current step and pending input), and the key requirement (sessionId). No output schema is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 adds minimal value beyond requiring sessionId. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets the wizard's current step and pending input for a specific session. It uses a specific verb ('get') and resource ('wizard status'), and distinguishes itself from sibling wizard tools like start, next, cancel which perform mutations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description notes that it requires sessionId and is read-only, but does not explicitly state when to use this tool versus alternatives like openclaw_status. However, the purpose is clear enough that an agent can infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly labels the tool as 'Read-only,' which is a key behavioral trait, especially since no annotations are provided. It also describes the output components (server health JSON-RPC, client metadata) and the action it performs (probe), giving adequate transparency 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, immediately front-loading the core purpose ('Combined health probe') and key details. Every sentence adds value with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple health check tool with one optional parameter and no output schema, the description adequately covers the return value composition and usage intent. It could be slightly more explicit about the exact format of the output, but the current level is sufficient for an agent to understand and use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'instance' is fully described in the input schema with details about routing and fallback behavior. The description does not add additional meaning or context beyond what the schema already provides. With 100% schema coverage, a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs a combined health probe, specifying both server-side and client-side components, and directly contrasts with sibling tools by emphasizing it's a one-shot 'is everything OK?' check. The verb 'probe' and resource 'health' are specific and distinguishable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly recommends use for a one-shot check ('Use this for a one-shot 'is everything OK?' check'), providing clear context. It does not explicitly state when not to use it or name alternative tools, but the context is clear enough for an agent to differentiate from more detailed health tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It mentions wire format requirements and idempotencyKey for deduplication, implying mutation but not fully disclosing side effects or idempotency beyond auto-generated keys.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences front-loaded with purpose, each sentence adds value without excess. Efficient and clear structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description covers key aspects: purpose, required parameters, idempotency, and sibling guidance. For a simple send tool, it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 mentions to and idempotencyKey but adds little beyond the schema; instance is not highlighted.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is a channel-routed send for pushing messages, and explicitly contrasts with typed siblings openclaw_chat_send and openclaw_sessions_send when session context is needed, providing strong distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises preferring typed alternatives when session context is desired, giving clear guidance on when not to use this tool and what alternatives exist.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses async processing, event streaming, and need to call preview for results. Lacks details on authentication, rate limits, or error behavior, but covers key behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with purpose, each sentence adds essential information. No redundant or wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, description explains how to obtain results (preview). It mentions composite key and instance routing. Could elaborate on error cases, but sufficient for typical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3. Description adds value by clarifying that text and message are aliases with version-dependent preference, and that either can be used but not both.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Send a user message into an existing session' with a specific verb and resource. It distinguishes from siblings by mentioning 'existing session' and directing to openclaw_sessions_preview for results.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explains when to use (sending a message to an existing session) and provides guidance on parameter choice (text vs message). Could be more explicit about alternatives like openclaw_sessions_create for new sessions, 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses it is a setter (mutation) and the required boolean. However, does not discuss side effects, error conditions, idempotency, or permissions. For a mutation tool with zero annotations, more behavioral context is expected.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, includes essential technical details and sibling reference. No redundant words. Efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, but description does not explain the return value or response format. Mentions wire format but not what the tool returns on success/failure. For a setter with no output schema, the agent needs to know what to expect. Missing return value documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%. Description adds value beyond schema: for 'enabled', it reinforces that it's a setter and required boolean; for 'instance', it provides detailed usage instructions and fallback behavior, which is not in the schema. Adds significant meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Toggle talk mode on/off' with specific verb 'Toggle' and resource 'talk mode'. Emphasizes it's a setter, not a getter, and explicitly distinguishes from sibling tool openclaw_talk_config for reading.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear guidance: use this to set state, use openclaw_talk_config to read. Mentions wire format and required boolean. Lacks explicit 'when not to use' but the distinction from the config tool is strong. Also documents optional instance parameter and fallback behavior.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that it does not touch device identity or tokens, and the post-operation behavior. No annotations exist, so the description carries the full burden, and it does so adequately, though it could mention 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with no wasted words. Action, key parameter behavior, and critical caveats are all front-loaded and efficiently communicated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
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 covers all essential aspects: what the tool does, scope, parameter usage, exclusions, and post-condition. It is entirely sufficient for an AI agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the parameter description in schema already explains the instance parameter fully. The tool description repeats this information without adding new semantic details beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it clears a persisted gateway config, with default clearing all instances and optional instance parameter for targeted clearing. The scope is well-defined, excluding device identity and tokens, distinguishing it from device-related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context on when to use (to clear config) and what happens after (fallback to env vars or error). Does not explicitly mention when not to use or alternatives, but the action is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It warns that this is 'SENSITIVE — returns secret material,' explains the command-scoped nature and wire format. It does not detail auth requirements or error behavior, but the sensitivity warning and scope explanation add significant context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose. Each sentence adds distinct value: purpose, wire format, sensitivity warning, usage advice. It is not overly verbose, though 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.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description does not describe the return value format (e.g., secret string or object) or error cases. It mentions 'returns secret material' but is vague. For a sensitive tool, more completeness on return and error handling would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 explaining the wire format and command-scoped semantics, and clarifies the fallback behavior for 'instance'. This goes beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Resolve a command-scoped secret.' It uses a specific verb and resource, and distinguishes from sibling tool 'openclaw_secrets_set' by explaining the difference in scoping (command-scoped vs config tree).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance: 'Only use for debugging missing/wrong-values issues.' Provides alternative: 'For arbitrary API keys consumed by skills, use openclaw_secrets_set.' This clearly tells the agent when to use and when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description carries full burden. Explains internal call to config.patch, that writes are restart-free and visible to next run. Does not disclose if overwriting existing secrets is allowed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences efficiently convey purpose, parameters, and behavioral notes. No redundancy, each sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given schema coverage and tool complexity, description covers usage and behavior well. Lacks mention of error conditions or overwrite behavior, but otherwise complete for agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage 100%, description adds meaningful context: explains default scope, skill-scoped usage for scope parameter, and instance routing. Provides examples that go beyond schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies storing secrets in the gateway's config tree (e.g., 'Store an arbitrary secret ... in the gateway's config tree'). It distinguishes from siblings like openclaw_secrets_resolve and highlights the default scope and skill-scoped usage.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides context on when to use default scope vs. override for skill-scoped secrets. Mentions that it writes to CONFIG tree, not secrets.resolve store. Lacks explicit when-not-to-use or alternatives beyond the note about secrets.resolve.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Explicitly declares 'Read-only', a key behavioral trait. Also mentions internal wrapping of 'sessions.preview'. With no annotations, the description provides essential transparency about safety and data access.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each carrying weight: main purpose, read-only nature, parameter guidance. No fluff, information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequately covers tool purpose, return content, and parameter details. Lacks specifics about output format or message limit, but for a simple preview tool it's sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description adds value by explaining that keys are 'full session keys' from openclaw_sessions_list with an example, and clarifies the instance parameter's fallback behavior. Goes beyond bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states verb 'Preview', resource 'sessions', and what it returns ('recent messages, status, and metadata'). Distinguishes from sibling tools like openclaw_sessions_subscribe by noting 'without subscribing', and references openclaw_sessions_list for key format.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage when you need session data without subscribing, and instructs to obtain keys from openclaw_sessions_list. Could be more explicit about when not to use alternatives, but guidance is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the critical limitation that the MCP runs over stdio so events cannot stream back, but does not mention failure behavior or return value specifics. Still, the main behavioral trait is 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no fluff. Purpose is front-loaded, followed by the crucial caveat. Every sentence serves a clear purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description lacks info on return values (e.g., confirmation object, error details). However, the core purpose and usage limitation are sufficiently covered for a simple subscription tool. Could be slightly more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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). The description repeats the parameter name but adds no additional meaning beyond what the schema already provides. Baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Subscribe') and the resource ('session lifecycle events (sessions.changed)'), and distinguishes it from sibling tools like openclaw_sessions_unsubscribe. It also names the underlying function wrapped.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (to confirm subscription acceptance) and when not (since deltas won't stream back in Claude Code due to stdio limitation), providing clear context for agent decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully carries the burden. It explains polling mechanics, the first-poll seed set that excludes existing messages, termination criteria (duration, maxMessages, terminal status), and a rate-limit warning (min interval 500ms). All behavioral traits are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: first sentence states purpose, then provides context/workaround, and finally details behavior. Every sentence adds value with minimal redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, behavior, termination conditions, and references sibling tools. It lacks explicit return format details, but given the tool's simple purpose (return new messages), this is acceptable. Output schema is absent, but the description sufficiently implies the return type.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The tool description does not add significant meaning beyond the already-detailed schema parameter descriptions; it focuses on overall behavior rather than parameter specifics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Watch a session by polling sessions.preview and return only the NEW messages.' It clearly distinguishes from siblings like openclaw_sessions_preview (snapshot) and openclaw_sessions_subscribe (streaming), which are mentioned in the workaround context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use this tool: as a workaround for the inability to stream events via stdio MCP. It details polling behavior, termination conditions, and default/max values. It does not explicitly state when NOT to use it or name alternatives beyond implicit reference to subscribe endpoints, but the usage context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses key behavioral traits: closing existing client connections and re-routing subsequent calls. This goes beyond what is obvious from the name and schema, providing valuable transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, with two sentences that efficiently convey the purpose and a key side effect. Every word adds value, and the structure is front-loaded with the main action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema, no annotations), the description is largely complete. It covers the main action, effect on other tools, and a precondition. A minor gap is the lack of return value description, but this is not critical for a side-effect tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes the parameter with 100% coverage. The description adds a precondition: 'Must already exist (use openclaw_setup first),' which provides meaningful context beyond the schema's type and description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Switch the active default instance' and explains the effect on subsequent tool calls. It distinguishes itself well from sibling tools like openclaw_setup (which likely creates instances) and openclaw_setup_list by specifying its unique role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: to set the default instance. It mentions the side effect of closing client connections and the routing behavior. However, it does not explicitly state when not to use it or compare to alternatives, hence a slight deduction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses side effect: 'Triggers a connect (if not already)'. With no annotations provided, this adds important behavioral context. Could mention authorization requirements but sufficient for an introspection tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three well-structured sentences: first sentence states purpose and side effect, second lists returns, third gives usage advice. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, description fully covers return contents (server version, role/scopes, methods/events, coverage report) and explains why this matters (discovery for openclaw_call and identifying gaps after upgrades). Complete for an introspection tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter 'instance' with clear description in schema; the description adds value by explaining fallback behavior and referencing another tool (openclaw_setup_list) for listing instances, which goes beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it inspects gateway capabilities, lists specific returned data (server version, role/scopes, methods/events, coverage report), and distinguishes from sibling tools by explaining its introspective purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage guidance: 'Use to discover what methods you can call via openclaw_call and to spot endpoints that still need a typed wrapper after a gateway upgrade.' Does not explicitly state when not to use, 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Explicitly warns that the operation is destructive, overwrites the current session state, and that state is lost unless branched first. This goes beyond the missing annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences, each adding value: purpose, technical reference, and a critical warning. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple restore operation with a well-described schema, the description covers the essential behavioral aspects and prerequisite conditions adequately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not add any parameter semantics beyond the input schema, which already has 100% coverage with clear descriptions. Baseline score is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Restore a session to a previous compaction snapshot') and the resource, distinguishing it from sibling tools like compaction_list and compaction_branch.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context: it is destructive and advises branching first to avoid losing current state. However, it does not explicitly state when to use this versus alternatives like creating a new session.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly states 'Read-only' and details the client-side filtering behavior, including that the gateway rejects `sinceMs`, `level`, and `component`. This discloses important behavioral traits not captured in annotations (which are absent) and adds context about version verification.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is five sentences, each serving a distinct purpose: purpose, read-only nature, client-side filtering, usage tip, and use cases. No redundancy, front-loaded with key information, and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description covers purpose, parameters behavior, usage context, and system architecture. It is complete for a log tailing tool, addressing complexity of client-server interaction and version-specific behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage, the description adds critical architectural insight: only `limit` is sent to the gateway; other filters are applied client-side. It also explains that `instance` falls back to default or environment variables. This enriches parameter understanding beyond schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it tails recent gateway logs, wrapping `logs.tail`, and is read-only. It provides specific debugging use cases (e.g., tracing cron failures, session aborts), distinguishing it from siblings which are for other OpenClaw operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use this tool (debugging) and gives explicit guidance: only `limit` is forwarded to the gateway; other parameters are applied client-side. It advises raising `limit` for wide tails. This clarifies parameter intent and limitations beyond the schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![openclaw-control-mcp MCP server](https://glama.ai/mcp/servers/smurfy92/openclaw-control-mcp/badges/card.svg)](https://glama.ai/mcp/servers/smurfy92/openclaw-control-mcp)

Score Badge

Copy to your README.md:

[![openclaw-control-mcp MCP server](https://glama.ai/mcp/servers/smurfy92/openclaw-control-mcp/badges/score.svg)](https://glama.ai/mcp/servers/smurfy92/openclaw-control-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/smurfy92/openclaw-control-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server