Skip to main content
Glama
Helms-AI

OpenClaw MCP Server

by Helms-AI
OverviewSchemaRelated ServersScoreDiscussions
JavaScript
Hybrid

OpenClaw MCP Server

MCP (Model Context Protocol) server that exposes OpenClaw Gateway tools to Claude Code and other MCP-compatible clients.

Features

Gives Claude Code (and any MCP client) access to:

  • Messaging — Send messages via Telegram, WhatsApp, Discord, Slack, Signal, iMessage, Google Chat

  • Sessions — List, inspect, and communicate with other OpenClaw sessions

  • Scheduling — Create and manage cron jobs for automated tasks

  • Nodes — Control paired devices (notifications, camera, location, remote commands)

  • Web — Search and fetch web content

  • Memory — Search OpenClaw's memory files

  • TTS — Text-to-speech conversion

  • Gateway — Status and configuration access

Related MCP server: openclaw-mcp

Prerequisites

  • Node.js 18+

  • OpenClaw Gateway running locally (default: http://127.0.0.1:18789)

  • Gateway auth token (if configured)

Installation

# Clone and install
cd /path/to/openclaw-mcp-server
npm install
npm run build

# Or install globally
npm install -g .

Configuration

Environment Variables

Variable

Description

Default

OPENCLAW_GATEWAY_URL

Gateway HTTP URL

http://127.0.0.1:18789

OPENCLAW_GATEWAY_TOKEN

Auth token (if required)

(none)

Client Setup

The OpenClaw MCP server works with any MCP-compatible client. Below are configuration instructions for popular clients.

Claude Desktop

Add to your Claude Desktop configuration file:

macOS: ~/Library/Application Support/Claude/claude_desktop_config.json Windows: %APPDATA%\Claude\claude_desktop_config.json Linux: ~/.config/Claude/claude_desktop_config.json

{
  "mcpServers": {
    "openclaw": {
      "command": "node",
      "args": ["/absolute/path/to/openclaw-mcp-server/dist/index.js"],
      "env": {
        "OPENCLAW_GATEWAY_TOKEN": "your-token-here"
      }
    }
  }
}

Note: Restart Claude Desktop after editing the configuration file.

Claude Code (CLI)

Add using the Claude Code CLI:

# Using the CLI
claude mcp add openclaw -- node /path/to/openclaw-mcp-server/dist/index.js

# Or with environment variables
claude mcp add openclaw -e OPENCLAW_GATEWAY_TOKEN=your-token -- node /path/to/openclaw-mcp-server/dist/index.js

Or manually edit ~/.claude/settings.json:

{
  "mcpServers": {
    "openclaw": {
      "command": "node",
      "args": ["/absolute/path/to/openclaw-mcp-server/dist/index.js"],
      "env": {
        "OPENCLAW_GATEWAY_TOKEN": "your-token-here"
      }
    }
  }
}

Zed Editor

Add to your Zed settings file (open with Zed: Open Settings or edit ~/.config/zed/settings.json):

{
  "context_servers": {
    "openclaw": {
      "command": {
        "path": "node",
        "args": ["/absolute/path/to/openclaw-mcp-server/dist/index.js"]
      },
      "settings": {
        "env": {
          "OPENCLAW_GATEWAY_TOKEN": "your-token-here"
        }
      }
    }
  }
}

Note: You may need to reload Zed after adding the configuration.

Cline (VSCode Extension)

  1. Open VSCode settings (Cmd/Ctrl + ,)

  2. Search for "Cline: MCP Servers"

  3. Click "Edit in settings.json"

  4. Add the OpenClaw server configuration:

{
  "cline.mcpServers": {
    "openclaw": {
      "command": "node",
      "args": ["/absolute/path/to/openclaw-mcp-server/dist/index.js"],
      "env": {
        "OPENCLAW_GATEWAY_TOKEN": "your-token-here"
      }
    }
  }
}

Alternatively, use the Cline MCP settings UI:

  1. Open Cline panel

  2. Click the settings/gear icon

  3. Navigate to MCP Servers section

  4. Add server with command: node /absolute/path/to/openclaw-mcp-server/dist/index.js

Note: Reload VSCode window after configuration changes.

Windsurf Editor

Add to Windsurf's configuration file (~/.windsurf/settings.json or via Settings UI):

{
  "mcp.servers": {
    "openclaw": {
      "command": "node",
      "args": ["/absolute/path/to/openclaw-mcp-server/dist/index.js"],
      "env": {
        "OPENCLAW_GATEWAY_TOKEN": "your-token-here"
      }
    }
  }
}

Or use the Windsurf Settings UI:

  1. Open Settings (Cmd/Ctrl + ,)

  2. Navigate to "MCP Servers"

  3. Click "Add Server"

  4. Enter server details:

    • Name: openclaw

    • Command: node

    • Args: /absolute/path/to/openclaw-mcp-server/dist/index.js

    • Environment variables: OPENCLAW_GATEWAY_TOKEN=your-token-here

Note: Restart Windsurf after adding the configuration.

Other MCP Clients

For any other MCP-compatible client, use the standard MCP server configuration format:

{
  "command": "node",
  "args": ["/absolute/path/to/openclaw-mcp-server/dist/index.js"],
  "env": {
    "OPENCLAW_GATEWAY_TOKEN": "your-token-here"
  }
}

Important Notes

  • Absolute Paths: Always use absolute paths (e.g., /Users/username/... or C:\Users\...) in configuration files, not relative paths or ~

  • Token Security: If your OpenClaw Gateway requires authentication, set the OPENCLAW_GATEWAY_TOKEN environment variable

  • Gateway URL: If your Gateway is not running on default http://127.0.0.1:18789, set OPENCLAW_GATEWAY_URL in the environment variables

  • Server Restart: Most clients require a restart or reload after changing MCP server configuration

Available Tools

Messaging

openclaw_message_send

Send a message via OpenClaw to various messaging platforms (Telegram, WhatsApp, Discord, Slack, Signal, iMessage, Google Chat).

Natural Language Examples:

  • "Send a Telegram message to @john saying 'Meeting at 3pm'"

  • "Message my team on Slack: 'Deploy is complete'"

  • "Send a silent notification to the dev channel on Discord"

Parameters:

  • message (string, required) - Message text to send

  • channel (string, optional) - Channel type: telegram, whatsapp, discord, slack, signal, imessage, googlechat

  • target (string, optional) - Target chat/user ID or name

  • replyTo (string, optional) - Message ID to reply to

  • silent (boolean, optional) - Send silently without notification

Example Input:

{
  "channel": "telegram",
  "target": "@username",
  "message": "Hello from OpenClaw!",
  "silent": false
}

Example Output:

{
  "success": true,
  "messageId": "msg_123456",
  "timestamp": "2026-02-02T10:30:00Z"
}

openclaw_message_broadcast

Broadcast a message to multiple targets across messaging platforms.

Natural Language Examples:

  • "Broadcast 'Server maintenance tonight at 10pm' to all my Telegram groups"

  • "Send a message to Alice, Bob, and Charlie on WhatsApp about the project update"

  • "Notify everyone in my contact list about the event"

Parameters:

  • message (string, required) - Message text to broadcast

  • targets (array of strings, required) - List of target IDs

  • channel (string, optional) - Channel type

Example Input:

{
  "channel": "telegram",
  "targets": ["@user1", "@user2", "@user3"],
  "message": "Important announcement for everyone!"
}

Example Output:

{
  "success": true,
  "sent": 3,
  "failed": 0,
  "results": [
    { "target": "@user1", "status": "delivered" },
    { "target": "@user2", "status": "delivered" },
    { "target": "@user3", "status": "delivered" }
  ]
}

Sessions

openclaw_sessions_list

List active OpenClaw sessions with optional filtering.

Natural Language Examples:

  • "Show me all active sessions from the last hour"

  • "List my Telegram sessions with their recent messages"

  • "What sessions have been active in the past 30 minutes?"

Parameters:

  • kinds (array of strings, optional) - Filter by session kinds/types

  • activeMinutes (number, optional) - Filter by activity within N minutes

  • limit (number, optional) - Maximum number of sessions to return

  • messageLimit (number, optional) - Include last N messages per session

Example Input:

{
  "activeMinutes": 60,
  "limit": 10,
  "messageLimit": 5
}

Example Output:

{
  "sessions": [
    {
      "sessionKey": "sess_abc123",
      "kind": "telegram",
      "label": "Main Chat",
      "active": true,
      "lastActivity": "2026-02-02T10:25:00Z",
      "messageCount": 127,
      "recentMessages": [
        { "role": "user", "content": "What's the weather?" },
        { "role": "assistant", "content": "Let me check..." }
      ]
    }
  ],
  "total": 1
}

openclaw_sessions_history

Fetch complete message history for a specific session.

Natural Language Examples:

  • "Show me the conversation history for session sess_abc123"

  • "Get the last 100 messages from my main session"

  • "Fetch the history with all tool calls for the Telegram session"

Parameters:

  • sessionKey (string, required) - Session key to fetch history for

  • limit (number, optional) - Maximum number of messages to return

  • includeTools (boolean, optional) - Include tool calls in history

Example Input:

{
  "sessionKey": "sess_abc123",
  "limit": 50,
  "includeTools": true
}

Example Output:

{
  "sessionKey": "sess_abc123",
  "messages": [
    {
      "timestamp": "2026-02-02T10:00:00Z",
      "role": "user",
      "content": "Search for OpenClaw documentation"
    },
    {
      "timestamp": "2026-02-02T10:00:05Z",
      "role": "assistant",
      "content": "I'll search for that...",
      "toolCalls": [
        { "tool": "web_search", "args": { "query": "OpenClaw documentation" } }
      ]
    }
  ],
  "total": 127
}

openclaw_sessions_send

Send a message to another active OpenClaw session.

Natural Language Examples:

  • "Ask Assistant-2 if they're done with the data analysis"

  • "Send a message to the monitoring session asking for current status"

  • "Tell the background session to pause its work"

Parameters:

  • message (string, required) - Message to send

  • sessionKey (string, optional) - Target session key

  • label (string, optional) - Target session label (alternative to sessionKey)

  • timeoutSeconds (number, optional) - Timeout for response

Example Input:

{
  "label": "Assistant-2",
  "message": "Can you help with the data analysis task?",
  "timeoutSeconds": 30
}

Example Output:

{
  "success": true,
  "response": "Sure, I'll start working on the data analysis right away.",
  "responseTime": 2.4
}

openclaw_sessions_spawn

Spawn a background sub-agent in an isolated session for autonomous task execution.

Natural Language Examples:

  • "Spawn a background agent to monitor server logs for errors"

  • "Create a sub-agent to research competitors and summarize findings in 30 minutes"

  • "Start an isolated session to handle customer support messages while I work on other tasks"

Parameters:

  • task (string, required) - Task description for the sub-agent

  • agentId (string, optional) - Specific agent ID to use

  • model (string, optional) - Model to use (e.g., "claude-sonnet-4")

  • label (string, optional) - Human-readable session label

  • runTimeoutSeconds (number, optional) - Maximum execution time

Example Input:

{
  "task": "Monitor the server logs and alert me if any errors occur in the next hour",
  "label": "Log Monitor",
  "model": "claude-sonnet-4",
  "runTimeoutSeconds": 3600
}

Example Output:

{
  "success": true,
  "sessionKey": "sess_xyz789",
  "label": "Log Monitor",
  "status": "running",
  "startTime": "2026-02-02T10:30:00Z"
}

Scheduling

openclaw_cron_list

List all scheduled cron jobs.

Natural Language Examples:

  • "Show me all my scheduled tasks"

  • "List all cron jobs including disabled ones"

  • "What automated tasks do I have set up?"

Parameters:

  • includeDisabled (boolean, optional) - Include disabled jobs in the list

Example Input:

{
  "includeDisabled": true
}

Example Output:

{
  "jobs": [
    {
      "id": "job_001",
      "name": "Daily Backup",
      "schedule": { "hour": 2, "minute": 0 },
      "enabled": true,
      "nextRun": "2026-02-03T02:00:00Z",
      "lastRun": "2026-02-02T02:00:00Z"
    },
    {
      "id": "job_002",
      "name": "Weekly Report",
      "schedule": { "dayOfWeek": 1, "hour": 9, "minute": 0 },
      "enabled": false
    }
  ],
  "total": 2
}

openclaw_cron_add

Create a new scheduled cron job.

Natural Language Examples:

  • "Schedule a daily backup at 2am"

  • "Create a cron job to send me weather updates every morning at 7am"

  • "Set up a weekly report to be generated every Monday at 9am"

Parameters:

  • job (object, required) - Job definition containing:

    • name (string) - Job name

    • schedule (object) - Schedule specification (minute, hour, dayOfWeek, etc.)

    • payload (object) - Task payload/configuration

    • sessionTarget (string) - Target session: main or isolated

    • enabled (boolean) - Whether job is enabled

Example Input:

{
  "job": {
    "name": "Morning Weather Alert",
    "schedule": {
      "hour": 7,
      "minute": 0
    },
    "payload": {
      "action": "send_message",
      "channel": "telegram",
      "message": "Good morning! Here's today's weather forecast."
    },
    "sessionTarget": "main",
    "enabled": true
  }
}

Example Output:

{
  "success": true,
  "jobId": "job_003",
  "nextRun": "2026-02-03T07:00:00Z"
}

openclaw_cron_remove

Delete a scheduled cron job.

Natural Language Examples:

  • "Delete the morning weather alert job"

  • "Remove cron job job_003"

  • "Cancel the daily backup task"

Parameters:

  • jobId (string, required) - Job ID to remove

Example Input:

{
  "jobId": "job_003"
}

Example Output:

{
  "success": true,
  "message": "Job job_003 removed successfully"
}

openclaw_cron_run

Trigger a cron job to run immediately, outside its scheduled time.

Natural Language Examples:

  • "Run the backup job now"

  • "Trigger the weekly report immediately"

  • "Execute job_001 right now"

Parameters:

  • jobId (string, required) - Job ID to execute

Example Input:

{
  "jobId": "job_001"
}

Example Output:

{
  "success": true,
  "executionId": "exec_12345",
  "startTime": "2026-02-02T10:30:00Z",
  "status": "completed",
  "result": "Backup completed successfully"
}

Nodes (Paired Devices)

openclaw_nodes_status

Get status information for all paired nodes (mobile devices, remote machines).

Natural Language Examples:

  • "Show me the status of all my connected devices"

  • "Which nodes are currently online?"

  • "What's my iPhone's battery level?"

Parameters: None

Example Input:

{}

Example Output:

{
  "nodes": [
    {
      "id": "node_iphone",
      "name": "iPhone 15 Pro",
      "type": "mobile",
      "platform": "ios",
      "online": true,
      "lastSeen": "2026-02-02T10:29:00Z",
      "battery": 87,
      "capabilities": ["camera", "location", "notifications"]
    },
    {
      "id": "node_laptop",
      "name": "MacBook Pro",
      "type": "computer",
      "platform": "macos",
      "online": true,
      "lastSeen": "2026-02-02T10:30:00Z"
    }
  ],
  "total": 2
}

openclaw_nodes_notify

Send a push notification to a paired node.

Natural Language Examples:

  • "Send a notification to my iPhone: 'Task completed successfully'"

  • "Alert my phone with high priority that the deployment is done"

  • "Notify all my devices that dinner is ready"

Parameters:

  • title (string, required) - Notification title

  • body (string, required) - Notification body/message

  • node (string, optional) - Node ID or name (defaults to all nodes)

  • priority (string, optional) - Priority level: passive, active, timeSensitive

Example Input:

{
  "node": "node_iphone",
  "title": "Task Complete",
  "body": "Your data analysis has finished processing.",
  "priority": "timeSensitive"
}

Example Output:

{
  "success": true,
  "delivered": true,
  "node": "node_iphone",
  "timestamp": "2026-02-02T10:30:00Z"
}

openclaw_nodes_camera_snap

Capture a photo from a node's camera.

Natural Language Examples:

  • "Take a picture with my iPhone's back camera"

  • "Snap a photo from both cameras on my phone"

  • "Capture a high-quality image from the front camera"

Parameters:

  • node (string, optional) - Node ID or name

  • facing (string, optional) - Camera to use: front, back, both

  • quality (number, optional) - Image quality 0-100

Example Input:

{
  "node": "node_iphone",
  "facing": "back",
  "quality": 85
}

Example Output:

{
  "success": true,
  "images": [
    {
      "camera": "back",
      "url": "https://openclaw.gateway/images/img_abc123.jpg",
      "size": 2456789,
      "timestamp": "2026-02-02T10:30:00Z"
    }
  ]
}

openclaw_nodes_location

Get current location from a paired node.

Natural Language Examples:

  • "Where is my iPhone right now?"

  • "Get the precise location of my phone"

  • "Show me the current location of node_iphone"

Parameters:

  • node (string, optional) - Node ID or name

  • desiredAccuracy (string, optional) - Accuracy level: coarse, balanced, precise

Example Input:

{
  "node": "node_iphone",
  "desiredAccuracy": "precise"
}

Example Output:

{
  "success": true,
  "location": {
    "latitude": 37.7749,
    "longitude": -122.4194,
    "accuracy": 10,
    "altitude": 52,
    "timestamp": "2026-02-02T10:30:00Z",
    "address": "San Francisco, CA"
  }
}

openclaw_nodes_run

Execute a command on a paired node.

Natural Language Examples:

  • "Run 'ls -la' on my laptop"

  • "Execute a git pull on the remote server"

  • "Check disk space on node_laptop by running 'df -h'"

Parameters:

  • command (array of strings, required) - Command and arguments to execute

  • node (string, optional) - Node ID or name

  • cwd (string, optional) - Working directory for command execution

  • timeoutMs (number, optional) - Command timeout in milliseconds

Example Input:

{
  "node": "node_laptop",
  "command": ["ls", "-la", "/home/user/projects"],
  "timeoutMs": 5000
}

Example Output:

{
  "success": true,
  "stdout": "total 48\ndrwxr-xr-x  6 user staff  192 Feb  2 10:00 .\ndrwxr-xr-x 12 user staff  384 Feb  1 09:00 ..\n...",
  "stderr": "",
  "exitCode": 0,
  "executionTime": 124
}

Web

openclaw_web_search

Search the web using the Brave Search API.

Natural Language Examples:

  • "Search the web for 'best TypeScript practices 2026'"

  • "Find recent articles about AI assistants from the past week"

  • "Look up OpenClaw documentation online"

Parameters:

  • query (string, required) - Search query

  • count (number, optional) - Number of results to return (1-10)

  • country (string, optional) - 2-letter country code for localized results

  • freshness (string, optional) - Time filter: pd (past day), pw (past week), pm (past month), py (past year)

Example Input:

{
  "query": "OpenClaw AI assistant",
  "count": 5,
  "freshness": "pm"
}

Example Output:

{
  "results": [
    {
      "title": "OpenClaw - Personal AI Assistant Platform",
      "url": "https://example.com/openclaw",
      "description": "OpenClaw is an advanced AI assistant platform...",
      "age": "2 days ago"
    },
    {
      "title": "Getting Started with OpenClaw",
      "url": "https://docs.example.com/openclaw/intro",
      "description": "Learn how to set up and use OpenClaw...",
      "age": "1 week ago"
    }
  ],
  "totalResults": 5
}

openclaw_web_fetch

Fetch and extract readable content from a URL.

Natural Language Examples:

Parameters:

  • url (string, required) - URL to fetch

  • extractMode (string, optional) - Extraction format: markdown or text

  • maxChars (number, optional) - Maximum characters to return

Example Input:

{
  "url": "https://example.com/article",
  "extractMode": "markdown",
  "maxChars": 5000
}

Example Output:

{
  "success": true,
  "url": "https://example.com/article",
  "title": "Understanding AI Assistants",
  "content": "# Understanding AI Assistants\n\nAI assistants have revolutionized...",
  "length": 3456,
  "extracted": "2026-02-02T10:30:00Z"
}

Gateway & Utilities

openclaw_gateway_status

Get current status of the OpenClaw Gateway session.

Natural Language Examples:

  • "What's the status of my current session?"

  • "Show me the Gateway status"

  • "How long has this session been active?"

Parameters:

  • sessionKey (string, optional) - Specific session key to query

Example Input:

{
  "sessionKey": "sess_abc123"
}

Example Output:

{
  "sessionKey": "sess_abc123",
  "status": "active",
  "uptime": 3600,
  "messageCount": 127,
  "toolCallCount": 45,
  "lastActivity": "2026-02-02T10:30:00Z",
  "connectedNodes": 2
}

openclaw_gateway_config_get

Retrieve current Gateway configuration settings.

Natural Language Examples:

  • "Show me the Gateway configuration"

  • "What features are enabled in my Gateway?"

  • "Get the current Gateway settings"

Parameters: None

Example Input:

{}

Example Output:

{
  "version": "1.2.0",
  "config": {
    "maxSessions": 50,
    "enabledChannels": ["telegram", "slack", "discord"],
    "features": {
      "webSearch": true,
      "tts": true,
      "nodes": true
    }
  }
}

openclaw_tts

Convert text to speech audio.

Natural Language Examples:

  • "Convert 'Hello world' to speech"

  • "Generate an audio file saying 'The task is complete'"

  • "Create a voice message for Telegram saying 'Running late, be there soon'"

Parameters:

  • text (string, required) - Text to convert to speech

  • channel (string, optional) - Target channel for format optimization

Example Input:

{
  "text": "Hello, this is a text to speech test.",
  "channel": "telegram"
}

Example Output:

{
  "success": true,
  "audioUrl": "https://openclaw.gateway/audio/tts_xyz789.mp3",
  "duration": 3.2,
  "format": "mp3",
  "size": 51200
}

openclaw_memory_search

Search OpenClaw's memory files using semantic search.

Natural Language Examples:

  • "Search my memory for conversations about the weather"

  • "Find any mentions of project deadlines from last week"

  • "Look up what we discussed about the deployment process"

Parameters:

  • query (string, required) - Search query

  • maxResults (number, optional) - Maximum number of results to return

  • minScore (number, optional) - Minimum relevance score (0-1)

Example Input:

{
  "query": "weather forecast discussions from last week",
  "maxResults": 5,
  "minScore": 0.7
}

Example Output:

{
  "results": [
    {
      "content": "We discussed the weather forecast for San Francisco...",
      "timestamp": "2026-01-28T14:30:00Z",
      "score": 0.89,
      "source": "session_log_2026-01-28"
    },
    {
      "content": "The forecast indicated rain for the weekend...",
      "timestamp": "2026-01-27T10:15:00Z",
      "score": 0.82,
      "source": "session_log_2026-01-27"
    }
  ],
  "total": 5
}

Development

# Install dependencies
npm install

# Run in development mode
npm run dev

# Build for production
npm run build

# Run built version
npm start

Testing

Test the server with MCP inspector:

npx @modelcontextprotocol/inspector node dist/index.js

Or test directly:

echo '{"jsonrpc":"2.0","id":1,"method":"tools/list"}' | node dist/index.js

License

MIT

Author

Helms AI

Available Tools

21 tools
openclaw_cron_addC

Add a new cron job

ParametersJSON Schema
NameRequiredDescriptionDefault
jobYesJob definition with name, schedule, payload, sessionTarget

TDQS

C2.6/5.0
Behavior1/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 'Add a new cron job' with no details on side effects, success/failure behavior, 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.

Conciseness3/5

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

The description is concise (one sentence) but lacks structure. It is appropriately front-loaded but could benefit from brief expansion on the job structure.

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 complex nested parameter and no output schema, the description is incomplete. It does not explain the cron system context, sessionTarget enum, or what happens after adding a job.

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% but parameter descriptions are minimal (e.g., 'Job definition with name, schedule, payload, sessionTarget'). The description adds no additional meaning beyond the schema, so baseline 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 'Add a new cron job' clearly states the action and resource, distinguishing it from siblings like list, remove, and run. It uses a specific verb and resource, avoiding tautology.

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. It does not mention prerequisites, common patterns, or that it creates jobs manageable by list/remove/run.

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

openclaw_cron_listB

List scheduled cron jobs

ParametersJSON Schema
NameRequiredDescriptionDefault
includeDisabledNoInclude disabled jobs

TDQS

B3.2/5.0
Behavior2/5

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

No annotations provided, and the description does not disclose any behavioral traits such as default behavior, pagination, or authentication 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?

Extremely concise at 4 words, front-loaded with purpose, but could include more detail without being 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?

Adequate for a simple list tool with one optional parameter, but missing context about default behavior (e.g., lists active jobs by default) and return structure.

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 has 100% coverage with a description for the only parameter; the description adds meaning beyond the parameter name, but the tool description does not elaborate on 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?

Description clearly states verb 'list' and resource 'scheduled cron jobs', distinguishing it from sibling tools like openclaw_cron_add, openclaw_cron_remove, etc.

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; usage is only implied by its listing nature.

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

openclaw_cron_removeC

Remove a cron job

ParametersJSON Schema
NameRequiredDescriptionDefault
jobIdYesJob ID to remove

TDQS

C2.9/5.0
Behavior2/5

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

The description lacks behavioral details. It does not state whether removal is permanent, irreversible, or if it requires specific permissions. With no annotations, the description fails to convey critical traits beyond the basic action.

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 short sentence), but this conciseness sacrifices informational value. It is not verbose, but it under-specifies, making it less helpful than a slightly longer description.

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 provides the minimal core purpose. However, it omits context like return value, side effects, and when removal is valid, which could confuse 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?

