Connect Claude or ChatGPT

The Vibes DIY MCP connector lets Claude or ChatGPT work with your apps: list them, read their data, and update records using your account's permissions. Connect once, then ask your assistant to work with a specific app.

Use a Vibes DIY account and an assistant that supports MCP connections. The hosted server is https://mcp.vibes.diy/mcp. Start with the copyable setup prompt, or follow your assistant's steps below.

Add it to Claude

From the Connectors Directory. Open Claude's connector settings and search for "Vibes DIY". Adding it starts an OAuth sign-in with your Vibes DIY account (Clerk handles the login screen) — approve it, and Claude can start calling the tools below.

As a custom connector. If the directory listing isn't visible to you yet (a workspace admin hasn't enabled it, or you're testing ahead of the public listing), add it manually as a custom connector using the server URL https://mcp.vibes.diy/mcp. The sign-in flow is identical either way.

Either path, you can remove the connector at any time from the same settings screen — Claude immediately loses the ability to act on your account until you reconnect.

Add it to ChatGPT

Where your account and workspace allow developer mode, enable it in Settings → Security and login → Developer mode. In Plugins, use the plus button to add a connection named vibes-diy with the URL https://mcp.vibes.diy/mcp. Complete the Vibes DIY OAuth sign-in, review the discovered tools, and select the connection from a conversation's tools menu.

You make this settings change yourself; pasting a prompt does not install a ChatGPT connection. See OpenAI's current connection guide for availability and setup details.

Add it to Claude Code

shclaude mcp add --transport http vibes-diy https://mcp.vibes.diy/mcp

Add --scope project to save it in the repo's .mcp.json, or --scope user to make it available across projects. Run /mcp in Claude Code and complete the OAuth sign-in yourself. Then paste the setup prompt to verify access.

Copy the setup prompt

Paste this into your assistant. It prefers the hosted connector, asks you to complete sign-in, and verifies access without writing data or spending build credits. In ChatGPT or Claude's web app, add the connection in settings first.

Install the Vibes DIY MCP connector in this session so you can read and write
data in my vibes. If you cannot change this client's connector settings,
guide me through adding it and wait for me to confirm before verification.

Preferred path — hosted connector (OAuth, no local install):

1. Use a remote HTTP MCP server named vibes-diy at:
   https://mcp.vibes.diy/mcp

   Claude Code CLI:
   claude mcp add --transport http vibes-diy https://mcp.vibes.diy/mcp
   Add --scope project for the repo's .mcp.json, or --scope user for all projects.

   Claude Desktop / claude.ai:
   Settings → Connectors → Add custom connector → paste the server URL.
   If Vibes DIY is already in the Connectors Directory, add that entry instead.

   ChatGPT:
   I add the hosted connection in settings and select it in this conversation.
   If setup is needed, use the ChatGPT steps in this guide:
   https://good.vibes.diy/docs/claude-connector
   Do not claim the connection was installed just because I pasted this prompt.

2. Ask me to complete OAuth sign-in with my Vibes DIY account.
   In Claude Code, tell me to run /mcp. In other clients, use their connection
   settings. Clerk handles the login screen. You cannot sign in for me.
   Wait for me to confirm.

3. Verify: list the actual vibes_* tools available, then call the list-apps
   tool and show the owner/slug results. If authentication fails, say the
   sign-in did not stick and stop rather than retrying blindly.

Fallback — local stdio server (only if hosted is unreachable, or I need it
bound to one app, and this client can run local MCP servers):

npx vibes-diy login

This login is interactive: hand it to me and wait. Then, for Claude Code:

claude mcp add vibes-diy -- npx vibes-diy mcp --app-slug APP --handle USER

Replace APP and USER with my app slug and owner handle; ask if unknown.
Alternatively, add this entry to .mcp.json without replacing other servers:

{ "mcpServers": {
    "vibes-diy": { "command": "npx", "args": ["vibes-diy", "mcp"] }
} }

Without --app-slug, the local server defaults to $VIBES_APP_SLUG or the current
directory name. Its seven tools are vibes_list_apps, vibes_list_databases,
vibes_get, vibes_put, vibes_delete, vibes_query, and vibes_generate.
Discover the hosted server's actual tools instead of assuming this local list.

