Upstash Has a Remote MCP Server Now

We are a little late to the MCP party but better late than never! Plenty of people asked us for one, so it is here now:

https://mcp.upstash.com/mcp

Connecting a client

Point a client at that URL. Connecting opens a browser consent page where you pick which account it gets, your personal account or one of your teams and whether the connection is read-only:

Every client you approve shows up under Account → OAuth Clients, with the access level it was given, who in the team approved it, and a button to revoke it. Owners and admins can revoke anyone's.

Claude Code, Claude Desktop and Codex can install the Upstash plugin instead, which brings the server along with the skills. In Claude Code that is two commands:

/plugin marketplace add upstash/skills
/plugin install upstash@upstash

Claude Desktop installs the same marketplace from Customize → Plugins, and Codex from codex plugin marketplace add. Clients without a plugin take the URL directly. Find the setup steps for your client.

No browser? Use an API key

Getting a client connected this way assumes a browser, and someone in front of it to press Approve. Something like a CI job has neither, so the server also accepts a Developer API key as a header, in the form email:API_KEY:

claude mcp add --scope user --transport http upstash https://mcp.upstash.com/mcp \
  --header "Authorization: Bearer you@example.com:YOUR_API_KEY"

A read-only key behaves like a read-only grant: the server refuses the same tools and strips the same credentials from results. There is no account picker here. The scope depends on the key, so a team key acts in its team and a personal key in your personal account.

Features

Available tools

There are 38 tools. Most of them either manage a resource or work with the data inside one.

Managing a resource is the work you would otherwise open the console for: creating and deleting Redis databases, renaming them, toggling eviction and auto-upgrade, taking backups, reading usage stats, creating Vector indexes and Search databases, reading QStash schedules and logs and the dead letter queue (DLQ).

Working with the data is running Redis commands against a database, publishing QStash messages, querying and upserting vectors and documents, iterating an index, cancelling a workflow run.

You do not have to take all 38. Adding ?features= to the URL scopes the connection to the products you care about. That keeps the tool list short and leaves more of the agent's context for your work:

https://mcp.upstash.com/mcp?features=redis,qstash_workflow

There are three groups: redis, qstash_workflow and vector_search. Products that share an API share a group, which is why QStash and Workflow are one and Vector and Search are another. Each product's own name works as an alias, so ?features=vector gives you the same tools as ?features=vector_search. The feature groups docs have the rest.

Accessing credentials

The tools that touch your data need a word of explanation, because reaching a resource's data normally means holding its REST token. The server fetches that token itself, authorized by your OAuth token, calls the endpoint, and hands back only the result. redis_run_command runs without a database password passing through the model.

Other tools do hand you credentials, on purpose. redis_get_database, index_get and the create tools return the resource's REST tokens, because an agent that just made you a database usually needs to wire an app up to it. The read-only switch on the consent screen is what turns that off: when the grant is read-only, the server strips the password and both tokens out of every one of those results, and you go to the console for them instead.

Previous agent surfaces

The upstash CLI has been around the longest. It calls the Developer API, takes non-interactive commands and prints JSON. That makes it good in CI and fine for an agent that is already comfortable in a shell.

The local MCP server came later. Your client spawns it with npx, it authenticates with your email and a Developer API key, and it covers Redis, QStash, Workflow and Upstash Box:

npx -y @upstash/mcp-server@latest \
  --email YOUR_EMAIL --api-key YOUR_API_KEY

Both still work. The local server is the one to use if you want Box tools, which the remote server does not carry yet. Going the other way, the remote server covers Vector and Search, which the local one does not.

What the remote server makes possible

Reaching agents that run somewhere else

A stdio server is a program your client starts on your machine. That works in a terminal or a desktop editor, where there is a machine to start it on.

Plenty of agents run somewhere that is not your machine, Claude on the web and Replit among them. They have no npx to spawn and no filesystem of yours to read a key from, so they cannot use a stdio server at all. An HTTP endpoint with OAuth behaves the same way whether the agent runs in your terminal or in a datacenter.

Shipping the MCP inside a plugin

The Agent Plugins standard packages skills and MCP servers as one installable folder, so a single plugin can give an agent the Upstash SDK skills and connect it to your account. We wrote about it when it landed.

A stdio server needs credentials, though, and a plugin is public package data. The spec closes both ways you might try to supply them: a plugin cannot embed a real key, because anyone can read it, and it cannot reference yours through a ${VAR} placeholder, because clients do not expand those. The header would arrive as the literal string.

So before we had a remote server, bundling the MCP into a plugin would have meant asking every user to put a Developer API key in an env file, in every project, and leave it there. That is a lot of long-lived credentials in a lot of repositories.

OAuth takes the credential out of the package. Our plugin manifest is now this, and it holds no secret:

{
  "$schema": "https://agent-plugins.org/schemas/1.0.0/mcp.schema.json",
  "mcpServers": {
    "upstash": {
      "type": "streamable-http",
      "url": "https://mcp.upstash.com/mcp"
    }
  }
}

Consent happens in your browser, and the grant belongs to one client. With read-only access granted, the server refuses every tool that would change something.

Still on our list

• OAuth in the upstash CLI. It still authenticates with a Developer API key, and the same browser consent would work there. That would be one less long-lived key on your machine.
• Exploring what we can offer accounts that came in through Vercel or Fly. They sign in from their provider's dashboard rather than the Upstash console, so there is no console session to attach a grant to, and we are still working out the right shape for it.
• Box tools on the remote server, and OAuth in the Box CLI. Upstash Box is the one product the local server covers and this one does not, which is the only reason left to use stdio.
• Choosing feature groups at consent time. Today ?features= is part of the URL, so it scopes what a client asks for rather than what the grant allows. On the consent screen it would be part of the grant itself, next to the account scope and the read-only flag.
• More tools. Restoring a backup, changing a database's plan or regions, and QStash queues and URL groups are all things you can do in the console but not yet through the server.

If something is missing or a tool behaves oddly, tell us on Discord or open an issue on GitHub.