The input schema covers 100% of parameters with a clear description for 'jobId'. The description adds no extra context beyond the schema, but the baseline of 3 is appropriate given high schema coverage.

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 'Remove' and resource 'cron job', making the action obvious. However, it does not differentiate from sibling cron tools like openclaw_cron_add or openclaw_cron_list, which limits clarity in distinguishing purposes.

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 guidelines are provided. The description does not indicate when to use this tool versus alternatives (e.g., openclaw_cron_add) or any prerequisites such as job existence or permissions.

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

openclaw_cron_runB

Trigger a cron job immediately

ParametersJSON Schema
NameRequiredDescriptionDefault
jobIdYesJob ID to run

TDQS

B3.1/5.0
Behavior2/5

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

With no annotations, the description bears full responsibility. It does not disclose whether the trigger is synchronous or async, what happens if the job is already running, or any side effects. Only the basic action is stated.

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, efficient sentence that conveys the core action without unnecessary words. However, it could be slightly expanded to improve clarity without sacrificing 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 simplicity (1 parameter, no output schema), the description lacks critical details such as return values, error states, or behavior upon completion. It is not fully informative 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 the description repeats the schema's parameter description ('Job ID to run') without adding additional meaning. Baseline of 3 applies per guidelines for 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?

The description clearly states the action ('trigger') and resource ('a cron job'), and the verb 'run' distinguishes it from sibling tools like openclaw_cron_add or openclaw_cron_remove.

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 triggering vs. adding or removing cron jobs. The context of usage is left entirely to the agent.

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

