# Tools, Skills & MCP: Extending OpenClaw

OpenClaw becomes more useful when it can do more than reply. With the right Tools, reusable Skills, and MCP connections, it can inspect files, run controlled workflows, interact with external systems, and help automate real work.

This OpenClaw guide explains what each layer does, how they work together, and how to extend an agent without giving it more access than it needs.

## The Simple Mental Model

Think of an extended OpenClaw workflow in three layers:

- **Tools** are the actions OpenClaw can take, such as reading files, browsing, or running an approved command.
- **Skills** are reusable instructions that tell OpenClaw how and when to use those tools for a specific task.
- **MCP** is a structured protocol that can make tools from an external system available to OpenClaw.

A Skill does not grant new access by itself. It defines the workflow. Tools provide the actions, and an MCP server can supply additional actions from a connected service.

For a pull request review, a [code-review Skill](/blog/openclaw-custom-skill) can define the checklist, local tools can read the diff and run tests, and a read-only GitHub MCP server can provide repository context.

## Tools vs Skills vs MCP: What Is the Difference?

| Layer | What it does | Best for | Example |
|---|---|---|---|
| Tools | Give OpenClaw an action it can perform | Files, browser, commands, APIs | Read a diff, run tests, search documentation |
| Skills | Define the procedure, output, and guardrails | Repeatable workflows | PR review, bug triage, documentation update |
| MCP | Supplies tools through a standard external connection | Structured integrations | GitHub, a database, an internal API, a custom app |

Use a Tool when OpenClaw needs to take an action. Use a Skill when the task needs the same process and guardrails each time. Use MCP when that action comes from a structured external integration.

## Common OpenClaw Use Cases

### Code review

Useful setup: a code-review Skill, file-reading tools, a terminal tool, and a read-only GitHub MCP connection.

*Example prompt:* Review this pull request for bugs, security risks, missing tests, performance regressions, and maintainability issues. Do not modify files or post comments without approval.

### Bug investigation

Useful setup: a bug-investigation Skill, read-only file and log access, and a terminal tool.

*Example prompt:* Investigate this error. Check the related files, logs, and recent changes. Return the most likely cause, evidence, and safest fix.

### Browser automation

With browser tools or a browser MCP integration, OpenClaw can test forms, collect research, validate workflows, and inspect a website. See the [OpenClaw browser automation guide](/blog/openclaw-browser-automation-guide) for practical examples and safety considerations.

### Research and documentation

A research Skill can enforce source, comparison, and output rules. A documentation Skill can apply the same structure to setup guides, API documentation, troubleshooting pages, changelogs, and internal runbooks.

## How to Use Tools in OpenClaw

Tools are the action layer. Before enabling one, decide exactly what the workflow needs: file reading, browser access, a command, an API call, or log access. Do not enable unrelated tools just because they are available.

### 1. Check the Gateway and OpenClaw status

```bash
openclaw gateway status
openclaw status
```

If the Gateway is not running:

```bash
openclaw gateway start
# or
openclaw gateway restart
```

### 2. Open the Control UI safely

The local Control UI is normally available at `http://127.0.0.1:18789/`. It is an admin surface for chat, configuration, and approvals. Keep it on localhost, or use a private network or SSH tunnel. Do not expose it publicly.

### 3. Start with the smallest permission set

For project inspection, enable read access before write access. For browser research, avoid login sessions or purchasing capabilities. Test one small task before scaling the workflow:

```bash
npm test
# or
pytest
```

### 4. Add approval before high-impact actions

Require approval before editing or deleting files, sending messages, changing production settings, deploying, updating customer records, or making paid API calls.

A useful safety instruction is: *Show the proposed patch first and wait for my approval before making file changes.*

## How Skills Improve OpenClaw Workflows

Skills make OpenClaw consistent without repeatedly pasting long prompts. In OpenClaw, a Skill is a Markdown instruction package, usually centered on a `SKILL.md` file. It teaches the agent how and when to use the tools it already has.

Use a Skill when you repeat a workflow, need a predictable output, or need guardrails around a sensitive task. You can [build a custom Skill](/blog/openclaw-custom-skill) or review the [best OpenClaw Skills](/blog/best-openclaw-skills).

