Kevin McGahey Updated 9 min read

The Agent Framework Wars Are Over — The Data Layer Won

Six competing agent frameworks, 120+ tools, and a 1,445% surge in enterprise interest. But the real battle was never about which framework wins — it's about how agents access your data. MCP just settled that question.

mcpai-agentsdatabaseagent-frameworksenterprise

There are now six production-grade AI agent frameworks competing for your codebase. LangGraph hit 1.0 GA and climbed to v1.0.10. CrewAI crossed 44,600 GitHub stars. OpenAI shipped the Agents SDK (v0.10.2), Anthropic released the Claude Agent SDK (v0.1.48), Google launched ADK at v1.26.0, and HuggingFace built Smolagents. StackOne mapped 120+ agentic AI tools across 11 categories.

Gartner reported a 1,445% surge in multi-agent system inquiries from Q1 2024 to Q2 2025. They predict 40% of enterprise applications will include task-specific AI agents by end of 2026, up from less than 5% today.

Everyone is building agents. The question nobody is asking: what are those agents going to read and write?

The Framework Doesn’t Matter If Your Agent Can’t Reach the Database

Here’s what every single one of those frameworks has in common: they need data. Not training data — live, operational, production data sitting in your PostgreSQL, MySQL, SQL Server, or Oracle databases.

You can spend weeks evaluating LangGraph vs CrewAI vs the OpenAI Agents SDK. You can architect the most elegant multi-agent system with specialized agents for reasoning, planning, and execution. But the moment one of those agents needs to look up a customer record, check inventory, or verify a transaction, you hit the same wall: how does an AI agent safely access a database?

The answer used to be “write custom integration code.” For each framework. For each database. For each table. That’s the kind of work that turns a 2-week prototype into a 6-month project.

MCP Won the Protocol War Before It Started

The Model Context Protocol has crossed 97 million monthly SDK downloads across Python and TypeScript. Every major AI provider has adopted it: Anthropic, OpenAI, Google, Microsoft, Amazon. It’s now governed by the Agentic AI Foundation under the Linux Foundation, co-founded by OpenAI, Anthropic, Google, Microsoft, AWS, and Block.

But the real signal isn’t the download numbers — it’s who shipped MCP servers in March 2026 alone:

  • Oracle announced the Oracle Autonomous AI Database MCP Server on March 24, supporting database versions 19c through 26ai. Enterprise-grade auditing, security policy enforcement, schema discovery — all exposed through MCP.
  • Google released the open-source Colab MCP Server on March 17, letting any MCP-compatible agent access cloud compute environments directly.
  • Datadog launched their MCP server for real-time observability data, giving agents secure access to monitoring and alerting context.

When Oracle — the company that once filed lawsuits over API compatibility — ships an MCP server for their flagship database, the protocol war is over. MCP is the data layer.

The Architecture That Actually Matters

The agentic AI field is going through what SiliconANGLE calls its “microservices revolution.” Single all-purpose agents are being replaced by orchestrated teams of specialized agents. But just like microservices needed a standardized way to communicate (HTTP, gRPC, message queues), multi-agent systems need a standardized way to access data.

The emerging stack looks like this:

┌─────────────────────────────────────────────┐
│           Your Agent Framework               │
│  (LangGraph / CrewAI / OpenAI / Anthropic)  │
├─────────────────────────────────────────────┤
│         MCP (Model Context Protocol)         │
│        The universal data access layer       │
├─────────────────────────────────────────────┤
│    Database REST API + MCP Server            │
│    (Faucet / Oracle MCP / Custom)            │
├─────────────────────────────────────────────┤
│         Your Production Database             │
│  (PostgreSQL / MySQL / SQL Server / Oracle)  │
└─────────────────────────────────────────────┘

The framework at the top can change — and it will. CrewAI shipped native MCP and A2A support in v1.10.1. LangGraph has MCP adapters. The OpenAI Agents SDK works with 100+ non-OpenAI models. The framework is becoming commodity.

The data layer is what stays constant. And the data layer is what determines whether your agent can actually do useful work.

Why “Just Connect to the Database” Is a Terrible Idea

The obvious shortcut is giving agents raw database access. Write an MCP tool that executes arbitrary SQL. Ship it. It works in the demo.

Then it destroys production data.

