What can you do with this server?

The openclaw-mcp server bridges AI clients (like Claude.ai) with the OpenClaw AI assistant gateway, enabling both synchronous and asynchronous interactions. * openclaw_chat – Send a message to OpenClaw and receive an immediate response; supports optional session ID for conversation continuity. * openclaw_status – Check the health and operational status of the OpenClaw gateway. * openclaw_chat_async – Queue a message for asynchronous processing and receive a task_id immediately; supports priority levels and session IDs. * openclaw_task_status – Poll the progress of a queued async task and retrieve its result once complete. * openclaw_task_list – List all async tasks with optional filtering by status (pending, running, completed, failed, cancelled) or session ID. * openclaw_task_cancel – Cancel a pending task that hasn't started processing yet.

de en es ja ko ru zh

openclaw-mcp

by freema

Overview Schema Source Related Servers Discussions Admin

TypeScript

OpenClaw MCP Server

npm version License: MIT GHCR Website

🦞 Model Context Protocol (MCP) server for OpenClaw AI assistant integration.

Demo

Related MCP server: claude-bridge-mcp

Why I Built This

Hey! I created this MCP server because I didn't want to rely solely on messaging channels to communicate with OpenClaw. What really excites me is the ability to connect OpenClaw to the Claude web UI. Essentially, my chat can delegate tasks to my Claw bot, which then handles everything else — like spinning up Claude Code to fix issues for me.

Think of it as an AI assistant orchestrating another AI assistant. Pretty cool, right?

Quick Start

Docker (Recommended)

Pre-built images are published to GitHub Container Registry on every release.

docker pull ghcr.io/freema/openclaw-mcp:latest

Create a docker-compose.yml:

services:
  mcp-bridge:
    image: ghcr.io/freema/openclaw-mcp:latest
    container_name: openclaw-mcp
    restart: unless-stopped
    ports:
      - "3000:3000"
    environment:
      - OPENCLAW_URL=http://host.docker.internal:18789
      - OPENCLAW_GATEWAY_TOKEN=${OPENCLAW_GATEWAY_TOKEN}
      - OPENCLAW_AGENT_ID=${OPENCLAW_AGENT_ID:-}
      - OPENCLAW_MODEL=openclaw
      - AUTH_ENABLED=true
      - MCP_CLIENT_ID=openclaw
      - MCP_CLIENT_SECRET=${MCP_CLIENT_SECRET}
      - MCP_ISSUER_URL=${MCP_ISSUER_URL:-}
      - MCP_REDIRECT_URIS=https://claude.ai/api/mcp/auth_callback,https://claude.com/api/mcp/auth_callback
      - TRUST_PROXY=1
      - CORS_ORIGINS=https://claude.ai
    extra_hosts:
      - "host.docker.internal:host-gateway"
    read_only: true
    security_opt:
      - no-new-privileges

Generate secrets and start:

export MCP_CLIENT_SECRET=$(openssl rand -hex 32)
export OPENCLAW_GATEWAY_TOKEN=your-gateway-token
docker compose up -d

Then in Claude.ai add a custom MCP connector pointing to https://your-domain.com/mcp with MCP_CLIENT_ID=openclaw and your MCP_CLIENT_SECRET.

Important: The connector URL must end with /mcp — that's the Streamable HTTP endpoint. A bare domain (https://your-domain.com) hits the server root and returns 404 after OAuth completes.

Tip: Pin a specific version instead of latest for production: ghcr.io/freema/openclaw-mcp:1.1.0

Local (Claude Desktop)

npx openclaw-mcp

Add to your Claude Desktop config:

{
  "mcpServers": {
    "openclaw": {
      "command": "npx",
      "args": ["openclaw-mcp"],
      "env": {
        "OPENCLAW_URL": "http://127.0.0.1:18789",
        "OPENCLAW_GATEWAY_TOKEN": "your-gateway-token",
        "OPENCLAW_AGENT_ID": "main",
        "OPENCLAW_MODEL": "openclaw",
        "OPENCLAW_TIMEOUT_MS": "300000"
      }
    }
  }
}

