Model Context Protocol: The Missing Link in Our Agent Workflows
MCP is changing how we think about connecting AI agents to real tools and systems — and we're actively rethinking our workflows around it.
As we’ve been going deeper on what AI can actually do across our projects — not just assist with, but actively participate in — we hit something that reframed how we’re thinking about agent architecture: the Model Context Protocol, introduced by Anthropic.
It stopped us in our tracks in the best way.
What MCP Actually Is
MCP is a standard that allows AI systems, particularly LLM-powered agents, to connect to external tools, APIs, and data sources in a structured, consistent way. Instead of building bespoke integrations for every service an agent might need to touch, MCP defines a shared interface: agents can discover capabilities, request actions, and operate across systems without the usual one-off glue work.
That might sound abstract, but the practical implication is significant. Right now, a lot of AI-assisted development still has a human in the middle — reading a ticket, pasting context into a prompt, manually verifying an output. MCP is the infrastructure layer that starts to remove that middleman.
Where This Gets Interesting
Once the concept clicked, the use cases started coming quickly.
Consider an agent connected to a Jira MCP server. It pulls a bug from the backlog, loads the relevant context, and then uses a Playwright MCP server to validate whether the issue is actually resolved — not through static analysis, but against a running application. That’s not a stretch anymore. That’s a pattern that’s beginning to emerge in teams doing serious agent work.
For our projects, we don’t use Jira. We work out of GitHub. But the same pattern applies: issues as the unit of work, MCP servers connecting agents to the repository, and over time, agents that can pick up a task, implement a change, coordinate with other agents across triage, implementation, and testing — all through shared context and a common protocol.
How It’s Changing How We Work
We’re still in the early stages of integrating MCP into our workflows, but the direction is clear enough that we’ve started making deliberate changes.
The first shift is how we think about task handoffs. Previously, moving work from “identified” to “in progress” to “verified” required a person at each step. We’re now building toward agent chains where MCP servers provide the connective tissue — so agents can pick up work, act on it, and pass it forward without a human bottleneck at every transition.
The second shift is how we structure our tooling. Building one-off integrations for every service an agent might need has always been expensive to maintain. MCP gives us a reason to invest more carefully in the integration layer, because a well-implemented MCP server pays dividends across every agent that uses it.
We don’t have this fully figured out yet. The workflows are still being refined, and there are real questions about coordination, state management, and what “agent collaboration” actually looks like in practice versus in theory. But the direction feels important — important enough that we’re treating it as a first-class part of how we build going forward, not an experiment to revisit later.
What We’re Watching
The most compelling near-term possibility is agents that don’t just assist one person, but work together across roles: one agent triaging, another implementing, another validating — all operating through the same protocol against the same live systems.
If that matures the way it looks like it will, the team workflows we’re building today will look significantly different in six months. We’re designing with that in mind.
If you’re experimenting with MCP servers or building agent workflows around them, we’d genuinely like to hear how you’re approaching it. This is an area where the community is figuring things out in real time.