Your AI now speaks Readyset: announcing the MCP server

Hot on the heels of rdst, the client side performance toolkit, today we're shipping something our customer have been requesting for a long time: native MCP (Model Context Protocol) support in Readyset. Claude, Cursor, Windsurf, and every other MCP-aware agent can now talk to your Readyset directly — inspecting proxied queries, analyzing what's cacheable, and creating or dropping caches in real time. The "copy SQL into a chat window, paste the result back" loop is over.

Even better: we're not shipping one MCP server. We're shipping two transports, each tuned for a different reality of how teams actually run databases. A stdio binary (readyset-mcp) that runs on a developer's laptop, and an HTTP endpoint baked right into the Readyset server. Both are secure by design — the choice between them is about who's running the agent and where, so you can adopt MCP on the terms that fit your setup.

Two shapes, one set of superpowers

Both transports expose the same toolkit — readyset_status, show_proxied_queries, show_caches, explain_cache_support, create_cache, drop_cache, and more — backed by the same SQL commands you'd run by hand. The difference is how the agent reaches Readyset and who's on the other end of the credential.

stdio: runs next to you, uses the credentials you already have

Your laptop                              Your Readyset
┌──────────┐  stdio  ┌────────────┐  MySQL/PG  ┌──────────┐
│Claude/IDE│ ──────► │readyset-mcp│ ─────────► │ Readyset │
└──────────┘         └────────────┘            └──────────┘

This is the fastest path from "I want AI on my database cache" to "AI is on my database cache." Claude spawns readyset-mcp as a child process on your machine. It connects to Readyset with your normal SQL credentials. That's it.

{
  "mcpServers": {
    "readyset": {
      "command": "readyset-mcp",
      "env": {
        "READYSET_HOST": "readyset.example.com",
        "READYSET_PORT": "3307",
        "READYSET_USER": "alice",
        "READYSET_PASSWORD": "..."
      }
    }
  }
}

No MCP tokens. No new auth system. No port to open on the server. No platform-team approval to wait on. If you can already connect to Readyset over SQL, you already have everything you need.

Embedded HTTP: runs inside Readyset, serves many agents at once

Agent ──HTTP + Bearer──► Readyset server
                          ├── Bearer auth + scope check
                          └── rmcp Streamable HTTP → SQL → Backend

When MCP runs inside the Readyset server, multiple agents — humans, CI jobs, hosted automations — can share it with individually-scoped credentials. Every default is tuned for safe production use:

• Off by default. Operators opt in with --enable-mcp. Nothing is exposed without a deliberate choice.
• Loopback by default. --mcp-address binds to 127.0.0.1:6035. Reaching it from another host requires an explicit configuration change, behind TLS termination.
• Only hashes persisted. Readyset stores SHA-256 hashes of tokens; the raw value lives wherever you keep secrets.
• Scopes are real and enforced. read_only for inspection. cache_admin adds create_cache / drop_cache. full covers destructive ops.
• No batch smuggling. Top-level JSON-RPC arrays are rejected outright, so a restricted tool can't sneak past the per-request scope check.
• Revocable on the spot. DROP MCP TOKEN invalidates immediately. ALTER MCP TOKEN ... SET EXPIRES rolls expiry forward without rotating the value.

Bearer tokens managed via SQL. No separate admin plane to learn or secure:

CREATE MCP TOKEN 'claude-ci' WITH SCOPE cache_admin
  EXPIRES '2026-12-31T23:59:59Z';
-- returns: rs_mcp_a1b2c3...  (shown once, never again)

This is the security model we'd want for our own production deployments — and now it's yours.

When to use which

Scenario	Use
You're a developer working on your own laptop	stdio
Readyset is a managed/SaaS deployment you don't operate	stdio
You want MCP today and your platform team hasn't reviewed it yet	stdio
A shared agent (Claude Code in CI, a hosted automation) needs access	HTTP + token
Multiple humans share access but you can't hand out DB passwords	HTTP + token
You need centralized, auditable, revocable credentials	HTTP + token

It really comes down to one question: who's running the agent, and is it just for them? If it's just you, on your machine, with your own credentials, stdio fits most naturally — you reuse credentials you already have, with no new pieces to configure. If the agent is shared — running in CI, serving multiple humans, or operating unattended — the embedded HTTP endpoint gives you scoped, expiring, revocable tokens managed centrally.

Control belongs to you

Here's the part we're most excited about, and the reason stdio is a first-class transport, not a developer-mode afterthought: the decision to let an AI touch a database should belong to the person whose access is on the line.

On a SaaS or managed Readyset, you don't control server flags. You can't --enable-mcp. You can't issue tokens. But you do have a SQL connection, and that's all readyset-mcp needs. The agent runs on your laptop, with your credentials, scoped to exactly what your database user can already do. No vendor enablement required. No security review on someone else's roadmap. No waiting.

On self-hosted Readyset, the same principle applies one layer up: developers can adopt MCP individually via stdio today — before the platform team flips on the central HTTP endpoint, before security signs off on tokens, before anyone needs to schedule a meeting. When the team is ready for shared automation — agents in CI, ops bots, multi-user IDE setups — operators turn on --enable-mcp and mint scoped tokens. Until then, individual adoption isn't blocked on org-wide rollout.

That's the shape of the trade-off we're proud of: stdio gives end users autonomy; HTTP gives operators centralized control. Pick the one that matches who's accountable for the access — or use both, with different agents, on the same Readyset.

Get started in 60 seconds

We ship both transports as Claude Code plugins so you can install them with one command. Add our marketplace first:

/plugin marketplace add readysettech/claude-plugins

HTTP (recommended if you operate the Readyset server)

/plugin install readyset-mcp@readyset

Claude Code will prompt for the MCP URL (defaults to http://127.0.0.1:6035/mcp) and a Bearer token. Mint one with:

CREATE MCP TOKEN 'my-agent' WITH SCOPE read_only;

Then make sure your Readyset server was started with --enable-mcp, and you're done.

stdio (when you don't control the Readyset server)

/plugin install readyset-mcp-stdio@readyset

Grab the readyset-mcp binary for your platform from the Readyset releases page, put it on your PATH, and Claude Code will prompt for the SQL connection details — the same host, port, user, and password you already use to connect.

Alternatively, you can manually download readyset-mcp from Readyset releases page and configure it manually.

Go cache something. Ask Claude what's slow. Let your AI do the boring parts. We can't wait to see what you build.