Wiring Four MCP Servers into One Agent: Maps, Chrome, Filesystem, and a Custom Tool
Most MCP tutorials stop at a single local server. This walkthrough shows the real integration pattern: mixing remote and local servers, handling rate limits, path sandboxing, and the agent loop's exact message shape. The six bugs are the kind that cost hours in practice, and each fix is spelled out.
The setup mixes remote HTTP MCP (Amap's geolocation and hotel-search APIs) with three local stdio servers: Chrome DevTools for browser control, FileSystem for disk access, and a hand-rolled user-lookup tool. A DeepSeek model drives the agent loop, deciding which tool to invoke across five rounds until the task is complete.
Six concrete pitfalls are documented: a missing `type` field that breaks IDE config parsing, `@langchain/openai` requiring `apiKey` inside the `configuration` object, dotenv loading from the wrong working directory, Amap's free-tier QPS limit triggering failures, FileSystem's path sandbox blocking writes, and a stray semicolon that silently moved tool-call handling outside the agent loop.
The result is a working multi-tool agent that geocodes an address, fetches nearby hotel details and images, generates an HTML page, and opens it in Chrome — all driven by a single natural-language prompt.
The agent loop's reliability hinges on correctly threading `tool_call_id` into every `ToolMessage`; omitting it breaks the model's ability to associate results with calls.
LangChain's `MultiServerMCPClient` treats remote and local servers identically after connection, but the failure modes differ sharply — network errors vs. process crashes vs. path sandbox violations.
The six pitfalls are not MCP-specific; they are standard Node.js and API-integration traps that become critical when an autonomous agent makes dozens of sequential calls without human intervention.