Claude에서 실제 Chrome 세션을 제어하세요 — 핸드오프 인지 기능이 포함된 코파일럿 모드입니다.
대부분의 브라우저 자동화 MCP 서버는 새로운 Playwright Chromium을 실행합니다. 하지만 "Stripe에 로그인하고 5가지를 클릭"하는 작업에서는 쿠키, 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 등)에 로그인하세요. 쿠키는 실행 후에도 유지되므로 서비스당 한 번만 로그인하면 됩니다.
왜 별도의 프로필인가요? 메인 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 컴포넌트(일부 웹 컴포넌트 위주의 사이트)
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.
