Skip to content

Signing In From Your Client

Most MCP clients now speak the full MCP authorization spec: they can discover that Cohearence is a protected server, register themselves, and walk you through a normal browser sign-in. You never generate or paste a token at all — the client holds a refresh token on your behalf and renews it on its own.

You sign in to Cohearence, not to a particular identity provider. Whichever way you already sign in — Google, email, or Apple — lands on the same Cohearence account, so a connector you set up here resolves to exactly the same data you see on your phone. It isn't a second identity.

The Cohearence MCP endpoint is the same for everyone:

https://api.cohearence.app/mcp

Signing in is what ties it to your account, so there's nothing account-specific to look up first.

Connecting your client

Covers Claude.ai and Claude Desktop, and it's the same connector a scheduled check-in uses.

  1. Open Settings → Connectors → Add custom connector.
  2. Enter https://api.cohearence.app/mcp as the URL.
  3. Claude sends you to Cohearence to sign in and approve access.
  4. Once approved, you're done — there's no secret for you to manage.

Connectors added this way live on your Claude account, which is what makes them available to Claude Routines. A server you added locally in the Claude Code CLI does not.

Add the server with a URL and no headers, in .cursor/mcp.json (project-scoped) or ~/.cursor/mcp.json (global):

{
  "mcpServers": {
    "cohearence": {
      "url": "https://api.cohearence.app/mcp"
    }
  }
}

Restart Cursor. Because there's no Authorization header, Cursor detects that the server wants a sign-in and opens the browser flow itself, then stores the credential. cohearence should show as connected under Settings → MCP.

Add the server with no --header flag, then sign in from inside a session:

claude mcp add --transport http cohearence https://api.cohearence.app/mcp

/mcp

Follow the sign-in steps in your browser; cohearence then shows as connected in the /mcp menu. Passing an Authorization header on the add command is the usual mistake here — it quietly keeps you on the token path and the sign-in flow never triggers.

Set auth: oauth on the server in ~/.hermes/config.yaml:

mcp_servers:
  cohearence:
    url: "https://api.cohearence.app/mcp"
    auth: oauth

Then, from a fresh terminal, run:

hermes mcp login cohearence

The fresh terminal matters: editing the config from inside a running Hermes session triggers an MCP reload that times out in 30 seconds, which isn't long enough to finish signing in. Tokens are saved and refreshed automatically after the first login.

Register the server with auth set to oauth, then log in:

openclaw mcp set cohearence '{
  "url": "https://api.cohearence.app/mcp",
  "transport": "streamable-http",
  "auth": "oauth"
}'

openclaw mcp login cohearence

Any static Authorization header is ignored while auth is oauth. Verify with openclaw mcp doctor cohearence --probe, and use openclaw mcp logout cohearence to drop the stored credentials while keeping the server definition.

Disconnecting

Remove or disconnect the server from your client and its access stops immediately. If you signed up for Cohearence with Google, you can also revoke from your Google Account permissions — that page only applies to Google sign-ins, so it won't list anything if you use email or Apple.

When this doesn't apply

Signing in needs a browser at least once. If your agent runs somewhere that has none — a CI job, a Cursor Cloud Agent, a cron host — or your client only accepts a static URL and header, use a Personal Access Token instead.