ai-multiagent-orchestrator-mcp
MCP server that coordinates multiple AI specialists (SQL database, document RAG, and web research) using LangGraph, routing each question to the relevant agents and synthesizing their responses into a single answer with honest confidence flags.
README
AI Multi-Agent Orchestrator
A LangGraph-based supervisor that coordinates three independent AI specialists — a SQL database agent, a document RAG agent, and a live web research agent — routing each question to whichever specialist(s) it actually needs, and synthesizing their results into one answer.
Live demo: https://ai-multiagent-archestrator.onrender.com/demo MCP endpoint: https://ai-multiagent-archestrator.onrender.com/mcp
This is Project 3 in a portfolio series. The two specialists it coordinates are themselves independently deployed, production projects:
ai-sql-agent-mcp— Project 1ai-document-mcp— Project 2
Why this project
Most "agent" demos show a single LLM calling a single tool. This project demonstrates something closer to production multi-agent systems: a supervisor that must decide which of several independent, already-deployed services to call, potentially several at once, and combine their results honestly — including saying when a specialist's answer is incomplete or low-confidence, rather than papering over gaps.
Architecture
- A user question comes in to the LangGraph Supervisor (Claude Sonnet 5).
- The supervisor decides which specialist(s) the question needs, and calls one, several, or none:
ask_database-> a live MCP call to ai-sql-agent-mcp (Project 1, deployed independently on Render)search_documents-> a live MCP call to ai-document-mcp (Project 2, deployed independently on Render)search_web-> a live call to the Tavily Search API
- Specialist results return to the supervisor, which synthesizes one final answer -- citing which specialist(s) it used, and flagging low-confidence or missing information honestly rather than guessing.
The supervisor and both MCP client wrappers run in this service. ask_database and search_documents are thin clients making real network calls to two other, independently deployed services -- not local functions pretending to be remote.
Features
- Multi-specialist fan-out: a single question can trigger multiple specialists in parallel (e.g. "what do our documents say about X, and what's the latest news on X?" correctly calls both
search_documentsandsearch_webin one supervisor turn — verified live, see Proof section below). - Judgment, not blind routing: the supervisor recognizes when a question needs no specialist at all and answers directly from general knowledge (verified live — see Proof section).
- Triple exposure: the same orchestration logic is reachable three ways — as an MCP tool (
orchestrate), as a REST endpoint (/demo/query), and via a browser demo (/demo) — all sharing one code path so they can't drift out of sync. - Graceful degradation: if a specialist errors or returns low-confidence results, the supervisor says so explicitly rather than fabricating certainty.
Live demo -- real, unedited output
Three real queries run against the live public deployment:
1. Document specialist, correctly scoped
"What does the Q3 report say about Acme Corp?"
Routed to search_documents only. Returned the real management-fee figures from the ingested report, and honestly flagged low retrieval confidence rather than overstating certainty.

2. SQL specialist, with an honest limitation
"What tables are in the database?"
Routed to ask_database. Correctly identified the customers and orders tables, and explicitly explained what it could not determine (no system-catalog access) instead of guessing.

3. No specialist needed
"what is AI"
Correctly recognized this needed no tool call at all, answered directly, and proactively offered to use a specialist if the question had actually been about the org's own data.

