MCP is a Convenience, Not an Architecture

Model Context Protocol has become the default answer to "how do your agents connect to things?" The protocol has real momentum. Every major cloud provider supports it. The Linux Foundation governs it. Over 5,800 verified servers exist. It feels inevitable.

MCP has become the hot dog cart of enterprise AI. It is everywhere, it is fast, and everybody is buying one. But nobody is confusing it with a kitchen.

Something is breaking.

Perplexity dropped MCP internally. Their CTO said publicly that the protocol is too expensive for production agent systems. Anthropic, MCP's own creator, published benchmarks showing a 98.7% reduction in token usage when agents write code against an SDK rather than loading MCP tool schemas. One team reported three MCP servers consuming 72% of their context window before the agent processed a single user message.

And at the MCP Developer Summit this week, Uber's agentic AI lead said MCPs "really are what make AI useful at Uber." But before Uber could scale, they had to build an entire MCP Gateway and Registry just to get control over the MCP servers their engineers were spinning up. No central governance existed. No consistency. No security controls. They built all of that on top of MCP.

When one of the most sophisticated engineering organizations in the world has to build a proprietary control plane just to make MCP manageable, the protocol is telling you something. It is a useful tool. It is not a foundation.

The Context Window Tax

Here is the core problem. MCP was designed to make it easy for an AI agent to discover and use tools. But "easy to discover" means loading full tool schemas into the agent's context window. Every tool comes with a name, description, JSON schema, field descriptions, enums, and system instructions. Each one costs 550 to 1,400 tokens.

Connect three MCP servers with 40 tools total, and you burn 55,000 tokens before the agent reads a single user message. That is over a quarter of a 200K context window. Gone.

Benchmarks from Scalekit tested 75 head-to-head comparisons between MCP and CLI approaches on the same model, same tasks, same prompts. MCP costs 4x to 32x more tokens for identical operations. The simplest task, checking a repository's language, consumed 1,365 tokens via CLI and 44,026 via MCP.

Cloudflare found that exposing its full Workers API through MCP would consume approximately 1.17 million tokens. Their solution reduced that to roughly 1,000 tokens by having the agent write code against a typed SDK instead.

This is not a tuning problem. This is architectural. The more tools you give an MCP-based agent, the worse it performs. A benchmark across six LLMs showed accuracy degradation as the tool count increased. At 100 tools with ambiguous prompts, one model dropped to coin-flip accuracy. Two OpenAI models failed completely at 150 tools.

If your agent strategy depends on connecting more and more MCP servers, you are building a system that gets dumber as it gets more capable. That is not a scalable architecture.

And even if the context problem did not exist, MCP would still not solve the harder problem: the data itself is often inconsistent, fragmented, and incorrect across systems. Connecting to a system is not the same as trusting what it returns.

The Governance Gap

Context bloat is the visible problem. The less visible one is governance.

MCP gives you a protocol. It does not give you a control plane. It does not give you security policies. It does not give you audit trails. It does not give you consistency across the dozens of MCP servers your engineering teams will inevitably spin up.

Uber learned this firsthand. Their engineers were building MCP servers without central guidance on deployment, security, or standards. The solution was a proprietary gateway and registry that sits on top of MCP. Uber essentially built their own governance layer because MCP does not have one.

An AWS principal engineer and MCP maintainer, Clare Liguori, acknowledged the challenge directly: enterprises are struggling with control. Gateways and registries are "super important for giving them those control points."

She also noted something revealing. Teams are writing Skills, essentially folders of instructions and scripts, just to make MCP tools usable in real workflows. The tools are not self-describing enough on their own. You need a second layer of documentation to tell the agent how to actually use them in context.

That is scaffolding on top of scaffolding.

And at the same Developer Summit, not a single talk mentioned responsible AI or ethical governance at the tool level. For enterprises in regulated industries like finance, healthcare, and government, that is not a footnote. It is a dealbreaker.

Where MCP Actually Works

None of this means MCP is useless. It works well in specific scenarios.

If you have a small, well-defined set of tools for a narrow use case, MCP is fine. It is a good hot dog. Quick, cheap, satisfying for what it is. Looking up an issue, creating a ticket, and fetching a document. Single-system, single-action operations where the tool count stays low and the context tax stays manageable.

It is also useful as a convenience layer on top of an existing agent architecture. If your agent already connects to Oracle Fusion via its own APIs and proprietary tooling, and you want to add a quick Slack notification or pull from Google Sheets, an MCP server can save you half a day of wiring up OAuth flows. That is a legitimate time saver.

The problem is that MCP becomes the architecture rather than a convenience. When every connection, every workflow, every integration runs through MCP servers. When you are loading 40, 80, or 150 tools into context and hoping the model picks the right one. When you have no governance layer, no audit trail, and no control over what your agents are doing across systems.

That is where it breaks.

What 10% Coverage Looks Like in Practice