Remote (Claude.ai) without Docker

AUTH_ENABLED=true MCP_CLIENT_ID=openclaw MCP_CLIENT_SECRET=your-secret \
  MCP_ISSUER_URL=https://mcp.your-domain.com \
  CORS_ORIGINS=https://claude.ai OPENCLAW_GATEWAY_TOKEN=your-gateway-token \
  npx openclaw-mcp --transport http --port 3000

Important: When running behind a reverse proxy (Caddy, nginx, Traefik, Cloudflare Tunnel, etc.) you must set:
MCP_ISSUER_URL (or --issuer-url) to your public HTTPS URL — otherwise OAuth metadata advertises http://localhost:3000 and clients fail to authenticate.
TRUST_PROXY=1 (or --trust-proxy 1) — otherwise express-rate-limit rejects the proxy's X-Forwarded-For header and /token crashes with ERR_ERL_UNEXPECTED_X_FORWARDED_FOR.

Recommended: Set MCP_REDIRECT_URIS=https://claude.ai/api/mcp/auth_callback,https://claude.com/api/mcp/auth_callback so authorization codes can only be delivered to Claude's callbacks. Note the exact /api/mcp/auth_callback path — matching is exact, and getting it wrong fails OAuth with Unregistered redirect_uri (see Troubleshooting).

See Installation Guide for details.

Architecture

┌─────────────────────────────────────────────────────────────────┐
│                         Your Server                             │
│                                                                 │
│  ┌─────────────────┐      ┌─────────────────────────┐          │
│  │   OpenClaw      │      │    OpenClaw MCP         │          │
│  │   Gateway       │◄────►│    Bridge Server        │          │
│  │   :18789        │      │    :3000                │          │
│  │                 │      │                         │          │
│  │  OpenAI-compat  │      │  - OAuth 2.1 auth       │          │
│  │  /v1/chat/...   │      │  - CORS protection      │          │
│  └─────────────────┘      │  - Input validation     │          │
│                           └──────────┬──────────────┘          │
│                                      │                          │
└──────────────────────────────────────┼──────────────────────────┘
                                       │ HTTPS + OAuth 2.1
                                       ▼
                              ┌─────────────────┐
                              │   Claude.ai     │
                              │   (MCP Client)  │
                              └─────────────────┘

Available Tools

Sync Tools

Tool	Description
`openclaw_chat`	Send messages to OpenClaw and get responses
`openclaw_status`	Check OpenClaw gateway health
`openclaw_instances`	List all configured OpenClaw instances

Async Tools (for long-running operations)

Tool	Description
`openclaw_chat_async`	Queue a message, get task_id immediately
`openclaw_task_status`	Check task progress and get results
`openclaw_task_list`	List your tasks with filtering
`openclaw_task_cancel`	Cancel a pending task

Tasks are scoped to the MCP connection that created them. In HTTP mode, where one process serves many clients, a client can only see and cancel its own tasks — another client's task_id reads as "not found" even if it is known. Reconnecting starts a fresh scope, so poll a task on the connection that queued it.

Multi-Instance Mode

Orchestrate multiple OpenClaw gateways from a single MCP server. One bridge, many claws — route requests to prod, staging, dev, or whatever you name them (lobster-supreme and the-claw-abides are perfectly valid names).

┌──────────────────────────────────────────────────────────────────────┐
│                        Claude.ai / Claude Desktop                    │
│                              (MCP Client)                            │
└──────────────────────┬───────────────────────────────────────────────┘
                       │
                       ▼
