> ## Documentation Index
> Fetch the complete documentation index at: https://docs.cloudhumans.com/llms.txt
> Use this file to discover all available pages before exploring further.

# MCP Server

> Connect Claude, Cursor, or any MCP client to your Cloud Humans data — no API keys, no glue code.

<Note>
  The MCP server is in **beta**. It is safe to use — it goes through the same permissions as everything else — but tools may change between releases as we refine the surface.
</Note>

The Cloud Humans MCP server exposes the same curated surface as the [public APIs](/api-reference/cloudchat/overview) as tools an AI assistant can call. Connect it once and your assistant can work with your Cloud Humans data in plain language — everything in the [API reference](/api-reference/cloudchat/overview) is available as a tool, and the set grows as the API does.

```text theme={null}
https://mcp.cloudhumans.com/openapi/cloudhumans/mcp
```

It speaks the standard [Model Context Protocol](https://modelcontextprotocol.io) over Streamable HTTP, so anything that can act as an MCP client can use it: Claude (web and desktop), Claude Code, Cursor, or your own agent.

## Connecting

There are no API keys to create. The server authenticates with **OAuth**: the first time your client connects, a browser window opens and you sign in with your regular Cloud Humans credentials — the same email and password you use in the app. Everything the assistant can see and do is bounded by what *your user* can see and do.

<Tabs>
  <Tab title="Claude (web / desktop)">
    Go to **Settings → Connectors → Add custom connector** and paste the server URL:

    ```text theme={null}
    https://mcp.cloudhumans.com/openapi/cloudhumans/mcp
    ```

    Claude opens the sign-in page. After you approve, the tools appear in every new conversation.
  </Tab>

  <Tab title="Claude Code">
    ```bash theme={null}
    claude mcp add --transport http cloudhumans https://mcp.cloudhumans.com/openapi/cloudhumans/mcp
    ```

    Then run `/mcp` inside Claude Code to trigger the sign-in flow.
  </Tab>

  <Tab title="Cursor">
    Add the server to `.cursor/mcp.json` (project) or `~/.cursor/mcp.json` (global):

    ```json theme={null}
    {
      "mcpServers": {
        "cloudhumans": {
          "url": "https://mcp.cloudhumans.com/openapi/cloudhumans/mcp"
        }
      }
    }
    ```

    Cursor detects the OAuth requirement and walks you through the login.
  </Tab>

  <Tab title="Other clients">
    Any client that supports **Streamable HTTP** transport and **OAuth 2.1 with dynamic client registration** works out of the box. Point it at the URL above; the server advertises its authorization endpoints and the client handles the rest.
  </Tab>
</Tabs>

## Accounts and projects

One login covers the whole platform, and the assistant can only see and do what your user can. If your login has access to more than one account or project, just name the one you mean in conversation ("on the Acme account…") — or ask the assistant which ones you have, and it will list them.

## Good to know

* If a tool reports something missing that you know exists, the assistant probably targeted the wrong account or project — say which one you mean and try again.
* Sessions expire like any login. If tools start failing after a long idle period, reconnect — most clients re-run the sign-in automatically.

## MCP or REST?

Same data, same permissions, two doors:

* **MCP** when a *person with an assistant* is doing the work: exploring, reviewing, making judgment calls. Zero code.
* **[REST API](/api-reference/cloudchat/overview)** when a *system* is doing the work: scheduled syncs, integrations, anything that runs unattended and needs deterministic behavior.

They compose: teams typically prototype a workflow over MCP in conversation, then harden the parts worth automating into REST calls.