openclaw_gateway_config_getA

Get current Gateway configuration

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A3.5/5.0
Behavior2/5

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

With no annotations provided, the description carries full burden but only states 'Get', implying read-only. No details are given about authorization, idempotency, rate limits, or what happens on error. This is insufficient 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 a single, front-loaded sentence with no filler. Every word is purposeful, 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.

Completeness3/5

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

For a simple getter with no parameters and no output schema, the description is minimal but adequate. However, it could be more complete by hinting at the structure of the configuration or stating that it returns the full config. The lack of any extra context beyond the name leaves room for improvement.

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 input schema has no parameters, and schema coverage is 100%. According to the rubric, a base score of 4 is appropriate when there are 0 parameters, as the description does not need to add param details. The description adds nothing extra, but that is acceptable.

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 'Get current Gateway configuration' uses a specific verb and resource, clearly stating the tool's purpose. It distinguishes itself from siblings like openclaw_gateway_status which likely provides status rather than 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 guidance on when to use this tool versus alternatives like openclaw_gateway_status. The description fails to mention any prerequisites or exclusions, leaving the agent without direction.

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

openclaw_gateway_statusC

Get OpenClaw Gateway session status

ParametersJSON Schema
NameRequiredDescriptionDefault
sessionKeyNoSession key (optional)

