MCP server for PinchTab — control Chrome (or any Chromium browser) via accessibility tree snapshots through the Model Context Protocol.
PinchTab is included as a dependency and starts automatically — no manual setup required.
npx pinchtab-mcpOr install globally:
npm install -g pinchtab-mcp
pinchtab-mcpRelated MCP server: cdpilot
Claude Desktop — add to ~/Library/Application Support/Claude/claude_desktop_config.json:
{
"mcpServers": {
"pinchtab": {
"command": "npx",
"args": ["-y", "pinchtab-mcp"]
}
}
}With a custom browser (see Configuration):
{
"mcpServers": {
"pinchtab": {
"command": "npx",
"args": ["-y", "pinchtab-mcp"],
"env": {
"CHROME_BINARY": "/Applications/Yandex.app/Contents/MacOS/Yandex",
"BRIDGE_HEADLESS": "false"
}
}
}
}Cursor / VS Code — add to .cursor/mcp.json or .vscode/mcp.json:
{
"servers": {
"pinchtab": {
"command": "npx",
"args": ["-y", "pinchtab-mcp"]
}
}
}Claude Code:
claude mcp add pinchtab -- npx -y pinchtab-mcpVariable | Default | Description |
|
| PinchTab API endpoint |
| (empty) | Auth token (must match PinchTab's |
| (auto-detect) | Explicit path to PinchTab binary |
Binary lookup order: PINCHTAB_BIN → node_modules/.bin/pinchtab → system PATH.
PinchTab itself is configured via env variables or a config file (~/.config/pinchtab/config.json):
Variable | Default | Description |
| (bundled Chromium) | Path to browser binary — use this for Yandex Browser, Brave, Edge, etc. |
| (none) | Connect to an already-running browser's DevTools (e.g. |
|
| Set to |
|
| PinchTab HTTP API port |
| (none) | Protect the API with an auth token |
|
| Browser profile directory (cookies, sessions) |
|
| Max open tabs |
|
| Block ads |
|
| Block image loading (faster scraping) |
|
| Block video/audio |
|
| Disable CSS animations |
|
| Anti-detection level |
| (system) | Override timezone |
| (auto) | Override User-Agent |
| (none) | Extra flags passed to the browser |
# Yandex Browser
CHROME_BINARY="/Applications/Yandex.app/Contents/MacOS/Yandex" npx pinchtab-mcp
# Brave
CHROME_BINARY="/Applications/Brave Browser.app/Contents/MacOS/Brave Browser" npx pinchtab-mcp
# Microsoft Edge
CHROME_BINARY="/Applications/Microsoft Edge.app/Contents/MacOS/Microsoft Edge" npx pinchtab-mcp
# Visible browser (non-headless) for debugging
BRIDGE_HEADLESS=false npx pinchtab-mcp
# Custom window size (default: random common resolution for stealth)
CHROME_FLAGS="--window-size=1920,1080" npx pinchtab-mcp
# Connect to an existing browser session (keeps your tabs, cookies, logins)
CDP_URL="http://localhost:9222" npx pinchtab-mcpFor tools reference, project structure, agent workflow, and code style see PROJECT_INDEX.md.
See CONTRIBUTING.md.
MIT
Click an element by its ref ID (e.g. 'e5'). Uses human-like click by default. Set waitMs to get a snapshot after clicking (saves a round-trip). For SPAs, clicking may not cause full navigation.
| Name | Required | Description | Default |
|---|---|---|---|
| humanClick | No | Use real mouse events (default: true). Set to false for programmatic .click(). | |
| ref | Yes | Element reference ID (e.g. 'e5') | |
| waitMs | No | Wait this many ms after clicking, then return a compact page snapshot (max 10000). | |
| waitNav | No | Wait for navigation after click (useful for link clicks). Default: false. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It covers human-like click default and waitMs snapshot, but omits error handling, navigation consequences, and return behavior. The SPA note is helpful, but gaps remain.
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, front-loaded with the main action. Every sentence provides useful information with no wasted words. Ideal conciseness.
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 no annotations, the description should cover return values, error cases, and prerequisites. It mentions waitMs returns a snapshot but does not state default return. Missing details on waitNav and error handling make it less complete than ideal.
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 100%, so baseline is 3. The description adds value by explaining default behavior (humanClick=true) and the purpose of waitMs (snapshot, saves round-trip). This enhances understanding beyond the schema.
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), the resource (element by ref ID), and distinguishes from siblings like hover or focus. It provides specific examples and mentions human-like click and waiting for snapshot, making the purpose unambiguous.
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 context on when to use waitMs (to get snapshot, saves round-trip) and notes SPA behavior. However, it does not explicitly compare with alternative tools like hover or press, leaving some inferential work to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Close the current tab or a specific tab by its ID.
| Name | Required | Description | Default |
|---|---|---|---|
| tabId | No | Tab ID to close. If omitted, closes the current tab. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description bears full responsibility for disclosing behavioral traits. It only says 'close,' which implies a destructive action, but fails to mention that it cannot be undone, what happens to tab state, or error handling for invalid tab IDs. This lack of detail leaves the agent unaware of 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?
Single sentence that is concise, clear, and front-loaded with the action. No wasted words or redundant information. It efficiently communicates the core functionality.
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 low complexity (one optional parameter, no output schema), the description covers the essential behavior: two usage modes. However, it lacks context about return values or success/failure feedback, which would be helpful for error handling. Still, it is sufficient for a simple close operation.
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 100%, so baseline is 3. The description adds value by explaining the default behavior when tabId is omitted ('closes the current tab'). However, it does not elaborate on format constraints or validation beyond schema, so it meets but does not exceed the baseline meaningfully.
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's function: closing a tab, either the current one or a specific one by ID. The verb 'close' and resource 'tab' are explicit, and the two usage modes are distinguished. It differentiates well from sibling tools like navigate or click.
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 is provided on when to use this tool versus alternatives (e.g., when to close vs. navigate away). There is no mention of prerequisites, such as requiring the tab to exist, or when not to use it. The description only states what it does, not when to apply it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all cookies for the current page.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description bears full responsibility for behavioral disclosure. It accurately indicates a read operation on cookies, implying no side effects. However, it omits details like whether HTTP-only cookies are included or potential error conditions.
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 a single concise sentence that immediately conveys the tool's purpose. Every word is necessary, and it is front-loaded with the action and resource.
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 (no parameters, no output schema), the description is minimally adequate. However, it lacks context about the return format or any filtering (e.g., domain scope), which would help the agent use the output 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 tool has zero parameters and 100% schema coverage. According to guidelines, 0 parameters warrant a baseline score of 4. The description adds no parameter info, which is acceptable since none exist.
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 verb 'Get' and the resource 'all cookies for the current page', distinguishing it from sibling tools like pinchtab_click or pinchtab_navigate which perform actions rather than data retrieval.
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 is provided on when to use this tool versus alternatives. There is no mention of use cases, prerequisites, or exclusions, leaving the agent to infer usage solely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute JavaScript code in the page context. Returns the result of the expression.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | JavaScript code to execute in the page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states that code is executed 'in the page context' and returns a result, which is accurate but minimal. It does not disclose potential side effects, security implications, or what happens to the page state. Since there is no contradiction with annotations (none exist), a score of 3 is appropriate.
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 brief and front-loaded, with two sentences that convey the core action and return value. No unnecessary words. However, it could be improved by including context about the execution environment or return value type, but it is appropriately sized for a simple tool.
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, the description mentions the return value, which is helpful. However, it lacks details about the types of expressions supported, error handling, or whether asynchronous code is allowed. The tool has only one parameter, so completeness is adequate but not thorough.
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 description coverage is 100%, so the baseline is 3. The description adds minimal extra meaning beyond the schema by specifying 'JavaScript code' and 'in the page context'. The schema already describes the parameter as 'JavaScript code to execute in the page', so the description does not significantly enhance understanding.
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 'Execute JavaScript code' and the resource 'in the page context', indicating a specific verb-resource pair. It also mentions the return value, which distinguishes it from other tools that perform actions on the page without returning results. However, it does not explicitly differentiate from sibling tools like pinchtab_get_text, which is a related but distinct operation.
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?
There is no guidance on when to use this tool versus alternatives. For example, it does not clarify whether to use this tool instead of pinchtab_get_text for extracting text content. The description lacks context about prerequisites, limitations, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Focus an element by its ref ID. Useful for triggering focus-dependent UI (e.g. autocomplete dropdowns) without clicking.
| Name | Required | Description | Default |
|---|---|---|---|
| ref | Yes | Element reference ID (e.g. 'e3') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description mentions UI effect but omits behavior on failure (e.g., if element not focusable) or side effects. Adequate for a simple action.
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 clear, front-loaded sentences. No unnecessary words; every sentence 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?
Sufficient for a single-parameter, no-output tool. Explains purpose and use case, but lacks details on error handling or prerequisites (e.g., element must be focusable). Mostly complete.
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 100% with description of 'ref' parameter. Description adds no extra meaning beyond schema (e.g., 'Element reference ID'). Baseline score.
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?
Clearly specifies verb 'Focus' and resource 'element by ref ID'. Distinguishes from sibling 'pinchtab_click' by noting it triggers focus without clicking.
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?
Provides clear context for when to use (triggering focus-dependent UI like autocomplete dropdowns) and implies not to use click. Lacks explicit when-not-to-use or alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get readable text content from the page (~800 tokens). Best for extracting article content or page information.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that output is readable and limited to ~800 tokens, but doesn't mention whether the tool is read-only, how it handles large pages, or if it waits for page load.
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, no fluff. Clearly communicates the action, token limit, and best use case.
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 simple tool with no parameters and no output schema, the description is fairly complete. It explains the essence and limitation, but could mention prerequisites (e.g., page must be loaded) or behavior on large pages.
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, and schema coverage is 100%. Baseline for 0 parameters is 4; description adds no redundant param info.
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 the verb ('Get'), resource ('readable text content'), and scope ('from the page, up to 800 tokens'). Distinguishes from siblings like pinchtab_snapshot which might return raw HTML.
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?
Description says 'Best for extracting article content or page information' which indicates when to use, but does not explicitly mention when not to use or provide alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check if PinchTab server is running and responsive.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It indicates the operation is a read-only check, but does not detail behavior on failure (e.g., timeout, error message) or response format. For a simple health check, the description is adequately 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 a single, precise sentence with no extraneous information, fitting the recommendation to be front-loaded and concise.
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?
Without an output schema, the agent cannot determine the tool's return type (e.g., boolean, status text). The description omits what 'running and responsive' means in terms of response, leaving the agent without necessary context to handle the result.
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 input schema has zero parameters, so schema coverage is 100%. Baseline score of 4 applies as the description need not add parameter details.
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 verb 'Check' and the resource 'PinchTab server', specifying what is checked ('running and responsive'). It effectively distinguishes from sibling tools like pinchtab_click or pinchtab_navigate, which are action-oriented for browser interactions.
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 the tool is for verifying server availability, but lacks explicit guidance on when to use it (e.g., before other operations) or when not to (e.g., if server is definitely down). No alternatives are mentioned, though no sibling tool duplicates this function.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Hover over an element by its ref ID. Triggers mouseover/mouseenter events — useful for revealing tooltips, dropdown menus, or hover states.
| Name | Required | Description | Default |
|---|---|---|---|
| ref | Yes | Element reference ID (e.g. 'e5') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It explains that the tool triggers mouseover/mouseenter events, which is useful behavioral context. However, it does not disclose potential side effects or prerequisites (e.g., element must be visible).
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 short sentences, front-loaded with the main action, and uses no unnecessary words. Every sentence 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?
For a simple one-parameter tool with no output schema, the description covers what it does and when to use it. It lacks error handling or preconditions, but the context of sibling tools (like wait_for_selector) mitigates this.
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 100% and the parameter description is clear. The description adds minimal extra meaning beyond repeating 'by its ref ID.' 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 clearly states the verb 'hover' and the resource 'element by its ref ID.' It also explains the triggered events and use cases, distinguishing it from sibling tools like click or focus.
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 mentions usefulness for revealing tooltips, dropdowns, or hover states, providing some context. However, it does not specify when not to use this tool or offer alternatives among the many sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all open browser tabs. Returns tab IDs, URLs, and titles.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description states it returns specific data (IDs, URLs, titles). Assumed read-only. No contradictions. Could explicitly confirm non-destructive nature.
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, perfectly concise. All necessary information front-loaded. No wasted words.
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?
No output schema, but description adequately explains what the tool returns. Tool is simple (zero params). Description covers all needed context.
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?
No parameters in schema, so description does not need to add parameter information. Schema coverage is 100% by default.
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 explicitly states 'List all open browser tabs' with specific verb and resource. Returns tab IDs, URLs, and titles. Clearly distinguishes from sibling tools like pinchtab_click or pinchtab_navigate.
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?
Implied usage is to get an overview of open tabs before performing actions. No explicit when-not or alternatives, but context from sibling tools makes it clear. Could mention it's for obtaining tab IDs for other operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Export the current page as a PDF. Returns the PDF as base64.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits. It only says it exports PDF and returns base64. It omits side effects, error conditions, whether it requires a loaded page, or any rate limits. Insufficient for fully informed use.
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 short sentences with no fluff. Each sentence provides essential information: action and output format. Efficient and well-structured.
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 (no params, no output schema), the description is fairly complete. It specifies the action and return format. However, 'current page' assumes knowledge of the tab context from sibling tools, and could be more explicit about what constitutes the 'current page'.
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, and schema coverage is 100%. Per guidelines, 0 parameters yields a baseline of 4. The description adds no parameter info because none exist.
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: 'Export the current page as a PDF' and the return format 'Returns the PDF as base64.' It uses a specific verb and resource, and is distinct from sibling tools which are all browser interactions (click, navigate, etc.).
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 is provided on when to use this tool versus alternatives, prerequisites (e.g., a page must be loaded), or when not to use it. There is no contextual information to help an agent decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Press a keyboard key (e.g. 'Enter', 'Tab', 'Escape', 'ArrowDown'). Optionally target a specific element.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | Key to press (e.g. 'Enter', 'Tab', 'Escape') | |
| ref | No | Element ref to focus before pressing the key (e.g. 'e5'). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It does not explain key press mechanics (e.g., keydown/keyup, whether it works without focus), side effects, or error conditions. The optional targeting is vaguely mentioned without detail on how it works.
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 concise with two sentences, front-loading the main action. It avoids unnecessary words but could benefit from slightly more structure (e.g., listing key examples in a clearer format).
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 complexity of browser automation and lack of output schema or annotations, the description is insufficient. It does not cover important details like modifier key support, element focus requirements, or what happens if the key press fails. The agent may misinterpret the tool's behavior.
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 100%, with schema descriptions for both 'key' and 'ref' already clear. The description adds only that targeting is optional, which is already implied by the parameter being not required. 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?
The description clearly states the tool presses a keyboard key, with examples like 'Enter', 'Tab', etc. It mentions optional element targeting, which distinguishes it from sibling tools like pinchtab_type (typing text) and pinchtab_click (mouse click).
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 provides no explicit guidance on when to use this tool versus alternatives. It lacks context such as when a key press is preferred over typing or clicking, and does not mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Take a screenshot of the page. Returns a base64-encoded image.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description indicates the output format (base64-encoded image) but lacks details such as whether it captures the full page or viewport, if it waits for page load, or any side effects. Without annotations, this is insufficient.
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 a single, clear sentence with no unnecessary words. It is front-loaded and efficient.
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 simple tool with no parameters and no output schema, the description is adequate but missing behavioral details like full-page vs viewport capture. It does not leverage sibling context to clarify usage boundaries.
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 the description does not need to add meaning beyond the schema. The schema coverage is 100% trivially, meeting the baseline of 4.
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 (take screenshot) and the result (base64-encoded image). It distinguishes from siblings like pinchtab_click or pinchtab_navigate, but does not explicitly differentiate from pinchtab_snapshot or pinchtab_pdf.
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 is provided on when to use this tool versus alternatives like pinchtab_snapshot or pinchtab_pdf. There is no mention of context, prerequisites, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scroll the page or a specific element. Supports all four directions.
| Name | Required | Description | Default |
|---|---|---|---|
| amount | No | Scroll amount in pixels. Default: 500 | |
| direction | Yes | Scroll direction | |
| ref | No | Element ref to scroll within (e.g. 'e5'). If omitted, scrolls the page. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must cover behavior. It states the action but omits details like scrolling behavior (smooth/jump), default effects, or prerequisites for the ref parameter.
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 a single, well-structured sentence that immediately conveys the core functionality without extraneous words.
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 simple scroll tool with no output schema and low complexity, the description is adequate but could mention return behavior and error conditions to be fully complete.
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 100% schema coverage, baseline is 3. The description adds value by clarifying that omitting ref scrolls the page, and including ref scopes within an element, going beyond enum and type descriptions.
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 scrolls a page or specified element in four directions, distinguishing it from other interaction tools like click or 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?
It effectively communicates the primary use case (scrolling) and covers all directions, but lacks explicit guidance on when not to use or comparisons with alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Select an option in a dropdown by its ref ID. Pass the option value or visible text.
| Name | Required | Description | Default |
|---|---|---|---|
| ref | Yes | Element reference ID of the <select> | |
| value | Yes | Option value or visible text to select |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It does not disclose behavioral traits like event firing, page interactions, or side effects beyond the basic action, leaving the agent uninformed about potential consequences.
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 consists of two concise sentences with no unnecessary words. It is front-loaded with the action and immediately provides key details.
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 simplicity of the tool (2 simple parameters, no output schema), the description fully informs the agent about what to provide and how to use it. No missing information for correct invocation.
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 description coverage is 100% and the description essentially repeats the schema text for both parameters ('Option value or visible text' for value, 'by its ref ID' for ref). No additional meaning is added.
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 verb 'Select', the resource '<select> dropdown', and the method using 'ref ID' and 'option value or visible text'. This distinguishes it from sibling tools like pinchtab_click or pinchtab_get_text.
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 explains how to use the tool (by ref ID and value/text) but does not provide explicit guidance on when to use it vs. alternatives, such as pinchtab_click or pinchtab_type, or mention preconditions or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get an accessibility tree snapshot of the page. Returns element refs (e0, e1, …) that can be used with click/type/press. Use filter='interactive' for fewer tokens. Use format='compact' for minimal output.
| Name | Required | Description | Default |
|---|---|---|---|
| diff | No | If true, return only changes since last snapshot. Great for multi-step workflows. | |
| filter | No | Filter elements: 'interactive' for buttons/links/inputs only. Default: 'all' | |
| format | No | 'compact' returns minimal refs (~3.6K tokens). Default: 'full' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description implicitly indicates read-only snapshot behavior but does not disclose potential side effects or precise behavior beyond returning refs. Adequate but not exhaustive.
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?
Three sentences, no redundancy. First sentence gives core purpose, subsequent sentences provide actionable usage guidance. Extremely efficient.
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, description adequately explains return value (element refs). All parameters are covered. Missing error handling details, but acceptable for a snapshot tool.
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 covers all parameters with descriptions. Description adds value by explaining 'diff' for multi-step workflows and emphasizing token savings for filter and format. Enhances understanding beyond schema.
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 gets an accessibility tree snapshot and returns element refs for use with click/type/press. It distinguishes from sibling tools like pinchtab_click that use these refs.
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?
Provides specific usage tips: filter='interactive' for fewer tokens, format='compact' for minimal output, and diff for multi-step workflows. Lacks explicit when-not-to-use or alternatives, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Type text into an input field by its ref ID. Uses human-like typing by default. Set clearFirst=true to click, select all, then type — required for React/Vue/Angular inputs where direct fill doesn't trigger state updates.
| Name | Required | Description | Default |
|---|---|---|---|
| clearFirst | No | Click the field, select all (Ctrl+A), then type. Required for React/Vue/Angular inputs. | |
| fast | No | Speed up humanType with shorter delays between keystrokes. Only applies when humanType=true. | |
| humanType | No | Use human-like keystroke simulation (default: true). Set to false for fast programmatic fill. | |
| ref | Yes | Element reference ID of the input field | |
| text | Yes | Text to type into the field |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fairly discloses key behaviors: human-like typing by default, clearFirst clicks and selects all, and fast speeds keystrokes. It does not mention side effects like clearing existing text or visibility requirements, but covers essential traits.
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 three sentences, front-loaded with the core purpose. Every sentence adds value: purpose, default behavior, and parameter guidance. No waste.
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 5 parameters, no output schema, and no annotations, the description covers the main behavioral traits and parameter nuances. It omits return value and error conditions, but overall is sufficient for a typing tool.
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 100%, but the description adds meaningful context beyond the schema: it explains the default for humanType, the necessity of clearFirst for React/Vue/Angular, and the effect of fast. However, it does not add detail for ref or text parameters.
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 'Type text into an input field by its ref ID', specifying the verb, resource, and distinguishing from sibling tools like pinchtab_click or pinchtab_press. It adds context about human-like typing and the clearFirst option for frameworks.
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 provides clear context for when to use clearFirst, fast, and humanType parameters. However, it does not explicitly guide when to use this tool versus siblings like pinchtab_press or pinchtab_get_text, missing some alternative differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Wait for a specified number of seconds. Useful after navigation or dynamic content loading.
| Name | Required | Description | Default |
|---|---|---|---|
| seconds | No | Number of seconds to wait (1-30). Default: 3 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility for behavioral disclosure. It adequately describes the primary behavior (waiting), but does not clarify whether the wait is blocking or if there are any side effects, though this is implied for a simple wait 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 exceptionally concise: two short sentences that front-load the core action and usage context with no superfluous words.
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 simple tool with no output schema, the description is sufficient: it states the purpose, usage context, and the single parameter. It could note blocking behavior but that is largely implied.
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 input schema already provides 100% coverage with a clear description including range and default. The tool description adds no additional meaning beyond the schema, so it meets the baseline for high schema coverage.
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's action ('Wait for a specified number of seconds') and its utility after navigation or dynamic content loading, effectively distinguishing it from sibling tools that perform other 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 provides clear context for when to use the tool (after navigation or dynamic content loading), but does not explicitly state when not to use it or mention alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Wait for a CSS selector to appear on the page. Polls every 500ms up to the timeout. Useful for waiting on dynamic content, modals, or lazy-loaded elements.
| Name | Required | Description | Default |
|---|---|---|---|
| selector | Yes | CSS selector to wait for (e.g. '#login-form', '.loaded', '[data-ready]') | |
| timeoutMs | No | Maximum wait time in ms (default: 5000, max: 15000). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose all behavioral traits. It mentions polling interval (500ms) and timeout, but does not specify return value, error behavior on timeout, or whether it waits for visibility vs. presence. This is a partial disclosure.
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, front-loaded with purpose and polling detail, then use cases. No wasted words, efficient and clear.
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?
The description lacks return value information (e.g., what is returned when element appears or times out) and does not mention error scenarios. Given no output schema, this is a gap. However, the tool is simple and the description covers core behavior.
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 100%, but the description adds value beyond the schema by explaining polling behavior and providing usage examples for the selector parameter. The timeout default and max are also mentioned.
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 a CSS selector to appear, which distinguishes it from sibling tools like pinchtab_wait that may be a generic delay. The verb 'wait' is paired with the specific resource 'CSS selector'.
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 provides explicit use cases: waiting on dynamic content, modals, or lazy-loaded elements. It does not specify when not to use or differentiate from alternatives like pinchtab_wait, but the context is clear.
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.
pinchtab_clickpinchtab_close_tabpinchtab_cookiespinchtab_evalpinchtab_focuspinchtab_get_textpinchtab_healthpinchtab_hoverpinchtab_list_instancespinchtab_navigatepinchtab_pdfpinchtab_presspinchtab_screenshotpinchtab_scrollpinchtab_selectpinchtab_snapshotpinchtab_typepinchtab_waitpinchtab_wait_for_selectorScored across 19 tools
Each tool targets a distinct browser automation action (click, type, scroll, navigate, etc.) with no functional overlap. Even similar actions like click vs focus vs hover are clearly differentiated by their descriptions and use cases.
All tools use the pinchtab_ prefix and snake_case. However, there is a minor inconsistency: some tools use verb_noun (e.g., pinchtab_list_instances, pinchtab_get_text) while others are just a noun (e.g., pinchtab_cookies, pinchtab_screenshot) instead of pinchtab_get_cookies or pinchtab_take_screenshot.
19 tools cover the essential browser automation operations without being excessive. Each tool serves a clear purpose, and the number feels well-scoped for a comprehensive automation server.
The tool set covers most common browser interactions: navigation, input, events, screenshots, PDF, cookies, evaluation, and tab management. Missing features like file upload or drag-and-drop are minor gaps that can be worked around with eval.
Automate cloud Chrome—navigate, click, type, screenshot, run code, record screen video
Hosted browser for AI agents: screenshots, post-JS DOM, console, WCAG. No install, no API key.
AI-powered browser automation — navigate, click, fill forms, and extract data from any website.
Run multi-step tasks in a real Chrome browser: persistent environments, live view, human takeover.
