MCP

The server is a thin adapter over the HTTP API. Every tool call becomes a request to the same /api/* endpoint the web app uses, so permission checks happen once, in one place, and an agent can never reach something a person with the same token could not.

This page is the reference. For step-by-step setup in Claude, ChatGPT, Cursor, Codex, VS Code and others, see the MCP page.

Connect with the CLI

The shortest path, and the one that needs no token. Install the CLI, then hand the command to your client:

$ claude mcp add rezee -- rezee mcp

rezee mcp speaks MCP's stdio transport and forwards each message to your workspace with the credential the CLI already holds. If there is no credential it runs the browser login first, so the first tool call opens a browser rather than failing.

For a client that wants the pieces spelled out - the shape most editors' JSON config takes:

{
  "mcpServers": {
    "rezee": {
      "command": "rezee",
      "args": ["mcp"]
    }
  }
}

It takes --host for an instance other than the configured one, and --no-browser to print the login URL instead of opening it - which is what you want over SSH.

Connect over HTTP

The server also lives at a URL, for clients that would rather hold one than spawn a process:

https://api.rezee.app/api/mcp

A client that speaks OAuth needs nothing else. Give it the URL and it discovers the rest: the endpoint answers an unauthenticated call with 401 and a challenge naming its metadata document, which names the authorization server, which the client registers itself with and then sends you to a consent screen. You tick what it may do and it gets a token. No token pasted anywhere, and nothing to revoke by hand later - connected apps are listed in your account settings with a disconnect beside each.

A client that does not speak OAuth can send a personal access token as a bearer token instead:

Authorization: Bearer reze_pat_...

The tools

Over 290 of them, one per meaningful action rather than one per endpoint. Every tool takes the workspace slug as its first argument, so one connection reaches every workspace you are a member of.

canvas_render answers with a picture rather than text - a model cannot read an SVG, and the point of one renderer is that the agent sees what the human sees.

Every tool ships MCP's safety annotations, derived from the request it makes rather than written down twice: a read is marked readOnlyHint, a delete or a gated tool is marked destructiveHint. A client that surfaces those to the person gets them right without being told.

What a connection may do

A connected app is granted capabilities, and the consent screen splits them in two. Every read arrives ticked - code, issues, pull requests, documents, chat, CI runs, tasks, agents, and your account and workspace list. Every write is offered unticked: issues:write, pulls:write, docs:write, chat:write, branches:write, runs:write, deploy:write, tasks:write, devices:write and notifications:write. Granting one has to be something you did rather than something you accepted.

Five capabilities are never offered to a connector, and cannot be asked for: repos:write, code:write, secrets:write, releases:write and tasks:run. The consequence worth naming rather than discovering: a connector cannot push. It reads code and opens pull requests. It also cannot create repositories, read or rotate CI secrets, or cut releases.

A call outside what a token holds comes back 403 with a challenge naming the capability that would have been enough - so a client can ask you to widen the grant rather than report a failure it cannot explain.

The gate in front of the irreversible

A Rezee agent stops and asks a person before any of 16 tools, even when its token allows them, because none can be undone by doing the opposite. Among them:

The gate is per-agent and lifting it is a deliberate act in workspace settings, not a scope a client can request. A gated call comes back as a tool result that says which gate stopped it, so the agent can tell you what it wanted to do.

A connector is not gated: it acts as you, and you can merge or publish yourself. Those same tools carry destructiveHint, so a client that confirms before acting asks you first.

Protocol details

• JSON-RPC 2.0 over a single POST /api/mcp. Protocol revision 2025-06-18; older clients negotiate down.
• Discovery is RFC 9728 then RFC 8414: /.well-known/oauth-protected-resource/api/mcp names the authorization server, and /.well-known/oauth-authorization-server names its endpoints. Both are reachable without a credential, which is the point of them.
• Dynamic client registration is open at /api/oauth/register. Clients are public - no secret - and PKCE with S256 is required. plain is not offered.
• Access tokens last an hour and are bound to this resource (RFC 8707); refresh tokens last 30 days. An authorization code is good for one minute and one use.
• Rate limiting is the API's, per principal. A throttled call comes back with the wait in _meta.retryAfterSeconds rather than as an opaque failure.

Connectors and agents are different things

A connector is an outside client acting as you, granted in a browser, holding your identity and a subset of your capabilities.

An agent is a member of the workspace with a name, an avatar and a token of its own, provisioned by an admin who typed its capabilities. It shows up in mentions, appears in the member list, and its work is attributed to it. See Agents.

Both reach the same tools through the same server. What differs is who is asking and who decided what they may do.