MCP Constellation
A model in a chat window can't touch a database or a file on its own. MCP is the layer that lets it, and I've built that layer by hand. I run more than twenty MCP servers across my system, and wrote several from scratch because the one I needed didn't exist yet.
Servers I wrote from scratch
- audio-ears: audio analysis, so agents can listen to a file and reason about it.
- A ComfyUI server: image and video generation wired into the agent layer.
- An NVIDIA-GPU server: live monitoring of the workstation the whole system runs on.
- A YouTube automation server: the action layer behind a content pipeline.
- An Ollama delegation layer: routing work to local models when the cloud isn't needed.
Plus the ones I integrated
A working environment is more than the servers you author. I've integrated and configured production servers for PostgreSQL, Qdrant, Playwright, n8n, Obsidian, and Perplexity, among others, wiring third-party tools into one coherent system the agents can act through as if it were a single toolset.
Why it matters for the role
Responsibility two on the Anthropic FDE posting is, almost word for word, deliver technical artifacts like MCP servers, sub-agents, and agent skills. I've already built and shipped that work, and it runs today. It isn't a plan to learn the skill. It's a record of having done it.
Build, or integrate? The judgment under the artifact.
An MCP server is the layer that lets a model actually touch a database or a file instead of just talking about one. Running more than twenty of them is a number. The judgment is knowing which to write yourself and which to wire in. Three of those calls.
When it's worth writing a server from scratch
Most of the time the right move is to integrate something that already exists, because the boring server someone else maintains is a server you don't have to. I wrote my own only where the thing I needed didn't exist yet: a way for agents to listen to an audio file and reason about it, live monitoring of the GPU the whole system runs on. The test isn't whether I could build it. It's whether the gap actually hurts and will keep existing. Writing a server you could have downloaded is how you end up maintaining code that was never your problem to begin with.
Why this layer exists at all instead of gluing tools in directly
You could hand an agent a one-off script for every tool it needs and skip the protocol entirely. It works until you have twenty tools and every one speaks a different dialect, and now adding the twenty-first means teaching the agent yet another bespoke shape. MCP is a single contract every tool conforms to, so the agent learns one way to act and the tools plug in behind it. The cost is a little ceremony per server. The payback is that the system stays addable instead of turning into a tangle nobody can extend.
Why the agent can't tell my servers from the third-party ones
Half the constellation is servers I wrote and half is production tools I integrated, Postgres and Qdrant and Playwright and the rest. From the agent's side that seam is invisible on purpose. It acts through one coherent toolset and never has to know which calls hit my code and which hit someone else's. That's the point of a real integration layer: it hides the wiring so the thing using it can reason about the job, not the plumbing. The work of making it look like one system is exactly the work that makes it usable.