Introduction
Your AI agent can write SQL. It can summarize text, reason about user intent, and call external APIs. But when a customer asks "Where is my order right now?", the agent hits a wall: the data it can access is hours old, trapped in a batch pipeline that refreshes on a schedule.
This is the core limitation of connecting AI agents to traditional databases. The Model Context Protocol (MCP) gives agents a standardized way to query data sources, but if the data source itself serves stale results, the agent's answers are stale too. An MCP streaming database changes this equation. Instead of querying batch-refreshed tables, agents query materialized views that stay current with sub-second latency as new events arrive.
RisingWave is a streaming database that speaks PostgreSQL wire protocol and maintains materialized views incrementally. This means any PostgreSQL-compatible MCP server can connect to RisingWave directly, and every materialized view becomes a tool that AI agents can discover and query. In this post, you will learn how to set up this integration, write materialized views that agents can use effectively, and see practical examples of agents querying live data.
What Is the Model Context Protocol and Why Does It Matter for Databases?
The Model Context Protocol (MCP) is an open standard created by Anthropic for connecting AI models to external data sources and tools. Think of it as a universal adapter: instead of writing custom integrations for every combination of AI model and data source, MCP provides a single protocol that both sides can implement.
MCP defines three core primitives:
- Tools: Functions that the AI model can execute (model-controlled)
- Resources: Context and data that the application provides (app-controlled)
- Prompts: Templated messages and workflows (user-controlled)
For database access, the "tools" primitive is the most relevant. An MCP server exposes database operations as tools that agents can call. When an agent needs data, it calls the appropriate tool, the MCP server translates the request into a SQL query, executes it against the database, and returns the results.
Why Databases Are the Most Important MCP Data Source
Agents can connect to APIs, file systems, and web services through MCP. But databases hold the structured, queryable data that powers most business-critical questions: customer records, order histories, system metrics, financial transactions. When a support agent needs to look up an order status, or a sales agent needs pipeline data, the answer lives in a database.
Several MCP servers already exist for databases: the official PostgreSQL MCP server, Microsoft's SQL Server MCP, Oracle's SQLcl integration, and more. The infrastructure for agent-to-database connectivity is maturing fast.
The Gap: Batch Data vs. Live Data
Here is the problem most teams overlook. Connecting an agent to a database through MCP is straightforward. Connecting it to fresh data is not.
Traditional data warehouses and batch pipelines refresh on schedules: every 15 minutes, every hour, or once a day. When an agent queries these systems, it gets answers based on the last refresh. A customer asks "Has my refund been processed?" and the agent confidently responds based on data that is 30 minutes old, missing the refund that completed 5 minutes ago.
An MCP streaming database eliminates this gap. RisingWave maintains materialized views that update continuously as new events flow in from Kafka, PostgreSQL CDC, or other sources. When an agent queries a materialized view, it gets the current state, not a stale snapshot.
How Does RisingWave Integrate with MCP for Agent-Ready Data?
RisingWave provides two paths for MCP integration. Both leverage the fact that RisingWave is PostgreSQL wire-compatible, so any tool that connects to PostgreSQL can connect to RisingWave.
Path 1: The Official PostgreSQL MCP Server
The simplest approach uses Anthropic's official PostgreSQL MCP server. Since RisingWave speaks PostgreSQL protocol, you just point the server at your RisingWave instance.
Configure it in your Claude Desktop claude_desktop_config.json:
{
"mcpServers": {
"risingwave": {
"command": "npx",
"args": [
"-y",
"@modelcontextprotocol/server-postgres",
"postgresql://root:root@localhost:4566/dev"
]
}
}
}
This gives the agent read-only access to all tables and materialized views in RisingWave. The agent can inspect schemas and run SELECT queries.
Path 2: The RisingWave MCP Server
For deeper integration, RisingWave provides a dedicated MCP server with 100+ tools that go beyond basic queries. This server supports creating and managing materialized views, monitoring streaming jobs, inspecting cluster health, and more.
Configure it in Claude Desktop:
{
"mcpServers": {
"risingwave-mcp": {
"command": "python",
"args": ["/path/to/risingwave-mcp/src/main.py"],
"env": {
"RISINGWAVE_CONNECTION_STR": "postgresql://root:root@localhost:4566/dev"
}
}
}
}
Or in VS Code's .vscode/mcp.json:
{
"servers": {
"risingwave-mcp": {
"type": "stdio",
"command": "python",
"args": ["/path/to/risingwave-mcp/src/main.py"],
"env": {
"RISINGWAVE_CONNECTION_STR": "postgresql://root:root@localhost:4566/dev"
}
}
}
}
The dedicated server exposes tools like list_materialized_views, describe_materialized_view, run_select_query, and create_materialized_view, giving the agent full awareness of what data is available.
Materialized Views as Agent-Discoverable Tools
The key design pattern is this: each materialized view becomes a purpose-built data endpoint that agents can discover, understand, and query. Instead of asking agents to write complex SQL against raw tables, you pre-build the views that answer specific business questions.
Here is a complete example. First, set up the source data from Kafka:
-- Ingest order events from Kafka
CREATE SOURCE order_events (
order_id INT,
customer_id INT,
product VARCHAR,
amount DECIMAL,
status VARCHAR,
updated_at TIMESTAMP
) WITH (
connector = 'kafka',
topic = 'orders',
properties.bootstrap.server = 'kafka:9092'
) FORMAT PLAIN ENCODE JSON;
-- Ingest inventory updates
CREATE SOURCE inventory_events (
product_id INT,
product_name VARCHAR,
warehouse VARCHAR,
quantity INT,
updated_at TIMESTAMP
) WITH (
connector = 'kafka',
topic = 'inventory',
properties.bootstrap.server = 'kafka:9092'
) FORMAT PLAIN ENCODE JSON;
Now create materialized views designed for agent consumption:
-- View: Live order status for customer support agents
CREATE MATERIALIZED VIEW live_order_status AS
SELECT
order_id,
customer_id,
product,
amount,
status,
updated_at
FROM order_events;
COMMENT ON TABLE live_order_status IS
'Current status of all orders. Use this to look up order status by order_id or customer_id. Returns the latest status for each order.';
-- View: Real-time inventory levels for operations agents
CREATE MATERIALIZED VIEW current_inventory AS
SELECT
product_name,
warehouse,
SUM(quantity) AS total_quantity
FROM inventory_events
GROUP BY product_name, warehouse;
COMMENT ON TABLE current_inventory IS
'Real-time inventory levels by product and warehouse. Query this to check stock availability before confirming order fulfillment.';
-- View: Revenue summary for sales and finance agents
CREATE MATERIALIZED VIEW revenue_by_product AS
SELECT
product,
COUNT(*) AS order_count,
SUM(amount) AS total_revenue,
AVG(amount) AS avg_order_value
FROM order_events
WHERE status = 'completed'
GROUP BY product;
COMMENT ON TABLE revenue_by_product IS
'Revenue metrics grouped by product. Only includes completed orders. Use this for sales performance questions.';
All SQL examples target RisingWave v2.3 syntax. Verify against the RisingWave SQL reference for the latest changes.
The COMMENT ON statements are critical. When an agent connects through MCP and lists the available tables, these comments appear as descriptions. The agent uses them to decide which view to query for a given question. Clear, specific comments turn your materialized views into self-documenting tools.
What Can AI Agents Do with MCP-Connected Materialized Views?
With materialized views exposed through MCP, agents can answer questions that require fresh, structured data. Here are three practical scenarios.
Use Case 1: Customer Support Agent with Live Order Data
A customer writes to support: "I placed order #4521 two hours ago. Has it shipped yet?"
The agent's interaction flow:
- Agent receives the customer question
- Agent calls
list_materialized_viewsto discover available data - Agent reads the comment on
live_order_status: "Current status of all orders..." - Agent calls
run_select_querywith:
SELECT order_id, status, product, amount, updated_at
FROM live_order_status
WHERE order_id = 4521;
Expected result:
order_id | status | product | amount | updated_at
----------+---------+---------+---------+---------------------
4521 | shipped | Laptop | 1299.00 | 2026-03-29 14:22:00
- Agent responds: "Your order #4521 for a Laptop ($1,299.00) shipped about 30 minutes ago."
Because the materialized view updates continuously from the Kafka source, the agent sees the latest status, not a batch snapshot from hours ago.
Use Case 2: Sales Agent with Real-Time Pipeline Context
A sales manager asks the agent: "Which products drove the most revenue this month?"
The agent queries the revenue_by_product view:
SELECT product, order_count, total_revenue, avg_order_value
FROM revenue_by_product
ORDER BY total_revenue DESC
LIMIT 5;
Expected result:
product | order_count | total_revenue | avg_order_value
------------+-------------+---------------+-----------------
Laptop | 342 | 410580.00 | 1200.52
Monitor | 287 | 132825.00 | 462.80
Tablet | 198 | 118602.00 | 599.00
Headphones | 451 | 67650.00 | 150.00
Keyboard | 623 | 49215.00 | 79.00
The agent gets numbers that reflect every completed order up to this moment, including the ones that closed in the last few minutes.
Use Case 3: Operations Agent Monitoring System Health
For infrastructure monitoring, create materialized views over metrics data:
CREATE SOURCE system_metrics (
host VARCHAR,
metric_name VARCHAR,
metric_value DOUBLE PRECISION,
recorded_at TIMESTAMP
) WITH (
connector = 'kafka',
topic = 'metrics',
properties.bootstrap.server = 'kafka:9092'
) FORMAT PLAIN ENCODE JSON;
CREATE MATERIALIZED VIEW host_health_summary AS
SELECT
host,
MAX(CASE WHEN metric_name = 'cpu_usage' THEN metric_value END) AS cpu_usage,
MAX(CASE WHEN metric_name = 'memory_usage' THEN metric_value END) AS memory_usage,
MAX(CASE WHEN metric_name = 'disk_usage' THEN metric_value END) AS disk_usage,
MAX(recorded_at) AS last_seen
FROM system_metrics
GROUP BY host;
COMMENT ON TABLE host_health_summary IS
'Latest CPU, memory, and disk usage per host. Use this to check if any server is overloaded or unresponsive.';
An on-call engineer asks the agent: "Are any hosts running hot right now?"
SELECT host, cpu_usage, memory_usage, disk_usage, last_seen
FROM host_health_summary
WHERE cpu_usage > 80 OR memory_usage > 85
ORDER BY cpu_usage DESC;
Expected result:
host | cpu_usage | memory_usage | disk_usage | last_seen
-------------+-----------+--------------+------------+---------------------
web-prod-03 | 94.2 | 87.1 | 62.0 | 2026-03-29 15:01:12
api-prod-07 | 82.5 | 91.3 | 71.4 | 2026-03-29 15:01:08
The agent flags exactly which hosts need attention, based on metrics that are seconds old.
The Architecture at a Glance
Kafka / CDC Sources → RisingWave → Materialized Views → MCP Server → AI Agent (Claude / Copilot) → User
Data flows from event sources into RisingWave, which maintains materialized views incrementally. The MCP server exposes those views as queryable tools. The agent discovers and queries them on behalf of users.
FAQ
What is an MCP streaming database?
An MCP streaming database is a database that integrates with the Model Context Protocol while maintaining continuously updated data. RisingWave fits this definition because it supports MCP connections through PostgreSQL compatibility and keeps materialized views fresh through incremental maintenance, giving AI agents access to live data rather than stale batch snapshots.
Can I use the standard PostgreSQL MCP server with RisingWave?
Yes. RisingWave implements PostgreSQL wire protocol, so the official @modelcontextprotocol/server-postgres package connects to RisingWave without any modifications. Point it at your RisingWave instance using a standard PostgreSQL connection string (e.g., postgresql://root:root@localhost:4566/dev), and it works out of the box.
How do MCP tools differ from regular SQL views for AI agents?
MCP tools provide a structured discovery layer on top of SQL. When an agent connects through MCP, it can list available tables and views, read their comments and schemas, and then decide which to query. Regular SQL views require the agent to already know the schema. With MCP, the agent learns what data is available at runtime, making it more autonomous.
Do materialized views in RisingWave update automatically for MCP queries?
Yes. Unlike traditional databases where materialized views require manual REFRESH commands, RisingWave uses incremental maintenance to update views continuously as source data changes. Every MCP query against a materialized view returns the latest state with sub-second freshness, without any scheduled refresh jobs.
Conclusion
Key takeaways:
- MCP standardizes agent-to-database connectivity, but the freshness of the underlying data determines how useful the agent's answers are.
- RisingWave's PostgreSQL compatibility means it works with existing PostgreSQL MCP servers out of the box, with no special adapters needed.
- Materialized views become agent tools when you pair them with descriptive
COMMENT ONmetadata that helps agents understand what each view provides. - The dedicated RisingWave MCP server offers 100+ tools for deeper integration, including streaming job monitoring and view management.
- Real-time data makes agents reliable: when a customer asks about order status, the agent returns the current answer, not yesterday's snapshot.
Ready to try this yourself? Try RisingWave Cloud free - no credit card required. Sign up here.
Join our Slack community to ask questions and connect with other stream processing developers.
