# Connecting RAUHA

**There are two routes, and mixing them is the usual reason a connection half-works.** Establish which one this client is on before showing anybody anything.

## Route 1 — a connector that signs in

The connector sends the person to **https://rauha.ai** to sign in and approve.
They need an account first — https://rauha.ai/signup, free, no card. Without
one there is nothing to sign in to and the flow dead-ends on a login screen.


**ChatGPT.** Add RAUHA as an app, and it sends the person to rauha.ai to sign in and approve. No key, nothing pasted, nothing in a config file. If somebody with a ChatGPT connector is being told to create a key, the wrong route is being followed.

The one thing worth watching: the consent screen names the account it is about to connect. A session already open from something else will connect *that* account, and the only symptom is that nothing said to it is ever kept. There is a link on the screen to change account.

**Grok.** https://grok.com/connectors → New Connector → Custom, and give it
`https://rauha.ai/api/mcp`. It discovers the rest and offers a Connect button.
Sign in, approve, done — no key.

**Check popups are not blocked, so you can sign in to your RAUHA memory.** The
sign-in opens in a popup and a blocker kills it silently — Grok then says it
could not connect to the server, which sounds like RAUHA is down and is not.

Nothing else on this page applies to either of these.

## Route 2 — a client that holds a key

**Claude Code, OpenClaw, Cursor, Windsurf, Roo, and anything else speaking streamable HTTP.** The person runs the setup once. An assistant reading this should show the relevant block and let them paste it — never install, upgrade or repair anything on their behalf.

```
url:       https://rauha.ai/api/mcp
transport: streamable HTTP
header:    Authorization: Bearer $RAUHA_KEY
```

Keys come from https://rauha.ai → **Keys**. They start with `rk_` and are shown once.

One key per thing that connects, so revoking one leaves the others working.

## Approving the tools

Whatever the client, approve all three permanently the first time it asks.
`rauha_context` and `rauha_recall` only read, and `rauha_remember` is
append-only — nothing here can delete or overwrite anything, so there is no
call worth stopping to think about.

In Claude Code, either accept at the first prompt or allow them at user scope
so every project inherits it:

```
mcp__rauha__rauha_context
mcp__rauha__rauha_recall
mcp__rauha__rauha_remember
```

A prompt on every recall breaks the point of it. The assistant is supposed to
check memory before saying it does not know, and it will not do that reliably
if checking costs the person a click.

## Claude Code

```bash
claude mcp add --transport http rauha https://rauha.ai/api/mcp \
  --header "Authorization: Bearer $RAUHA_KEY"
```

## OpenClaw

In `~/.openclaw/openclaw.json`, then `openclaw gateway restart`:

```json
"mcp": {
  "servers": {
    "rauha": {
      "url": "https://rauha.ai/api/mcp",
      "transport": "streamable-http",
      "enabled": true,
      "headers": { "Authorization": "Bearer $RAUHA_KEY" }
    }
  }
}
```

The gateway runs as its own process, so `RAUHA_KEY` has to reach **it** — either in the gateway's environment, or wired through `skills.entries.rauha.apiKey`. Exporting it in a terminal is not enough.

## Cursor, Windsurf, Roo

`.cursor/mcp.json`, `~/.codeium/windsurf/mcp_config.json`, `.roo/mcp.json`:

```json
{ "mcpServers": { "rauha": {
  "url": "https://rauha.ai/api/mcp",
  "headers": { "Authorization": "Bearer $RAUHA_KEY" }
} } }
```

## Anything else

Any client that speaks streamable HTTP works with the url and header above. Clients that support OAuth can omit the key entirely and let RAUHA's authorization server handle sign-in — discovery is at `https://rauha.ai/.well-known/oauth-protected-resource`.

## Telling the two failures apart

Both look the same from inside a conversation:

- **No `rauha_*` tools at all** — the server was never registered.
- **`unauthorised`** — registered, but the credential is missing, wrong or revoked. In OpenClaw this is usually `$RAUHA_KEY` not being expanded, or not being in the gateway's own environment.

## OpenClaw: silence signals and tool calls

OpenClaw delivers the **last** text an agent produces, so a silent-reply pattern such as `NO_REPLY` must be the final output or nothing at all — and a RAUHA call in between changes what "final" means.

Two failures come from this, and both look like RAUHA broke WhatsApp:

- A tool call after the signal makes the tool result the last output, so the silence is lost and something unintended is delivered.
- A signal emitted before a call, then re-emitted after it, can suppress a reply that was meant to go out.

The rule: **make every RAUHA call first, and let the real response — or the silence signal — be the last thing produced.** Never place a call between the signal and the end of a turn.

This is OpenClaw's delivery model rather than anything RAUHA does; the same applies to any tool called late in a turn.

## Key hygiene

Keys are stored hashed and shown once. A lost key is replaced, not recovered. Revoking one leaves every other key and connector working.