We covered this in depth in our post on AI agent security incidents — 88% of organizations report security incidents related to AI agent access. The three most common attack vectors are:

  1. Raw SQL access — agents generating and executing unvalidated queries
  2. Shared credentials — a single database user for all agent operations
  3. No audit trails — no way to trace which agent modified which records

Oracle’s new MCP server acknowledges this problem directly. Their implementation enforces database security policies, manages schema discovery permissions, and provides enterprise-grade auditing. That’s not accidental — it’s a response to real production failures.

But Oracle’s solution only works for Oracle databases. What about the PostgreSQL instance running your SaaS product? The MySQL database behind your e-commerce platform? The SQL Server warehouse your analytics team queries?

The Multi-Database Problem

Here’s the reality of enterprise data in 2026: nobody runs a single database. The average enterprise has data spread across 3-5 different database engines. Your agents need to access all of them, with consistent security, consistent APIs, and consistent MCP tool interfaces.

This is where the framework wars become truly irrelevant. Whether you’re using LangGraph or CrewAI, your agent still needs to:

  1. Discover what tables and columns exist
  2. Query data with proper filtering, pagination, and field selection
  3. Create, update, and delete records with validation
  4. Respect role-based access control per table and per operation
  5. Expose all of this through MCP with correct tool annotations

Building that for one database is a project. Building it for seven databases is a career.

How Faucet Solves This in 60 Seconds

Faucet is a single binary that connects to your SQL database — PostgreSQL, MySQL, MariaDB, SQL Server, Oracle, SQLite, or Snowflake — and serves a complete REST API with a built-in MCP server. No code generation. No configuration files. No framework lock-in.

# Install
brew install faucetdb/tap/faucet

# Connect your PostgreSQL database and start the server
faucet db add --name myapp --driver postgres --dsn "postgres://user:pass@localhost:5432/myapp"
faucet serve

# That's it. You now have:
# - REST API at /api/v1/myapp/_table/{table} on port 8080
# - MCP server at /mcp
# - OpenAPI 3.1 spec at /openapi.json
# - Admin UI at /

Every database gets the same eight MCP tools (faucet_list_tables, faucet_describe_table, faucet_query, faucet_insert, and so on), each with proper annotations:

{
  "name": "faucet_query",
  "description": "Query records from a database table with optional filtering, field selection, ordering, and pagination...",
  "annotations": {
    "readOnlyHint": true
  }
}

Your agents — regardless of framework — can discover tables, query with filters, and write data through a governed API layer. The MCP tool annotations tell the agent (and the human supervising it) which operations are read-only and which can change data.

Connecting Faucet to Any Agent Framework

Because Faucet speaks MCP natively, it works with every framework that supports the protocol.

With Claude Desktop or Claude Code:

{
  "mcpServers": {
    "faucet": {
      "command": "faucet",
      "args": ["mcp"]
    }
  }
}

With any MCP-compatible agent (Streamable HTTP, role-scoped by API key):

faucet serve
# MCP endpoint: http://localhost:8080/mcp  (send X-API-Key: faucet_YOUR_KEY)

With HTTP-based agent frameworks (REST API):

# Start the server
faucet serve

# Agents call the REST API directly
curl -H "X-API-Key: faucet_YOUR_KEY" \
  "http://localhost:8080/api/v1/myapp/_table/customers?filter=status%20%3D%20'active'&limit=10"

The point isn’t which method you use. The point is that switching from CrewAI to LangGraph to the OpenAI Agents SDK doesn’t require touching your data layer at all. Faucet stays the same. The API stays the same. The MCP tools stay the same. The RBAC policies stay the same.

Multi-Database, Same Interface

Where Faucet diverges from Oracle’s MCP server (which only supports Oracle) or one-off solutions is multi-database support. The same binary, the same API patterns, the same MCP tools — across seven database engines: PostgreSQL, MySQL, MariaDB, SQL Server, Oracle, SQLite, and Snowflake.

# PostgreSQL
faucet db add --name pg --driver postgres --dsn "postgres://user:pass@localhost:5432/app"

# MySQL (MariaDB uses the same driver)
faucet db add --name shop --driver mysql --dsn "user:pass@tcp(localhost:3306)/app?parseTime=true"

