openclaw-mcp

Server Quality Checklist

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

Latest release: v1.1.1
Disambiguation5/5
Each tool has a clearly defined purpose: chat (sync/async), status, task management (status/list/cancel), platform messaging, memory operations, alerts, agent spawning, and web search. There is no meaningful overlap between the tools, as even similar actions (e.g., chat vs. message) target distinct contexts (OpenClaw conversation vs. external platform).
Naming Consistency3/5
All tools share the 'openclaw_' prefix, which provides cohesion, but the pattern after the prefix is inconsistent. Some use verb-first (openclaw_chat, openclaw_web_search), some use noun-only (openclaw_status, openclaw_task_list), and some use noun-verb (openclaw_memory_read, openclaw_task_cancel). This mixed convention is readable but not predictable.
Tool Count5/5
With 12 tools, the server is well-scoped for its purpose of controlling an OpenClaw instance. Each tool covers a distinct capability, and the count is within the ideal range for an assistant-like MCP server.
Completeness4/5
The toolset provides comprehensive coverage for chatting (sync/async), task management (status/list/cancel), messaging, memory read/write, alerting, agent spawning, and web search. Minor gaps exist, such as no explicit memory delete or session management, but these are not critical for the server's apparent purpose.
Average 3.5/5 across 12 of 12 tools scored. Lowest: 2.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
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

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, and the description does not disclose key behaviors such as whether spawning is synchronous, how results are returned, resource implications, or error handling. The description adds minimal beyond the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, but it largely restates the tool name and lacks substantive specification. It is under-specified rather than appropriately concise.
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 tool has 3 parameters, no output schema, and no annotations, the description is severely incomplete. It fails to explain how to use the spawned agent, how to retrieve results, or what happens after spawning, leaving major gaps for an AI 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 baseline is 3. The description does not add extra meaning to parameters beyond the schema, but the schema provides reasonable descriptions for task, model, and agent_id.
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 identifies the action (spawn) and the resource (OpenClaw sub-agent) with a task. It distinguishes from siblings like chat or status, though the phrase 'perform a task' is somewhat generic.
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 exclusions, prerequisites, or how it relates to other tools like openclaw_chat or openclaw_task_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, and the description does not disclose important behavioral traits such as whether the file is overwritten, whether directories are created, or what the return value is. For a mutation tool, this is a significant transparency gap.
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 is front-loaded with the verb and resource. Every word earns its place, and there is no extraneous content.
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 no annotations and no output schema, the description is too sparse. It fails to mention overwrite behavior, side effects, or success/failure feedback, leaving important context missing for safe 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?
The input schema already describes both parameters with a relative path example and content meaning, giving 100% coverage. The description adds no additional parameter semantics beyond what the schema provides, so the baseline of 3 applies.
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 writes content to a memory file in the OpenClaw workspace, using the specific verb 'write' and identifying the resource. It distinguishes from sibling openclaw_memory_read by the write/read contrast, though it does not explicitly name 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?
The description provides no guidance on when to use this tool versus alternatives, no prerequisites, and no exclusion criteria. It simply states the function without contextual usage direction.
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 the action and target channels, but does not mention return values, side effects, error handling, authentication needs, or gateway requirements. This leaves significant behavioral uncertainty for a send 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 a single sentence with no filler, directly conveying the core purpose and scope. It is well-structured and front-loaded, earning a high score for 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 and no annotations, this simple description is insufficient for complete understanding. It omits return values, potential errors, prerequisites, and any post-send behavior. The schema covers parameters, but the description does not fill the contextual gaps left by missing structured metadata.
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 provides descriptions for all four parameters (target, channel, message, media_path) with 100% coverage, fulfilling the baseline. The description adds no extra parameter semantics beyond what the schema already states, so it neither enhances nor detracts.
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 "Send a message on Telegram or WhatsApp via the OpenClaw gateway," using a specific verb and resource. It identifies the scope (channels and gateway) but does not explicitly distinguish from siblings like openclaw_chat, so it falls short of a 5.
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_chat, openclaw_alert, or openclaw_status. The description lacks any context about prerequisites, selection criteria, 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the basic send/receive behavior but does not mention session handling, statefulness, error cases, timeouts, or other behavioral traits. This is insufficient for a tool with no annotation 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?
The description is a single, concise sentence with no filler or repetition. It front-loads the core action and outcome, earning a perfect score for conciseness.
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 simple with two params and no output schema, but the description omits key contextual information for an agent, such as the synchronous nature relative to openclaw_chat_async, session_id reuse semantics, or what the response contains. While not grossly inadequate, it leaves room for ambiguity in a toolset with several similar siblings.
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 full descriptions for both parameters (message and session_id), so schema coverage is 100%. The description adds no extra meaning beyond the schema, such as how session_id affects behavior or examples of valid messages. Baseline 3 is appropriate since the schema does the heavy lifting.
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's function: 'Send a message to OpenClaw and get a response.' It includes a specific verb and resource, and the outcome ('get a response') distinguishes it from sibling tools like openclaw_chat_async (async) and openclaw_message (possibly no response). However, it does not explicitly name alternatives or differentiate itself, so it stops short of a 5.
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 such as openclaw_chat_async, openclaw_message, or other siblings. It does not state any context, prerequisites, or exclusions, leaving the agent to infer usage on its own.
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 of disclosing behavior. It does state that the tool 'Returns status, and result if completed,' which gives some transparency about the return payload. However, it does not explicitly confirm that this is a non-destructive read operation, nor does it mention error behavior or whether the status check is one-time or can be polled. The description adds some value but leaves 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?
The description is exceptionally concise with two short sentences: 'Check the status of an async task. Returns status, and result if completed.' Every word earns its place, with no filler or repetition. This is a model of efficient communication.
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 one-parameter tool, the description covers the core function and return behavior. However, it lacks detail on the possible status values, what 'result' looks like, or how this behaves when the task ID is invalid. Given no output schema exists, the description could be more explicit about the return format. It is adequate but not complete for an agent needing to interpret the response.
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 only parameter (task_id), which is clearly described as 'The task ID returned from openclaw_chat_async'. The tool description adds no additional parameter meaning beyond what the schema already 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.
Purpose4/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: checking the status of an async task. The verb 'check' and resource 'async task' are specific, and it is distinguishable from sibling tools like openclaw_chat_async (which starts tasks) and openclaw_task_cancel (which cancels). However, it does not explicitly differentiate from openclaw_task_list, which also deals with tasks, so it falls short of a 5.
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 usage guidance is provided. The description does not state when to use this tool versus alternatives, nor does it mention prerequisites like having a task ID from openclaw_chat_async (though that is noted in the schema parameter description). The 'when to use' is only implied by the tool's name and description.
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 responsibility for disclosing behavior. It only states 'Search the web via OpenClaw' without mentioning side effects, return format, or limitations. It does not clarify that this is a read-only operation or what the agent should expect in response, leaving significant behavioral 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?
The description is a single, front-loaded sentence with no wasted words. It communicates the core function efficiently and is appropriately sized for a simple one-parameter tool.
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 has no output schema, so the description should explain what the tool returns or provides after execution. It only states the action ('search the web') without any indication of results or postconditions, making it incomplete for an agent to understand the full context of invoking 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?
The schema description coverage is 100%, with a clear description for the 'query' parameter. The tool description adds no additional semantics beyond the schema, so the baseline score of 3 is appropriate. No parameter-specific nuances are missing.
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 'search' and the resource 'the web', distinguishing it from sibling tools like chat, status, or memory. It provides a specific, actionable purpose that is not ambiguous.
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 web searches by its phrasing, but it does not explicitly state when to use this tool versus alternatives, nor does it provide exclusions. There are no direct alternative search tools among siblings, so the guidance is minimal but adequate.
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 of behavioral disclosure. It only states the action without mentioning side effects, permissions, failure handling, or what happens after sending—key details for a tool with no output 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 a single, clear, front-loaded sentence with no redundant words. It efficiently communicates the tool's 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?
While the tool is simple and the schema covers parameters, the absence of an output schema means the description should clarify what the caller can expect after sending. It does not mention return values, delivery confirmation, or asynchronous behavior, leaving the completeness partially lacking.
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 covers 100% of parameters with descriptive text (level, title, details). The description adds no parameter-specific meaning, but the schema already defines all three fields, so the baseline 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: 'Send an urgent alert to Gabriel on Telegram via OpenClaw.' It specifies the verb, resource, recipient, and channel, and distinguishes it from siblings like openclaw_message by emphasizing urgency and the specific target.
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 a clear context: use this tool when an urgent alert needs to go to Gabriel on Telegram. It does not explicitly name alternatives or exclusions, but the urgency and target provide enough context for selection.
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 key async behavior: returns a task_id immediately and can be polled for results. However, it lacks details on error handling, failure modes, authentication, or what the polling endpoint is, leaving some behavioral 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?
The description is two sentences, front-loaded with the primary action and immediate return, followed by a usage hint. Every word earns its place; no redundant 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 3 parameters and no output schema, the description gives essential context (task_id, polling) but omits details like how to poll, potential error responses, or what the full return object looks like. The schema covers parameters, but the description doesn't fully compensate for the missing output schema.
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 description does not add parameter-specific meaning beyond the schema; the schema descriptions for message, priority, and session_id are already self-explanatory.
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 OpenClaw asynchronously, using a specific verb and resource. It explicitly distinguishes from the likely synchronous sibling openclaw_chat by noting the async behavior and immediate task_id return, 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 provides explicit usage guidance with 'Use this for potentially long-running conversations,' indicating when to choose this tool over alternatives. It does not explicitly name the alternative (openclaw_chat) but the context is clear enough from the async nature and the 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 discloses that cancellation only works on pending tasks, which is a key behavioral constraint. However, it does not describe side effects (e.g., whether the task is permanently removed, whether it can be undone, or what happens if the task has already started). This is a significant gap for a destructive operation, but the 'only works' statement provides some 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 concise sentences, front-loaded with action, no redundant information. Perfectly sized.
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 simple (1 param, no output schema, no annotations). The description covers the purpose and the main constraint, but omits what happens on success/failure and whether cancellation is reversible. Given the lack of annotations and output schema, this leaves some ambiguity, so it's 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 the parameter task_id is clearly described as 'The task ID to cancel.' The tool description adds no additional meaning beyond that. 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 uses the specific verb 'Cancel' with resource 'task' and adds a scope condition ('Only works for tasks that haven't started yet'), clearly differentiating it from sibling tools like openclaw_task_status and openclaw_task_list. It leaves no ambiguity about what the tool does.
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 states the condition for use: tasks must be pending/not yet started. This provides clear context for when to invoke it. It doesn't explicitly name alternatives or exclusions, but the sibling list doesn't contain another cancel tool, so the guidance is sufficient. The restriction is explicit, earning a 4.
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 this is a read operation, which is inherently non-destructive, but it does not detail error handling, permission requirements, path traversal restrictions, or return value format. The description is minimally transparent beyond the core 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 a single, front-loaded sentence with no filler or redundant information. It earns its place by stating the action and scope precisely.
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 parameter, no output schema, and no annotations, the description adequately conveys purpose and scope. It could explicitly mention that the file contents are returned, but that is implied by 'Read' and the overall structure of the description.
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% because the only parameter 'path' has a helpful description including an example. The tool description adds no extra parameter-level detail, so the baseline of 3 applies for a high-coverage schema where the schema does the heavy lifting.
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 ('Read') and clearly identifies the resource ('memory file') within the context of the OpenClaw workspace. This clearly distinguishes the tool from its sibling openclaw_memory_write, which targets the complementary write 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 clearly implies the tool's usage context: when you need to read a memory file from the workspace. It does not explicitly mention alternatives or exclusions, but the sibling naming makes the when-to-use clear, and no competing read tool exists among the siblings.
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. 'List' implies a read-only operation, but there is no explicit statement about non-mutating behavior, pagination, sorting, or return format. The bare description leaves room for ambiguity about what 'all tasks' entails.
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 of ten words, front-loaded with the core action. Every word earns its place, and the sentence structure is clear and unambiguous.
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 listing tool with two optional parameters and no output schema, the description is mostly complete. However, it lacks any mention of pagination, result limits, or ordering, which could be relevant for a tool that lists 'all' tasks. Still, the tool's simplicity keeps it close to a 4.
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 status and session_id. The description adds value by clarifying these are optional filters, reinforcing the 'required: []' in the schema. It doesn't dive into format details, but the schema already provides those.
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 all tasks' with a specific verb and resource, and mentions optional filters for status or session. This distinguishes it from sibling tools like task_status (which likely retrieves a single task's status) and task_cancel (which mutates tasks).
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 for listing all tasks with optional filters, but does not explicitly state when to use this versus alternatives like task_status. There is no 'when-not' or mention of alternative tools for single-task lookups.
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 burden. It transparently states this is a read-only operation ('Get') focused on status/health, with no hidden side effects implied. It does not detail response format or edge cases, but for a 0-parameter status tool it is sufficiently clear.
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, front-loaded sentence with no fluff. It efficiently conveys the tool's purpose without unnecessary words, making it highly concise and well-structured.
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 0-parameter status tool with no output schema, the description is nearly complete. It states the purpose clearly. However, it could be slightly more explicit about what 'health information' includes or when to prefer this over other status-related tools, but it is not a significant 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?
The tool has 0 parameters, and the schema coverage is 100% (empty schema fully described). The baseline for 0 params is 4, and the description correctly indicates there are no parameters to specify. No additional parameter semantics are needed.
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 OpenClaw gateway status and health information. The verb 'Get' plus specific resource 'gateway status and health information' distinguishes it from sibling tools like task status, memory, and chat 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?
Usage is implied as a status check, but there is no explicit guidance on when to use it versus alternatives, no mention of exclusions, or context like 'use when needing to verify gateway health.' The description is minimal and leaves the agent to infer the scope.
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-mcp MCP server](https://glama.ai/mcp/servers/GabrielBertoli/openclaw-mcp/badges/card.svg)](https://glama.ai/mcp/servers/GabrielBertoli/openclaw-mcp)

Score Badge

Copy to your README.md:

[![openclaw-mcp MCP server](https://glama.ai/mcp/servers/GabrielBertoli/openclaw-mcp/badges/score.svg)](https://glama.ai/mcp/servers/GabrielBertoli/openclaw-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/GabrielBertoli/openclaw-mcp'

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