RisingWave MCP for AI. Process, ingest, and query real-time data streams.
Gemini Works with every AI agent you already use
…and any MCP-compatible client
How this MCP server connects to your AI agent
RisingWave provides direct access to your real-time streaming database via an MCP Server. You can execute full SQL statements (DDL/DML), stream raw JSON events into tables, and list all data components—including sources, sinks, and materialized views—all through natural conversation with your AI client.
What AI agents can do with RisingWave (Streaming Database) Automation
Execute sql
Runs any full SQL statement against the database, allowing reading and writing of data.
Ingest events
Feeds streaming JSON records directly into a target table for immediate processing.
List materialized views
Retrieves the names and status of all pre-calculated materialized views in your database.
Execute DDL and DML statements (like CREATE, SELECT, or INSERT) against your database.
Send single JSON objects or arrays of objects directly into a specified table for real-time processing.
Retrieve the names and basic metadata for all standard, user-defined database tables.
List configured connections to outside systems, like S3 buckets or other databases.
Show all defined endpoints where processed data is written (the output side of your pipelines).
List and check the status of pre-calculated, complex derived datasets.
Ask an AI about this
Waiting for input…
What AI agents can do with RisingWave (Streaming Database) MCP Server: 6 Tools for Real-Time Data
These tools let your AI client manage the entire data lifecycle in RisingWave—from listing tables to streaming events and running complex queries.
Make your AI actually useful.
Add this MCP to Claude, Cursor, or Windsurf and your AI stops guessing. It gets real tools to look things up, take action, and handle the stuff you keep doing by hand.
Start using RisingWave (Streaming Database) on VinkiusExecute Sql
Runs any full SQL statement against the database, allowing reading and writing of data.
Ingest Events
Feeds streaming JSON records directly into a target table for immediate processing.
List Materialized Views
Retrieves the names and status of all pre-calculated materialized views in your...
List Sinks
Shows a list of external destinations configured for data output from your pipelines.
List Sources
Lists all connected external systems or initial data sources feeding into RisingWave.
List Tables
Provides a straightforward list of every user-created table within the database schema.
Security and governance baked right in.
Pick your AI client below to get set up. Just create a Vinkius account, subscribe, and you're instantly up and running. We handle the entire backend infrastructure, delivering out-of-the-box support for HTTPS Streamable, SSE, and OAuth2—zero messy routing required.
Claude AI
Open Claude Settings
Go to claude.ai, click your profile icon, then navigate to Customize → Connectors.
Add Custom Connector
Click the "+" button and select Add custom connector. Paste your Vinkius endpoint URL:
https://edge.vinkius.com/[YOUR_TOKEN_HERE]/mcp
Replace [YOUR_TOKEN_HERE] with your token
from cloud.vinkius.com. For OAuth-protected servers, expand
Advanced settings to add credentials.
Start a conversation
Open a new chat. The RisingWave integration is available immediately — no restart needed.
Choose How to Get Started
Build a custom MCP for your own tools, or connect a ready-made integration from our catalog.
Build Your Own
Turn any API into an MCP. Import a spec, define Agent Skills, or deploy with MCPFusion.
- Import from OpenAPI, Swagger, or YAML specs
- Create Agent Skills with progressive disclosure
- Deploy to edge with MCPFusion framework
- Built in DLP, auth, and compliance on every call
- Real time usage dashboard and cost metering
- Publish to catalog or keep private
Make Your AI Do More
Start with RisingWave (Streaming Database), then connect any of our 5,100+ other servers whenever your AI needs more. One click, no limits.
- Use this MCP plus 5,100+ others, all in one place
- Add new capabilities to your AI anytime you want
- Every connection is secured and compliant automatically
- Track usage and costs across all your servers
- Works with Claude, ChatGPT, Cursor, and more
- New servers added to the catalog every week
Independent Platform Disclaimer: Vinkius is an independent platform and is not affiliated with, endorsed by, sponsored by, verified by, or otherwise authorized by RisingWave. All third-party trademarks, logos, and brand names are the property of their respective owners. Their use on this website is strictly for informational purposes to identify service compatibility and interoperability.
VINKIUS INFRASTRUCTURE
Cloud Hosted
Managed infra
V8 Isolated
Sandboxed per request
Zero-Trust Proxy
No stored credentials
DLP Enforced
Policy on every call
GDPR Compliant
EU data residency
Token Compression
~60% cost reduction
Built on the Model Context Protocol (MCP) for Claude, ChatGPT, Cursor, and more
The Model Context Protocol standardizes how applications expose capabilities to LLMs. Instead of operating in isolation, your AI gains direct access to external platforms, live data, and real-world actions through secure, standardized connections.
This connection provides 6 powerful capabilities that interface natively with Claude, ChatGPT, Cursor, and other compatible AI platforms. No middleware. No custom integration required.
Debugging data pipelines used to mean opening five different tabs and running manual checks., Solved with Vinkius AI Gateway
Today, if a stream breaks, you have to manually jump into the dashboard UI. You check the materialized view status in one tab; then you open the source connection logs in a second tab. If you suspect bad input, you're stuck opening an API playground just to send test JSON data.
With this MCP server, it's different. The agent handles the state checks for you. You simply tell it: 'Check the materialized views and ingest three test events.' It runs `list_materialized_views`, confirms status, then executes `ingest_events`—all in one conversational flow.
Using RisingWave with `execute_sql` makes querying real-time data simple.
Before this, getting a live count of active users meant setting up a dedicated view and running it via a separate BI tool. You had to manually manage the connection parameters and refresh schedules just for ad-hoc checks.
Now, you tell your agent: 'What is the current user count?' The agent executes `execute_sql` with the right syntax against the live stream data. It's instantaneous, direct, and requires zero setup outside of telling it what to do.
What your AI can actually do with this
RisingWave gives your AI client direct hands-on control of your real-time streaming database. You don't need to jump between a SQL console, an API playground, or documentation just to run a query. This MCP Server puts the entire data lifecycle—from source connection to final sink output—right into natural conversation with your agent.
It lets you manage everything in one place.
When you use this server, your agent treats the database like a fully executable toolset. You'll find that managing complex streaming pipelines is straightforward because you can inspect every piece of data going in and out, and you can modify it as it flows through the system.
To start, you need to know what data you're dealing with. You can use list_sources to check all the external systems connected to RisingWave; this shows you exactly where your raw data is coming from, whether it's an S3 bucket or another database connection. Next, if you want a full picture of your setup, list_tables gives you a straightforward list of every standard, user-defined table in the schema.
You can also check out what processed data ends up as materialized views; running list_materialized_views shows you the names and current status of all those complex, pre-calculated datasets.
Data doesn't just appear magically. The server lets you track where it goes once it’s done being processed. You can run list_sinks to view every configured external destination—that’s where your final output gets written—and list_sources helps confirm the input endpoints. If you need a complete inventory of the pipeline's components, you've got all the details right here.
Once you know what data exists and where it flows, you can start manipulating it. You have full power over running SQL statements. The execute_sql tool runs any full DDL or DML statement against your database. This means you can execute things like CREATE, SELECT, or INSERT commands directly through chat.
You're not limited to just reading data; you can write and change it live.
For raw, real-time input, the ingest_events tool lets you feed streaming JSON records straight into a specific table for immediate processing. You don't need separate scripts or endpoints; you just tell your agent what data to send, and it handles the stream ingestion process instantly.
Basically, this server gives you total visibility and control. You run execute_sql to change the schema or write new records. You use ingest_events to push raw JSON objects into a table as they arrive. If you need to know what external systems feed the system, you check list_sources. To see where your cleaned data goes next, you check list_sinks.
And if you wanna audit all the complex datasets that have been pre-calculated for you, just run list_materialized_views.
019e5d51-44c9-71c6-9045-b08d3a443b50 
Here's how it actually works
The bottom line is: you use natural language instructions to perform complex, low-level database operations without writing code.
Subscribe to this MCP Server and provide your RisingWave connection URL.
Your AI agent uses the provided tools (e.g., list_tables or execute_sql) to query the database's state.
The server executes the command, returns the results (like a table list or data rows), and passes that output back to your chat interface.
Who is this actually for?
This is for the data engineer who hates context switching. You're tired of running a query in one terminal, checking the schema in another UI, and then manually scripting an event stream in a third place. If your job involves validating streaming logic or building real-time dashboards, this saves you time.
Uses list_materialized_views to quickly verify if their complex streaming logic is correctly populating derived tables during development cycles.
Injects test data using ingest_events directly from the code editor, validating API endpoints without needing a staging database instance.
Uses list_sources and list_sinks to map out all available data pipelines before designing a new real-time dashboard or report.
What Changes When You Connect
Immediate Data Verification: Don't guess if your pipeline works. You use list_materialized_views to see the exact status of derived datasets before running a full report.
Zero-Friction Testing: Need to test an endpoint? Use ingest_events to stream JSON data right into the table from your chat, bypassing manual API calls and giving instant feedback.
Full Data Map Visibility: Stop guessing where data comes from or goes. Running list_sources, list_sinks, and list_tables gives you a complete, auditable topology of the entire system.
Direct Query Execution: You don't need to export schemas just to check column types. Use execute_sql to run DDL statements or simple SELECT queries directly against the live stream data.
Efficiency Over Manual Steps: Instead of opening a console, running a query, copying results, and then logging into a separate monitoring dashboard, your agent handles all steps in one flow using multiple tools.
See it in action
Debugging broken event pipelines
A backend developer notices the 'user_activity' table is empty. They ask their agent to run list_sources first, confirming the S3 connection is active. Then, they use ingest_events to send three test records directly into the target table using known good JSON structure. The system confirms ingestion success, allowing them to pinpoint the failure source outside of RisingWave.
Schema exploration for a new dashboard
An analytics engineer needs data from a newly integrated dataset but isn't sure what tables exist. They prompt their agent with 'Show me everything.' The agent runs list_tables and then uses list_materialized_views, providing the full list of available datasets, accelerating the dashboard build time.
Verifying data output paths
A data team member finishes building a new real-time stream. Before deploying, they use the agent to run list_sinks. This confirms that both the 'S3 archive' and the 'reporting database' outputs are correctly configured targets for the processed data.
Running ad-hoc validation queries
A developer needs to check if a specific user ID (123) was logged in today. Instead of writing a Python script, they ask their agent to run SELECT * FROM user_activity WHERE user_id = 123 AND date > 'today'. The agent executes the execute_sql tool and returns the result set instantly.
The honest tradeoffs
Trying to list everything with one query
A user tries to run a massive, complex SQL query like SELECT * FROM system_schema hoping it will reveal all sources and sinks. This fails because the schema is too complex, and the tool is designed for data operations, not metadata discovery.
To check the available components, use the dedicated tools: Run list_tables to see user tables, then run list_sources to find external feeds, and finally, use list_materialized_views to check derived datasets. Use a tool for its specific job.
Forgetting data validation
A developer just uses ingest_events without knowing the required JSON structure, sending malformed data that breaks the entire pipeline and leaves no clear error trail.
Before ingesting, use list_tables to confirm the target schema. Then, manually run a simple SELECT * FROM [table] with sample query using execute_sql to validate the expected column types before sending events.
Over-relying on natural language alone
The agent responds vaguely: 'I see you have data.' The user is left without knowing what specific tools or views were used, and can't proceed with the next step.
Force the agent to use a tool. Prompt it specifically: 'Run list_materialized_views and tell me which one summarizes sales by day.' This forces the server to execute the precise metadata check needed.
When It Fits, When It Doesn't
Use this MCP Server if your core workflow involves real-time data movement, complex streaming transformations, or constant schema validation. You need a single interface that lets you switch between querying live data (execute_sql), simulating inputs (ingest_events), and mapping the infrastructure (list_sources, list_sinks).
Don't use it if your job is purely batch processing (where all data lands in one place before being processed) or if you only need to run simple, pre-defined reports. For those cases, a simpler reporting database connection might be enough. If you just need to read static files without streaming concerns, look at file storage connectors instead of this full streaming platform.
Questions you might have
Can I run complex JOIN queries on my materialized views? +
Yes! Use the execute_sql tool to run any valid RisingWave SQL query. You can perform complex analytical queries or inspect the results of your real-time aggregations.
How do I check if my Kafka or Pulsar sources are correctly connected? +
Use the list_sources tool. It queries the internal catalog to provide a list of all external data sources currently configured in your RisingWave instance.
Is there a way to push data directly into a table without using an external source? +
Absolutely. Use the ingest_events tool to send JSON objects or arrays directly to a specific table via the Events API, perfect for testing or low-latency ingestion.
When I use the execute_sql tool, how do I handle schema changes or create new tables? +
You manage structural changes using standard DDL commands within execute_sql. Simply run an ALTER TABLE statement to modify existing columns, or a CREATE TABLE command if you need a brand-new data structure. The system accepts all valid SQL dialects for these operations.
What are the rate limits or maximum throughput when using the ingest_events tool? +
The ingest_events tool handles high volumes of JSON objects, typically supporting batch processing up to thousands of records per call. For extreme sustained loads, check your RisingWave configuration for specific API quotas, as those govern the actual ingestion rate.
If I run list_materialized_views, does the result show me the current operational status (e.g., running or failed)? +
Yes, the output from list_materialized_views includes metadata about each view's health. You'll see indicators that tell you if the stream is active, paused, or if it has encountered recent errors requiring attention.
After running list_sources, how do I verify which external systems are connected and authorized? +
The list_sources tool provides a catalog of configured endpoints. To confirm connectivity, you must check the accompanying connection details provided in the output for credentials or status flags. If it's not listed, the source hasn't been set up yet.
When I run execute_sql, what is the recommended way to ensure my queries don't impact production data? +
The best practice is always to test complex SELECT statements or DML operations against a staging or development instance of your database. If you must use the live environment, wrap all read operations in transactions and verify results before committing changes.
We've already built the connector for RisingWave. Just plug in your AI agents and start using Vinkius.
No hosting. No infrastructure. No complex setup.
All 6 tools are live and waiting.
You're up and running in seconds.
Gemini Vinkius gives your AI agents access to the full catalog of app connectors, all fully managed, secure, and enterprise-ready. One subscription, every tool you need.
Built, hosted, and secured by Vinkius. You just connect and go.