I Set Up a Server. Connected Claude to It. Here's What Happened.
I Set Up a Server. Connected Claude to It. Here's What Happened.
By Cynthia Schomp · Fractional CTO
I want to show you the whole picture.
Six emails to get here. You now know what an LLM is, what a skill does, how adaptive learning keeps a brand skill from drifting, what plugins are, what a full work week looks like when Claude runs the workflow, and what it costs when every Monday starts over.
That's the vocabulary. This email is what you do with it.
What I Built
I set up a server in my office.
Not a cloud instance. Not a SaaS subscription. A physical machine on my network, running my infrastructure, under my control. Then I connected Claude to it.
The connection runs through something called MCP. Model Context Protocol. It's the bridge that lets Claude reach outside its own walls and talk to real systems. Not a plugin in a marketplace. Not a tool connection inside Claude's settings. A protocol-level bridge between Claude and the systems I own.
When that bridge is live, the conversation changes.
What Claude Can Do Now That It Couldn't Before
Before the server: Claude knew my process. It had my brand skill loaded. It could draft, structure, rewrite, and advise.
After the server: Claude can operate inside it.
It can read from my actual databases. Not summaries I pasted in. The live data. It can check the real status of a deployment. It can run automation workflows, read logs from my web servers, and take action on systems where a plugin in a marketplace was never going to exist because I built those systems myself.
The difference is reach. A well-loaded skill makes Claude a very capable advisor. MCP into your own server makes it a capable operator.
The Practical Version of What That Looks Like
Before MCP: I'd ask Claude to help me troubleshoot something on my website. I'd copy in the relevant error, describe the context, paste in what I thought was the relevant config. Good output. Incomplete input because I was manually relaying what I thought it needed.
After MCP: Claude reads the log directly. It sees the actual error in the actual context, not my description of it. It pulls the relevant config itself. Its analysis starts from complete information.
Every time a human manually relays information to a system, there's a compression step. You summarize. You leave things out. You don't know what you don't know to include. MCP removes that step.
Why the Server Matters
Plugins connect Claude to systems someone else built and someone else controls. You get what they decided to give you.
A server you own has no such constraint. My databases, my automation workflows, my deployment pipelines, my monitoring data. None of that lived in a plugin marketplace. I built it. The only way to give Claude real access to it was to build the bridge myself.
MCP is an open protocol: here is how a model and a system can talk to each other. The server I set up speaks MCP. Claude speaks MCP. They understand each other.
What the Full Stack Looks Like Now
Skills tell Claude how to think. Plugins connect Claude to the SaaS layer. MCP connects Claude to the infrastructure I own. Memory connects sessions to each other so nothing gets lost between Mondays.
The skills still load. The brand skill still reads its reference files before any copy goes out. The adaptive learning still runs. The MCP connection isn't a replacement for the work I did building those skills. It's what those skills are running on top of.
What This Means for Agencies at This Level
Most agencies don't need this. Most agencies need skills and plugins, and that's enough to change the shape of a work week. Email 05 showed you what that looks like. Those numbers were real.
Some agencies will eventually hit the ceiling of what plugins can reach. Their data lives in systems they built. Their workflows run on infrastructure no marketplace covers. When you hit that ceiling, MCP is the answer.
The Full Arc
Email 01: Claude is an LLM, not a chatbot. You can customize how it thinks. Email 02: Skills solve the blank slate problem. Load your process once, it's there every session. Email 03: Brand skills can learn from feedback. The reference files update themselves. Email 04: Plugins give Claude hands. Tool connections that turn drafts into actions. Email 05: A real week. Real numbers. Claude as workflow layer, not chat tool. Email 06: At some point it stops being a tool and starts being a system. Memory, persistence. Email 07: I connected Claude to my actual infrastructure. Here's what it can do now.
That's the rabbit hole. You went down it. I'm glad you did.
What I'm Still Figuring Out
The governance question keeps coming up. When Claude can read from and write to real systems, you need real discipline about what it's allowed to do without a human decision in the loop. I have rules. The rules are holding. But they're not finished.
The other open question is skill maintenance at scale. The more the system can do, the more skills it needs to do it well. MCP doesn't change that. It just raises the stakes.
This series is done. The topic isn't.
Thank you for reading all the way to email 07. You started not knowing the difference between Claude and a chatbot. You end knowing what MCP is and why a server in someone's office changes what AI assistance actually means.
That's not nothing. That's the whole vocabulary.
If you missed any emails in this series, the full archive is waiting: hellocyn.com/archive -- every issue, in order, yours to read whenever.
-- Cynthia Fractional CTO · Schomp.ai · The CTO's Desk
Reply to this if you're building something similar. I read every reply.
Get the next one.
One email per day. Real deployments. No theory.