┌──────────────────────────────────────────────────────────────────────┐
│                     OpenClaw MCP Bridge Server                        │
│                                                                      │
│  ┌──────────────┐  ┌──────────────┐  ┌──────────────┐               │
│  │  Instance     │  │  Instance     │  │  Instance     │              │
│  │  Registry     │  │  Resolver     │  │  Validator    │              │
│  └──────┬───────┘  └──────┬───────┘  └──────┬───────┘               │
│         │                 │                  │                        │
│  ┌──────┴─────────────────┴──────────────────┴───────┐               │
│  │              Per-Instance OpenClaw Clients          │              │
│  │     (separate auth, timeout, URL per instance)     │              │
│  └────────┬──────────────┬──────────────┬────────────┘               │
└───────────┼──────────────┼──────────────┼────────────────────────────┘
            │              │              │
            ▼              ▼              ▼
   ┌──────────────┐ ┌──────────────┐ ┌──────────────┐
   │  🦞 prod     │ │  🦞 staging  │ │  🦞 dev      │
   │  (default)   │ │              │ │              │
   │  :18789      │ │  :18789      │ │  :18789      │
   │  OpenClaw GW │ │  OpenClaw GW │ │  OpenClaw GW │
   └──────────────┘ └──────────────┘ └──────────────┘

Setup

OPENCLAW_INSTANCES='[
  {"name": "prod", "url": "http://prod:18789", "token": "tok1", "default": true},
  {"name": "staging", "url": "http://staging:18789", "token": "tok2"},
  {"name": "dev", "url": "http://dev:18789", "token": "tok3"}
]'

Usage

All tools accept an optional instance parameter to target a specific gateway:

# Chat with staging instance
openclaw_chat message="Deploy status?" instance="staging"

# Check health of prod
openclaw_status instance="prod"

# List all configured instances
openclaw_instances

# Async task targeting dev
openclaw_chat_async message="Run tests" instance="dev"

When instance is omitted, the default instance is used. Each instance has its own auth token, timeout, and URL — fully isolated.

Key Features

Zero-migration upgrade — existing single-instance deployments work without any config change
Per-instance isolation — separate auth tokens, timeouts, and URLs
Dynamic routing — Claude picks the right instance per request
Task tracking — async tasks remember which instance they target
Security — tokens are never exposed via openclaw_instances

See Configuration — Multi-Instance Mode for the full reference.

Documentation

Installation — Setup for Claude Desktop & Claude.ai
Configuration — Environment variables & options
Deployment — Docker & production setup
Threat Model — What Claude can/can't trigger, trust boundaries & attack surfaces
Logging — What gets logged, where, and what is never logged
Development — Contributing & adding tools
Security — Security policy & best practices

Security

⚠️ Always enable authentication in production!

# Generate secure client secret
export MCP_CLIENT_SECRET=$(openssl rand -hex 32)

# Run with auth enabled
AUTH_ENABLED=true MCP_CLIENT_ID=openclaw MCP_CLIENT_SECRET=$MCP_CLIENT_SECRET \
  openclaw-mcp --transport http

CORS is disabled unless you opt in. Set CORS_ORIGINS only when a browser client needs to reach the server directly:

CORS_ORIGINS=https://claude.ai,https://your-app.com

See Configuration for all security options.

Upgrading to 1.7.0

Two defaults changed for security. Both only affect HTTP mode; stdio is unchanged.

