Skip to main content
Glama

LobsterMCP

OpenClaw documentation, queryable by AI agents — so Claude Code stops guessing and starts knowing.

Author: Osama · License: MIT · Unofficial community tool, not affiliated with or endorsed by OpenClaw.


What is this?

OpenClaw is an AI agent platform for connecting LLMs to messaging channels, tools, and services. When Claude Code (or any AI agent) works on an OpenClaw project, it needs to look things up constantly: How do I configure a model? What's the JSON5 syntax for provider auth? How do I set up multi-agent routing?

LobsterMCP is an MCP server that puts the full OpenClaw documentation directly in front of your agent — 194 entries across 13 topics, indexed with BM25 search. No web lookups, no hallucinations, no asking the user to go find the docs.


Related MCP server: Swarms MCP Documentation Server

Installation

Option 1 — Claude Code (local build)

git clone https://github.com/osamac2128/lobstermcp
cd lobstermcp
npm install && npm run build
claude mcp add lobster-mcp -s user -- node /absolute/path/to/lobstermcp/dist/index.js

Option 2 — Claude Code settings.json

{
  "mcpServers": {
    "lobster-mcp": {
      "command": "node",
      "args": ["/absolute/path/to/lobstermcp/dist/index.js"]
    }
  }
}

Tools

resolve-topic

Finds the right documentation topic for your query. Call this first.

Input:  { query: "models" }

Output: {
  topics: [{
    topicId: "models",
    name: "Models & Model Selection",
    description: "Configuring primary models, fallbacks, allowlists...",
    entryCount: 5,
    confidence: 1.0,
    relatedTopics: ["providers", "configuration", "agents"]
  }]
}

query-config-docs

Returns full documentation and code examples for your query.

Input:  { query: "set primary model anthropic", topicId: "models" }

Output: Markdown with full docs, config snippets, CLI examples, and source URLs

Topics

Topic ID

Entries

Covers

models

5

Primary model, fallbacks, allowlists, aliases, /model command

providers

18

Anthropic, OpenAI, OpenRouter, Ollama, GLM, GitHub Copilot, and more

configuration

5

openclaw.json config file, JSON5 format, all config keys, config.patch/config.apply

gateway

21

Running the gateway, remote access, pairing, protocol, multiple gateways, ACP bridge

agents

20

Agent runtime, workspaces, AGENTS.md/SOUL.md/TOOLS.md, multi-agent routing

sessions

6

Session keys, compaction, pruning, session store

tools

16

exec, browser, web search, agent-send, slash commands, llm-task, subagents

skills-plugins

10

Creating skills (SKILL.md format), plugin manifest, ClawdHub registry

channels

23

Telegram, Discord, Slack, WhatsApp, Matrix, Signal, iMessage, and more

install

23

Installation, onboarding wizard, Docker, updating, platform guides

concepts

23

Memory, system prompts, context, streaming, queue, retry, usage tracking

security-sandbox

11

Sandboxing, elevated tools, exec approvals, tool policies

debugging

13

openclaw doctor, logs, health checks, FAQ, common issues

13 topics · 194 documentation entries


Example queries

resolve-topic: "how to configure a model"
→ topicId: "models"

query-config-docs: "set primary model anthropic claude", topicId: "models"
→ Full docs on agents.defaults.model.primary, fallbacks, allowlist config

resolve-topic: "anthropic api key"
→ topicId: "providers"

query-config-docs: "anthropic setup-token auth", topicId: "providers"
→ Full docs on setup-token vs API key, onboarding wizard, config snippet

resolve-topic: "run gateway background"
→ topicId: "gateway"

query-config-docs: "multi-agent routing bindings", topicId: "agents"
→ Full docs on agents.list, bindings, agentId, isolated workspaces

Architecture

  • Search — BM25 in-memory search with Porter stemmer and field boosting (title 3×, tags 2×, description 1.5×)

  • Storage — Static JSON files loaded at startup, zero runtime dependencies

  • Transport — MCP stdio transport (works with any MCP-compatible client)

  • Content — Sourced from official OpenClaw documentation

lobstermcp/
├── src/
│   ├── index.ts              # MCP server entry point
│   ├── tools/
│   │   ├── resolve-topic.ts  # Topic resolution tool
│   │   └── query-docs.ts     # Doc search tool
│   ├── search/
│   │   ├── engine.ts         # BM25 search engine
│   │   └── tokenizer.ts      # Porter stemmer tokenizer
│   └── store/
│       ├── index.ts          # DocStore class
│       ├── loader.ts         # Content file loader
│       └── types.ts          # Shared types
├── content/                  # Documentation JSON (13 files + topics.json)
└── scripts/
    └── build-openclaw-content.mjs  # Regenerate content from OpenClaw source

Updating the content

Content is generated from the OpenClaw source docs. To regenerate:

# Requires openclaw source at ../openclaw (relative to this repo)
node scripts/build-openclaw-content.mjs
npm run build

