Aartiq ships a real, implemented MCP server (aartiq-mcp, MIT) that drives the browser from Claude Desktop and any MCP client — 64 tools across 11 categories — plus an Agent API that exposes the same surface over HTTP. Every tool call runs a fail-closed security pipeline and everything binds to the loopback interface. This page documents the implemented system; each claim links to the exact source lines on GitHub.
11 tool categories, all defined in one file — aartiq-mcp/server/index.js.
Open any browser panel on demand — settings (per-section), bookmarks, history, downloads, clipboard, permissions, sync, and command center.
Open and drive the AI sidebar, which is the path to full capabilities: PDF generation, navigation, research, and tool execution.
send_ai_prompt routes through the real sidebar so MCP clients get RAG, web search, document generation, and live browser actions — not a stubbed chat.
Read and modify any browser setting — profile, appearance, search, API keys, privacy, permissions, shortcuts, history, automation, sync, extensions, plugins, MCP, about, updates, performance, system, admin.
Add, list, and remove bookmarks; browse and clear browsing history through the vault.
List, grant, and revoke permissions; read and update security settings and firewall levels.
Create, list, toggle, delete, and run scheduled tasks — cron-based automation driven by the agent.
Full browser control: navigation, tabs, page reading, form filling, screenshots — with the same fail-closed sandboxing as direct commands.
Search and play YouTube videos inline, plus media and system media control.
Clipboard, volume, brightness, and system automation routed through the permission-gated shell.
explain_feature, list_all_features, and get_security_overview tools give clients an auditable map of the surface they are driving.
The implemented transport chain, from MCP client to sandboxed tool execution.
A standalone, MIT-licensed MCP server bundle (aartiq-mcp/) that any MCP client can launch via stdio. It exposes 64 tools across 11 categories and bridges into the running Aartiq browser over a local HTTP bridge.
The stdio server never talks to the browser directly. A BridgeClient forwards each tool call over plain HTTP to the browser process, which alone holds the real capabilities.
Inside the browser, the agent-api ToolRegistry is the single enforcement point for every tool call over both MCP and HTTP transports.
The browser also exposes its own tools to MCP clients internally and can register approved external MCP servers (SSE/stdio) as tool providers.
MCP and the agent API are not a backdoor — they share the browser's security pipeline.
All three HTTP listeners bind to loopback by default. The agent API uses 127.0.0.1 and exposes every interface only when remote is explicitly turned on; the MCP SSE bridge resolves its bind host through resolveBindHost() (mcp-browser-server.js:1678-1681) and listens on 127.0.0.1 unless the security_mcpBridgeRemote setting is turned on (main.js:9161, default off). Beyond those three, the WiFi sync service binds all interfaces on purpose so the phone can reach it over the LAN (AARTIQ_WIFI_SYNC_HOST narrows the bind), with Host and Origin checked at the WebSocket upgrade and every sync action carrying the device's access token; the PDF sync service binds loopback and requires a token on every file endpoint. The README states both plainly.
Every tool call runs the verb gate, tab lock, handler, and prompt-injection scan before returning. Untrusted tool output is scanned and quarantined when unsafe — content is never trusted by default.
Two agents can never drive the same tab: TabLockManager refuses a second agent unless the lock has expired or been handed off.
Tools are risk-classified; high-risk actions require the native permission approval UI before they execute (biometric where enabled). Default agent trust is "limited".
How Aartiq actually connects — the working path, not a mock.
aartiq-mcp ships as a Claude Desktop extension bundle (.mcpb) and an npm package (aartiq-mcp-server, v2.0.0, MIT). Entry point: node server/index.js.
The browser listens for bridge calls on 127.0.0.1:46203 while running. Configuration happens in the desktop app (Settings → MCP) — this website does not proxy tokens or run OAuth for you.
Point your client at the stdio entry point. Every request to the bridge needs the session token, and the Host and Origin are checked as well, so a client that has not been given the token is refused rather than connected. Works on macOS and Windows; requires Node.js ≥ 18. The token is stored in ~/.aartiq-mcp-token (mode 0600) and survives restarts; delete the file and restart Aartiq to rotate it, then run Auto-Configure again.
The MCP surface you see on this page is the one that ships: the tool list, the bridge, the security pipeline, and the approvals are all in the open-source repository and enforceable in CI. Aartiq does not proxy third-party OAuth servers (Gmail, Slack, etc.) through this website — those exist as real, approved external MCP servers you register in the desktop app, and the registry is in the source above. See the security docs and the Agent API docs for the full model.