The abstract argument about context windows and governance becomes concrete when you look at what an MCP toolkit actually delivers for a real enterprise platform.

Composio, one of the leading MCP integration providers, offers a Workday toolkit with 24 tools. Here is what those tools do: check PTO balances, create time off requests, list absence types, get holiday events, retrieve worker profiles, list job postings, pull interview feedback, and access prospect skills and resumes.

That is genuinely useful. An HR chatbot that answers "how much PTO do I have?" or "what open job postings am I managing?" saves time. It is the Answers layer of an enterprise workflow, and it works.

But Workday customers do not buy Workday to check PTO balances. They buy it to run HR operations, process payroll, manage benefits, and handle the lifecycle of every employee from hire to exit. Those workflows cross 4-6 platform boundaries, and the MCP toolkit touches none of them.

Hire to Onboard

A candidate accepts an offer in Workday Recruiting. The Composio toolkit can list the job posting and pull interview feedback. That is the first 10%.

Then the real workflow starts. A background check triggers to First Advantage or HireRight. New hire data pushes to ADP or Ceridian for payroll setup, because most enterprise Workday customers use third-party payroll providers. Benefits enrollment flows to insurance carriers and 401k administrators. IT provisioning fires in Okta or Active Directory. An equipment request lands in ServiceNow or Jira. Compliance training assignments push to Cornerstone or Docebo. A welcome email goes out through the company's communication platform.

Seven systems. Eight handoffs. Business logic at every transition point. The MCP toolkit sees the job posting. It cannot touch the next seven steps.

Payroll Processing

This is where the gap becomes a canyon. Workday has a payroll module, but the majority of enterprise customers process payroll through third-party providers. Workday exports employee data (hours worked, salary changes, tax details, deductions, garnishments) via its Payroll Interface and Payroll Effective Change Interface connectors to ADP, Ceridian, Paychex, or country-specific providers. Payroll results, payslips, and general ledger entries flow back into Workday.

An ADP study found that organizations spend an average of 22 hours per week, per country, managing the data flow between HR and payroll systems. Ninety-four percent of global organizations said they want integration across all of their systems.

The Composio Workday toolkit has zero payroll tools. Not a single one. No PECI connector. No payroll data export. No GL journal entry import. No tax filing integration. The most time-consuming, error-prone, compliance-critical workflow in the entire Workday ecosystem is completely invisible to MCP.

Compensation and Equity

Stock option vesting and RSU events live in equity administration platforms like E*Trade or Morgan Stanley at Work. When shares vest, the tax withholding calculations need to flow into Workday compensation, then downstream to the payroll provider for processing. Getting this wrong means incorrect W-2s, employee tax issues, and compliance risk.

The toolkit has no compensation tools. No equity integration. No tax calculation support.

Benefits Administration

Open enrollment. Life events. Qualifying status changes. Each one triggers data flows from Workday to insurance carriers, broker platforms, HSA providers, and retirement plan administrators. Deadlines are strict. Errors affect employees directly. Compliance requirements vary by state and country.

The toolkit can check absence balances. It cannot enroll an employee in medical coverage, process a qualifying life event, or send enrollment data to a single carrier.

Employee Offboarding

Final payroll run through ADP. Access revocation across Okta and every SaaS application. Asset recovery ticket in ServiceNow. Benefits continuation notification to the carrier. Knowledge transfer documentation. Exit interview scheduling.

The toolkit can list workers. It cannot execute a single step of an offboarding workflow.

The Pattern

Every meaningful Workday workflow crosses at least three platform boundaries. The value, the time savings, the error reduction, the compliance protection, all of that lives in the space between systems. An MCP toolkit that reads data inside one of those systems covers 10-15% of the workflow. The remaining 85% requires agents that understand the business process end-to-end, connect to every system in the chain with deep proprietary tooling, handle exceptions intelligently, and maintain audit trails across every handoff.

The problem is not accessing systems. It is executing the workflow across them with the right data at each step.

That is not an integration problem. It is an engineering problem. And it is why the forward-deployed engineering model exists.

The Vendor-Native Trap

MCP toolkits are shallow from the outside. But the agents that ERP vendors are building inside their own platforms are often shallow from the inside.

Take a recent LinkedIn post from an Oracle Financial Consultant showcasing an AI agent built in Oracle AI Agent Studio. The agent automates invoice inquiries "end-to-end." Here is what it does: the user provides an invoice number they already know, the agent retrieves the invoice details from the database, generates a deep link, and sends an email notification with the link.

That is a database lookup with an email. Oracle BI Publisher has had scheduled report delivery with email notifications for over a decade. OTBI saved searches surface this data on dashboards. Fusion notification workflows route alerts without any AI involvement. A properly configured system would already have the invoice details in a worklist or a scheduled report in the AP manager's inbox before they thought to ask.

And the volume tells the story. Invoice lookups by number in a mid-size AP department happen maybe a few dozen times a week. Each one saves 15 seconds of navigation clicks. The total weekly time savings is measured in minutes, not hours.