A strong Skill defines:

- The task goal and required input
- The steps, output format, and evidence required
- Rules and constraints
- Failure handling and approval requirements

**Weak instruction:** “Write better code.”

**Useful Skill instruction:** “Review this code for logic bugs, security risks, missing tests, and performance issues. Return findings by severity with suggested fixes. Do not modify files without approval.”

## How MCP Extends OpenClaw

MCP, short for Model Context Protocol, is a standard way to connect an agent with tools from an external system. An MCP server advertises its available capabilities, and OpenClaw can discover and use the permitted tools through that connection.

Use MCP when a workflow needs structured access to GitHub, a database, an internal API, an issue tracker, a documentation platform, or a custom business application. MCP is not required for every workflow: local tools and a clear Skill are often enough.

### OpenClaw can use MCP in two directions

- **OpenClaw as an MCP client:** OpenClaw connects to configured MCP servers and exposes their allowed capabilities as tools during an agent run.
- **OpenClaw as an MCP server:** A compatible MCP client can connect to OpenClaw through the Gateway bridge using `openclaw mcp serve`.

### Start with a read-only MCP connection

For a first integration, choose a small workflow and read-only access. A GitHub connection can read a pull request and its files without being able to comment, merge, or modify settings.

```bash
openclaw mcp status --verbose
openclaw mcp doctor
openclaw mcp probe <server-name>
```

## Security Checklist Before Extending OpenClaw

Use this checklist before enabling a Tool, Skill, or MCP server. For a deeper walkthrough, read [OpenClaw security best practices](/blog/openclaw-security-best-practices).

- Use the least permissions possible and start with read-only access.
- Keep API keys and tokens outside prompts, source files, and public logs.
- Do not expose unrestricted shell access or the Control UI to the public internet.
- Review an MCP server before installing it and limit the tools it exposes to OpenClaw.
- Use narrowly scoped tokens and keep test and production environments separate.
- Require approval before file edits, messages, deployments, database updates, and paid API calls.
- Review logs after a new tool or MCP server runs, then disable capabilities you do not need.
- Rotate credentials when access changes or a secret may have been exposed.

## Common Problems and Fixes

| Problem | Likely cause | Fix |
|---|---|---|
| Tool is not showing | Not installed, enabled, or detected | Check configuration, permissions, and logs |
| Tool exists but does not work | Missing permission or wrong path | Check access, paths, and environment variables |
| Skill is ignored | Instructions are vague or the Skill is not loaded | Add clear rules, examples, and output format |
| MCP server fails | Wrong command, port, token, or configuration | Run `openclaw mcp status --verbose` and `openclaw mcp doctor` |
| Workflow feels risky | Too many permissions are enabled | Return to read-only access and add approval gates |

## When to Use Managed OpenClaw Hosting

Self-hosting is a good fit when you want full control and are comfortable operating tools, Skills, MCP servers, ports, Gateway health, logs, updates, and uptime.

Managed hosting is a good fit when you want to focus on workflow design rather than server setup, Gateway maintenance, and MCP operations. Compare [managed vs self-hosted OpenClaw](/blog/openclaw-managed-vs-self-hosted), then start with one tool, one Skill, and one real workflow.

## Frequently Asked Questions

**What are Tools in OpenClaw?** Tools are the actions OpenClaw can take, such as reading files, running commands, browsing a site, calling an API, or checking logs.

**What are Skills in OpenClaw?** Skills are reusable instruction packages, typically built around a `SKILL.md` file. They tell OpenClaw how and when to use the available tools for a specific workflow.

**What is MCP in OpenClaw?** MCP is a standard way for OpenClaw to discover and use tools exposed by external systems. OpenClaw can manage outbound MCP connections and can also run as an MCP server for compatible clients.

**Is MCP required to use OpenClaw?** No. You can build useful workflows with local tools and Skills alone. MCP is most useful when you need structured access to a third-party service, internal API, or custom system.

**How do I use MCP safely with OpenClaw?** Use trusted MCP servers, narrowly scoped tokens, read-only access where possible, and approval before every write action.
