Claudeから実際のChromeセッションを操作します — ハンドオフ認識機能を備えたコパイロットモードです。
ほとんどのブラウザ自動化MCPサーバーは、新しいPlaywright Chromiumを起動します。しかし、「Stripeにログインして5つの項目をクリックする」といった作業では、Cookieや2FA、ブックマークが引き継がれないため役に立ちません。mcp-helmは「あなたの」Chromeに接続します。すでにログイン済みのブラウザを使用し、Claudeがアクティブなタブに対して一連のツールを実行できるようにします。
また、いつ操作を中断すべきかも認識します。ページに2FAプロンプト、キャプチャ、支払い確認、または生体認証リクエストが表示されると、スクリーンショットツールがそれをフラグ立てし、Claudeはhandoff()を呼び出してあなたに操作を委ねることができます。
「目と手」の問題です。Claudeが「設定 → APIアクセスをクリックして」と言い、あなたが設定をクリックしてもAPIアクセスが存在しない場合、スクリーンショットをClaudeに送り返し、Claudeが再度推測するというやり取りが発生します。5秒のタスクのために5分間の往復が発生し、Stripe、Apple、Play Console、Cloudflare、Vercelなどの設定を行うたびにこれが繰り返されます。
mcp-helmはこのループを断ち切ります。Claudeは実際のページを確認し、アクセシビリティツリーから要素を選択（座標の推測は不要）し、実行すべきでない操作に直面した場合は停止します。
Related MCP server: MCP Accessibility Bridge
npm install -g mcp-helm~/.claude.json（またはMCPクライアントの設定ファイル）に追加します：
{
"mcpServers": {
"helm": {
"command": "mcp-helm"
}
}
}シェルrcファイルに以下のエイリアスを追加します：
alias chrome-pilot='open -a "Google Chrome" --args --remote-debugging-port=9222 --user-data-dir=$HOME/.chrome-pilot'一度実行します：chrome-pilot。別のChromeプロファイルが開きます。Claudeに操作させたいすべてのサービス（Play Console、Stripeなど）にログインしてください。Cookieは起動後も保持されるため、サービスごとに一度ログインするだけで済みます。
なぜ別のプロファイルなのか？ メインのChromeは、すでに実行中の場合、リモートデバッグモードで起動できないためです。専用プロファイルは
~/.chrome-pilotに保存され、日常のブラウジングとは分離されます。
You: Upload the AAB at <path> to Play Store internal testing.
Claude: [calls helm.attach] → [helm.navigate to play.google.com/console]
[helm.screenshot] → sees the dashboard
[helm.click "Personalized AI Portfolio Bot"]
... etc2FAプロンプトが表示されると、screenshotはhandoffTriggers: ["2FA prompt"]を返し、Claudeはhandoffを呼び出して待機します。
ツール | 目的 |
| ポート9222でChromeに接続します。最初に必ず呼び出してください。 |
| 開いているすべてのタブを一覧表示します。 |
| インデックスまたはURLのサブ文字列でアクティブなタブを切り替えます。 |
| PNG + URL + タイトル + 検出されたハンドオフトリガーを返します。 |
| インタラクティブな要素の番号付きリスト（a11yツリー）を表示します。 |
| ID（inspectから取得）、テキスト、またはCSSセレクターでクリックします。スクリーンショットの差分から |
| フィールドに入力します。 |
| URLに移動します。 |
| テキストまたはセレクターを待機します。 |
| 一時停止し、人間に操作を交代するよう求めます。 |
座標ではなくアクセシビリティツリーを使用。 視覚ベースのクリック（Anthropicのコンピュータ使用）は優れていますが、Retinaディスプレイや高DPRスケーリングでは不安定になりがちです。a11yツリーは安定したセマンティックなIDを提供し、スクリーンリーダーが使用するものと同じです。
クリックごとにスクリーンショットの差分を確認。 changed: falseの場合、クリックは無効でした。Claudeが成功したと誤って報告するのを防ぎます。
ハンドオフ検出は正規表現ベース（LLMベースではない）。 安価で高速であり、一般的なログインフレーズで誤検知が発生しません。
タブ管理のヒューリスティックはなし。 attachは最初の空でないタブを選択します。正確に行うにはlist_tabsとfocus_tabを使用してください。予測可能性は巧妙さよりも優れています。
v0.1 — 単純なフロー（Play Console、Stripeダッシュボード、Vercel、Cloudflare）で動作します。まだ対応していないエッジケース：
Shadow DOMコンポーネント（Webコンポーネントを多用するサイト）
iframe（フレーム切り替えの対応が必要）
ディスクからのファイルアップロード
Enterキー以外のキーボードショートカット
MIT
Connect to a running Chrome instance (must be launched with --remote-debugging-port). Returns the active tab URL and total tab count. Always call this first.
| Name | Required | Description | Default |
|---|---|---|---|
| port | No | CDP port; default 9222 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes return values but lacks details on error handling, side effects, or behavior when connection fails. No annotations to supplement, so description carries full burden but is incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two efficient sentences with no waste. Critical info (precondition, return values, usage order) is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, return value, precondition. Lacks error behavior and output format, but these are minor for a simple initialization tool with one optional parameter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema provides full coverage of the single parameter (port with default). Description adds no extra meaning beyond schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states action (connect to Chrome instance), resource (running Chrome with specific flag), and return values (active tab URL, tab count). It distinguishes from siblings by being the first call.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states prerequisite (must be launched with --remote-debugging-port) and ordering (always call this first). Provides clear when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Click by id (from inspect), by visible text, or by CSS selector. Returns {changed: true/false} based on a pre/post screenshot diff — false means the click had no effect.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | ||
| text | No | ||
| selector | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description discloses the return value ({changed: true/false}) and its meaning (pre/post screenshot diff), indicating whether the click had effect. This adds behavioral context beyond a simple 'click'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: first covers purpose and methods, second covers return value. No unnecessary words, front-loaded with critical info.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple action and no output schema, the description covers purpose, targeting methods, and return value interpretation. It could mention caveats (e.g., waiting for page load) but is fairly complete for typical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description explains each parameter's meaning ('id from inspect', 'visible text', 'CSS selector'), but lacks details on format, constraints, or precedence rules. It provides basic semantics but not full specification.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (click) and three identification methods (id, visible text, CSS selector). It distinguishes from sibling tools like 'type' or 'attach' by specifying click-specific targeting.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage through the methods but does not explicitly state when to prefer click over other actions (e.g., when to use attach vs click). No exclusions or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Switch the active tab by index (from list_tabs) or by URL substring.
| Name | Required | Description | Default |
|---|---|---|---|
| index | No | ||
| urlContains | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden. It only states the action (switch active tab) but does not disclose behaviors like what happens if index or URL substring is invalid, whether it errors silently, or side effects like changing focus. Minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with action and methods. Every word earns its place with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple nature and no output schema, the description is adequate but lacks details on behavior when both params are missing or multiple matches. The robot can infer basic usage from sibling tools but additional context would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 2 parameters with 0% description coverage. The description explains that 'index' comes from list_tabs and 'urlContains' is a substring, adding meaning beyond raw schema. However, it does not specify behavior if both are provided or if neither is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool switches the active tab and identifies two methods: by index (from list_tabs) or by URL substring. It distinguishes itself from sibling tools like list_tabs (listing) and navigate (URL navigation). However, it does not explicitly mention 'browser tab', which is implied from context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage after list_tabs to get index or URL, but does not explicitly state when to use this tool versus alternatives like navigate or click. No guidance on when not to use it or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Pause and ask the human to complete the next step manually (2FA, payment, sensitive config). Returns a paused state — the human resolves it in the browser, then tells Claude to continue.
| Name | Required | Description | Default |
|---|---|---|---|
| reason | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description explains the tool returns a paused state and that the human resolves it in the browser before continuing. This adequately discloses the non-automated, interactive behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler. The first sentence states the action and examples, the second explains the result. Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and lack of output schema, the description covers the main use case and return behavior. However, it does not mention what happens if the human fails to complete the step, which would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, meaning nothing in the schema describes the 'reason' parameter. The description only hints at usage ('for 2FA, payment, sensitive config') but does not explain the parameter's format, expected input, or provide examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The verb 'pause and ask' clearly describes the action, and 'human to complete the next step manually' specifies the resource and context. This distinguishes it from sibling tools like click or type, which perform automated actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly lists use cases (2FA, payment, sensitive config) and implies that other tools are for automated steps. While it doesn't explicitly say 'when not to use', the examples provide clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return a numbered list of interactive elements (buttons, links, inputs) from the accessibility tree. Use the returned id with click() or type() — no coordinates needed.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It discloses that the tool reads the accessibility tree and returns a list with ids, indicating a safe, non-destructive operation. It does not detail edge cases (e.g., no elements found), but for a simple inspection tool this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, each earning its place: the first states the action and result, the second provides actionable guidance. No redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters, no output schema, and a clear set of siblings, the description fully explains what the tool does, what it returns, and how to use it in conjunction with other tools. No critical information is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, and the schema coverage is 100%. The description does not need to add parameter info. The baseline for no params is 4, and the description offers additional value by explaining the output format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the action: returning a numbered list of interactive elements (buttons, links, inputs) from the accessibility tree. It distinguishes itself from sibling tools like click and type by explaining its role in providing element identifiers for those actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states how to use the results: 'Use the returned id with click() or type() — no coordinates needed.' This provides clear integration guidance but does not mention when to avoid using the tool, though the context is well implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all open tabs across contexts. Use to find a specific tab to focus.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description implies a read-only operation (listing open tabs). It does not contradict any annotations, and the behavior is straightforward. No side effects or limitations are mentioned, which is acceptable for a simple list tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two short sentences, no wasted words, and effectively communicates the purpose and usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters, no output schema, and a simple purpose, the description is complete. It tells the agent exactly what the tool does and why to use it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so schema coverage is 100%. The description does not need to add parameter meaning. Baseline score of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all open tabs across contexts, distinguishing it from siblings like focus_tab (which focuses a specific tab) and navigate (which goes to a URL). The verb 'list' and resource 'open tabs across contexts' are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description suggests using this tool to find a specific tab to focus, providing context for when to use it before focus_tab. It does not explicitly exclude other uses or mention alternatives, but the guidance is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Capture the active tab. Returns base64 PNG, URL, title, and any detected handoff triggers (2FA, captcha, payment prompts). Call this after every action to verify state.
| Name | Required | Description | Default |
|---|---|---|---|
| fullPage | No | Full scrollable page (default false) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavioral traits: it captures the active tab, returns specific data, and detects handoff triggers. It implies a read-only operation but does not elaborate on side effects or permissions; however, the key behaviors are transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no wasted words. It front-loads the primary action and immediately details the return value and recommended usage. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional parameter) and lack of output schema, the description is complete: it clarifies the parameter, the return format, and when to use it. No additional information is needed for an agent to select and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% coverage for the single parameter ('fullPage'), including a description. The description does not add any further semantics beyond what the schema already states, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies 'Capture the active tab' and lists exact return contents (base64 PNG, URL, title, handoff triggers), making it clear what the tool does and differentiating it from siblings like 'click' or 'inspect'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises 'Call this after every action to verify state,' providing a clear usage context. It does not mention when not to use or alternatives, but the guidance is sufficiently directive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Type into a field by id (from inspect) or CSS selector. Set submit=true to press Enter after.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | ||
| id | No | ||
| selector | No | ||
| submit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It only discloses the submit parameter behavior (pressing Enter) but does not address error handling, field clearing, waiting, or other side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at two sentences (18 words) with no extraneous information. Every word serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema and no annotations, the description lacks details about return values, error scenarios, and other behavioral nuances. It is minimal and leaves gaps for an agent to infer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning to id and selectors (by inspect or CSS) and explains the submit parameter. However, it does not clarify precedence between id and selector, and the term 'from inspect' is ambiguous. With 0% schema coverage, the description partially compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Type into a field') and identifies the target via id from inspect or CSS selector. It distinguishes from sibling tools like click or attach, but could be more precise about the typing mechanism.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit guidance on when to use this tool versus alternatives. It implies usage for text input into fields but does not mention prerequisites or fallback behaviors.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Wait for visible text or a CSS selector to appear on the page.
| Name | Required | Description | Default |
|---|---|---|---|
| text | No | ||
| selector | No | ||
| timeoutMs | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It lacks details on timeout behavior, error handling, and whether it waits for visibility or existence. The term 'visible text' is ambiguous.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no fluff, but front-loaded. Could benefit from a brief structure outlining condition and timeout.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and three parameters, the description is too brief. It fails to mention return values, timeout behavior, or page scope.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description should explain parameters. It only loosely ties 'text' and 'selector' to the description but omits timeoutMs entirely.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool waits for visible text or a CSS selector to appear, which is a specific verb+resource. It distinguishes from siblings like click, navigate, and type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives like waitForSelector or waitForNavigation. No context on prerequisites or conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0attachclickfocus_tabhandoffinspectlist_tabsnavigatescreenshottypewait_forScored across 10 tools
Each tool has a clearly distinct purpose: attaching, navigating, clicking, typing, inspecting, tab management, screenshotting, waiting, and handoff. No overlapping functionality.
All tool names follow a consistent verb or verb_noun pattern with lowercase and underscores (e.g., focus_tab, list_tabs, wait_for). No mixing of conventions.
With 10 tools, the set covers core browser automation tasks without being bloated or sparse. Each tool earns its place.
The tool surface covers connection, navigation, interaction, inspection, tab management, and human handoff. Minor gap: no explicit scrolling or back/forward navigation, but these are often handled indirectly.
Connect Claude to your Platform7n workspaces — chat, links, and tasks. One-click OAuth.
Share context and questions between Claude instances — VS Code, claude.ai web, and mobile.
Real Chrome for agents: start a browser, read pages as numbered markdown, click, type, hand off.
Browser MCP for logged-in tasks. Uses your Chrome — credentials stay local. Zero-token replay.