# SQL Server
faucet db add --name warehouse --driver mssql --dsn "sqlserver://user:pass@localhost:1433?database=app"

# Oracle
faucet db add --name erp --driver oracle --dsn "oracle://user:pass@localhost:1521/ORCL"

# SQLite
faucet db add --name local --driver sqlite --dsn "/path/to/data.db"

# Snowflake
faucet db add --name analytics --driver snowflake --dsn "user:pass@account/db/schema?warehouse=WH"

# SQL Server on Azure, PostgreSQL on RDS, Oracle on-prem — same command

An agent that knows how to call faucet_query against PostgreSQL can call faucet_query against MySQL with zero changes. The query syntax differences, type mapping variations, and pagination quirks are handled by Faucet, not by your agent code.

RBAC That Travels with the Agent

When Gartner says 40% of enterprise apps will include AI agents by end of 2026, the unspoken requirement is access control. You can’t give every agent full database access.

Faucet’s RBAC system lets you define roles with per-table, per-verb permissions:

# Create a read-only role for analytics agents
faucet role create --name analytics-reader
faucet role grant --role analytics-reader --service myapp --component "_table/customers" --verbs GET
faucet role grant --role analytics-reader --service myapp --component "_table/orders" --verbs GET

# Create a role for order-processing agents: read and update orders, never delete
faucet role create --name order-processor
faucet role grant --role order-processor --service myapp --component "_table/orders" --verbs GET,PATCH

# Bind an API key to each role
faucet key create --role analytics-reader --label analytics-agent

Anything not granted is denied, so order-processor cannot delete orders or touch any other table.

The role travels with the API key. Regardless of which agent framework calls the API, the permissions are enforced at the data layer. Your LangGraph agent gets the same access controls as your CrewAI agent. Swap frameworks, keep your security posture.

The Next 12 Months

The MCP ecosystem is accelerating. The 2026 roadmap acknowledges real gaps in auth, observability, gateway patterns, and configuration portability — and the community is closing them fast. CData projects the MCP market will reach $10 billion by the end of the year.

Here’s what this means for your agent architecture decisions:

  1. Don’t over-invest in framework-specific integrations. The framework layer is churning too fast. What matters is the data layer underneath.

  2. Standardize on MCP for data access. It’s governed by the Linux Foundation, adopted by every major AI provider, and being baked into enterprise databases by Oracle itself.

  3. Treat your database API as infrastructure, not application code. Just like you don’t hand-write HTTP servers anymore, you shouldn’t hand-write database-to-API layers for agents.

  4. Enforce access control at the data layer, not the agent layer. Agents will be swapped, upgraded, and replaced. Your RBAC policies shouldn’t need to change when that happens.

The agent framework wars make for great blog posts and conference talks. But the teams shipping agents to production in 2026 aren’t debating LangGraph vs CrewAI. They’re making sure their data layer is solid, secure, and framework-agnostic.

The framework is the part that changes. The data layer is the part that lasts.

Getting Started

Get a governed, MCP-enabled database API running in under a minute:

# Install Faucet
brew install faucetdb/tap/faucet

# Point it at your database and start it
faucet db add --name myapp --driver postgres --dsn "postgres://user:pass@localhost:5432/myapp"
faucet serve

# Your agents can now access data through REST or MCP
# with proper tool annotations and RBAC

Works with PostgreSQL, MySQL, MariaDB, SQL Server, Oracle, SQLite, and Snowflake. Single binary, no dependencies, MIT licensed.

Google's gRPC Transport for MCP: What It Signals About the Database API Stack

Google is pushing gRPC as a first-class MCP transport alongside stdio and HTTP/SSE. The interesting story isn't the protocol buffers — it's what 'pluggable transports' means for the data layer that sits behind every MCP server.

Every Enterprise Needs an MCP Gateway — Your Database Is the First Thing Behind It

The MCP Dev Summit consensus is clear: gateways are the architecture for production AI agents. Uber, AWS, Docker, and Kong are all building them. But a gateway without a database layer behind it is a router with nowhere to route. Here's how the new agent architecture actually works.

Oracle Just Built MCP Into Its Database — Here's Why Every Database Needs One

Oracle's Autonomous AI Database MCP Server validates that database-to-agent connectivity is the next infrastructure layer. But you don't need Oracle's database to give your agents structured data access.