OpenClaw MCP: Build a Multi-Tool Assistant in Minutes

A Claude agent without tools is a very good text generator. An agent with tools is something different: it can take action, retrieve real information, and produce results that cannot be faked with pattern matching. MCP (Model Context Protocol) is the standard that makes attaching tools to Claude agents straightforward and composable. OpenClaw has first-class support for it, and wiring up a multi-tool assistant takes less time than you probably expect.

What MCP Adds to an OpenClaw Agent

Without tools, a Claude agent running in OpenClaw is limited to what it can reason about from conversation history and its training data. That is genuinely useful for answering questions, drafting text, and working through problems in a structured way. But the moment a user asks "what is on my calendar tomorrow" or "send that as a draft email to the team", a chat-only agent has to apologize because it has no way to access that information.

MCP changes this by providing a standard protocol for exposing tools, called servers, that Claude can call during a conversation. An MCP server is a small process that exposes a set of named functions with defined input and output schemas. Claude sees the available tools, decides which ones to call based on the user's message and the system prompt instructions, and OpenClaw handles the actual execution and feeds the results back into context before Claude generates the final reply.

The key property of MCP is composability. You can run five MCP servers at once (calendar, email, files, web search, database) and Claude treats them all as a unified toolset. You do not need to build custom function-calling logic for each integration. You configure the servers, declare them in your OpenClaw config, and Claude reasons about which tools to use for which requests.

Wiring Up MCP Servers to an OpenClaw Agent

OpenClaw reads MCP server configuration from the agent config file. Each server is listed with its command, arguments, and any environment variables it needs. OpenClaw launches each server as a subprocess at startup and maintains a persistent connection for the lifetime of the agent process.

agent:
  name: personal-assistant
  model: claude-opus-4-5
  system_prompt: |
    You are a personal assistant with access to the user's calendar,
    email drafts, and web search.
    When the user asks about their schedule, use the calendar tool first.
    When asked to draft or send a message, create a draft and show it
    to the user for approval before sending anything.
    For questions requiring current information, use web_search.

mcp_servers:
  - name: google-calendar
    command: npx
    args: ["-y", "@modelcontextprotocol/server-google-calendar"]
    env:
      GOOGLE_OAUTH_CREDENTIALS: "/path/to/credentials.json"

  - name: gmail
    command: npx
    args: ["-y", "@modelcontextprotocol/server-gmail"]
    env:
      GMAIL_OAUTH_CREDENTIALS: "/path/to/credentials.json"

  - name: web-search
    command: npx
    args: ["-y", "@modelcontextprotocol/server-brave-search"]
    env:
      BRAVE_API_KEY: "your_brave_api_key"

When a user sends a message, OpenClaw passes the full context (system prompt, conversation history, and the list of available MCP tools) to Claude. Claude reasons about the request, decides which tools to call and in what order, and OpenClaw executes those calls against the appropriate MCP servers. The results are injected back into context, and Claude uses them to compose the final response.

Writing Tool-Use Instructions in the System Prompt

Having tools available does not guarantee Claude uses them well. The system prompt is where you define when and how to invoke each tool. Vague instructions produce inconsistent tool use. Specific instructions produce reliable, repeatable behavior that users can predict and trust.

The pattern that works is: for each tool, define a trigger condition (when to use it) and a behavior constraint (how to use it). The calendar trigger is "any question about schedule or meetings." The email constraint is "show the draft to the user for approval before sending." These two instructions eliminate entire categories of mistakes that would otherwise require debugging live conversations after users have already noticed the problem.

A Worked Example: Personal Assistant with Calendar and Email

Here is a realistic flow showing how the multi-tool assistant handles a compound request. The user sends: "I have a meeting tomorrow at 2pm. Can you find out who the other attendees are and draft a prep email for me to send them?"

OpenClaw receives the message. Claude reads the system prompt and the message, identifies two needed tool calls (calendar lookup, then email draft), and calls them in sequence. First it calls the calendar tool with tomorrow's date filtered for the 2pm slot. The tool returns the event details including attendee email addresses. Claude then drafts a preparation email addressed to those attendees and presents the draft to the user for approval before sending anything.

{
  "event": {
    "title": "Product Sync",
    "start": "2026-06-27T14:00:00",
    "end": "2026-06-27T15:00:00",
    "attendees": [
      "sarah@company.com",
      "james@company.com"
    ],
    "description": "Weekly product review"
  }
}

This is the kind of compound, multi-step task that used to require custom orchestration code for every new workflow. With an MCP-powered OpenClaw agent, you configure the servers once and let Claude reason about the steps. The agent handles variations on this request without any code changes on your part. The system prompt is where the intelligence lives, and Claude's reasoning handles the rest.