What the July 28 MCP update means for enterprise data and AI teams

On July 28, 2026, the Model Context Protocol specification added Streamable HTTP transport, enabling stateless request handling for AI agent connections. For most enterprise teams, the announcement read as an infrastructure detail. The implications run deeper than that.

AI agents have always been able to connect to tools and data sources via MCP. What previously required persistent server-side infrastructure (processes that maintained session state across requests, connections that needed to stay open) can now operate over standard HTTP request-response cycles. Agents connect, query, and disconnect. The cloud deployment patterns that power every API service now apply to AI agent connectivity.

The practical barrier to deploying production AI agents just dropped significantly.

What is MCP?

The Model Context Protocol (MCP) is an open standard for connecting AI agents to external tools, data sources, and services. Developed by Anthropic and now broadly adopted, it provides a consistent interface so agents built on any model can interact with enterprise systems (databases, APIs, documentation, and internal tooling) without custom integrations for each connection.

MCP defines how an agent sends a request to a tool, how the tool responds, and how the agent incorporates that response into its reasoning. Instead of building bespoke connectors for every AI use case, organizations implement MCP once per system and any compliant agent can use it.

This piece covers the July 28 update specifically. A longer introduction to MCP for enterprise teams is available here.

What changed on July 28

The original MCP transport relied on HTTP with Server-Sent Events (SSE), a model in which the server kept a connection open and pushed events to the client over time. That approach worked for many scenarios but required persistent connection management, dedicated server processes, and infrastructure patterns most enterprise teams do not run for standard APIs.

The July 28 update replaces that model with Streamable HTTP transport. Each request is now independent. The server processes it, returns a response, and holds no state between requests. Agents can run on serverless infrastructure, auto-scaling containers, or standard cloud services without the overhead of managing persistent connections.

Stateful vs. stateless MCP

Stateful MCP requires the server to maintain session context between requests. The connection stays open. The server tracks what has been exchanged, and each subsequent request can reference prior state. This model works well for long-running, conversational interactions but demands dedicated infrastructure to manage those open connections.

Stateless MCP treats each HTTP request as self-contained. The server processes the request and returns a response without storing session information. This is the default pattern for REST APIs. It scales horizontally, deploys to standard cloud infrastructure, and fits into existing monitoring and reliability tooling without modification.

The July 28 update made stateless operation a first-class option in the MCP specification. Teams that previously avoided MCP because of the infrastructure requirements can now implement it using the same patterns they apply to any other API service.

The accidental safeguard that no longer applies

Early AI deployments benefited from an accidental safeguard. Scarcity.

Connecting an AI agent to enterprise systems required significant engineering effort. That friction was not a feature anyone designed. It was a consequence of immature tooling and the absence of standard protocols. But it had a practical effect: organizations deployed slowly. The number of agents operating in any environment stayed low. Governance was possible, if imperfect, because the surface area remained manageable.

MCP changed the connectivity picture. The July 28 update changes the deployment picture. When connecting an agent to enterprise infrastructure takes hours rather than weeks, the constraint on how many agents an organization runs becomes intent, not engineering capacity.

More agents means governance cannot wait

As MCP lowers the operational cost of agent deployment, organizations will run more agents, across more systems, at faster iteration cycles. That is the straightforward consequence of removing infrastructure friction. It is also where the governance challenge shifts from theoretical to operational.

Organizations that have managed AI governance through manual review and periodic audits will find that model becomes unsustainable. At machine speed, agents retrieve information, execute logic, and surface outputs faster than any review process can track them individually. An agent fleet of dozens or hundreds makes the agent-by-agent inspection model impractical not because anyone designed it that way, but because volume outpaces the approach.

The questions that emerge (what data did each agent access, was that data accurate, who is accountable for the output, what happens when an agent acts on stale or classified information) are not new questions. They are the same questions data teams have always applied to analytics pipelines and business intelligence. MCP's maturation simply makes the timeline more urgent. Teams that answer these questions now, before the agent fleet scales, are in a fundamentally different position than those that address them after an incident.

Trust must be part of the infrastructure

At scale, manual review no longer works. Trust must become part of the infrastructure itself, not a process applied after deployment but a continuous capability operating alongside it.

That means understanding not only what an agent is doing, but also the quality, lineage, ownership, and policy context of the data informing those decisions. Governance becomes an operational capability rather than a compliance exercise performed after the fact.

Data observability already addresses many of these questions for analytics pipelines and business intelligence systems. It helps organizations understand where data originates, how it moves through systems, whether it remains healthy, and which downstream consumers depend on it. Applying those same principles to AI agents provides the foundation for trustworthy enterprise AI.

Where Bigeye fits

Bigeye ships an MCP Server (currently in Beta) that gives AI agents direct access to the capabilities enterprise data teams rely on for quality monitoring, lineage, and catalog management.

An agent running on Claude Code, Snowflake Cortex Code, or GitHub Copilot CLI can interact with Bigeye the same way a developer would: checking whether a table has open quality issues, tracing the lineage of a dataset, searching the catalog for relevant sources, profiling a table before running analysis, or managing monitors and dimensions. Those interactions happen from within the agent workflow, not through a separate lookup in the Bigeye interface.

The practical difference is in the interface. Before the MCP Server, a data engineer working with an AI agent needed to pull quality issues or lineage from the Bigeye UI and paste relevant context into the conversation. With the MCP Server, the agent queries Bigeye directly. Context about data quality, sensitivity, and lineage arrives in the agent's workflow without a human intermediary.

Bigeye MCP Server documentation covers setup for each supported client, available tools, and configuration options.

The Agent Trust Hub operates at the governance layer alongside the MCP Server. As agents interact with Bigeye through the MCP protocol, those interactions become part of the audit record: which data was accessed, which quality issues the agent encountered, which lineage paths it queried. Organizations deploying agents at scale can see what their agents are doing and verify that they are operating on trustworthy data.

Today, Bigeye observes more than 100 million lineage relationships and over 15 trillion rows of data across enterprise environments. USAA, Zoom, Hertz, and Cisco rely on that operational foundation to understand how data moves through complex systems. The MCP Server extends that foundation into the agent layer, not as a separate product but as a direct interface to the same platform.

Infrastructure is maturing. Trust is the next constraint.

The July 28 MCP update represents a meaningful step toward AI agent infrastructure that operates on familiar cloud-native deployment patterns. As the operational burden of connectivity decreases, organizations can focus more attention on deploying AI at scale.

That evolution also changes where the hardest problems live. Connecting agents to enterprise systems is becoming increasingly standardized. Ensuring those agents access the right data, operate within policy, and produce decisions organizations can explain and audit remains the more difficult challenge.

Enterprise AI will increasingly be defined not simply by how many agents an organization can deploy, but by how confidently it can trust them in production. The organizations that build that confidence will do so through the same discipline applied to data infrastructure: continuous monitoring, clear lineage, and governance that operates at the same scale as the systems it oversees.

Learn more about Bigeye's MCP Server and Agent Trust Hub.