mcp-store
Aggregates multiple MCP servers and custom Python tools behind a single endpoint, with intelligent context and tool discovery for AI agents.
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
mcpServersJSON snippet intoconfig.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@toolfunctions (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
echoandcataloglive 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
百度地图核心API现已全面兼容MCP协议,是国内首家兼容MCP协议的地图服务商。
Playwright MCP Server
一个模型上下文协议服务器,它使大型语言模型能够通过结构化的可访问性快照与网页进行交互,而无需视觉模型或屏幕截图。
Magic Component Platform (MCP)
一个由人工智能驱动的工具,可以从自然语言描述生成现代化的用户界面组件,并与流行的集成开发环境(IDE)集成,从而简化用户界面开发流程。
Audiense Insights MCP Server
通过模型上下文协议启用与 Audiense Insights 账户的交互,从而促进营销洞察和受众数据的提取和分析,包括人口统计信息、行为和影响者互动。
VeyraX
一个单一的 MCP 工具,连接你所有喜爱的工具:Gmail、日历以及其他 40 多个工具。
graphlit-mcp-server
模型上下文协议 (MCP) 服务器实现了 MCP 客户端与 Graphlit 服务之间的集成。 除了网络爬取之外,还可以将任何内容(从 Slack 到 Gmail 再到播客订阅源)导入到 Graphlit 项目中,然后从 MCP 客户端检索相关内容。
Kagi MCP Server
一个 MCP 服务器,集成了 Kagi 搜索功能和 Claude AI,使 Claude 能够在回答需要最新信息的问题时执行实时网络搜索。
e2b-mcp-server
使用 MCP 通过 e2b 运行代码。
Neon MCP Server
用于与 Neon 管理 API 和数据库交互的 MCP 服务器
Exa MCP Server
模型上下文协议(MCP)服务器允许像 Claude 这样的 AI 助手使用 Exa AI 搜索 API 进行网络搜索。这种设置允许 AI 模型以安全和受控的方式获取实时的网络信息。