A real accounts payable agent would take that invoice, match it against the purchase order and goods receipt, identify the discrepancy, determine whether the variance falls within tolerance, route the exception to the right approver based on amount and category, track the resolution timeline, and post the payment once approved. That workflow spans procurement, receiving, AP, approvals, and treasury. It touches multiple systems. It requires business logic, exception handling, and audit trails. That is where the hours get recovered, not from looking up an invoice number someone already had.

The pattern repeats across vendor-native agent offerings. Our analysis of Oracle AI Agent Studio found 85 available agents, with the overwhelming majority concentrated in SCM and Procurement. Finance and HR coverage is mostly marketing slides and roadmap items. The agents that do exist tend to wrap existing system capabilities in a conversational interface, labeling a read operation as "automation" and a notification as "end-to-end."

MCP toolkits give you shallow reads from the outside. Vendor-native agents give you shallow reads from the inside. Neither one does the work.

The Alternative: Build the Core, Borrow the Rest

There is a different way to build agents for enterprise systems. It starts with a simple principle: own your core connectivity, and use open standards where they save time.

Enterprise workflows do not break because tools are missing. They break because the data is wrong and the execution across systems is fragile. A payroll file exports from Workday with a cost center that changed last Tuesday but has not propagated to ADP yet. A journal entry fails because the GL account mapping between Oracle and the consolidation system is stale. A benefits enrollment triggers downstream but the employee's qualifying event date is inconsistent between HR and the carrier portal. These are data problems and execution problems, not connectivity problems. MCP does not solve any of them.

Dayos is not an integration layer. It is an execution layer for enterprise operations. The difference between a hot dog cart and a commercial kitchen is not the menu board. It is the infrastructure behind the counter.

Our agents connect to Oracle, Workday, SAP, NetSuite, and Dynamics using our own APIs and proprietary tools. We built that connectivity because enterprise ERP systems are not generic SaaS apps. They have complex security models, approval chains, business logic, and transactional state. A generic MCP server cannot understand the difference between a draft journal entry and a posted one. It cannot navigate a three-way match exception. It cannot handle the 462 setup tasks in Oracle's Functional Setup Manager. And it cannot validate the data flowing between systems before acting on it.

Our agents use four reasoning strategies matched to the problem type. They route intelligently between API connectivity and headless browser automation for workflows that vendors lock behind the UI. Every reasoning step is logged and auditable. Every agent is purpose-built by forward-deployed engineers who understand both the AI architecture and the business process. These are not self-serve toolkits. They are engineered outcomes, built and operated by people who know what month-end close actually looks like.

MCP is one tool in our drawer. So is Google's CLI and Agent Skills. So is A2A for invoking vendor-native agents like Oracle AI Agent Studio. So is Composio for the long tail of SaaS integrations where building a custom connector is not justified.

None of these are the architecture. They are accelerants. If any one of them disappears tomorrow, our agents still work.

The Landscape is Splitting

The market for AI agents is splitting into two camps, and the divide is becoming clearer every month.

One camp treats protocols and integration platforms as the foundation. They connect MCP servers, layer on Composio or similar middleware, and ship it as an "agent." This approach is fast to demo but fragile in production. Context bloat, tool accuracy degradation, no governance, no domain expertise. These are the companies that will struggle when a customer asks them to handle a month-end close that spans Oracle GL, a bank reconciliation file, and three spreadsheets nobody wants to talk about.

The other camp builds agents with proprietary tools and deep domain knowledge, then selectively leverages open standards where they help. These companies understand three things that matter to customers.

First, the biggest AI opportunity is not another SaaS tool. It is the existing critical systems where trillions of dollars of business operations already run. Customers do not need a 36th tool in their stack. They need someone who goes into the guts of how their business actually operates, inside Oracle, Workday, SAP, and every system those platforms touch.

Second, services come first. Software follows. The categories where AI creates the most value, like finance, HR, and procurement, are too complex to automate with a self-serve toolkit. You start with engineers who understand the business process, build working automation, and compound that knowledge into software over time. Trying to skip straight to a platform play without domain expertise is how you end up with invoice lookups masquerading as agents.

Third, the sweet spot is work that is complex enough that AI augments humans without replacing them. Month-end close, three-way matching, payroll reconciliation, benefits administration. These are not simple enough for a protocol to solve and not physical enough to resist automation entirely. They are thorny, cross-platform, regulation-heavy processes that reward depth.

Enterprise back-office automation is exactly that kind of category. Too complex for a generic protocol. Too important for a self-serve toolkit. Too cross-platform for a vendor-native agent that only sees inside its own walls.

MCP is a convenience. Use it where it helps. But if someone tells you their agent architecture is built on MCP, ask them what happens when the context window fills up, the tool accuracy drops, and the governance audit comes knocking.

Then ask them who closes the books.