Development

npm install      # Install dependencies
npm run build    # Compile TypeScript
npm run dev      # Watch mode
npm start        # Run server

Requirements

  • Node.js 18+

  • Any MCP-compatible client (Claude Code, Claude Desktop, etc.)


License

MIT — © Osama

Available Tools

2 tools
query-config-docsA

Get detailed OpenClaw documentation and code examples. Use resolve-topic first to find the right topicId, or search directly with a query.

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNoMax results to return (1-10, default 5)
queryYesWhat you want to know (e.g. "how to set primary model", "configure Anthropic API key", "gateway remote setup")
topicIdNoOptional topic ID from resolve-topic to narrow results

TDQS

A4.4/5.0
Behavior3/5

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

No annotations are provided, so the description carries the full behavioral burden. It clearly states that the operation returns documentation and code examples, but it does not disclose result format, pagination, or edge-case behavior. This is adequate for a simple read-only query tool but not rich.

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 tight sentences, with the core purpose front-loaded and usage guidance immediately after. No filler words or redundant restatements of the tool name.

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

Completeness4/5

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

For a simple three-parameter lookup tool, the description plus complete schema coverage is nearly sufficient. It does not explain the return format, but given the low complexity and clear retrieval purpose, this is a minor gap rather than a critical omission.

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?

Schema description coverage is 100%, so the schema already documents each parameter. The description adds value by clarifying the relationship between query and topicId: resolve-topic first or search directly. This improves an agent's understanding beyond the schema alone.

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-resource pair: 'Get detailed OpenClaw documentation and code examples.' It also references the sibling resolve-topic explicitly, making it clear that this tool retrieves documentation while resolve-topic finds topic IDs. This distinguishes it well from the only sibling.

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

Usage Guidelines5/5

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

The second sentence gives explicit workflow guidance: use resolve-topic first to obtain a topicId, or search directly with a query. This tells the agent when to use this tool and how it relates to the alternative, leaving little to inference.

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

resolve-topicA

Find OpenClaw documentation topics matching your query. Returns topic IDs to use with query-config-docs. Topics include: models, providers, configuration, gateway, agents, sessions, tools, skills-plugins, channels, install, concepts, security-sandbox, and debugging.

ParametersJSON Schema
NameRequiredDescriptionDefault
queryYesYour question or topic to look up (e.g. "models", "providers", "gateway", "agents", "configuration")

TDQS

A4.5/5.0
Behavior4/5

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

No annotations are provided, so the description carries full responsibility for explaining behavior. It discloses that the tool performs a lookup, returns topic IDs, and enumerates the known topic surface. It does not describe no-match behavior, but for a simple query-to-ID resolver this is a minor gap rather than a major omission.

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

Conciseness5/5

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

The description is two sentences with no filler. It front-loads the action and result, then provides a compact but useful enumeration of supported topics. Every sentence contributes to correct invocation.

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 one simple string parameter, no output schema, and a single sibling tool, the description covers what the agent needs: what the tool does, what it returns, the accepted topic space, and how the result connects to query-config-docs. Nothing essential is missing.

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?

Schema description coverage is 100%, giving the baseline of 3. The description adds value beyond the schema by listing valid topic names and explaining that the query resolves into an ID for downstream use, which meaningfully clarifies what to pass in the 'query' parameter.

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 ('Find'), names the resource ('OpenClaw documentation topics'), and states the concrete output ('topic IDs to use with query-config-docs'). This clearly separates resolve-topic from its sibling: it produces IDs, while the sibling presumably consumes them.

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 makes the workflow clear: use this tool to get topic IDs, then pass them to query-config-docs. It does not explicitly list exclusion criteria (e.g., 'do not use if you already have a topic ID'), but the stated purpose gives an agent enough context to choose it appropriately.

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.

  1. 2 tool updatesv0.1.0
    • First observedquery-config-docs
    • First observedresolve-topic

TDQS

A4.4/5.0

Scored across 2 tools

Disambiguation5/5

The two tools have clearly distinct purposes: resolve-topic finds topic IDs, and query-config-docs retrieves detailed documentation. Though query-config-docs can also search directly, the workflow is still unambiguous and each tool's role is well-defined.

Naming Consistency5/5

Both tool names follow the same verb-noun pattern using hyphens: resolve-topic and query-config-docs. This is consistent and readable, with a clear action-then-object structure.

Tool Count3/5

With only two tools, the server feels minimal but not unreasonable for a focused documentation lookup scope. It sits at the thin end of the scale, barely maintaining a meaningful surface.

Completeness3/5

The tools cover topic discovery and content retrieval, but there is no way to list all available topics or navigate documentation structure beyond keyword matching. The direct search capability mitigates the gap, but some exploration workflows remain unsupported.

Maintenance

ActivityInactive
ResponsivenessNo issues

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/osamac2128/lobstermcp'

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