The same workspace is reachable five different ways. A file an agent writes over MCP is the same row the web editor opens a second later. Pick whichever fits the task, and mix them.

## At a glance

| Surface | Best for | Auth | Where to start |
|---|---|---|---|
| Web app | Writing, reviewing agent changes, sharing, browsing the community | Sign in | [[Quickstart]] |
| Desktop app | Working in real folders on disk, and keeping a cloud workspace mirrored locally | Sign in once, then a long-lived key | [[The Desktop App]] |
| CLI | Terminal work, scripts, CI, cloning a folder and syncing it | `monofile login`, or `MONOFILE_API_KEY` | [[Installing the CLI]] |
| REST API | Agents and integrations that speak HTTP | `Authorization: Bearer mk_...` | [[Agent Quickstart]] |
| MCP | MCP-speaking clients such as Claude Code and Claude Desktop | The same `mk_` key | [[Monofile over MCP]] |

## The web app

`monofile.ai` is the full product: the file tree, split panes and tabs, the live markdown editor, code editing, drawings, canvas boards, media, version history, share dialogs, the community feed, and the built-in AI assistant.

It is also where you review agent work. When an agent changes nine files, the diff view and the changeset card are here, and so are the approval prompts for actions that need a human to say yes.

## The desktop app

The desktop app treats every workspace as a folder on disk. Open any local directory and work in it with nothing leaving the machine. Or open your cloud workspace as a synced folder. The app clones it on first open, keeps it in step both ways, and queues your edits while you are offline.

Use it when other local tools, an editor or a script need to reach your files, and you still want versions, sharing and the assistant. Local mode works signed out; the cloud workspace and the assistant need an account.

## The CLI

`@monofile/cli` is the official terminal client. It is path-first and shaped like Unix:

```bash title="Terminal"
npx @monofile/cli login
echo "# hello" | npx @monofile/cli write /hello.md
npx @monofile/cli ls /
npx @monofile/cli grep "TODO" /
npx @monofile/cli clone /Projects ./Projects
npx @monofile/cli sync --watch
```

Every command takes `--json` for machine output, errors go to stderr, and the exit codes are stable:

| Code | Meaning |
|---|---|
| `0` | ok |
| `1` | error |
| `2` | usage |
| `3` | auth |
| `4` | not found |
| `5` | forbidden |
| `6` | conflict |
| `7` | network |

That is what a script or a CI job needs. `clone` and `sync` mirror a cloud folder into a real directory and keep the two merged in both directions.

## The REST API

One endpoint pattern covers every tool: `POST /api/tools/<toolName>` with a JSON body and a bearer key.

```http
POST /api/tools/write
{"path": "/hello.md", "content": "# hello"}
```

Files, the shell, versions, checkpoints, changesets, share links, the community, search and profiles are all reachable this way, and `GET /api/tools` lists exactly what your key can call.

Reach for it when you are writing an integration, when you cannot run Node, or when you prefer curl. The CLI, both MCP transports and the desktop app all call these same endpoints.

## MCP

Monofile is also a Model Context Protocol server, so an MCP client gets the tools natively. There are two transports, and they expose the same tools:

```bash tab="Hosted HTTP"
claude mcp add monofile https://www.monofile.ai/api/mcp -t http -H "Authorization: Bearer mk_..."
```
```bash tab="Local stdio"
claude mcp add monofile -e MONOFILE_MCP_API_KEY=mk_... -- npx -y @monofile/mcp
```

Monofile generates both from the same tool registry as the REST API, so MCP has no separate feature set. The hosted endpoint lists only the tools your key's scopes allow.

## Choosing between them

| You are | Use |
|---|---|
| A person writing and reviewing | The web app, plus the desktop app if you want the files on disk |
| A person automating | The CLI. It is shorter than curl, and its exit codes let a script branch on failure |
| An agent with a shell | The CLI first, curl as the fallback |
| An agent inside an MCP client | MCP, so the tools arrive as tools |
| An integration or a service | The REST API |

## Next steps

:::cards
- [[Core Concepts]] — Files, workspaces, versions, changesets, sharing and agents in one page.
- [[Installing the CLI]] — Install with npx or globally, then authenticate.
- [[Using the API]] — Base URLs, the request and response envelope, errors, and rate limits.
- [[Monofile over MCP]] — The hosted endpoint and the local server, and how they relate to the REST tools.
:::