TDQS

C2.6/5.0
Behavior2/5

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

No annotations are provided, and the description only says 'Get', implying a read operation but not explicitly stating it is read-only. There is no disclosure of authentication needs, side effects, or what 'status' entails.

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 (one phrase), which is acceptable but could be slightly expanded to include key behavioral details 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 simplicity of the tool (1 optional param, no output schema), the description should at least indicate what information the status response contains. It provides no return value 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?

The input schema already describes the single optional parameter (sessionKey). The description adds no additional meaning, such as why or when to provide the key, or the effect of omitting 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 'Get' and the resource 'OpenClaw Gateway session status', distinguishing it from sibling tools like openclaw_nodes_status and openclaw_sessions_list. However, it does not explicitly differentiate from these siblings.

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_sessions_list or openclaw_gateway_config_get. The agent is left to infer usage from the name.

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

openclaw_message_broadcastB

Broadcast a message to multiple targets

ParametersJSON Schema
NameRequiredDescriptionDefault
channelNoChannel type
targetsYesList of target IDs
messageYesMessage text

TDQS

B3.1/5.0
Behavior2/5

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

No annotations provided, and the description lacks details on side effects, permissions, rate limits, or whether the operation is synchronous. 'Broadcast' implies mutation but no 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.

Conciseness4/5

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

