For agents
Argus over MCP
An agent that already knows how to use tools can drive hundreds of isolated browser profiles — each with its own fingerprint, proxy and cookie jar — without being taught an API. 134 tools, over a server that ships inside the launcher and installs nothing.
On this page
What the server is
MCP is how a coding agent discovers what a program can do. The agent asks for a tool list, gets one back with names, descriptions and argument schemas, and calls what it needs — no wrapper, no SDK, nothing to keep in step with a changelog.
The Argus server runs from inside the launcher's own application bundle, started with ELECTRON_RUN_AS_NODE. There is no package to install and nothing new listening: it speaks JSON-RPC over stdin and stdout to the client that launched it, and reaches the local API on your behalf.
For most clients the launcher writes the config file for you and shows you the path first. Two of them have no file it can write, and say so by handing over a snippet instead.
This is a local API. It listens on loopback on the machine running Argus, and nothing off that machine can reach it. There is no hosted web API.
Which means there is nothing to install and nothing to keep in step. No npm package, no npx command, no second process listening on a port of its own: the client you connect starts the server itself, and the server talks to the launcher already running on your machine.
Which plan you need
The API and the MCP tools are on every plan, including Free. A plan sets how many profiles, seats and automations a workspace gets — it does not decide whether the API answers.
The free plan runs five profiles with no card, and all 134 tools reach them. What a paid plan buys is room — more profiles, more seats, more stored automations — which is set out on the pricing page. Nothing about connecting an agent is behind it.
Connecting it
- Install Argus and open the launcher. The API starts with it and stops with it — a refused connection almost always means the launcher is closed, not that the address is wrong. Mac and Windows builds.
- Mint a key in the API tab. It is shown once — only a hash is stored, so a lost key is replaced rather than recovered. A key can be scoped to the folders you name.
- Connect your client. For most of them the launcher writes the config file for you and shows you the path before it touches anything. Two have no file it can write and hand you a snippet instead. By hand, the block is this shape:
{
"mcpServers": {
"argus": {
"type": "stdio",
"command": "Argus Launcher",
"args": ["<the path shown after you connect>"],
"env": {
"ELECTRON_RUN_AS_NODE": "1",
"ARGYS_API_TOKEN": "<your key>",
"ARGYS_API_BASE": "http://127.0.0.1:39219"
}
}
}
}Restart the client afterwards — every one of them reads its MCP config at process start, and there is no reload signal Argus can send. Then the first call from that client raises an approve-or-deny card in the launcher and blocks until a human answers it. That pause is not a hang, and retrying only queues a second card.
The config path for each client, and how to confirm from the other side rather than taking our word for it, is on the integrations page.
What an agent gets
134 tools. 120 of them front one of the 124 endpoints on the local API; the remaining 14 have no endpoint behind them at all — they attach to a profile that is already open and speak to the page directly, which is how an agent reads a page, clicks through it and takes a screenshot it can actually see.
Alongside the tools the server advertises resources: the documents that make up a project's brain — its brief, its rules, its notes and its runbooks — read one at a time at argus://project/<id>/<path>. A tool returns the index; a resource returns a body, once the agent has decided it wants that body. Pulling a hundred notes into context to find one is the thing that arrangement exists to prevent.
Every tool, the endpoint behind it, and the arguments each one takes are on the API reference, and as one Markdown file or an OpenAPI 3.1 spec if you would rather your agent fetched it than scraped this page.
Where its reach ends
The agent's reach ends at your desk. The API is loopback, so nothing off the machine can call it, there is no hosted runner, and no part of a session passes through us — which also means an agent running in someone else's cloud cannot reach your profiles at all.
Inside the machine there are three further limits, and they are enforced in code rather than asked of the model. A key scoped to folders sees only the profiles in them, and gets a 403 rather than an empty list for anything else. Assigning a proxy is refused when it would put more profiles behind one exit than your sharing limit allows, and the refusal names the profiles already there. And a cookie set is held by exactly one profile, because two profiles on one set is one account signed in twice.
The asymmetry worth knowing before you plan around it: an agent can create a profile, but it cannot purge one. Deleting moves a profile to Trash, where the app can restore it and the on-disk browser data stays. The irreversible purge is a human action in the app.
Drop-in rules for your own CLAUDE.md or AGENTS.md — these boundaries written as instructions an agent reads before its first call — are in the public repository.
Clients
Argus ships a setup card for each of these, and any other MCP client works from the snippet above.
What each one writes, where, and how to check it took — plus the AI, messaging, data and captcha connectors an automation can reach — is on the integrations page.
Ready to run profiles at scale?
Download Argus for Mac or Windows and start free with 5 profiles.
