--- title: "From 0 to 260 Tools: Our MCP Server Architecture" description: "58 MCP servers, 680+ tools, 3-tier architecture. A deep dive into the technical infrastructure behind StudioMeyer's AI platform." author: "Matthias Meyer" published: 2026-02-26 updated: 2026-02-26 language: en tags: ["mcp", "architektur", "tools", "typescript", "infrastruktur"] canonical: "https://studiomeyer.io/en/blog/mcp-server-architektur-260-tools" markdown_versions: ["https://studiomeyer.io/de/blog/mcp-server-architektur-260-tools.md", "https://studiomeyer.io/en/blog/mcp-server-architektur-260-tools.md", "https://studiomeyer.io/es/blog/mcp-server-architektur-260-tools.md"] publisher: "StudioMeyer, https://studiomeyer.io (llms.txt: https://studiomeyer.io/llms.txt)" --- # From 0 to 260 Tools: Our MCP Server Architecture 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: 1. **Start small.** One server, three tools, solve one problem. Then expand. 2. **Zod schemas are mandatory.** Not optional, not "later." From the first tool onward. 3. **Think modular.** One server per domain, not one server for everything. 4. **Dual transport from the start.** stdio for development, HTTP for production. 5. **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](https://studiomeyer.io/en/developers) -- 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. ## Read more, Building MCP Servers - [Build Your Own MCP Server: Step-by-Step with TypeScript](https://studiomeyer.io/en/blog/mcp-server-selber-bauen.md) - [58 MCP Servers, 680+ Tools: Our AI Infrastructure in Detail](https://studiomeyer.io/en/blog/mcp-server-infrastruktur.md) - [MCP Server Architecture: How We Build Intelligent Agent Networks](https://studiomeyer.io/en/blog/mcp-server-architecture.md)