The description is one short sentence, front-loaded with essential information. It could be slightly more detailed but remains appropriately concise.

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, output schema, and sibling differentiation, the description is insufficient. It does not explain broadcast behavior (e.g., return values, async nature) or when to prefer it over 'openclaw_message_send'.

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%; descriptions for 'channel,' 'targets,' and 'message' are provided in the schema. The description adds no additional meaning beyond what is already in the schema.

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

Purpose5/5

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

The description 'Broadcast a message to multiple targets' uses a specific verb ('broadcast') and resource ('message'), and implies sending to multiple recipients, distinguishing it from the sibling 'openclaw_message_send' which likely addresses a single target.

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_message_send'. The description does not specify appropriate contexts or exclusions.

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

openclaw_message_sendB

Send a message via OpenClaw channels (Telegram, WhatsApp, Discord, Slack, Signal, etc.)

ParametersJSON Schema
NameRequiredDescriptionDefault
channelNoChannel type (telegram, whatsapp, discord, slack, signal, imessage, googlechat)
targetNoTarget chat/user ID or name
messageYesMessage text to send
replyToNoMessage ID to reply to (optional)
silentNoSend silently without notification (optional)

TDQS

B3.1/5.0
Behavior2/5

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

No annotations provided, and description fails to disclose behavioral traits such as delivery guarantees, authentication requirements, rate limits, or error handling; too vague for a messaging 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?

