How do I use OpenClaw MCP Server?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@OpenClaw MCP Server Get my RMappi balance" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

OpenClaw MCP Server

by kiuru

Overview Schema Related Servers Score Discussions

TypeScript

Local

OpenClaw MCP Server

General TypeScript MCP server for OpenClaw tools.

The server is organized around toolsets so new OpenClaw capabilities can be added without recreating MCP startup, transport, and registration boilerplate.

Structure

src/
  index.ts              # transport startup
  server.ts             # MCP server factory
  toolsets/
    index.ts            # registers all toolsets
    toolset.ts          # shared toolset interface
    core.ts             # base server introspection tools

Related MCP server: Angular Bootstrap MCP Server

Install

npm install

Build

npm run build

Run

npm start

The server only supports stdio transport and is intended for local MCP clients that spawn the server process.

Deploy as a STDIO MCP Server

This server is deployed by installing dependencies, building the TypeScript output, and configuring an MCP client to spawn the built stdio entry point.

From the repository directory:

npm install
npm run build

Use node with the absolute path to dist/index.js as the MCP server command. Example client configuration:

{
  "mcpServers": {
    "openclaw": {
      "command": "node",
      "args": [
        "C:\\Projects\\openclaw-mcp-tools\\dist\\index.js"
      ],
      "env": {
        "ENV_RMAPPI_USER": "email@example.com",
        "ENV_RMAPPI_PASSWORD": "password"
      }
    }
  }
}

For a cloned checkout in a different location, replace the args path with that checkout's absolute dist/index.js path.

For macOS or Linux, the same configuration uses a POSIX path:

{
  "mcpServers": {
    "openclaw": {
      "command": "node",
      "args": [
        "/absolute/path/to/openclaw-mcp-tools/dist/index.js"
      ],
      "env": {
        "ENV_RMAPPI_USER": "email@example.com",
        "ENV_RMAPPI_PASSWORD": "password"
      }
    }
  }
}

If using the RMappi/Osuria tools on a fresh machine, also install the Chromium browser binary once:

npx playwright install chromium

After changing TypeScript files, run npm run build again before restarting the MCP client. The client owns the server process lifecycle; stop and restart the MCP client to pick up a new build or environment variable changes.

Inspect

Build first, then run the MCP Inspector against the stdio entry point:

npm run build
npm run inspect

Equivalent direct command:

npx @modelcontextprotocol/inspector node dist/index.js

Use dist/index.js, not dist/server.js. The server.js file only exports the MCP server factory and does not connect a stdio transport.

Adding Toolsets

Create a new file in src/toolsets/:

import type { Toolset } from "./toolset.js";

export const myToolset: Toolset = {
  name: "my-toolset",
  description: "Tools for a focused OpenClaw capability.",
  register(server) {
    server.registerTool(
      "openclaw_my_action",
      {
        title: "My Action",
        description: "Does one focused OpenClaw action.",
        inputSchema: {},
        annotations: {
          readOnlyHint: true,
          destructiveHint: false,
          idempotentHint: true,
          openWorldHint: false
        }
      },
      async () => ({
        content: [{ type: "text", text: "ok" }]
      })
    );
  }
};

Then add it to src/toolsets/index.ts.

Tool names should use the openclaw_ prefix and snake_case verbs, for example openclaw_list_projects or openclaw_create_job.

RMappi/Osuria Balance Tool

Tool: openclaw_get_rmappi_balance

Use this tool when the user asks for RMappi/Osuria saldo, bank balance, available funds, or taloyhtion tilin saldo.

Required environment variables:

$env:ENV_RMAPPI_USER = "email@example.com"
$env:ENV_RMAPPI_PASSWORD = "password"

Temporary compatibility fallback:

$env:ENV_RMAPPI__PASSWORD = "password"

The tool does not accept credentials as MCP arguments. It opens https://app.osuria.com, accepts the cookie dialog if present, logs in, navigates to /balance, reads account cards by visible labels, logs out, and closes the browser.

If Playwright browser binaries are not installed yet, run:

npx playwright install chromium

RMappi/Osuria Invoices Tool

Tool: openclaw_get_rmappi_invoices

Use this tool when the user asks for RMappi/Osuria invoices, laskut, voucher numbers, invoice totals, or invoices for a specific month.

Inputs:

{
  "year": 2026,
  "month": 6
}

Both fields are optional. If omitted, the tool uses the current local year and month.

The tool uses the same ENV_RMAPPI_USER and ENV_RMAPPI_PASSWORD credentials as the balance tool. After login it reads sessionStorage["x-session-token"], calls the RMappi invoices API with that token, returns the API JSON array, logs out, and closes the browser. The token is never returned in tool output.

Available Tools

3 tools

openclaw_get_rmappi_balanceGet RMappi BalanceA

Read-only

Use this tool when the user asks for RMappi/Osuria saldo, bank balance, available funds, or taloyhtion tilin saldo. It logs in to https://app.osuria.com with environment credentials, reads the Balance page account cards, logs out, and closes the browser session. Credentials are read only from ENV_RMAPPI_USER and ENV_RMAPPI_PASSWORD, with temporary fallback ENV_RMAPPI__PASSWORD.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`accounts`	Yes

TDQS

A4.7/5.0

Behavior5/5

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

The description goes beyond annotations by detailing the login process, reading the balance page, logging out, and closing the browser. It specifies credentials are read from environment variables with a fallback. This adds significant behavioral context beyond readOnlyHint and destructiveHint.

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, well-structured paragraph. It front-loads the use case, then concisely explains the process and credential source. No extraneous information is present.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

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

Given the tool has no parameters and an output schema exists, the description covers all necessary context: when to use, what it does, and how credentials are handled. It is complete for the tool's simplicity.

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?

There are zero parameters, so the schema covers everything. With no parameters, a baseline of 4 is appropriate; the description adds no parameter-specific detail because none is needed.

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

Purpose5/5

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

The description explicitly states the tool is for when the user asks for 'RMappi/Osuria saldo, bank balance, available funds, or taloyhtion tilin saldo', clearly identifying the verb (get balance) and resource (RMappi/Osuria). It distinguishes from sibling tools (invoices, server info) by its specific use case.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear guidance on when to use the tool ('when the user asks for...'). It doesn't explicitly state when not to use, but the context of siblings and the specific query terms imply appropriate usage. The credential fallback note is additional useful context.

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

openclaw_get_rmappi_invoicesGet RMappi InvoicesA

Read-only

Use this tool when the user asks for RMappi/Osuria invoices, laskut, voucher numbers, invoice totals, or invoices for a specific month. It logs in to https://app.osuria.com with environment credentials, reads x-session-token from sessionStorage after login, calls the RMappi invoices API for the requested year and month, logs out, and closes the browser session. The access token is used only inside the automation and is never returned.

ParametersJSON Schema

Name	Required	Description	Default
`year`	No	Four-digit year. If omitted, the current local year is used unless the user clearly means another year.
`month`	No	Month number from 1 to 12. If omitted, the current local month is used unless the user clearly means another month.

Output Schema

ParametersJSON Schema

Name	Required	Description
`invoices`	Yes

TDQS

A4.5/5.0

Behavior5/5

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

The description discloses the full automation flow: login to app.osuria.com, session token retrieval, API call, logout, and browser closure. It also clarifies that the access token is never returned. This adds significant value beyond the readOnlyHint and destructiveHint annotations.

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 structured logically: first a usage summary, then step-by-step details. Each sentence adds necessary information without redundancy. It could be slightly more concise but is efficient for a tool with automation steps.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

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

Given the presence of an output schema, the description does not need to detail return values. It covers authentication, defaults, and the overall process. The only minor gap is error handling (e.g., login failure), but the description remains adequately complete for its intended use.

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?

Both parameters are fully covered in the schema. The description adds useful context about default behavior (current local year/month) and how to interpret when omitted. This clarifies ambiguity beyond the schema descriptions.

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 specifies the tool is for retrieving RMappi/Osuria invoices, including related terms like 'laskut', 'voucher numbers', and 'invoice totals'. It distinguishes from siblings by naming the tool and its resource, and the sibling tools have different purposes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear usage context: 'Use this tool when the user asks for RMappi/Osuria invoices...' and gives specific queries. It does not explicitly state when not to use it or name alternatives, but the context is sufficiently directive given the sibling tools.

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

openclaw_server_infoOpenClaw Server InfoA

Read-onlyIdempotent

Returns basic information about the OpenClaw MCP server and the registered toolsets. This tool is read-only and does not call external services.

