Files
LangBot/en/usage/mcp
99185d0b1d Feat/sandbox (#94)
* docs: add sandbox documentation for all languages

Add comprehensive documentation for the code sandbox feature:
- Overview, built-in tools, scope and lifecycle
- Backend configuration (Docker/Nsjail/E2B)
- Security profiles (default/offline_readonly/network_basic/network_extended)
- Complete configuration reference

Languages: zh, en, ja

* docs: add skills documentation for all languages

Add comprehensive Skills system documentation covering:
- Design philosophy and industry practices comparison (Claude Code, OpenAI GPTs, Cursor)
- Layered architecture (management, import, execution layers)
- Current activation mechanism ([ACTIVATE_SKILL:] marker) with TODO for future Tool Call optimization
- Agent Skills open standard compliance with field specifications
- Complete tools API reference

Languages: zh, en, ja

Co-Authored-By: Claude Opus 4.7 <[email protected]>

* docs: update sandbox documentation to include new tools and configuration options

* Refactor Skills API documentation to align with Tool Call mechanism

- Updated the overview of the Skills system to emphasize the Tool Call mechanism for activating and registering skills.
- Removed deprecated tools and consolidated functionality into `activate` and `register_skill`.
- Revised usage examples and parameters for the new tools, ensuring clarity on their requirements and expected responses.
- Enhanced descriptions of the activation process, including the injection of skill instructions and mounting of skill packages.
- Improved error handling documentation for better user guidance.
- Added notes on sandbox requirements for tool usage and the creation of new skills.

* docs: align sandbox runtime guides

* docs: align sandbox & skills guides with current Box implementation

Correct five inaccuracies across the zh/en/ja sandbox and skills docs so
they match the actual code:

- Box launch command: use the lbp CLI subcommand
  (`langbot_plugin.cli.__init__ box`) instead of the removed
  `langbot_plugin.box --mode ws`.
- Environment variables: replace the obsolete `LANGBOT_BOX_LOCAL_*`
  vars with the unified `SECTION__SUBSECTION__KEY` override convention
  (`BOX__LOCAL__*`); note that the langbot_box service reads no
  config.yaml/env and is configured by LangBot over INIT RPC.
- Skills: drop the stale "falls back to data/skills" claims — the Box
  Runtime is the sole source of skills; when Box is unavailable the
  skill list is simply empty.
- Document the new `box.enabled` master switch (default true) and what
  it gates.
- Document that the langbot_box compose service is optional, gated
  behind the `box`/`all` compose profile.

* docs: align sandbox docs with implementation

* docs: simplify sandbox naming and diagrams

* docs: shorten AI capability nav labels

* docs: merge sandbox configuration pages

* docs: document BOX__BACKEND as sole backend selector

* docs: recommend all profile for docker deploy

* docs: add docker permission fix for sandbox

* chore(skills): add obra/superpowers writing-skills

Install the writing-skills skill from obra/superpowers via
`npx skills add`. Lands the skill files under .agents/skills/
(universal layout) with a Claude Code symlink at .claude/skills/
and the pin in skills-lock.json.

Also gitignore .claude/settings.local.json since it's per-user
Claude Code state (skill symlinks under .claude/skills/ remain
tracked).

* docs(sandbox,skills): tighten user guides for onboarding

Rewrite the sandbox and skills user guides to be shorter, plainer, and
focused on getting users productive instead of explaining internals.

Changes per page (zh/en/ja kept in lockstep):

- sandbox/readme: 170 → 73 lines. Drop the "what is a sandbox" essay,
  decorative mermaid, and the backend table that already lives in
  config.mdx. Lead with the six built-in tools and the scope picker
  (the parts users actually configure).
- sandbox/runtime-relationships: 75 → 54 lines. Replace the runtime
  prose with a single comparison table; tighten the troubleshooting
  entry-points.
- skills/readme: 320 → 114 lines. Cut the "design philosophy" /
  "industry comparison" / "KV cache theory" sections — those are
  implementation details users don't need to ship. Lead with the
  user-visible flow (Agent reads <available_skills> → calls activate →
  follows the SKILL.md).
- skills/skill-format: 360 → 134 lines. One excellent example
  (api-tester) instead of three overlapping ones. Drop the standalone
  "field details" subsections that just restate the table.
- skills/tools-api: 200 → 122 lines. Drop the old-vs-new historical
  comparison and the duplicated activation section; keep the two tool
  signatures, parameters, returns and errors.

sandbox/config.mdx left untouched (already condensed upstream).

Principles applied come from obra/superpowers writing-skills (installed
in 08c35a4): lead with use, one excellent example, tables for scanning,
cut internals and history.

* docs(sandbox): drop redundant 'how to choose' table from runtime-relationships

The 对照表 above already has a '何时使用 / When to use' column that says
the same thing. Repeating it as a second 怎么选 / How to Choose table
was pure noise.

* docs(skills): collapse to one page, link out for SKILL.md spec

Delete skill-format.mdx and tools-api.mdx — Skills now has a single
page. The format details and tools reference were already covered in
shorter form inside readme.mdx; the separate pages were repetition.

In readme.mdx:
- Inline a compact 'SKILL.md format' section (one example + a three-
  field table) and point at agentskills.io for the canonical spec.
- Drop the 'next steps' section and the tools-api link, since both
  destinations no longer exist.

docs.json: remove the two pages from each locale's Skills nav. Add
redirects from the old paths to readme so existing links don't 404.

* docs(nav): flatten Skills — single page, no group wrapper

Group with one child is just visual noise in the sidebar. Replace
{ group: Skills, pages: [...readme] } with the readme path directly
in the parent AI Configuration group, in all three locales.

* docs(mcp,skills): lead with LangBot Space as the preferred install path

LangBot Space (https://space.langbot.app) now hosts a curated list of
MCP servers and Skills. Surface that as the first install option in
both user guides.

- usage/mcp/readme: rework the intro Info block to recommend LangBot
  Space first (third-party channels demoted to "alternative source").
  Add a "Install from LangBot Space (Preferred)" section above the
  existing manual flow; rename that flow to "Add MCP Server Manually".
- usage/skills/readme: add a "Install from LangBot Space (Preferred)"
  section above "Creating a Skill"; rename the existing section to
  "Creating a Custom Skill" so the contrast is clear.

zh/en/ja kept in sync.

* docs(skills): reorganize the readme around the user journey

The old structure interleaved "what it is" → "how it works internally"
→ "prerequisites" → "format spec" → install options. Reorder around
how users actually approach the page:

  Intro → compare with plugins/MCP → install → enable → write → debug

Specific moves:
- Drop the standalone "Workflow" flow diagram; fold the one important
  point (activation pulls SKILL.md via Tool Result) into the intro.
- Merge the standalone "Prerequisites" section into a short Note on the
  Install heading — that's where the constraint actually applies.
- Bring "Install from LangBot Space" and "Create your own" together
  under one "Install" H2 with H3 subsections; they were sibling H2s
  before, which buried the relationship.
- Move "Writing a SKILL.md" after install + enable, since most users
  start with marketplace skills.
- Demote the "Tools the Agent sees" table to an H3 inside the writing
  section — it's reference, not a top-level concern.

114 → 100 lines, zh/en/ja in lockstep.

* docs(mcp,models): reorder MCP page + move tool-use capability to Models

Two related changes, same as the Skills cleanup pattern:

usage/mcp/readme — reorganize around the user journey
- Drop the standalone "Enable function calling on the model" section;
  that belongs in the Models doc (it's not MCP-specific — sandbox tools
  and Skills depend on the same model capability).
- Drop the redundant "Effect" section — its one fact (built-in Agent +
  tool-use model) already lives in the Note under "Three Transport
  Modes".
- Group install paths under one "Installing an MCP Server" H2 with
  Space (preferred) and manual flows as H3 siblings, mirroring the
  Skills doc layout.
- Move the stdio MCP technical block under a clearly-labeled
  "Advanced: stdio MCP" H2 so casual readers skim past it.
- Trim screenshot duplication and collapse three steps in the manual
  flow into one paragraph + one screenshot per step.
- 140 → 107 lines, zh/en/ja kept in lockstep.

usage/models/readme — rename and expand "function calling" → "tool use"
- The checkbox is renamed to "Tool Use" (zh: 工具使用能力 / ja: ツール
  使用); function calling kept in parentheses for recognition.
- Expand the bullet into a Note that explicitly lists where the
  capability matters: MCP servers, sandbox built-ins (exec/read/write/
  edit/glob/grep), Skills. Without it, even bound extensions stay
  silent.
- Note that the underlying model must actually support function
  calling for the checkbox to take effect.

* docs(sandbox): point sandbox/config readers to System Environment Settings

The page lists box.* YAML blocks without ever telling the reader where
those settings actually go. Add a one-line Note at the top linking to
deploy/settings (System Environment Settings), where the data/config.yaml
location and load mechanism are documented.

* docs(sandbox/config): align the page with the real config structure

The previous version listed local / docker / nsjail / e2b as four
parallel "backends" in one flat table. That's wrong: looking at the
config template and the SDK's _select_backend, the real model is:

- box.backend accepts 'local' | 'docker' | 'nsjail' | 'e2b'
- 'local' is shorthand for "auto-pick from Docker / Nsjail" — not a
  fourth backend
- 'local', 'docker', 'nsjail' all *share* the box.local.* config
  section; the section is misleadingly named ("local" here means
  "host-local backends", not "for backend: 'local'")
- 'e2b' uses box.e2b.* instead
- 'local' is the only value that auto-falls-back; everything else is a
  hard selection

Rewrite the page around that structure:
- Group backends as "local containers" vs "cloud" with the four values
  inside, and call out the local-vs-fourth-backend distinction.
- Split the old single "common settings" table into two clearly-scoped
  tables: box.local.* (for local backends) and box.e2b.* (for cloud).
- Move box.runtime.endpoint into the Docker Compose section, where it
  actually matters.
- Add an explicit note that backend is a hard selection — only 'local'
  fans out.

zh/en/ja kept in lockstep.

* docs(deploy): note Box control-plane transport differs by deploy method

In Docker deployments the Box control plane runs as the langbot_box
container (WebSocket); manual / uvx deployments use a stdio subprocess.
Also clarify the LangBot image bundles the docker client so langbot_box
can create sandbox containers via the mounted socket without extra setup.
zh / en / ja.

---------

Co-authored-by: Claude Opus 4.7 <[email protected]>
Co-authored-by: Junyan Qin <[email protected]>
2026-06-04 20:18:29 +08:00
..
2026-06-04 20:18:29 +08:00

---
title: "MCP Server"
---

LangBot can call tools from MCP servers. Once an MCP server is added, the built-in Agent — with tool use enabled on its model — can invoke those tools during a conversation.

<Info title="MCP supports Streamable HTTP, SSE, and stdio modes.">
  Install from [LangBot Space](https://space.langbot.app) for the smoothest setup — listed MCPs are pre-configured and ready to use.

  You can also fetch from [ModelScope](https://modelscope.cn/mcp), [mcp.so](https://mcp.so), or [composio.dev](https://composio.dev/toolkits), then add them manually as shown below.
</Info>

## Three Transport Modes

| Mode | When to use | Notes |
|------|-------------|-------|
| Streamable HTTP (`mode: "http"`) | Remote MCP service that speaks Streamable HTTP | LangBot connects to the remote URL directly |
| SSE | Remote MCP service that speaks SSE | LangBot connects to the remote URL directly |
| stdio | MCP server launched by a local command | Only available when Box Runtime is up |

<Note>
MCP tools require the pipeline to use the **built-in Agent**, with a model that has **tool use enabled** — see [Models](../models/readme). External runners (Dify, n8n, Langflow, Coze, etc.) use their own tool mechanisms.
</Note>

## Installing an MCP Server

### From LangBot Space (Preferred)

[LangBot Space](https://space.langbot.app) is the official LangBot marketplace, with a curated list of ready-to-use MCP servers. In the WebUI, browse and install them with one click under `Plugin Management` → `MCP Management` — URL, command, and mode are filled in by the listing, so nothing has to be configured by hand.

This covers most cases. For services that aren't listed, use the manual flow below.

### Adding Manually

Open `Plugin Management` → `MCP Management`:

<img width="1000px" src="/images/zh/deploy/mcp/mcp02.png" alt="MCP management page" />

Click `Add` in the top right, choose `Add MCP Server`, fill in the URL (HTTP/SSE) or command (stdio), click `Test` to verify connectivity, then `Submit`:

<img width="400px" src="/images/zh/deploy/mcp/mcp03.png" alt="create new MCP server" />

After saving, toggle the switch on the card to connect. Click the card to see details:

<img width="400px" src="/images/zh/deploy/mcp/mcp05.png" alt="MCP server detail" />

## Enabling in a Pipeline

Once an MCP server is added, the pipeline extension config decides which servers the Agent can see:

- Enable "all MCP servers", or
- Bind only specific MCP servers

Tools from unbound servers won't appear in that pipeline's tool list.

## Advanced: stdio MCP

stdio MCP is hosted by Box Runtime. Before the connection is ready, LangBot:

1. Creates or reuses a shared MCP Box session
2. If a local project path can be inferred from the command, stages the project into the workspace
3. Installs dependencies if the project has `requirements.txt`, `pyproject.toml`, `setup.py`, or `setup.cfg`
4. Connects the MCP process's stdin/stdout through a WebSocket relay

To fine-tune mount, network, or timeout behavior, add a `box` override under the MCP `extra_args`:

```json
{
  "mode": "stdio",
  "extra_args": {
    "command": "python",
    "args": ["server.py"],
    "env": {},
    "box": {
      "host_path": "/path/to/mcp-project",
      "network": "on",
      "host_path_mode": "ro",
      "startup_timeout_sec": 120,
      "image": "python:3.11-slim"
    }
  }
}
```

Common fields:

| Field | Notes |
|-------|-------|
| `host_path` | MCP project directory on the host. Must be within `box.local.allowed_mount_roots` |
| `network` | Whether network is allowed (typically for dependency install) |
| `host_path_mode` | Access mode when staging `host_path`; defaults to `ro`. stdio MCP usually stages into the workspace |
| `startup_timeout_sec` | Box prep + dependency install timeout, default 120s. Connection wait gets about 30s extra |
| `image` | Runtime image when the Docker backend is used |

<Warning>
stdio MCP runs inside Box. Dependency install and process startup are subject to the sandbox profile, network permission, resource limits, and the mount allowlist.
</Warning>

## Common Issues

| Symptom | What to check |
|---------|---------------|
| MCP connection fails | URL, command, arguments, env vars are correct |
| stdio MCP stuck connecting | Box Runtime status; `startup_timeout_sec` may be too short |
| Dependency install fails | Sandbox network permission; dependency files are correct |
| Local files inaccessible | `host_path` exists; it's inside `allowed_mount_roots` |
| Agent doesn't see MCP tools | Pipeline uses built-in Agent; model has tool use enabled; MCP is bound on the pipeline |