Single sentence front-loads purpose efficiently, but lacks any structured details that would improve scannability.

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 5 parameters, no output schema, and no annotations, the description does not explain return values, error handling, or prerequisites; incomplete for effective usage.

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 3; description adds no additional parameter-level meaning beyond what 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?

Description clearly states the action (send a message) and resource (OpenClaw channels), listing concrete examples like Telegram, WhatsApp, Discord, distinguishing it from sibling tools like openclaw_message_broadcast.

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 siblings; lacks context for when to prefer openclaw_message_send over openclaw_message_broadcast or openclaw_sessions_send.

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

openclaw_nodes_camera_snapB

Capture a photo from a node's camera

ParametersJSON Schema
NameRequiredDescriptionDefault
nodeNoNode ID or name
facingNoCamera facing
qualityNoImage quality 0-100

TDQS

B3.2/5.0
Behavior2/5

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

No annotations are present, so the description must fully disclose behavior. It only states the action but does not mention side effects (e.g., if the photo is stored or returned), permissions needed, error conditions, or rate limits. This is insufficient 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 a single sentence with no wasted words. However, it is front-loaded only with the basic action; more critical context (e.g., return value) is omitted. Still, 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?

For a simple tool with 3 parameters and no output schema, the description covers the core action but lacks behavioral context (e.g., what happens to the captured photo). An agent would benefit from knowing whether the photo is returned directly or stored remotely.

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 all three parameters (node, facing, quality). The description adds no additional meaning beyond the schema, so baseline score of 3 is appropriate.

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

Purpose5/5

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

The description clearly states it captures a photo from a node's camera, using a specific verb and resource. It distinguishes itself from sibling tools which deal with other node operations (location, notify, run, status) that are not camera-related.

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 vs alternatives, prerequisites, or exclusions. The description only states the action, leaving the agent to infer usage context.

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

openclaw_nodes_locationC

Get location from a paired node

ParametersJSON Schema
NameRequiredDescriptionDefault
nodeNoNode ID or name
desiredAccuracyNo

TDQS

C2.7/5.0
Behavior2/5

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

No annotations are provided, and the description only states 'Get location,' implying a read-only query. However, it does not disclose important behavioral traits such as whether pairing is required, what happens if the node is not paired, or the format of the returned location.

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 with no unnecessary words. However, given the tool's two parameters and lack of annotations, more detail might be warranted, but it remains appropriately short.

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 tool with two parameters, no output schema, and no annotations, the description is too minimal. It fails to explain what 'paired node' means, the significance of accuracy levels, or what the return value contains. This is insufficient for an agent to invoke the tool correctly.

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 does not add any meaning beyond the input schema. The schema has 50% description coverage (only 'node' has a description), but the tool description does not explain the 'desiredAccuracy' enum values or the difference between coarse, balanced, and precise.

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 'Get location from a paired node' clearly states the verb (Get) and resource (location from a paired node). It implies a read operation on a specific node, which distinguishes it from sibling tools like openclaw_nodes_camera_snap or openclaw_nodes_status. However, it does not explicitly differentiate itself from all siblings.

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_nodes_status or openclaw_gateway_status. The description does not mention prerequisites (e.g., node must be paired) or conditions for use.

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

