mcp-store

mcp-store

Aggregates multiple MCP servers and custom Python tools behind a single endpoint, with intelligent context and tool discovery for AI agents.

Category
访问服务器

README

mcp-store

One MCP endpoint for all your agents' tools. mcp-store is a gateway that aggregates any number of existing MCP servers and your own Python tools behind a single connection — with a context layer that tells agents what's available and when to use it.

Three ways to put a tool on it:

  • Route an existing MCP server — paste its standard mcpServers JSON snippet into config.json. stdio, Streamable HTTP, and legacy SSE upstreams all work, and you can rename, redescribe, or hide their tools at the gateway without touching the upstream.
  • Write your own MCP in Python — one folder under plugins/ is one MCP. Drop in @tool functions (zero boilerplate) or a full FastMCP sub-server; the folder name becomes the tool namespace. mcp-store new-plugin <name> scaffolds a working one.
  • Ship it with the gateway — built-in tools like echo and catalog live in the codebase itself.

Agents connect once and get everything, namespaced by source (fs_read_file, weather_get_forecast), described by an auto-generated routing map, and — for large catalogs — discoverable through an opt-in search interface instead of a context-crushing tool list.

How it works

%%{init: {"flowchart": {"curve": "basis"}}}%%
flowchart TB
    INF["Infisical<br/>secret store"]
    A1["Claude Code"]
    A2["OpenClaw agents"]
    A3["any MCP client"]

    subgraph gw["mcp-store gateway — one process"]
        direction TB
        EP["<b>one MCP endpoint</b><br/>Streamable HTTP<br/>:8000/mcp/ · stdio"]

        PRES["<b>what agents see</b><br/>curation — rename · hide<br/>context — instructions<br/>catalog · opt-in search"]

        BI["<b>built-ins</b><br/>echo · catalog<br/><i>ship with the gateway</i>"]
        PL["<b>plugins — your Python</b><br/>one folder = one MCP<br/>weather/ → weather_*<br/><i>drop a folder · restart</i>"]
        PX["<b>upstream proxies</b><br/>fs_* · gh_* from config.json<br/><i>paste any mcpServers entry</i>"]

        EP --> PRES
        PRES --> BI
        PRES --> PL
        PRES --> PX
    end

    A1 --> EP
    A2 -->|"one connection each"| EP
    A3 --> EP

    INF -. "secrets → env at runtime<br/>never in repo or image" .-> gw

    U1["npx MCP server<br/>stdio subprocess"]
    U2["remote MCP server<br/>Streamable HTTP"]
    U3["legacy MCP server<br/>SSE"]

    PX --> U1
    PX --> U2
    PX --> U3

    %% theme-safe styling: explicit fills + dark text on nodes; the one
    %% cluster stays transparent so its title keeps GitHub's light/dark contrast
    classDef client fill:#dbeafe,stroke:#60a5fa,color:#0f172a
    classDef endpoint fill:#ede9fe,stroke:#8b5cf6,stroke-width:2px,color:#0f172a
    classDef shaping fill:#fef3c7,stroke:#f59e0b,color:#0f172a
    classDef builtin fill:#f1f5f9,stroke:#94a3b8,color:#0f172a
    classDef plugin fill:#dcfce7,stroke:#22c55e,stroke-width:2px,color:#0f172a
    classDef proxy fill:#ccfbf1,stroke:#14b8a6,color:#0f172a
    classDef upstream fill:#f8fafc,stroke:#cbd5e1,color:#334155
    classDef secret fill:#ffe4e6,stroke:#f43f5e,color:#0f172a

    class A1,A2,A3 client
    class EP endpoint
    class PRES shaping
    class BI builtin
    class PL plugin
    class PX proxy
    class U1,U2,U3 upstream
    class INF secret

    style gw fill:transparent,stroke:#8b5cf6,stroke-width:2px

    %% secrets edge red; proxy→upstream edges teal to tie them to their tile
    linkStyle 7 stroke:#f43f5e
    linkStyle 8,9,10 stroke:#14b8a6,stroke-width:2px

Reading it top to bottom, the way a call flows: agents hold one connection each to the endpoint; the presentation layer decides what they see (curation reshapes tools, the context layer explains them); below it sit the three tool sources. Green is where your code goes. The purple border is the process boundary — plugins run inside it with full privileges, while the teal arrows are the proxies' live sessions out to upstream servers running in their own processes. The dashed red edge is the only way secrets enter: injected into the environment at runtime, never committed, never baked into the image.

