LobsterMCP
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@LobsterMCPhow do I configure the primary model?"
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.
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.jsOption 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 URLsTopics
Topic ID | Entries | Covers |
| 5 | Primary model, fallbacks, allowlists, aliases, |
| 18 | Anthropic, OpenAI, OpenRouter, Ollama, GLM, GitHub Copilot, and more |
| 5 |
|
| 21 | Running the gateway, remote access, pairing, protocol, multiple gateways, ACP bridge |
| 20 | Agent runtime, workspaces, |
| 6 | Session keys, compaction, pruning, session store |
| 16 | exec, browser, web search, agent-send, slash commands, llm-task, subagents |
| 10 | Creating skills ( |
| 23 | Telegram, Discord, Slack, WhatsApp, Matrix, Signal, iMessage, and more |
| 23 | Installation, onboarding wizard, Docker, updating, platform guides |
| 23 | Memory, system prompts, context, streaming, queue, retry, usage tracking |
| 11 | Sandboxing, elevated tools, exec approvals, tool policies |
| 13 |
|
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 workspacesArchitecture
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 sourceUpdating 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 buildDevelopment
npm install # Install dependencies
npm run build # Compile TypeScript
npm run dev # Watch mode
npm start # Run serverRequirements
Node.js 18+
Any MCP-compatible client (Claude Code, Claude Desktop, etc.)
License
MIT — © Osama
Available Tools
2 toolsquery-config-docsA
Get detailed OpenClaw documentation and code examples. Use resolve-topic first to find the right topicId, or search directly with a query.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results to return (1-10, default 5) | |
| query | Yes | What you want to know (e.g. "how to set primary model", "configure Anthropic API key", "gateway remote setup") | |
| topicId | No | Optional topic ID from resolve-topic to narrow results |
TDQS
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.
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.
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.
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.
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.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Your question or topic to look up (e.g. "models", "providers", "gateway", "agents", "configuration") |
TDQS
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.
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.
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.
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.
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.
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.
2 tool updates
v0.1.0- First observed
query-config-docs - First observed
resolve-topic
TDQS
Scored across 2 tools
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.
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.
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.
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
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
MCP server for agentverse documentation, generated by doc2mcp.
DocBase MCP server for AI agents
The Needle MCP server enables semantic search on documents stored in files like PDFs, DOCX, and XLSX by connecting AI applications to external data sources. It provides capabilities to create and manage document collections, perform natural language searches on stored content, and retrieve relevant information without requiring exact keyword matches.
Driflyte MCP server which lets AI assistants query topic-specific knowledge from web and GitHub.
Related MCP Servers
- FlicenseAqualityDmaintenanceA server that enables Claude to search and access documentation from popular libraries like LangChain, LlamaIndex, and OpenAI directly within conversations.13-
- FlicenseNot gradedqualityDmaintenanceAn Agent Framework Documentation server that enables AI agents to efficiently retrieve information from documentation databases using hybrid semantic and keyword search for seamless agent integration.-
- AlicenseAqualityAmaintenanceMCP server that gives AI coding agents on-demand access to private project docs via BM25 ranked search. One setup for Claude Code, Cursor, Codex, Gemini CLI, and more. Docs stay private, never in public repos.1515Apache 2.0
- FlicenseNot gradedqualityCmaintenanceAn offline MCP server that provides LangChain and LangGraph documentation search via BM25 full-text search, enabling drop-in replacement for cloud-hosted docs in airgapped environments.-
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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