Setup
Connect an agent to Rindler
Rindler runs a hosted MCP server. Any agent that speaks MCP can connect to it and drive the same sites Rin drives, and anything an agent can do you can also do with curl. The browser work always happens on Rindler's side, so connecting your own agent extends Rindler rather than moving off it.
Three ways to connect
The CLI is the shortest path. It signs you in, mints a key tied to your session, and configures Claude Code and Codex for you:
curl https://rindler.ai/cli | sh
rindler login
The CLI is a dashboard tool. It signs in through app.rindler.ai, and the devices and keys it creates appear on your dashboard. See the CLI guide for the full command list.
The install script writes a .mcp.json in your project and leaves any other servers alone:
curl https://rindler.ai/install | sh
By hand, add this to your .mcp.json. No key needed: you are prompted to sign in on first use.
{
"mcpServers": {
"rindler": {
"command": "npx",
"args": ["-y", "mcp-remote", "https://mcp.rindler.ai/mcp"]
}
}
}
Where each agent keeps its config
| Agent | File | Scope |
|---|---|---|
| Claude Desktop | ~/.claude/claude_desktop_config.json | all projects |
| Claude Code | ~/.claude.json | all projects |
| Claude Code, Cursor, Windsurf | .mcp.json in the project root | that project |
| Codex | ~/.codex/config.toml | all projects |
Adding custom connections in the Claude Desktop app is still a beta feature and may need enabling in its settings.
Which key to use
The CLI mints a key bound to your sign-in, which is what you want on a laptop: it lapses when your session does, and there is nothing to revoke by hand.
For CI or a server, mint a long-lived key in the dashboard and set RINDLER_API_KEY. It takes precedence over everything else and is never written to disk. To use one in a config file instead, send it as a bearer header:
{
"mcpServers": {
"rindler": {
"url": "https://mcp.rindler.ai/mcp",
"headers": { "Authorization": "Bearer rindler_live_YOUR_KEY" }
}
}
}
Tokens are shown once when you create them. Copy it then; the dashboard cannot show it again.
Without an agent, using curl
Every call an agent makes is an HTTP call you can make yourself. List what you can drive:
curl -s https://mcp.rindler.ai/v1/runtime/configs \
-H "Authorization: Bearer $RINDLER_API_KEY"
The response is an envelope, not a bare array: {"configs": [...]}.
Running an action is two calls. The first returns a job id:
curl -s -X POST https://mcp.rindler.ai/v1/runtime/run \
-H "Authorization: Bearer $RINDLER_API_KEY" \
-H "Content-Type: application/json" \
-d '{"site": "example.com", "actions": [{"name": "search", "inputs": {"query": "laptops"}}]}'
The second reads the result:
curl -s https://mcp.rindler.ai/v1/runtime/jobs/JOB_ID \
-H "Authorization: Bearer $RINDLER_API_KEY"
Read two fields, not one
A job can finish and still have retrieved nothing, so status and retrieval.complete answer different questions.
| status | retrieval.complete | What happened |
|---|---|---|
complete | true | It ran and got the records |
complete | false | It ran and came back empty. Treat this as a failure |
failed | any | It did not run |
The CLI encodes exactly this: rindler run exits non-zero when retrieval is incomplete, even on a job that finished.
When something is wrong
Run rindler doctor first. It checks your config, your key, both agent installs, and whether the server is reachable.
| What you see | What it means |
|---|---|
| 403 when mapping | your key has no mapping capability, which is a workspace setting |
| 403 when running | about the site, not your login: your workspace cannot reach that site |
| 401 everywhere | the key was revoked, or the sign-in it was bound to ended |
| Your agent does not see Rindler | wrong config file for that agent; check the table above |
Where to go next
- The full command list is in the CLI guide.
- For what the tools actually do once you are connected, see the docs overview.