When we built the first MCP server at StudioMeyer, it had three tools. Today we operate 58 MCP servers with over 680 tools -- a system that maps our entire business logic, from CRM to billing to video production and website analysis. This article is the technical story behind it: how do you build an MCP infrastructure that scales without collapsing?
The beginning: One server, three tools#
Every large system starts small. Our first MCP server was a CRM tool with three functions: create contact, search contact, update contact. TypeScript, Zod schemas for input validation, one handler per tool. Simple, functional, useful.
But once a system works, requirements grow. "Can you also create invoices?" "We need monitoring." "Outreach emails should also run through MCP." Each requirement meant: new tools, new schemas, new handlers. And it became clear: a single server with 680 tools would not work.
The 3-tier architecture#
The solution was an architecture that separates tools by access level and responsibility. Three tiers, clearly defined:
Tier 1: Internal servers#
Tier-1 servers are exclusively for our own infrastructure. They run locally, communicate via stdio (Standard Input/Output), and are never publicly reachable. These are the tools that work directly with our database, servers, and internal processes.
Examples:
- Nex Intelligence -- Our memory system. Stores decisions, learnings, patterns. Over 300 entries, searchable by AI.
- Deploy (8 tools) -- Container management, deployments, rollbacks. Direct Docker access, therefore strictly internal.
- Monitor (9 tools) -- Service health, container status, resource monitoring.
Tier 2: Shared servers#
Tier-2 servers are used both internally and by our agent systems. They offer dual transport: stdio for local use, HTTP for agent access. These servers encapsulate business logic needed by multiple systems.
Examples:
- CRM (25 tools) -- Contacts, deals, pipeline, lead scoring, tags, notes, activities, search. The most comprehensive server in the system.
- Billing (17 tools) -- Invoices, payments, subscriptions, Stripe integration.
- Outreach (10 tools) -- Email sequences, follow-ups, lead generation, template management.
- Onboard (5 tools) -- Customer onboarding workflows, milestone tracking, checklist management.
- Audit -- Code quality, security scans, compliance checks.
Tier 3: Customer-facing servers#
Tier-3 servers are built to function as standalone products. They have clean APIs, complete documentation, and can be integrated by customers as MCP servers in their own assistants.
Examples:
- Media -- Video generation, image generation, n8n workflow integration.
- Video -- Website recording, scroll capture, multi-device recording, text-to-speech, post-production.
- Effects -- Animation extraction from live websites. Hover states, GSAP timelines, scroll triggers, SVG paths, Lottie animations.
- Generate -- CSS keyframes, GSAP animations, scroll effects, WebGL shaders, Three.js scenes, particle systems.
- Website -- Website analysis, screenshots, DOM extraction, component detection, HTML-to-React conversion.
- Social -- Social media content creation, carousels, stories, brand kit management.
The tech: TypeScript, Zod, and dual transport#
Every MCP server follows the same pattern. This makes the architecture predictable and maintainable, regardless of whether the server has 5 or 50 tools.
Zod schemas for everything#
Every tool input is defined by a Zod schema. No any types, no optional validations. If a parameter is wrong, the schema fails -- before the handler even runs.
This is not just type safety -- it is documentation. The AI assistant reads the schema and knows exactly which parameters are expected, which are optional, and which formats apply.
Dual transport: stdio + HTTP#
Our shared library (@studio-mcp/shared) provides startDualTransport() -- a function that makes every MCP server available via both stdio and HTTP.
stdio is used when the agent starts the server as a subprocess. Direct, fast, no network latency. Ideal for local development and Tier-1 servers.
HTTP is used when agents access the server over the network. Each Tier-2 and Tier-3 server has a dedicated port (CRM: 4001, Billing: 4002, Monitor: 4003, Deploy: 4004, Outreach: 4005, Onboard: 4006, Audit: 4007).
Server factory pattern#
For HTTP sessions, we use a factory pattern: createMcpServer() creates a fresh server instance for every HTTP session. No shared state between sessions, no memory leaks, no race conditions.
Why modular?#
The temptation is to put everything in one server. One server, all tools, done. But that does not scale -- for several reasons:
Tool sprawl: An assistant with 680 tools simultaneously is overwhelmed. Tool selection quality drops drastically beyond about 30-40 tools per context.
Responsibility: If the billing server has a bug, only billing is affected. Not CRM, not monitoring, not website analysis.
Security: Not every agent needs access to everything. The sales agent has no deploy access. The DevOps agent has no CRM access. Least privilege by design.
Scaling: Each server can be scaled independently. If CRM is under load, we scale the CRM server -- not the entire system.
What you can learn from this#
If you want to build your own MCP servers, here are the lessons from our experience:
- Start small. One server, three tools, solve one problem. Then expand.
- Zod schemas are mandatory. Not optional, not "later." From the first tool onward.
- Think modular. One server per domain, not one server for everything.
- Dual transport from the start. stdio for development, HTTP for production.
- Factory pattern for HTTP. No shared state. Every session gets a fresh instance.
The tools running on this architecture are available in our tools overview -- individually or as packages. And if you want to build your own MCP infrastructure: we have done it before. We can do it for you too.