openclaw_nodes_notifyC

Send a notification to a paired node

ParametersJSON Schema
NameRequiredDescriptionDefault
nodeNoNode ID or name
titleYesNotification title
bodyYesNotification body
priorityNo

TDQS

C2.9/5.0
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 'Send a notification', implying a mutation, but omits consequences, authorization needs, or whether it is destructive. This is insufficient for safe tool 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 a single concise sentence, front-loading the action. It is not verbose, but could include slightly more detail without losing conciseness (e.g., indicating the notification type).

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 simplicity of the tool (no output schema, no annotations), the description is too sparse. It does not explain what 'paired node' means, delivery guarantees, or any side effects. The agent lacks sufficient context to use 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?

Schema coverage is 75% (3 of 4 parameters have descriptions). The 'priority' parameter has an enum but no description beyond the 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.

Purpose4/5

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

The description clearly states the verb 'send', the resource 'notification', and the target 'paired node'. It is specific and distinguishable from siblings like 'openclaw_message_send' which send messages, not notifications. However, it could be more explicit about what a notification entails versus a message.

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_message_send' or 'openclaw_message_broadcast'. The description does not specify context, prerequisites, or exclusions, leaving 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.

openclaw_nodes_runC

Run a command on a paired node

ParametersJSON Schema
NameRequiredDescriptionDefault
nodeNoNode ID or name
commandYesCommand and arguments
cwdNoWorking directory
timeoutMsNoCommand timeout

TDQS

C2.9/5.0
Behavior2/5

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

No annotations provided. Description does not disclose behavioral traits such as whether the command is blocking, what permissions are needed, error handling, or side effects. Minimal 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?

Single sentence, no fluff. Every word serves a purpose. Appropriate length for a simple command execution 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?

For a tool with 4 parameters and no output schema, the description is insufficient. Lacks explanation of 'paired node', how to specify node (ID or name), behavior of command array, default cwd, or timeout implications.

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. Description adds no extra meaning beyond the schema; e.g., 'node' and 'command' meanings are left to schema descriptions.

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 verb 'Run' and resource 'command on a paired node'. Distinguishes from sibling tools like openclaw_nodes_status or openclaw_nodes_notify, but does not explicitly differentiate from similar command-execution tools.

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. Does not mention prerequisites, when-not-to-use, or compare to sibling tools like openclaw_nodes_camera_snap or openclaw_nodes_location.

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

openclaw_nodes_statusA

Get status of paired nodes (mobile devices, remote machines)

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A3.5/5.0
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 states 'Get status' (a read operation) but does not disclose any behavioral traits such as whether it requires authentication, if it is quick, or what happens if nodes are offline. The description is too 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 a single, front-loaded sentence that wastes no words. It is perfectly concise for a tool with no parameters.

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 no parameters and no output schema, the description minimally conveys the purpose. However, it could be more helpful by explaining what 'status' includes (e.g., connectivity, battery level, last seen). It is just adequate.

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 zero parameters and 100% schema coverage, the baseline is 4. The description does not need to add param info, but it also does not provide any extra context about the absence of parameters. It is adequate.

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 ('Get status') and resource ('paired nodes'), and clarifies that nodes are mobile devices and remote machines. It clearly distinguishes from sibling tools like openclaw_nodes_run or openclaw_nodes_camera_snap, which perform different actions on nodes.

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 any guidance on when to use this tool versus alternatives (e.g., when to check status vs. when to use openclaw_nodes_location). No explicit 'when' or '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.

openclaw_sessions_historyB

Fetch message history for a session

ParametersJSON Schema
NameRequiredDescriptionDefault
sessionKeyYesSession key to fetch history for
limitNoMax messages to return
includeToolsNoInclude tool calls in history

TDQS

B3.3/5.0
Behavior2/5

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

Annotations are absent, so the description must carry the full burden. It states 'fetch' which implies a read operation, but does not disclose any behavioral traits such as being read-only, requiring authentication, or having rate limits. Minimal disclosure beyond the 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?

The description is a single, efficient sentence with no wasted words. It is front-loaded and straight to the point. Every word earns its place, achieving maximum 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?

Given the tool's simplicity (3 parameters, no output schema, no nested objects) and full schema coverage, the description is adequate but lacks information about return values or when the tool might be used. Adding what the return data contains 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 baseline is 3. The description adds no additional meaning beyond what the schema provides for the three parameters (sessionKey, limit, includeTools). Parameters are adequately documented 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 'Fetch message history for a session' uses a specific verb (fetch) and resource (message history for a session). It clearly distinguishes this tool from siblings like openclaw_sessions_list (list sessions) and openclaw_sessions_send (send message). 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 (e.g., session must exist) or when not to use it. The description only states the action without contextual usage advice.

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

openclaw_sessions_listB

List active OpenClaw sessions with optional filters

ParametersJSON Schema
NameRequiredDescriptionDefault
kindsNoFilter by session kinds
activeMinutesNoFilter by activity within N minutes
limitNoMax sessions to return
messageLimitNoInclude last N messages per session

TDQS

B3.1/5.0
Behavior2/5

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

With no annotations, the description should disclose behavioral traits like read-only nature, but it only states 'list active sessions' without confirming idempotency 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.

