> ## Documentation Index
> Fetch the complete documentation index at: https://docs.gainable.dev/llms.txt
> Use this file to discover all available pages before exploring further.
# Overview
> Drive Gainable from Claude Code, Claude, Cowork, or Codex through one MCP connector
Gainable isn't only a web app. The **Gaia harness** is accessible via a remote [MCP](https://modelcontextprotocol.io) server, so an AI client can build, refine, publish, and share your apps — from your terminal, from a Claude chat, or from a Cowork session.
There is one endpoint and nothing to install:
```
https://build.gainable.dev/mcp
```
## What you get
No package to install and nothing to keep on your `PATH`. Add a URL, sign in through your browser, and you're building.
Claude Code, Claude, Cowork, Claude Desktop, and Codex all connect to the same endpoint and get the same tools.
The connector drives the exact same contract agent, planner, Build Agent, and validators as the web app. Nothing is downgraded.
Generated files never enter your context. The harness builds server-side and streams back a summary.
## Pick your client
One `claude mcp add`, then `/mcp` to sign in.
Add it once as a custom connector — it shows up in chat, Cowork, Desktop, and mobile.
`codex mcp add`, then `codex mcp login`.
Any MCP client that speaks streamable HTTP and OAuth 2.1 can connect to the same URL.
## How it fits together
```
You ──▶ Claude Code / Claude / Cowork / Codex ──▶ build.gainable.dev/mcp ──▶ your app
(the MCP client) (the Gaia harness)
```
1. You describe what you want in your client's chat.
2. The client calls a connector tool — `build`, `chat`, `import`, `publish`.
3. The harness does the work **server-side** and streams progress back.
4. Your client relays the harness's questions to you and your answers back to it.
That relay is the whole job. When the harness asks which view should be the home page, or which column identifies a row, those are your calls — a good client forwards them verbatim rather than answering on your behalf.
## Two modes
Most work happens in the first one.
Your request goes to the Gainable harness. The planner and Build Agent do the work server-side in one cheap turn — the same path as typing in the web app. Right for almost everything: "add KPIs", "fix this view", "change the layout", "build me a CRM".
Your client writes the app code itself: it reads the build conventions and the files it needs, edits them, runs the **same validators** the Build Agent uses, and pushes. Only when you explicitly ask — "code it yourself", "without the harness".
Author mode is a separate OAuth scope, not a setting. You grant it with a checkbox when you sign in, so a connection that can build apps can't write code into them unless you said so. See [Author mode](/mcp/tools#author-mode).
## Signing in
The connector uses OAuth 2.1 with dynamic client registration and PKCE, so every client handles sign-in the same way: it opens your browser, you approve, and the token is stored by the client (in your OS keyring for terminal clients).
| | |
| ---------------------- | ----------------------------------------------------------------- |
| Endpoint | `https://build.gainable.dev/mcp` |
| Transport | Streamable HTTP (`POST` only — there is no separate SSE endpoint) |
| Scopes | `mcp` (always) · `datasets` · `users` · `code` |
| Shown in client UIs as | **Gainable (Gaia)** |
### What you're granting
Building, changing, publishing and sharing apps comes with every connection. Three groups of tools sit behind their own checkbox on the consent screen, and a connection that doesn't have one **can't see those tools at all** — they're absent from the list, not refused at call time.
| Checkbox | Scope | What it adds |
| -------------------------------------------------- | ---------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| *Also let it work with your datasets* | `datasets` | List datasets and read their rows, create new ones, replace the contents of one, delete one no app is using. Importing a spreadsheet into a new app works without it. |
| *Also let it add and manage people on the account* | `users` | Invite people by email, change whether they're a builder or an app user, remove them. **Inviting a builder uses a paid seat.** |
| *Also let it write code in your apps* | `code` | [Author mode](/mcp/tools#author-mode) — write views, routes and models directly instead of asking Gainable to make the change. |
You can review or revoke any connection at any time from **[Account → Connections](https://build.gainable.dev/account/connections)**, and flip any of the three scopes there without reconnecting — the change takes effect on the connection's next request.
The people checkbox is only **offered** to someone who could manage users themselves. Connecting a client can never hand out more access than you already had.
After you approve, Gainable opens a short **what-now** page with a few first prompts you can copy. Every one of them names the product — see below for why that matters.
No Gainable account yet? You can [create one free](https://build.gainable.dev/auth/signup) during the sign-in step and carry straight on.
## Say "Gaia" in your first message
This is the single thing most worth knowing, and the most common reason a connected client does nothing.
Connecting the server doesn't make your assistant use it. *"Build me an app to track expenses"* is a request it can answer from its own head — and it will, producing something that looks like an answer and never touching Gainable at all. Naming the product is what routes the request.
```text Routes to Gaia theme={null}
Have Gaia build an event planning app from this spreadsheet
```
```text Answered from its own head theme={null}
Build me an app to track expenses
```
**Only the first message needs it.** Once a tool has run, the app's `projectId` is in the conversation and everything after it is ordinary follow-up:
```text theme={null}
Have Gaia build a deals pipeline from this sheet ← names it
Add a probability column to the deals table ← doesn't need to
Make the sponsors view the home page
Publish it
```
Gaia, Gainable, "Gaia Build" and "Gainable Build" all name the same product, so any of them routes correctly. In ChatGPT you can also pick the connector directly with **@ Gaia** instead of naming it in the sentence.
This matters most where nobody is watching. A [scheduled sync](/mcp/datasets#putting-it-on-a-schedule) whose instruction doesn't name Gaia can run every morning, answer itself, and never touch your dataset — with nothing in the log to say so.
Starting a genuinely new app later in the same conversation is also a first message: name Gaia again, and say it's a new app, or you may get a change to the one you already have.
## Not to be confused with your app's MCP server
Gainable involves two different MCP servers, and they do opposite jobs:
| | The Gaia harness MCP | Your app's MCP server |
| ------------- | ----------------------------------------------- | -------------------------------------------------- |
| URL | `build.gainable.dev/mcp` | `.gainable.app/mcp` |
| Purpose | **Build** apps | **Query and write** an app's data |
| Used by | You, from Claude Code / Claude / Cowork / Codex | Your app's Copilots, and any agent you point at it |
| Documented in | This section | [Copilot data access](/copilots/data-access) |
This section is about the first one. The second is what makes an app you build this morning a queryable data source this afternoon.
## What the connector can do
Ten tools by default, and up to eighteen depending on which scopes you granted. You never name them — your client picks from what you ask — but this is the shape of it:
| | Tools | Scope |
| --------------------------- | ----------------------------------------------------------------------------------------- | ---------- |
| Find your way around | `apps_list` · `apps_select` · `project_setup` | `mcp` |
| Build a new app | `import` · `build` | `mcp` |
| Change a built app | `chat` | `mcp` |
| Ship it | `publish` · `share` | `mcp` |
| Decide who can open it | `app_access` · `app_users` | `mcp` |
| Work with your data | `dataset_list` · `dataset_schema` · `dataset_records` · `dataset_sync` · `dataset_delete` | `datasets` |
| Manage the account's people | `account_users` | `users` |
| Author mode | `code_context` · `code_push` | `code` |
See the [tool reference](/mcp/tools) for every parameter.
The connector ships its own operating instructions to every client on connect, so there is no plugin, skill, or rules file to install alongside it. Adding the URL is the whole setup.
## Next steps
Add the connector to your terminal.
Add it to chat, Cowork, and Desktop.
Every tool, action, and parameter.
Create a dataset once, sync it forever.