A request flows agent → endpoint → transforms (curation, optional tool search) → the owning source: built-in and plugin tools execute in-process; upstream tools route through a live proxy to the real server. Secrets never live in the repo or the image — Infisical injects them into the environment at runtime, and config.json carries only ${VAR} references.

Built on FastMCP 3. The design bias throughout is adopt, don't build — proxying, mounting, transforms, and directory loading are framework primitives, composed rather than reimplemented.

Quickstart

uv sync
cp config.example.json config.json       # edit to taste
uv run mcp-store serve --config config.json

The gateway is now serving at http://127.0.0.1:8000/mcp/. Point an agent at it:

claude mcp add --transport http mcp-store http://127.0.0.1:8000/mcp/

See what it exposes, or run the preflight:

uv run mcp-store tools --config config.json
uv run mcp-store doctor --config config.json

Documentation

Full documentation lives in docs/.

🤖 AI agents: follow docs/AGENTGUIDE.md — a task-router with exact recipes and verification steps for working on this repo. Humans: start with the guides below.

Guide What it covers
Getting started Install, first run, connecting agents, your first plugin
Configuration reference Every config key, default, and failure behaviour
Routing upstream servers Adding existing MCP servers and curating their tools
Writing your own MCP The folder-per-MCP plugin model, manifest, trust model
The context layer Instructions, the catalog tool, tool search
Secrets The Infisical model — runtime injection, ${VAR} references
Deployment Docker, compose, container paths, doctor as a CI gate
CLI reference serve · tools · doctor · new-plugin
Architecture Internals, request/startup flow diagrams, design decisions

Engineering history — research, verified-fact spikes against FastMCP 3.4.4, decision records — is in context/.

Project layout

mcp-store/
├── config.example.json    # copy to config.json; servers + plugins + gateway settings
├── plugins/               # your MCPs, one folder each (weather/ and notes/ are examples)
├── src/mcp_store/         # the gateway: config, plugins, gateway, curation, doctor, cli
├── tests/                 # 83 tests, all in-memory, sub-second
├── docs/                  # user documentation (start at docs/README.md)
└── context/               # internal engineering docs: plans, research, decisions

Status

Python 3.11+ · uv · FastMCP >=3.4,<4 · 83 tests passing · verified end-to-end over HTTP, stdio, and in Docker against real upstream servers. No auth in v1 — bind to localhost or a trusted network (details).

推荐服务器

Baidu Map

Baidu Map

百度地图核心API现已全面兼容MCP协议,是国内首家兼容MCP协议的地图服务商。

官方
精选
JavaScript
Playwright MCP Server

Playwright MCP Server

一个模型上下文协议服务器,它使大型语言模型能够通过结构化的可访问性快照与网页进行交互,而无需视觉模型或屏幕截图。

官方
精选
TypeScript
Magic Component Platform (MCP)

Magic Component Platform (MCP)

一个由人工智能驱动的工具,可以从自然语言描述生成现代化的用户界面组件,并与流行的集成开发环境(IDE)集成,从而简化用户界面开发流程。

官方
精选
本地
TypeScript
Audiense Insights MCP Server

Audiense Insights MCP Server

通过模型上下文协议启用与 Audiense Insights 账户的交互,从而促进营销洞察和受众数据的提取和分析,包括人口统计信息、行为和影响者互动。

官方
精选
本地
TypeScript
VeyraX

VeyraX

一个单一的 MCP 工具,连接你所有喜爱的工具:Gmail、日历以及其他 40 多个工具。

官方
精选
本地
graphlit-mcp-server

graphlit-mcp-server

模型上下文协议 (MCP) 服务器实现了 MCP 客户端与 Graphlit 服务之间的集成。 除了网络爬取之外,还可以将任何内容(从 Slack 到 Gmail 再到播客订阅源)导入到 Graphlit 项目中,然后从 MCP 客户端检索相关内容。

官方
精选
TypeScript
Kagi MCP Server

Kagi MCP Server

一个 MCP 服务器,集成了 Kagi 搜索功能和 Claude AI,使 Claude 能够在回答需要最新信息的问题时执行实时网络搜索。

官方
精选
Python
e2b-mcp-server

e2b-mcp-server

使用 MCP 通过 e2b 运行代码。

官方
精选
Neon MCP Server

Neon MCP Server

用于与 Neon 管理 API 和数据库交互的 MCP 服务器

官方
精选
Exa MCP Server

Exa MCP Server

模型上下文协议(MCP)服务器允许像 Claude 这样的 AI 助手使用 Exa AI 搜索 API 进行网络搜索。这种设置允许 AI 模型以安全和受控的方式获取实时的网络信息。

官方
精选