Conciseness4/5

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

The description is very short (one sentence) and free of fluff, though it could benefit from slightly more detail without losing 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 four optional parameters, no output schema, and no annotations, the description lacks critical context about return format, defaults, and behavior of filters like activeMinutes and messageLimit.

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 parameters are already described in the schema; the description adds no additional meaning beyond 'optional filters'.

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 resource (active OpenClaw sessions), and distinguishes from siblings like openclaw_sessions_history by specifying 'active'.

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_sessions_history or openclaw_sessions_spawn; usage is merely implied.

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

openclaw_sessions_sendC

Send a message to another OpenClaw session

ParametersJSON Schema
NameRequiredDescriptionDefault
sessionKeyNoTarget session key
labelNoTarget session label (alternative to sessionKey)
messageYesMessage to send
timeoutSecondsNoTimeout for response

TDQS

C2.8/5.0
Behavior2/5

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

No annotations are provided, and the description only states the basic action. It does not disclose whether the send is synchronous, if a response is awaited, if the target session must be active, or any side effects. Behavioral transparency is very poor.

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 short sentence, which is concise but lacks structure. It does not front-load important details or provide an overview. It is minimally adequate.

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 and no output schema or annotations, the description should explain parameter relationships, expected behavior, and constraints. It fails to address whether both sessionKey and label can be used together, what timeout applies to, or any error conditions. Incomplete for the tool's 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% with each parameter described. However, the tool description adds no additional meaning about how parameters interact (e.g., precedence between sessionKey and label, timeout behavior). Baseline 3 with no extra value.

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 'Send a message to another OpenClaw session' clearly indicates the action and target. It distinguishes from siblings like openclaw_message_send (which may be for general messages) and openclaw_message_broadcast, but does not explicitly call out 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 on when to use this tool versus alternatives, no explanation of sessionKey vs label usage, no mention of prerequisites or context. The description provides zero usage recommendations.

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

openclaw_sessions_spawnB

Spawn a background sub-agent in an isolated session

ParametersJSON Schema
NameRequiredDescriptionDefault
taskYesTask description for the sub-agent
agentIdNoAgent ID to use (optional)
modelNoModel to use (optional)
labelNoSession label (optional)
runTimeoutSecondsNoMax run time

TDQS

B3/5.0
Behavior2/5

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

No annotations exist, and the description does not disclose behavioral traits such as destructive potential, authentication needs, or side effects. The description carries full burden but is minimal.

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

Conciseness3/5

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

Description is a single sentence, front-loaded with the verb, but is too minimal and lacks structure for a 5-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?

Given 5 parameters, no output schema, and no annotations, the description is insufficient. It doesn't explain return values, side effects, or process 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 parameters are already documented. 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?

Description clearly states the action (spawn), the resource (background sub-agent in an isolated session), and distinguishes from siblings like openclaw_sessions_list.

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 prerequisites or exclusions provided.

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

openclaw_ttsC

Convert text to speech

ParametersJSON Schema
NameRequiredDescriptionDefault
textYesText to convert to speech
channelNoChannel for output format hint

TDQS

C2.9/5.0
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 behavioral traits like audio format, latency, limits, or synchronous/asynchronous behavior. For a TTS tool, more context is needed.

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 and is front-loaded. It is concise, but the minimalism sacrifices completeness. It earns its place but could be more structured.

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, the description should explain return values or side effects. It does not. Also, it omits important context for a TTS tool, making it incomplete despite 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 coverage is 100%, so baseline is 3. The description does not add meaning beyond the schema descriptions for 'text' and 'channel'. It merely restates the tool's purpose.

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 'Convert text to speech' clearly states the action and resource. It is specific enough to convey the tool's function, though it does not distinguish from siblings, which are unrelated.

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 vs alternatives. Siblings are unrelated, so context is minimal, but the description lacks any usage hints or prerequisites.

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

openclaw_web_fetchB

Fetch and extract readable content from a URL

ParametersJSON Schema
NameRequiredDescriptionDefault
urlYesURL to fetch
extractModeNoExtraction mode
maxCharsNoMax characters to return

TDQS

B3.1/5.0
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 says 'extract readable content' but does not disclose any behavioral traits such as following redirects, handling errors, or what constitutes 'readable'. This is minimal disclosure.

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. It is not overly verbose, but could be expanded slightly to include key behavioral details without becoming wasteful.

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 no annotations, the description is too minimal. It does not explain the extraction modes, maxChars behavior, or what the output looks like. The agent lacks sufficient context to use 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?

Schema coverage is 100%, so the description adds little beyond what the schema already provides. The word 'extract' somewhat relates to the extractMode parameter but does not add new 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 the verb 'Fetch and extract' and the resource 'readable content from a URL'. It distinguishes from sibling 'openclaw_web_search' which is for searching, not fetching a specific URL.

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_web_search or other fetching mechanisms. There is no mention of when not to use it or any prerequisites.

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

Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.2/5.0
Disambiguation5/5

Each tool has a distinct purpose, with clear separation between messaging, sessions, nodes, and other domains. Minor overlap between message_send and message_broadcast is resolved by description.

Naming Consistency5/5

All tools follow a consistent openclaw_{category}_{action} pattern in snake_case, making names predictable and easy to parse.

Tool Count4/5

21 tools cover multiple domains but are slightly above the ideal 3-15 range. However, the count is justified by the breadth of functionality and does not feel excessive.

Completeness3/5

While core workflows like cron, messaging, and web are well-covered, there are notable gaps: no memory write, no gateway configuration update, and no node pairing/unpairing. These gaps could hinder some agent tasks.

Maintenance

ActivityInactive
ResponsivenessSyncing

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

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/Helms-AI/openclaw-mcp-server'

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