ParametersJSON Schema

Name	Required	Description	Default
`response_format`	No	Output format: 'markdown' for human-readable or 'json' for structured data	markdown

Output Schema

ParametersJSON Schema

Name	Required	Description
`name`	Yes
`version`	Yes
`toolsets`	Yes

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint. The description adds that it does not call external services, enhancing transparency beyond the structured fields.

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

Conciseness5/5

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

Two short sentences with no wasted words. First sentence states purpose, second adds safety context. Highly concise and front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

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

For a simple informational tool with full annotations and output schema, the description covers all necessary aspects: what it returns, that it's read-only, and that it doesn't call external services. No gaps.

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 single parameter 'response_format' is fully described in the schema with enum and description. The tool description does not add extra meaning, 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?

Description clearly states it returns basic information about the OpenClaw MCP server and registered toolsets. It is distinct from siblings which deal with specific RMAPPI data, making the purpose unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

While it implies usage for server info and notes read-only nature and no external calls, it does not explicitly contrast with siblings or provide when-not-to-use instructions. Still, the context is clear.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

3 tool updatesv0.1.0Jun 28, 2026
- First observedopenclaw_get_rmappi_balance
- First observedopenclaw_get_rmappi_invoices
- First observedopenclaw_server_info

Install Server

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

TDQS

A4.2/5.0

Disambiguation5/5

Each tool has a distinct purpose: balance retrieval, invoice retrieval, and server info. The two RMappi tools are clearly differentiated by their function (balance vs invoices), and the third is entirely separate. No ambiguity.

Naming Consistency5/5

All tools follow a consistent naming pattern: 'openclaw_' + verb_noun (get_rmappi_balance, get_rmappi_invoices, server_info). The pattern is uniform and predictable.

Tool Count3/5

With only 3 tools, the server feels minimal. While it covers balance and invoices for RMappi, the scope is narrow. The count is acceptable for a focused utility but could be expanded.

Completeness2/5

The domain appears to be RMappi/Osuria financial operations, but only balance and invoices are covered. Missing common operations like listing accounts, transaction history, or payments leaves significant gaps.

Maintenance

ActivityStale

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

smithery-ai-cookbook-ts-smithery-cli
ai.smithery
A simple Typescript MCP server built using the official MCP Typescript SDK and smithery/cli. This…
Developer Tools
213
hostinger-api-mcpOAuth
io.github.hostinger
MCP server for Hostinger API
Cloud Platforms Developer Tools
1150
mcp AOAuth
com.mux
The official MCP Server for the Mux API
Multimedia Processing Entertainment & Media API Testing
22168
MCP Billing Gateway A
io.github.sapph1re
Billing proxy for MCP servers. Adds Stripe and x402 crypto payments without writing billing code.
Payments & Billing
1211

Related MCP Servers

mcp-rest-api
API Testing Developer Tools
dkmaker
A
license
A
quality
F
maintenance
A TypeScript-based MCP server that enables testing of REST APIs through Cline. This tool allows you to test and interact with any REST API endpoints directly from your development environment.
Updated 5 months ago (2026-04-06 22:25 UTC)
1
93
101
MIT
Angular Bootstrap MCP Server
Developer Tools API Testing Databases
palsuman
A
license
Not graded
quality
D
maintenance
A TypeScript-based MCP server that provides backend API handling and facilitates communication between microservices. Features an organized structure with controllers, routes, and models for easy extensibility and maintenance.
Updated a year ago (2025-08-09 11:14 UTC)
225
1
MIT
MCP Server TypeScript Template
Code Execution Developer Tools
HarshitRatan
F
license
Not graded
quality
D
maintenance
A demonstration MCP server built in TypeScript that shows how to implement stdio-based communication for integration with MCP clients. Serves as a template for building custom MCP servers with strong typing and maintainability.
Updated a year ago (2025-08-18 07:05 UTC)
-
MCP API Server
Weather Services Developer Tools
mcgiverdev
F
license
C
quality
D
maintenance
A modular MCP server that connects to external APIs, providing tools for weather data, user management, and company operations. Features a scalable architecture with TypeScript support, HTTP client abstraction, and robust error handling.
Updated a year ago (2025-08-19 00:33 UTC)
5
-

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/kiuru/openclaw-mcp-tools'

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