{"slug": "i-connected-3-mcp-servers-to-one-agent-it-got-scary-fast", "title": "I Connected 3 MCP Servers to One Agent. It Got Scary Fast.", "summary": "A developer connected three MCP servers to a single AI agent and discovered that while MCP standardizes tool communication, it lacks governance for multi-server setups. The developer built Fabric, an open-source control plane with policy enforcement, approval workflows, and audit logging, after finding no existing tools to manage agent capabilities across multiple servers.", "body_md": "I looked at my terminal last week and realized my AI agent had the same access to deploy production as it did to search a README. No policy. No approvals. No audit trail. Three MCP servers wired directly in, side by side, identical trust.\n\nThe first two were fine — docs search, code search. Read-only. The third could promote builds to production. And that's when it clicked: MCP standardized how agents talk to tools, but did absolutely nothing for what happens after you connect more than a couple of them.\n\nThe official MCP servers repo has 88,900 stars and 11,300 forks. Claude, ChatGPT, VS Code, Cursor — they all speak MCP. There's a registry for browsing servers. The ecosystem is taking off, and I couldn't find a single governance tool for any of it.\n\nThree paths. None of them worked.\n\n**API gateways** route HTTP. They don't understand MCP tool schemas. You can't write a rule that says \"this agent can use `deployment:promote`\n\nbut not `deployment:rollback`\n\n\" — the gateway doesn't know what those are.\n\n**Custom middleware** works until the person who built it leaves and nobody understands how the approval chain works. No UI. Every new server requires code changes.\n\n**Nothing** — just wire servers directly and trust the agent code. This was my setup. It felt fine at two servers. At three, I couldn't answer \"what can this agent actually do?\"\n\nSo I started building.\n\nI had a plan. v0.1.0: API — servers, capabilities, policies. v0.2.0: Admin UI and approvals. v0.3.0: audit, alerts, trust posture.\n\nThen I realized a control plane without a UI isn't a control plane at all. Nobody curls an endpoint to see which servers are registered or which approvals are pending. The UI was supposed to be a v0.2 feature. I pulled it into v0.1.0.\n\nSame thing happened with approvals. Then audit. Then alerts. Each layer depended on the one before it. Cutting any of them meant cutting the core promise: \"see, control, and audit what your agents do.\" By the time I stopped, v0.1.0 had absorbed most of v0.2 and v0.3. Three planned layers became eight.\n\nI don't know if that was smart or stubborn. It tripled the timeline. But shipping disconnected pieces that wouldn't make sense until months later felt worse.\n\nThe backend took days. FastAPI, PostgreSQL, Redis, OPA — standard stack.\n\nWhat ate weeks:\n\n**The PRD and Customer User Journeys.** Before writing a single component, I mapped every flow: register a server, review an approval, audit an incident. What happens when it fails? Empty states, error states, permission-denied states. Every CUJ forced answers the API never asked for. I kept wondering if I was over-planning.\n\n**The UI.** Originally v0.2. Bringing it into v0.1 meant navigation, error boundaries, trust posture color coding, role-based filtering, the approval panel — every screen end-to-end. Then testing it. Sixty-eight Playwright E2E scenarios. Backend tests ran in seconds. UI tests took forever.\n\n**CI.** Poetry v2 dropped `--no-update`\n\n. npm 11 rejected TypeScript peer deps. Neither had anything to do with my code. A day fixing infrastructure that \"already worked.\"\n\n**Mypy.** 170 type errors across 41 files. Every one was a design decision I'd been sloppy about, disguised as a type violation. Strict mode didn't let me hide.\n\n**PyPI.** Three attempts. `mcp-fabric`\n\nwas taken. `mcpfabric`\n\nblocked. `fabric-mcp`\n\nblocked. Fourth try: `mcp-fabric-toolmesh`\n\n.\n\nThe number I keep coming back to: 170 type errors across 41 files. That's not bugs. That's unclear thinking, surfaced by a tool that refused to let it slide.\n\nYou register MCP servers and Fabric auto-discovers their tools. Raw tool names normalize into domain-level capabilities — `/promoteDeploy`\n\nand `/promote`\n\nboth map to `deployment:promote`\n\n. Every request hits OPA policies. Sensitive capabilities can require human approval. Everything is logged. Alerts fire when servers degrade. Identity tokens per agent class. Capability packs for permission bundling.\n\n474 tests. Six parallel CI jobs. Published to PyPI. Open source.\n\nI've been running it against my own three servers. Before Fabric, every token had access to everything. Now the developer agent searches docs and code. The release engineer requests deployment — but it pauses for approval. The difference between \"trust the code\" and \"verify every request\" took 30 minutes of configuration.\n\n**PRD and CUJs on day one, not after the API.** I built the backend first, then designed the UI around it. Backwards. The CUJ mapping caught gaps the API missed.\n\n**The UI is not a v0.2 feature.** If your tool needs human interaction, the UI is MVP. Designing the API for curl and the UI for humans meant refactoring when they didn't match.\n\n**Scope consolidation is not scope creep.** Packing 0.2 and 0.3 into 0.1 looked like bad planning. In hindsight, each layer depended on the previous. The real mistake was the original roadmap pretending they were independent.\n\nI'm still figuring out if tool governance should be a layer on top of MCP, or something the spec itself eventually absorbs. I built what I needed for my setup — I don't know if it generalizes.\n\nIf you're running MCP servers: how are you handling this? Wiring directly and hoping? Writing middleware? Waiting for the ecosystem? I suspect most people's answer is \"we're not handling it yet,\" and that feels like a conversation worth having.\n\n[github.com/deghosal-2026/mcp-fabric](https://github.com/deghosal-2026/mcp-fabric) · [pypi.org/project/mcp-fabric-toolmesh](https://pypi.org/project/mcp-fabric-toolmesh/)", "url": "https://wpnews.pro/news/i-connected-3-mcp-servers-to-one-agent-it-got-scary-fast", "canonical_source": "https://dev.to/debashish_ghosal/i-connected-3-mcp-servers-to-one-agent-it-got-scary-fast-4loe", "published_at": "2026-07-25 13:10:45+00:00", "updated_at": "2026-07-25 13:33:00.243057+00:00", "lang": "en", "topics": ["ai-agents", "developer-tools", "ai-safety", "ai-infrastructure"], "entities": ["MCP", "Fabric", "Claude", "ChatGPT", "VS Code", "Cursor", "FastAPI", "PostgreSQL"], "alternates": {"html": "https://wpnews.pro/news/i-connected-3-mcp-servers-to-one-agent-it-got-scary-fast", "markdown": "https://wpnews.pro/news/i-connected-3-mcp-servers-to-one-agent-it-got-scary-fast.md", "text": "https://wpnews.pro/news/i-connected-3-mcp-servers-to-one-agent-it-got-scary-fast.txt", "jsonld": "https://wpnews.pro/news/i-connected-3-mcp-servers-to-one-agent-it-got-scary-fast.jsonld"}}