When we built the first MCP server at StudioMeyer, it had three tools. Today we operate 20 MCP servers with over 260 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 260 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 260 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 Store -- 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.
Originally published on studiomeyer.io. StudioMeyer is an AI-first digital studio building premium websites and intelligent automation for businesses.
Top comments (0)