Steuern Sie Ihre echte Chrome-Sitzung von Claude aus – Copilot-Modus mit Übergabe-Erkennung.
Die meisten MCP-Server für Browser-Automatisierung starten ein frisches Playwright-Chromium. Das ist nutzlos, wenn die Aufgabe darin besteht, sich bei Stripe anzumelden und 5 Dinge anzuklicken – Sie haben dort weder Ihre Cookies, noch Ihre 2FA oder Ihre Lesezeichen. mcp-helm verbindet sich mit IHREM Chrome, dem Browser, bei dem Sie bereits angemeldet sind, und ermöglicht es Claude, eine kleine Auswahl an Tools auf dem aktiven Tab auszuführen.
Es weiß auch, wann es sich zurückziehen muss: Wenn die Seite eine 2FA-Aufforderung, ein Captcha, eine Zahlungsbestätigung oder eine biometrische Anfrage anzeigt, markiert das Screenshot-Tool dies und Claude kann handoff() aufrufen, um auf Sie zu warten.
Das Problem mit den Augen und Händen: Claude sagt Ihnen „Klicken Sie auf Einstellungen → API-Zugriff“, Sie klicken auf Einstellungen, aber dort gibt es keinen API-Zugriff. Also machen Sie einen Screenshot für Claude, das dann erneut rät. Das sind 5 Minuten Hin-und-Her für eine 5-Sekunden-Aufgabe, und das passiert bei jeder Einrichtung von Stripe / Apple / Play Console / Cloudflare / Vercel.
mcp-helm verkürzt diese Schleife. Claude sieht die tatsächliche Seite, wählt Elemente aus dem Accessibility-Tree aus (kein Raten von Koordinaten) und stoppt, wenn es etwas tun würde, das es nicht tun sollte.
Related MCP server: MCP Accessibility Bridge
npm install -g mcp-helmFügen Sie dies zu ~/.claude.json (oder der Konfiguration Ihres MCP-Clients) hinzu:
{
"mcpServers": {
"helm": {
"command": "mcp-helm"
}
}
}Fügen Sie diesen Alias zu Ihrer Shell-RC hinzu:
alias chrome-pilot='open -a "Google Chrome" --args --remote-debugging-port=9222 --user-data-dir=$HOME/.chrome-pilot'Führen Sie ihn einmal aus: chrome-pilot. Ein separates Chrome-Profil öffnet sich. Melden Sie sich bei allem an, was Claude steuern soll (Play Console, Stripe, etc.). Cookies bleiben über Sitzungen hinweg erhalten – Sie melden sich nur einmal pro Dienst an.
Warum ein separates Profil? Ihr Haupt-Chrome kann nicht im Remote-Debugging-Modus gestartet werden, während er bereits läuft. Das dedizierte Profil befindet sich in
~/.chrome-pilotund bleibt von Ihrem täglichen Surfen getrennt.
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"]
... etcWenn eine 2FA-Aufforderung erscheint, gibt screenshot handoffTriggers: ["2FA prompt"] zurück und Claude ruft handoff auf, um zu warten.
Tool | Zweck |
| Verbindung zu Chrome auf Port 9222 herstellen. Immer zuerst aufrufen. |
| Alle offenen Tabs auflisten. |
| Aktiven Tab nach Index oder URL-Teilzeichenfolge wechseln. |
| PNG + URL + Titel + erkannte Übergabe-Auslöser. |
| Nummerierte Liste interaktiver Elemente (a11y-Tree). |
| Klicken nach ID (aus inspect), Text oder CSS-Selektor. Gibt |
| In ein Feld tippen. |
| Zu einer URL navigieren. |
| Auf Text oder Selektor warten. |
| Pausieren und den Menschen bitten, zu übernehmen. |
Accessibility-Tree, nicht Koordinaten. Visuell gestütztes Klicken (Anthropic Computer Use) ist großartig, aber fehleranfällig auf Retina-Displays und bei hoher DPR-Skalierung. Der a11y-Tree liefert stabile, semantische IDs – und ist das, was Screenreader verwenden.
Screenshot-Diff nach jedem Klick. Wenn changed: false, war der Klick wirkungslos. Das bewahrt Claude davor, fröhlich Erfolg zu melden.
Übergabe-Erkennung basiert auf Regex, nicht auf LLM. Günstig, schnell, keine Fehlalarme bei gängigen Anmeldephrasen.
Keine Heuristiken für Tab-Management. attach wählt den ersten nicht leeren Tab; verwenden Sie list_tabs + focus_tab, um präzise zu sein. Vorhersehbarkeit ist besser als Cleverness.
v0.1 – funktioniert für einfache Abläufe (Play Console, Stripe-Dashboard, Vercel, Cloudflare). Grenzfälle, die noch nicht behandelt werden:
Shadow-DOM-Komponenten (einige Web-Component-lastige Seiten)
iframes (muss das Wechseln von Frames unterstützen)
Datei-Uploads von der Festplatte
Tastaturkürzel außer 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.
