One MCP Server Becomes a Group Project

▶ Watch (4:09)

Tupe started April 2025 with one MCP server for fabric interconnection. Five to ten tools wrapped existing APIs. Demos worked. Then network, data center, and infrastructure teams wanted their APIs exposed. One MCP server became a group project. Equinix now runs 5 public MCP servers with 230+ tools. Fabric server alone holds 80 tools. The real problem shifted from adding capability to setting domain boundaries and governance.

Domain Boundaries Before Tools

▶ Watch (6:42)

Three design patterns emerged. First, design domains before tools. Map agent workflows and user journeys, then define domain boundaries. Second, avoid the mega MCP server trap. Single servers tempt every team to contribute. Set clear domain boundaries early. Third, namespace tool names from the start. Overlapping nomenclature across teams confuses agents. Use domain-based prefixes. Tupe also kept the agent as pure orchestration layer with no cross-server tool calls at runtime.

Tags and Skills Shrink the Context Window

▶ Watch (10:10)

Tupe expected 200 tools would let agents work like senior engineers. It did not deliver. Context explosion blocked performance. The solution combined tool tags with skills. Tags label each tool by domain and operation type. Skills hold procedural knowledge for a workflow and reference only the tags they need. When a customer intent arrives, the skill fetches only matching tools into context. No tool dump. No context flood.

Production Infrastructure from Day One

▶ Watch (11:35)

Tupe treats MCP servers as secure API endpoints. Rate limiting, audit logging, and OAuth apply. Equinix adopted the November 2025 spec with client ID metadata and DCR. Tool tags enable scoped authorization. For discovery, Equinix built an internal MCP registry based on the open spec. Agents discover servers dynamically instead of hardcoding URLs. Observability via LangSmith tracks tool call accuracy and failures.

Q&A

How did you break a giant MCP server into small domain servers? Tupe started from the customer workflow: combine tools that solve a complete user journey, which set a clear governance rule for alignment. ▶ Watch (17:34)

How do tags plus skills actually reduce what an agent sees in context? The skill picks up based on progressive disclosure of name and description, then fetches only tools matching its required tags from the MCP server. ▶ Watch (18:47)

Is MCP short-lived with A2A on the horizon? Adoption just started. 2026 is the real production adoption year. A2A may play a role or MCP may evolve into that space. Time will tell. ▶ Watch (22:03)

Notable Quotes

when you write fourth or fifth MCP server you create problems Vaibhav Tupe · ▶ Watch (5:48)

think about designing domain first instead of designing tools Vaibhav Tupe · ▶ Watch (6:45)

MCP server is nothing different than any other secure API endpoint Vaibhav Tupe · ▶ Watch (12:02)

we are not hard coding any MCP server URLs within agent not via config or anything Vaibhav Tupe · ▶ Watch (14:02)

Key Takeaways

  • Define domain boundaries before building tools to prevent coordination problems.
  • Use tool tags with skills to control which tools enter the agent context window.
  • Treat MCP servers as production infrastructure with OAuth, registries, and observability.

About the Speaker(s)

Vaibhav Tupe is a distinguished Technology Advisory Board Member and Engineering Leader specializing in cybersecurity, cloud, and AI-ready data center infrastructure. With over 13 years of experience, he currently serves as a Technology Leader at Equinix USA, where he drives high-performance…