MCP Factory: Building Plugin-Based Model Context Protocol Servers

What is an MCP factory?

The MCP Factory is a plugin-based foundation for building Model Context Protocol servers. Since the Model Context Protocol is essentially a decorated REST API — convenient developer UX that dynamically adds discoverable capabilities to any LLM tooling — the factory makes it fast and consistent to wrap any existing REST API in an MCP server without rebuilding the same plumbing each time.

Why standardize: SOLID and a service-plugin architecture

Every MCP server is remarkably similar, so the factory standardizes the shared plumbing — error handling, HTTP calls, markdown formatting. Each server is a self-contained plugin under services, following SOLID and the open-closed principle: add new plugins, but don't edit shipped ones. A little generated redundancy is worth keeping services independent and shippable.

The tech stack

The factory uses FastMCP (a Python framework for rapid, performant async MCP servers — inspired by, but not related to, FastAPI) and Python 3.13. Dependencies and environment are managed with UV. The entry point is main.py; server.py is the FastMCP server; the service registry is where you register new services. Default transport is standard I/O (stdio); HTTPS deployment is possible but out of scope.

Four building blocks

Each plugin builds on four pieces: the base API client (an async contract that handles network requests — you implement fetch), the base formatter (turns data into an LLM- and human-friendly markdown string — you implement format), the service plugin (duck-typed, handles registering the service), and the service registry (where all plugins are collected and exposed).

Adding a new service

Practical steps: make a folder for the service, add config (load API keys from the environment, never hard-code secrets in config.py), implement the fetch client and the markdown formatter by extending the base classes, register it with one line in server.py, and add tests. Most of the work is creating new files; only server.py needs editing to integrate.

Testing: TDD, unit + end-to-end

Aaron is a fan of test-driven development — write tests early, even before the code. Unit tests exercise each piece in isolation and keep quality high (if code is hard to unit-test, that's a code smell — the function may be doing too much). End-to-end tests verify the connected system and map naturally onto user stories; run them before merging to main.

What "agent" really means

Aaron's preferred definition: an agent is when the programmer cedes the program's control flow (the if-statements, loops, branching) to a model. LLMs are statistical, probabilistic, text-to-text systems, so they can handle unstructured problems deterministic code can't — but they can also make mistakes. Tools always return text, because language models live in the token-in, token-out world.

Reference services and the live demo

The factory ships with two examples: NASA's Astronomy Picture of the Day (a public REST API with a working demo key) and Code Guardian (a non-HTTP service that scans a codebase for security issues). In a live demo, Aaron pointed Claude at an open currency-conversion API (Frankfurter) with a ready-made prompt following the repo's "house rules" (a CLAUDE.md of context); Claude built, registered, and tested a new currency service end-to-end with no hand-written code.

Philosophy: ship quality, not lines of code

A recurring theme: lines of code are debt, not productivity. LLMs generate code cheaply, which makes it more important — not less — to apply solid engineering principles so systems stay reliable, consistent, and maintainable. The goal is shipping quality products, not just shipping a lot.