Управляйте своей реальной сессией Chrome из Claude — режим второго пилота с поддержкой передачи управления.
Большинство MCP-серверов для автоматизации браузера запускают новый экземпляр Playwright Chromium. Это бесполезно, когда задача состоит в том, чтобы «войти в Stripe и нажать 5 кнопок» — у вас нет ваших файлов cookie, 2FA, закладок. mcp-helm подключается к ВАШЕМУ Chrome, в который вы уже вошли, и позволяет Claude запускать небольшой набор инструментов для работы с активной вкладкой.
Он также знает, когда нужно отступить: когда на странице появляется запрос 2FA, капча, подтверждение оплаты или запрос биометрии, инструмент создания скриншотов помечает это, и Claude может вызвать handoff(), чтобы подождать вас.
Проблема «глаз и рук»: Claude говорит вам «нажмите Настройки → Доступ к API», а вы нажимаете «Настройки», и там нет доступа к API, поэтому вы делаете скриншот для 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"
}
}
}Добавьте этот псевдоним в ваш shell 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"]
... etcЕсли появляется запрос 2FA, screenshot возвращает handoffTriggers: ["2FA prompt"], и Claude вызывает handoff, чтобы подождать.
Инструмент | Назначение |
| Подключение к Chrome на порту 9222. Всегда вызывайте первым. |
| Список всех открытых вкладок. |
| Переключение активной вкладки по индексу или подстроке 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 (некоторые сайты с активным использованием веб-компонентов)
iframes (нужно реализовать переключение фреймов)
Загрузка файлов с диска
Сочетания клавиш, кроме 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.