Tech stack
| Layer | Technology |
|---|---|
| Orchestration | LangGraph (supervisor + tool-calling graph) |
| LLM | Claude Sonnet 5 (Anthropic API) |
| Specialist transport | MCP (Model Context Protocol) over streamable HTTP |
| Web research | Tavily Search API |
| Server | FastMCP 3 (MCP server + custom REST/HTML routes) |
| Testing | pytest, pytest-asyncio, unittest.mock |
| CI | GitHub Actions |
| Deployment | Docker on Render (free tier) |
Project structure
orchestrator/
config.py - centralized, validated settings (pydantic-settings)
mcp_clients.py - MCP client wrappers for ai-sql-agent-mcp and ai-document-mcp
web_agent.py - Tavily-based web research specialist
graph.py - LangGraph supervisor + tool-calling loop
server.py - FastMCP server: orchestrate tool, /health, /demo, /demo/query
tests/ - pytest suite, all external calls mocked
.github/workflows/ci.yml - runs the test suite on every push and PR
Dockerfile
Running locally
Requires Python 3.12+ and API keys for Anthropic and Tavily.
git clone https://github.com/rajmyagentit-del/AI-MULTIAGENT-ARCHESTRATOR.git
cd AI-MULTIAGENT-ARCHESTRATOR
pip install -r requirements.txt
cp .env.example .env # then fill in your real keys
python orchestrator/server.py
The server starts on http://localhost:8000. Visit /demo in a browser, or:
curl -X POST http://localhost:8000/demo/query \
-H "Content-Type: application/json" \
-d '{"question": "How many customers do we have?"}'
Running with Docker
docker build -t ai-multiagent-orchestrator .
docker run -p 8000:8000 --env-file .env ai-multiagent-orchestrator
Environment variables
| Variable | Required | Description |
|---|---|---|
ANTHROPIC_API_KEY |
Yes | Claude API key |
TAVILY_API_KEY |
Yes | Tavily search API key |
SQL_AGENT_MCP_URL |
No | Defaults to the live Project 1 deployment |
DOCUMENT_AGENT_MCP_URL |
No | Defaults to the live Project 2 deployment |
PORT |
No | Defaults to 8000; Render sets this automatically |
Testing
python -m pytest tests/ -v
10 tests, all passing, all external services (Anthropic, Tavily, both MCP servers) mocked -- CI runs standalone with no real secrets required. Tests cover:
- Correct MCP tool-call argument names (regression coverage for two real bugs found during development -- see Engineering Notes)
- Error handling when a specialist fails or is unreachable
- The supervisor's routing decision logic
- The full supervisor<->tools loop end-to-end (mocked LLM + mocked specialist)
Deployment
Deployed on Render via the included Dockerfile, free tier. Auto-deploys on every push to main. Note: free tier spins down on inactivity -- the first request after idle time can take up to ~50 seconds while it cold-starts.
Engineering notes: real problems hit and fixed
Documenting these because working through them honestly is more useful than pretending the build was frictionless:
- MCP client library version gap: the initial
mcpSDK pin (1.1.3) predated thestreamable_httpclient transport needed to actually call the two live specialist servers. Diagnosed via a realModuleNotFoundError, resolved by upgrading to 1.29.0 (not the newest 2.0.0 major, which introduced its own unrelated dependency conflicts). - Wrong tool parameter name: assumed
ask_database's parameter wasquery; the real signature usesquestion. Found via a live test against the deployed server, confirmed against the Project 1 source, fixed, and locked in with a regression test. - Claude Sonnet 5 content shape: with extended thinking enabled by default, message content is a list of typed blocks (thinking plus text), not a plain string like older models. The first live deployment leaked a raw thinking block into the public /demo/query response. Fixed with an explicit text-extraction helper and verified on the redeployed live service.
- Unused dependency causing a real conflict chain: fastapi and uvicorn were added early on a guess, before settling on the FastMCP framework pattern. Neither was ever actually imported. They silently pinned starlette too old for fastmcp to install, causing a multi-layer version conflict. Root-caused by checking actual imports rather than chasing version numbers indefinitely, then removed entirely.
- CI failing on every historical commit: config.py's fail-fast validation (a deliberate design choice) correctly blocked test collection in CI because no secrets exist there. Fixed with obviously-fake placeholder env vars in the workflow, safe because every test mocks the real API calls.
License
MIT -- see LICENSE.
Credits
Built on top of two other original projects in this portfolio series (ai-sql-agent-mcp, ai-document-mcp), coordinated via LangGraph, Anthropic's Claude API, Tavily, and FastMCP.
推荐服务器
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 模型以安全和受控的方式获取实时的网络信息。