Installation boundaries:

- Everything runs as me. No admin or elevated access: the connector can only
  do what my account could do by hand.
- Verification is read-only: list apps and, at most, describe one app's shape.
  No put, delete, publish, generate, or create. vibes_generate spends real
  AI credits and deploys a live app.
- Never put my API key or token in a tool argument or config file. Hosted uses
  OAuth; the local server reads the credential saved by vibes-diy login.
- Report which path you used, where the config landed (file path or hosted
  settings location), the exact tools available, and the list-apps output.

What the hosted connector can do

The connector exposes ten tools. Before the list, the shortest thing to know about using them:

Just paste the link

Wherever Claude needs to know which app you mean, you can paste the link straight out of your browser's address bar instead of typing a name. Any of these work:

owner/slug — the short name Claude uses when it lists your apps.
The app's page on this site, https://vibes.diy/vibe/owner/slug — and it doesn't matter what comes after that, so a link you copied part-way through working on the app still works.
The app's own address, https://slug--owner.vibesdiy.app/.

The tools themselves, grouped by what they touch:

Find your apps

List your apps — the starting point for everything else; returns your apps as owner/slug so you can tell Claude which one you mean.
List an app's databases — see what data an app keeps.
Describe an app — ask what an app offers: its databases, and for each one a handful of document ids plus the field names and types those documents use. It's how Claude learns the shape of an app before working with it, instead of fishing around. It only reports what you can read — where your account has no read access, it says there's nothing readable rather than showing you someone else's documents.

Read an app's data

Get a document — fetch one document by its id.
Query documents — filter by field, key, prefix, or range, with limits and sort order, the same query shapes the app's own code can run.

Write an app's data

Put a document — create a new document or update an existing one (a last-write-wins upsert, same as the app's own writes).
Delete a document — permanently removes it. Claude treats this as a destructive action and will confirm before calling it.

Build and ship an app

Create an app — mint a brand-new app from source Claude writes, and push its first version.
Push — update an existing app's draft source. This does not change what's already live.
Publish — promote the current draft to the live release everyone sees at the app's public URL. This is destructive: it replaces what's live for every visitor, so Claude confirms before calling it.

Every call runs as you — the connector has no elevated or admin access. It can only do what your account could already do by hand.

Data and access semantics

A few platform behaviors are worth knowing before you ask Claude to build or publish something:

An app is open by default from the moment Claude creates it — not from when you publish it. The open default is set by the push, and "create an app" mints the slug and pushes its first version. So a connector-built app starts out both world-readable (its documents are readable through the data API, no sign-in required) and auto-accept editor (anyone who requests write access is granted it automatically). Publishing only decides what visitors get at the app's public URL — it is not what opened the data up.
Not publishing is not privacy. An unpublished app's data is still readable and writable on those defaults, so "just don't publish it" won't hold anything back. For a genuinely private app, deploy it privately — npx vibes-diy push --private from the CLI turns off both public access and auto-accept editor — and/or give the app an access function that decides who can read each document. The connector's ten tools have no private switch of their own, so ask Claude for the source and take it through the CLI, or add the access rules to the app itself.
Sharing is one-directional. If an app is wired into your follow graph, followers can see what you share with them; that doesn't make you able to see their data back.
Revoking access stops future data, not past copies. If you remove a grant or unpublish an app, the platform stops routing new data to whoever lost access — it doesn't erase copies they already received.

See The Access Model and Local-first data & sync for the full picture.

The free alternative: local MCP over stdio

Don't want to go through OAuth, or want Claude Code, Cursor, or another MCP-capable agent to work on your vibes' data using your local device credential instead of a hosted connector? Run

shnpx vibes-diy mcp

This starts a local stdio MCP server with the seven tools listed in the setup prompt, including app generation. It authenticates with the device certificate from vibes-diy login — no directory listing, no OAuth screen, no account tier required beyond the free plan. See "Mount your vibes into any AI agent" in the CLI handbook for setup.