CORS is now off by default. Previously an unset CORS_ORIGINS sent Access-Control-Allow-Origin: *. If a browser client depends on that, set the origins explicitly (CORS_ORIGINS=https://your-app.com), or CORS_ORIGINS=* to restore the old behaviour.
Async tasks are scoped to the connection that created them. A client that used to poll a task_id queued by a different connection will now get "not found".

Migrating from SSE to HTTP transport

Starting with v1.5.0, the primary transport is Streamable HTTP (--transport http). The legacy SSE transport (--transport sse) is deprecated but still works for backward compatibility.

What changed

Before	After
`--transport sse`	`--transport http` (recommended)
Primary endpoint: `GET /sse`	Primary endpoint: `POST/GET/DELETE /mcp`
Health: `"transport": "sse"`	Health: `"transport": "streamable-http"`

Migration steps

CLI / Docker: Replace --transport sse with --transport http

# Before
openclaw-mcp --transport sse --port 3000
# After
openclaw-mcp --transport http --port 3000

Claude.ai connector URL: No change needed — Claude.ai already uses /mcp (Streamable HTTP)
Legacy clients: The /sse and /messages endpoints still work. A deprecation warning is logged on each SSE connection.
Dockerfile ENTRYPOINT: Updated automatically if using the official Docker image

Note: --transport sse will continue to work as a deprecated alias. Both transports are served simultaneously regardless of which flag you use.

Requirements

Node.js ≥ 20

OpenClaw gateway running with HTTP API enabled:

// openclaw.json
{ "gateway": { "http": { "endpoints": { "chatCompletions": { "enabled": true } } } } }

License

MIT

Author

Created by Tomáš Grasl

OpenClaw — The AI assistant this MCP connects to
MCP Specification — Model Context Protocol docs

Available Tools

7 tools

openclaw_chatC

Send a message to OpenClaw and get a response

ParametersJSON Schema

Name	Required	Description
`message`	Yes	The message to send to OpenClaw
`instance`	No	Target OpenClaw instance name. Use openclaw_instances to list available instances. Defaults to the default instance.
`session_id`	No	Optional session ID for conversation context

TDQS

C2.9/5.0

Behavior2/5

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

Without any annotations, the description must convey behavioral traits. It only states 'get a response' but does not disclose error handling, rate limits, or blocking behavior. This is insufficient for an agent to understand 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.

Conciseness4/5

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

The description is a single sentence with 10 words, which is concise. However, it could be more informative while still being brief.

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, and the description fails to explain the response format or behavior. It does not mention the importance of session_id for conversation context or any error scenarios. Sibling tools indicate additional functionality (e.g., instances, async) that are not referenced.

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 three parameters have descriptions in the schema (100% coverage), so the description adds no new information. The baseline is 3, and the description does not exceed it.

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 (send a message) and the target (OpenClaw), and implies a synchronous response. However, it does not explicitly differentiate from the sibling tool 'openclaw_chat_async' which is an asynchronous version.

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_chat_async' or when not to use it. The description lacks contextual selection advice.

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

openclaw_chat_asyncA

Send a message to OpenClaw asynchronously. Returns a task_id immediately that can be polled for results. Use this for potentially long-running conversations.

ParametersJSON Schema

Name	Required	Description
`message`	Yes	The message to send to OpenClaw
`instance`	No	Target OpenClaw instance name. Defaults to the default instance.
`priority`	No	Task priority (higher = processed first). Default: 0
`session_id`	No	Optional session ID for conversation context

TDQS

A4/5.0

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 async behavior and returning a task_id, but does not mention error handling, rate limits, or authentication requirements. 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 two sentences: the first explains the action and immediate return, the second provides usage guidance. No wasted words, front-loaded with key 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?

Given the tool's complexity (4 parameters, async behavior, sibling tools), the description covers the core purpose, async mechanism, and usage context. It lacks details on failure modes or error handling, but is sufficient for most agents. No output schema, but the return value is implied.

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 each parameter having a clear description in the input schema. The tool description does not add extra meaning beyond the schema, 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 'Send a message to OpenClaw asynchronously', providing a specific verb and resource. It distinguishes from sibling tools like openclaw_chat (likely synchronous) and openclaw_task_status (polling).

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 'Use this for potentially long-running conversations', giving explicit context for when to use the async variant. It also mentions returning a task_id for polling, implying the alternative is to use openclaw_task_status. Could be more explicit about when not to use it, but overall clear.

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

openclaw_instancesA

List all configured OpenClaw instances. Shows instance names, URLs, and which is the default. Use instance names in other tools to target a specific OpenClaw gateway.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.5/5.0

Behavior4/5

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

No annotations provided, so description bears full burden. It describes the tool as listing instances (read-only), which is accurate. No mention of authentication or edge cases, but for a simple list, it 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 concise sentences, front-loaded with purpose. Every word adds value; no redundancy.

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 parameters, no output schema, and simple functionality, the description fully covers what an agent needs: listing instances and their attributes for use in other tools.

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 no parameters, and schema coverage is 100%. Description adds no parameter details as none exist, meeting the baseline of 4 for zero-parameter tools.

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 configured instances, showing names, URLs, and default. It explicitly differentiates from siblings like openclaw_chat by specifying the use case of retrieving instance names for targeting other 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 advises using instance names in other tools, implying usage before those tools. However, it does not explicitly state when not to use or list alternatives, but the context is clear for a listing tool.

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

openclaw_statusB

Get OpenClaw gateway status and health information

ParametersJSON Schema

Name	Required	Description	Default
`instance`	No	Target OpenClaw instance name. Defaults to the default instance.

TDQS

B3.4/5.0

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 disclosure. It only states that the tool retrieves status and health info, but does not disclose behavioral traits such as side effects, authentication needs, or rate limits. Minimal additional 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, front-loaded sentence with no wasted words. Every part 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 is almost complete. However, it could mention that it retrieves status for a specific instance (addressing the parameter's role) and note that openclaw_instances can be used to list available instances.

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% (the single optional parameter 'instance' is described in the schema). The description adds no extra meaning beyond what the schema already provides, so baseline score of 3 is appropriate.

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

Purpose5/5

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

The description uses the specific verb 'Get' and identifies the resource as 'OpenClaw gateway status and health information', which clearly distinguishes this tool from siblings like openclaw_chat (chatting) and openclaw_task_list (task management).

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_instances for listing instances) or any exclusions. The description implies a health check but does not provide explicit context.

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

openclaw_task_cancelA

Cancel a pending task. Only works for tasks that haven't started yet.

ParametersJSON Schema

Name	Required	Description	Default
`task_id`	Yes	The task ID to cancel

TDQS

A3.9/5.0

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.

openclaw_task_listA

List all tasks. Optionally filter by status, session, or instance.

ParametersJSON Schema

Name	Required	Description
`status`	No	Filter by task status
`instance`	No	Filter by instance name
`session_id`	No	Filter by session ID

TDQS

A3.5/5.0

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 does not explicitly state that the tool is read-only or describe side effects, pagination, or performance. The name 'list' suggests read-only, but explicit context is missing.

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

Conciseness5/5

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

The description is a single concise sentence with no wasted words. It is front-loaded with the core action and immediately lists the filters.

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 (3 optional params, no output schema, no annotations), the description covers the basic functionality. However, it lacks details on return format, pagination, or error handling, which would be useful 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% and all parameters have descriptions. The description adds 'Optionally filter by status, session, or instance,' which mostly repeats the schema. It does not add significant new meaning beyond what the schema already provides.

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 'List all tasks' with optional filters, which is a specific verb+resource. It distinguishes from sibling tools like openclaw_task_cancel and openclaw_task_status, though it does not explicitly differentiate them.

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 tasks with optional filters but provides no exclusions or alternative tool references. Sibling tools exist but are not mentioned, so guidance is minimal.

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

openclaw_task_statusB

Check the status of an async task. Returns status, and result if completed.

ParametersJSON Schema

Name	Required	Description	Default
`task_id`	Yes	The task ID returned from openclaw_chat_async

TDQS

B3.3/5.0

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.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

7 tool updatesv1.4.2May 25, 2026
- Addedopenclaw_chat
- Addedopenclaw_chat_async
- Addedopenclaw_instances
- Addedopenclaw_status
- Addedopenclaw_task_cancel
- Addedopenclaw_task_list
- Addedopenclaw_task_status
6 tool updatesv1.4.1May 9, 2026
- Removedopenclaw_chat
- Removedopenclaw_chat_async
- Removedopenclaw_status
- Removedopenclaw_task_cancel
- Removedopenclaw_task_list
- Removedopenclaw_task_status
6 tool updatesv1.0.2Feb 8, 2026
- First observedopenclaw_chat
- First observedopenclaw_chat_async
- First observedopenclaw_status
- First observedopenclaw_task_cancel
- First observedopenclaw_task_list
- First observedopenclaw_task_status

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.7/5.0

Scored 2026-05-26 21:35 across 7 tools

Disambiguation4/5

Most tools have distinct purposes, but openclaw_chat and openclaw_chat_async could be confused if an agent skims descriptions. The async variant is clearly labeled, so overall disambiguation is good but not perfect.

Naming Consistency5/5

All tools use the consistent pattern 'openclaw_verb_noun' with snake_case. This makes it easy to predict tool names and understand their function.

Tool Count5/5

Seven tools is ideal for an API gateway wrapper. Each tool covers a distinct operation without redundancy, and the scope is well-scoped for interacting with OpenClaw instances.

Completeness4/5

The set covers core operations: chat (sync/async), instance management, health status, and task management. Minor gap: no tool for listing sessions or conversation history, but the core workflows are complete.

Maintenance

ActivityMaintained

ResponsivenessWithin a week

Resources

Need Help?

Related Servers

Related MCP Connectors

argo-mcp B
io.github.Argo-RPG-Platform
MCP server for Argo RPG Platform — connects AI assistants to campaign data via OAuth2
Games & Gamification Knowledge & Memory
6221
Remote Desktop CommanderOAuth
app.desktopcommander
Hosted MCP server connecting claude.ai, ChatGPT and other AI apps to your own computer
Shell Access OS Automation
237
QuallaaOAuth
com.quallaa
Talk to your public-facing AI from any MCP client — Claude, ChatGPT, Cursor, Cline, Windsurf.
AI & Machine Learning Communication
2
hithereiamaliff-mcp-nextcloudOAuth
ai.smithery
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Cloud Storage File Systems Workplace & Productivity
238

Related MCP Servers

MCP OpenAI Server
Agent Orchestration Command Line
mzxrai
A
license
B
quality
C
maintenance
A Model Context Protocol (MCP) server that lets you seamlessly use OpenAI's models right from Claude.
Updated 2 years ago (2024-12-06 18:15 UTC)
1
207 npm
76
MIT
claude-bridge-mcp
Code Execution Coding Agents
0motionguy
A
license
Not graded
quality
D
maintenance
An MCP server that exposes your local Claude Code CLI over HTTP+SSE, enabling any MCP-compatible client to use your Claude Code MAX/PRO subscription remotely.
Updated 7 months ago (2026-02-17 05:03 UTC)
5 npm
2
MIT
claude-max-mcp
AI & Machine Learning Agent Orchestration
Jonahbkerr
A
license
A
quality
C
maintenance
An MCP server that enables any AI agent to call Claude using your existing Max/Pro subscription via OAuth, avoiding additional API billing.
Updated 4 months ago (2026-05-18 16:15 UTC)
1
1
MIT
lighthouse-mcp-oauth
Security Developer Tools
Ulaklar
F
license
Not graded
quality
D
maintenance
Enables Claude.ai to connect to a Hermes MCP server via OAuth 2.1 authorization code flow with PKCE, acting as a reverse proxy and single-user authorization gateway.
Updated 3 months ago (2026-06-14 14:56 UTC)
-

Appeared in Searches

ClawdBot Worker - Bot or Worker Service Information

OpenClaw MCP Server

Demo

Why I Built This

Quick Start

Docker (Recommended)

Local (Claude Desktop)

Remote (Claude.ai) without Docker

Architecture

Available Tools

Sync Tools

Async Tools (for long-running operations)

Multi-Instance Mode

Setup

Usage

Key Features

Documentation

Security

Upgrading to 1.7.0

Migrating from SSE to HTTP transport

What changed

Migration steps

Requirements

License

Author

Related Projects

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

Appeared in Searches