Your AI coding agent can write the app. The open question is where the backend runs and who owns it afterward.
"My agent can call a deploy tool" is no longer a differentiator. Write-capable cloud-management MCP servers are common in 2026. What matters is what the agent provisions for you: an open, portable stack you actually control, not a managed surface over one vendor's proprietary services.
Eyevinn Open Source Cloud (OSC) is an MCP server that provisions 184 managed open-source backend services through conversation. When the agent is done, you have a stack that runs unmodified open-source containers. You can take it, export it, and run it yourself. A vendor-locked platform cannot truthfully offer that second half.
Adding OSC to your agent
One line to add the server:
claude mcp add --transport http osc https://mcp.osaas.io/mcp
Then run /mcp in Claude Code. This opens an OAuth 2.1 PKCE flow against the OSC auth server. No API key to paste, no token file to manage.
After that, you talk to your agent like you normally would:
"Create a PostgreSQL database and an S3-compatible object store, and give me the connection details."
The agent calls OSC MCP tools, provisions both services, and returns the endpoints. You wire those connection strings into your app code and deploy wherever you want. OSC, your own infra, anywhere. You own the services either way.
The full list of tools and setup docs is at osaas.io/mcp.
If you use Codex
The OSC /mcp page lists Codex as a compatible client, but at the time of writing it does not show the config block Codex needs. Here it is:
# ~/.codex/config.toml
[mcp_servers.osc]
url = "https://mcp.osaas.io/mcp"
Then run codex mcp login osc to complete the auth flow. Codex supports URL-based streamable-HTTP MCP servers through both codex mcp and config.toml. Verify against the current Codex MCP docs if something has changed since this post was written.
What "you own it" actually means in practice
Every service OSC provisions is unmodified open source running in a standard container. There is no OSC-proprietary fork between you and the software.
To make that concrete, OSC ships an Exit Test: provision a service, export your data with curl, spin up the identical container image on your own machine with Docker, and diff. Same bytes. You can run the walkthrough yourself. That is not something a platform built on proprietary runtimes can offer.
The catalog
As of July 2026, the catalog holds 184 managed open-source services across 8 categories: databases, storage, messaging, video, analytics, and more. The live count is on the examples page.
A few questions I get
Can my agent provision a database? Yes. The agent calls a tool over the OSC MCP endpoint to create the instance and gets back connection details ready to wire into your app. PostgreSQL, PostgreSQL with pgvector, and others are in the catalog.
Do I own what the agent deploys? Yes. Unmodified open source in a standard container, no proprietary runtime layer between you and the software.
Can I run the stack without OSC later? Yes. Export your data, run the same container images yourself. The Exit Test is a short script that demonstrates this end to end.
Does it work with tools other than Claude Code? The OSC MCP endpoint is a standard streamable-HTTP server. Claude Code and Codex work today. Other clients that support URL-based MCP servers should work as well.
If you want to try it, the quickest path is to add the MCP server, spin up a service in a conversation, and then run the Exit Test to verify you can take it with you. The MCP page has everything you need to get started.
Top comments (0)