3 Months With MCP: What Actually Changed in My Engineering Workflow
I set up four MCP servers in one evening. Then removed two. Added one different one. Three months later I know what Model Context Protocol is: not a smarter AI. Less friction at specific handoff points.
Most MCP content is "how to set up in 5 minutes." This is what happens after day 90, when the initial enthusiasm is gone.
Why I put it off
MCP (Model Context Protocol) is an open standard that lets AI agents connect to external data sources and tools through a common interface. In practice: instead of you copying context between apps, the agent reaches it directly.
I saw the announcement and scrolled past it. My reasoning: another integration layer that would add more complexity than it removes. I already had Claude Code, Obsidian, and Jira — each in its own window, working fine.
Then a colleague showed me his agent reading his Obsidian vault directly from the terminal, no copy-pasting. I got it. It's not an abstraction layer. It's a removed manual step.
That evening I installed: Obsidian MCP, Atlassian MCP, Figma MCP, chrome-devtools-mcp. Four servers. I wanted to see what would survive.
What I kept: three servers that earned their place
Obsidian MCP. My entire working context lives in the ivanpin_docs vault. When the Claude Code agent runs cron tasks T1–T14, it reads and writes notes directly there. Before: copy file content, paste into prompt, get response, copy back. Now that step doesn't exist. Not "10x faster" — just one manual handoff removed at every iteration.
Atlassian MCP stayed for a different reason. My Jira project is a live task list. The agent reads open tickets without me switching to the browser. Small thing. But when you're in flow, every browser switch is a flow break.
chrome-devtools-mcp is infrastructure, not convenience. The entire SSI automation stack — 13 cron tasks — runs on it. Without it, the agent can't see the browser at all.
Figma MCP I removed after two weeks. Made two requests, understood I don't work with Figma in a mode where an agent alongside makes sense. My design process is async. Installing a server "in case it's useful" is a bad habit.
Where time actually came back
Using MCP across three servers (Obsidian, Atlassian, chrome-devtools), I reclaimed roughly 45 minutes a day in context switching — not from any one task, but from the accumulated overhead of manual handoffs that I'd stopped noticing.
The cron task workflow before: agent runs, I wait, I see something unclear in output, open Obsidian, find the file, check context, come back. With Obsidian MCP the agent sees the vault itself — when a question comes up, it resolves it without me.
Atlassian MCP gave something different. I used to start my morning with Jira. Now the agent pulls open tickets into context without a command. It's not fewer hours. It's fewer interruptions mid-task.
What didn't speed up: writing code. MCP doesn't affect how Claude Code generates logic. No before/after difference there. MCP works at the seams, not in the core.
Three places it didn't help
Figma MCP was the first to go, already mentioned. No use case that fit.
The harder one: a server updated, its schema changed, the agent started misreading part of the context. I didn't notice immediately. Spent an hour debugging. MCP integrations need the same versioning attention as any other dependency. "Set it and forget it" doesn't apply.
The third is quieter but cumulative. When Obsidian MCP reads a large vault, every agent call costs more — literally, in tokens. You don't see this at install time. The bill shows it.
The hidden cost: context isn't free
Every MCP server extends the agent's context window. More context means more expensive calls. For one or two requests a day, it's invisible. For 13 cron tasks running multiple times a day, it's a real budget line.
I narrowed what Obsidian MCP reads by default. Instead of the whole vault, I pointed it at specific directories. Calls got cheaper, the work stayed the same.
If you're planning to use MCP for automation, count the tokens before you start. Not after the first invoice.
My 3-minute server check
Before installing another server:
First — is there a specific task I'm doing manually every day? If it's "might be useful" — no.
Second — how does this server affect context size? If it pulls data into every request that's irrelevant 80% of the time — no.
Third — who maintains the server and how often does the schema change? A community server without an active maintainer is technical debt. Not a tool.
Three questions. Under a minute each.
The bottom line
Three out of four servers survived. Around 45 minutes a day in context switching is gone. Architecture decisions are still mine — the cron tasks aren't.
MCP doesn't make you smarter. It removes friction where friction costs money. If those points exist in your workflow, it's worth trying. If they don't, installing "for future use" is a bad idea. I tested that. Figma MCP sat unused for two weeks before I admitted it.
Three months in, it's production work, not an experiment. That's the only honest endorsement I can give.
Related: Claude Code and Obsidian: how we keep living documentation