What is Model Context Protocol (MCP)?

Before MCP, connecting an AI agent to an enterprise system meant building a custom integration. Want an agent to read from your data catalog? Write the connector. Your data warehouse? Write another one. Your observability platform? Another one after that. Every new AI use case meant new code to maintain, new failure modes to manage, and engineering work that didn't compound into anything shared. Each integration was its own project, starting from zero.

The Model Context Protocol (MCP) is an open standard that replaces that pattern. Instead of every AI application building its own connector for every tool, MCP defines a protocol both sides agree to implement. An AI agent that speaks MCP can connect to any service that exposes an MCP server. Build the server once, and any compliant AI client can use it.

Anthropic released MCP in November 2024 as an open-source standard. In its December 2025 ecosystem update, Anthropic reported more than 10,000 active public MCP servers and roughly 97 million monthly SDK downloads. OpenAI, Google, and Microsoft have all adopted the specification, and developer tools including Visual Studio Code, Cursor, and GitHub Copilot support MCP natively. According to Stacklok's 2026 software report, 41% of surveyed software organizations are running MCP servers in limited or broad production.

MCP is no longer a bet on a future ecosystem. It's the default infrastructure choice for enterprise AI agent connectivity.

MCP replaces custom integrations with a shared protocol

MCP follows a client-server architecture. Three participants are involved in every interaction: the host, the client, and the server.

The host is the AI application: Claude Desktop, Visual Studio Code, Claude Code, GitHub Copilot CLI, or a custom enterprise application running a language model. The host manages the overall agent experience and coordinates connections to multiple external services simultaneously.

The client lives inside the host. When the host connects to an external service, it creates an MCP client to manage that specific connection. A host running connections to five different services manages five MCP clients, each independently maintaining its own connection.

The server is the external service (your data catalog, your observability platform, your ticketing system) that exposes capabilities to AI clients through the MCP protocol. Servers can run locally on the same machine, using standard input and output streams, or remotely over HTTP.

What a server exposes falls into three types, defined by the MCP specification:

Tools are executable functions an agent can invoke: check data quality on a table, run a database query, profile a dataset, trace lineage on a column. Tools are how agents take actions in external systems rather than just reading from them.

Resources are data sources the agent can read for context: file contents, database records, API responses. Where a tool performs an action, a resource provides information.

Prompts are reusable interaction templates that help structure recurring workflows: system instructions for a specific task type, or few-shot examples that help the agent perform consistently across similar requests.

For most enterprise data teams, tools are where the practical value shows up first. When an agent has access to a data quality tool through MCP, it can check whether a table has open quality issues in the same workflow where it's querying that table, without a human pulling the information from a separate interface and pasting it into the conversation.

Stdio and HTTP: two transports that determine where MCP servers run

MCP supports two transport mechanisms, which determine how the host and server communicate.

Stdio transport runs the server as a local process on the same machine as the host, communicating through standard input and output streams. This works well for developer tools and local agent workflows where the data doesn't need to leave the machine.

Streamable HTTP transport communicates over HTTP, enabling remote servers to serve many clients simultaneously. This is the transport formalized in the July 28, 2026 MCP specification update, and it's what makes enterprise-scale MCP deployment practical. Servers can run on standard cloud infrastructure, scale horizontally, and fit into existing reliability and monitoring setups without modification.

The July 28 update also made MCP fully stateless. Every request now carries all the information needed to process it. Servers don't retain session state between requests. This brings MCP in line with standard REST API patterns, which means the infrastructure skills and tooling data engineering teams already use apply directly to running MCP servers in production.

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

Why data teams are paying attention now

MCP's significance for data teams isn't primarily technical. It's about what happens to deployment pace when the cost of connecting agents to enterprise systems drops.

Before MCP, the engineering overhead of agent connectivity acted as an unofficial constraint on how many agents an organization could run. Building and maintaining custom integrations consumed engineering capacity. Teams ran fewer agents than they might have, across fewer systems, with longer cycles between iterations.

MCP removes much of that overhead. When connecting an agent to a new data system takes hours rather than weeks, organizations can deploy more agents, across more systems, at faster cycles. The constraint on how many agents an enterprise runs shifts from engineering capacity to intent and governance.

That shift matters for data teams because manual governance approaches don't scale alongside growing agent fleets. Organizations managing AI activity through manual reviews and periodic audits will find that model breaks down as the number of agents grows. The questions data teams have always asked about pipelines and business intelligence (where did this data come from, is it accurate, who's accountable for what happened downstream) don't get simpler when an organization runs dozens of agents simultaneously against the same data. They get harder to answer without infrastructure designed to support them.

Data teams that already have governance frameworks for their pipelines are doing most of the analytical work that AI agent governance requires. The next step is extending that work to cover agent activity specifically, using the same observability and lineage signals already in place.

Bigeye's MCP Server puts data context directly into the agent workflow

Getting data quality, lineage, and catalog context into an AI agent workflow currently requires a manual step: look up the information in Bigeye, copy it, paste it into the chat. Bigeye's MCP Server (currently in Beta) removes that step.

An agent running on Claude Code, Snowflake Cortex Code, or GitHub Copilot CLI can check quality issues on a table, trace lineage, search the catalog, profile a dataset before analysis, or manage monitors and dimensions, all from within the agent workflow. The server is available at mcpgateway.bigeye.com/mcp and is open source for teams that need to self-host in air-gapped environments.

The Agent Trust Hub operates alongside the MCP Server at the governance layer. As agents interact with Bigeye through MCP, those interactions become part of the audit record: which data each agent accessed, which quality issues it encountered, and which lineage paths it queried. For data teams running agents at scale, that record answers governance questions without requiring manual review of individual agent sessions.