Model Context Protocol is the connection layer for AI systems — the standard for how agents reach tools, data, and each other. The interesting question isn't whether an agent platform uses MCP. By 2026 every serious one does. The interesting question is how deep it goes. Inside Harnyss, MCP runs end to end. The same protocol that lets an agent call Salesforce is the protocol that lets a customer plug in their internal billing system, the protocol that lets one agent call another, and the protocol that lets an operator ask the platform itself why a workflow failed last night. That last surface is the one most people haven't seen yet — and it's the part that quietly changes what a piece of software is.
The substrate decision
A harness for autonomous AI agents has to solve a connection problem at three levels: agents reaching tools, agents reaching customer-specific systems, and agents reaching each other. For most of 2024 those three problems had different shapes, different protocols, different auth models. Building a harness on top meant maintaining three internal abstractions and praying they didn't drift.
MCP collapses the three into one shape. We didn't have to think hard about whether to build on it; it's the protocol the ecosystem converged on. The decision worth thinking about wasn't whether — it was how far. We chose to run MCP end to end, including for things most platforms still wire up bespoke. The rest of this post is what that buys.
The four surfaces
Inside Harnyss, MCP shows up in four places. The first three are common. The fourth is the part worth slowing down on.
Tools agents call
The most obvious use. Every external system an agent interacts with — calendaring, email, CRM writes, ticketing, payments, internal APIs — sits behind an MCP server. The agent sees a uniform capability surface; the harness handles auth, rate limits, audit, and governance once at the protocol boundary instead of N times across N bespoke adapters.
This is plumbing, but it's the right plumbing. The integration layer of an agent platform is the part that grows without bound. Doing it once, at the protocol level, is the difference between a harness that scales to a long tail of integrations and one that needs an engineering team per vertical.
Customer systems plugged in
The hard part of selling AI into a real organization is that the most valuable integrations are with systems we have never seen — internal databases, homegrown order systems, the spreadsheet a department secretly runs the business out of. We can't ship those, and bespoke connectors are a tax neither side wants to pay.
Because MCP is the standard, customers who already have or build an MCP server for their internal system can plug it straight into Harnyss. The harness picks it up, the governance layer maps it to roles and approval rules, and agents start using it under the same rails as every native integration. No proprietary connector framework to learn. Standard in, standard out.
Inter-agent capability
Agents in a Harnyss harness don't only call tools — they call each other. The CMO agent asks the analytics agent to pull a number. A sub-agent spawned for a research task returns its result to its parent. An escalation walks up a tree until someone with the right authority can decide.
We expose agent-to-agent calls as MCP capabilities too. From inside an agent's reasoning loop, "call another agent" looks the same as "call a tool" — same protocol, same auth, same audit shape. The harness handles routing, policy enforcement, and logging; the agent doesn't have to know any of that. It just calls a capability.
The result so far is a system where the same primitive — an MCP capability — covers reaching the outside world, reaching into customer systems, and reaching across the org chart. One protocol, three jobs. That alone is worth the architectural commitment.
But the fourth surface is the one that changes what a piece of software is.
The platform answering questions about itself
Every part of Harnyss — the agents, the harness layer, the governance engine, the audit trail, the configuration surface — is built out of the same MCP capabilities the agents use. The reasoning loop that powers an SDR agent is the same reasoning loop, with different scope, that powers the operator-facing assistant inside the dashboard. When you talk to Harnyss as an operator, you are talking to an agent that has MCP access to the platform itself.
That sounds abstract. What it means in practice:
- An operator can ask "why did the renewal-followup workflow fail at 2:14 last night?" The operator-side agent walks the audit trail through MCP, surfaces the failed tool call, reads the error, identifies the upstream cause (a stale OAuth token on the CRM server), and explains it in plain language — with the option to fix it in the same conversation.
- An operator can say "build me an agent that triages support tickets, escalates anything mentioning refunds to a human, and posts a daily digest to #cx-leads." The operator-side agent composes existing MCP capabilities — the ticketing server, the escalation policy primitive, the Slack server — into a new agent definition. No form-filling. No DSL. The harness writes itself.
- An operator can ask "how do I use approval flows for the finance role?" and get a working answer pulled from the platform's actual configuration surface, not a documentation site that has drifted from the product.
The reason this works is end-to-end MCP. If we had wired up the agent-tool layer with MCP and the platform-configuration layer with REST APIs and the audit layer with a proprietary query language, the introspection surface would be split across three incompatible interfaces and the operator-side agent could not span them. Because everything is MCP, everything is reachable. The platform's own surface area is just another set of capabilities the harness can call.
This is the part that is new. It's not new to put a chatbot in front of software — that's been around for years and is mostly a worse search bar. It's new for the chatbot to actually be the software's operator surface, with the same governance, audit, and authority model as the agents doing real work. That's only possible when the substrate underneath is the same substrate, all the way down.
Why the end-to-end version matters
Picking the same protocol for every connection problem isn't just architectural tidiness. It collapses the product.
- Governance is implemented once. The same role-based authority rules that decide whether the CMO agent can write to the CRM also decide whether an operator can ask the platform to spin up a new agent. One policy engine, one audit trail.
- Audit is implemented once. Every action — agent or operator — is an MCP call with the same shape. The trail is uniform, queryable, and complete.
- Observability is implemented once. When something fails, the failure is an MCP call that didn't succeed. The harness can explain itself because the harness can see itself.
- The operator experience and the agent experience converge. Operators ask the platform to do things in the same shape agents ask the platform to do things, with the same authority model differentiating who can do what.
A platform that wires up four different protocols for four different connection problems can ship the same features, but it ships them four times, and the cross-cutting behaviors — governance, audit, introspection — never quite line up.
What this means for the product
The model is a commodity. The agent is a unit of work. The harness is the product. And when the harness is built end to end on the same protocol the agents themselves speak, the harness gains a property most software doesn't have: it can explain itself, modify itself, and be reached by its operators in the same shape it reaches the world.
That isn't a feature. It's a structural consequence of picking one substrate and using it everywhere.
If you want a deeper look at the layers that sit on top of this substrate, our writeups on governance and agent delegation go a level down. Or if you'd rather see it running in your own org, start a free trial.