Controls Safari browser allowing navigation, reading page content, clicking elements, filling forms, executing JavaScript, tab management, and scrolling.
Gives Claude Desktop the ability to control Safari — navigate pages, read content, click elements, fill forms — via the MCP protocol, just like "Claude in Chrome".
Claude Desktop (MCP stdio)
↕ JSON-RPC
bridge/bridge.js (Node.js)
↕ WebSocket ws://localhost:45678
Safari Extension background.js (MV2)
↕ browser.tabs / executeScript
Active Safari tabRelated MCP server: Safari MCP Server
claudeForSafari/ ← git root
├── .gitignore
├── README.md
├── bridge/ ← Node.js bridge (MCP ↔ WebSocket)
│ ├── bridge.js
│ ├── package.json
│ └── package-lock.json
└── app/ ← Xcode project
├── claudeExtension.xcodeproj
├── claudeExtension/ ← Swift host app (macOS)
└── claudeExtension Extension/
└── Resources/ ← SINGLE SOURCE for extension files
├── manifest.json
├── background.js
├── content.js
├── popup.html / popup.js / popup.css
├── images/
└── _locales/Rule: all extension file edits go directly in
app/claudeExtension Extension/Resources/. There is no separatesafari-extension/folder.
macOS 14+ (Sonoma or later)
Xcode 16+
Node.js v18+ — nodejs.org if not yet installed
An Apple developer account (free account is enough for local use)
Claude Desktop with MCP support
git clone git@github.com:Lyosis/claudeForSafari.git
cd claudeForSafaricd bridge
npm install
cd ..Open app/claudeExtension.xcodeproj in Xcode
Select the claudeExtension scheme (the host app)
Choose My Mac as the destination
Press Cmd+R — Xcode builds and launches the app
macOS will show a banner: "claudeExtension wants to add a Safari extension" → click Open Safari Preferences and enable the extension.
Safari → Settings (Cmd+,) → Extensions tab
Check claudeExtension
In the right column → Allow on all websites
Without this permission, script injection into pages will fail silently.
Open (or create):
~/Library/Application Support/Claude/claude_desktop_config.jsonAdd the safari entry under mcpServers:
{
"mcpServers": {
"safari": {
"command": "node",
"args": [
"/absolute/path/to/claudeForSafari/bridge/bridge.js"
]
}
}
}Replace /absolute/path/to/ with the actual path where you cloned the repo.
If node is not in Claude Desktop's PATH, use its full path:
which node # e.g. /usr/local/bin/node or /opt/homebrew/bin/nodeThen restart Claude Desktop.
The bridge starts automatically with Claude Desktop.
Safari must be open with the extension enabled.
The extension reconnects automatically to the bridge after sleep or after visiting Safari Settings — no manual action required.
Tool | Description |
| List available Safari profiles |
| Navigate to a URL |
| Read the visible text of the current page |
| Get the full HTML of the current page |
| Execute arbitrary JavaScript |
| Find elements by CSS selector or text content |
| Click an element |
| Fill an |
| Scroll the page |
| List open tabs |
| Open a new tab |
| Close a tab |
| Switch to a tab by ID |
safari_form_inputsupports<input>and<textarea>fields. Rich text editors usingcontenteditable(Notion, Gmail compose, etc.) are not yet supported.
"Safari extension not connected"
Is Safari open? Is the extension checked in Safari → Extensions?
Check the bridge is running: ps aux | grep bridge.js
Check logs: Console.app → filter by claude-safari
Permission denied on script injection
→ Safari → Settings → Extensions → claudeExtension → Allow on all websites
safari_get_page_text fails on an internal tab
→ Internal Safari pages (favorites://, about:blank, etc.) cannot be injected. Navigate to an http:// or https:// URL first.
Bridge won't start
→ Check Node.js: node -v (v18+ required)
→ Use the absolute path to node in claude_desktop_config.json
Xcode — "No signing certificate"
→ Xcode → Settings → Accounts → add your Apple ID → Download Manual Profiles
The bridge listens on ws://localhost:45678 — localhost only, never exposed to the network.
However, any local process can connect to that port. There is no cryptographic authentication between the bridge and the Safari extension. The threat model assumes that other processes running under your user account are trusted. If you run untrusted local software, be aware that it could theoretically connect to the bridge.
safari_javascript executes arbitrary JavaScript in the active tab by design. Treat it like browser DevTools — only use it on pages you trust.
All extension file edits go in:
app/claudeExtension Extension/Resources/After editing background.js or manifest.json:
Rebuild in Xcode (Cmd+R)
Safari → Settings → Extensions → disable then re-enable the extension
(or restart Safari)
The bridge (bridge/bridge.js) does not need a rebuild — Node.js picks up changes on the next Claude Desktop restart.
MIT
Click an element identified by a CSS selector.
| Name | Required | Description | Default |
|---|---|---|---|
| selector | Yes | CSS selector of the element to click | |
| tabId | No | Tab ID — omit to use the active tab | |
| profile | No | Safari profile name (e.g. "Perso", "Pro"). Omit to use the first connected profile. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description does not disclose behavioral traits such as page load waiting, element visibility requirements, or potential side effects (e.g., triggering navigation).
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 wasted words. However, it could be slightly expanded to include key behavioral notes without losing 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?
For a mutation tool with no output schema and no annotations, the description is too brief. It omits important details like error handling, waiting behavior, and element state requirements.
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 three parameters with descriptions. The tool description adds no extra meaning beyond what the schema already provides, so baseline score of 3 applies.
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 action ('click') and target ('element identified by a CSS selector'). It distinguishes from sibling tools like safari_form_input (input text) and safari_find (find elements).
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 versus alternatives (e.g., safari_javascript for complex interactions, safari_navigate for navigation). No when-not or context hints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find elements on the page by CSS selector and/or visible text.
| Name | Required | Description | Default |
|---|---|---|---|
| selector | No | CSS selector (optional) | |
| text | No | Filter elements whose text contains this string (optional) | |
| limit | No | Max elements to return (default 20) | |
| tabId | No | Tab ID — omit to use the active tab | |
| profile | No | Safari profile name (e.g. "Perso", "Pro"). Omit to use the first connected profile. |
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 does not disclose the return format (e.g., element references) or any side effects. The agent cannot infer how the results are structured or how to use them with other tools. This is a significant gap.
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 of 12 words with no redundancy. It is front-loaded and communicates the core purpose efficiently.
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?
Despite having 5 parameters and no output schema or annotations, the description does not explain the output format (e.g., element references) or how the tool integrates with siblings like safari_click. The agent lacks crucial context for effective 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?
Schema coverage is 100% with each parameter having a description. The description adds no extra meaning beyond the schema; it only restates that selector and text can be used together. Baseline 3 is appropriate as the schema already does the heavy lifting.
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 'Find' and the resource 'elements on the page', and specifies the search method 'by CSS selector and/or visible text'. This distinguishes it from sibling tools like safari_click (which acts on elements) or safari_read_page (which reads content).
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 is minimal and does not explicitly state when to use this tool versus alternatives. It implies usage for locating elements, but lacks guidance on scenarios where safari_javascript or other tools might be more appropriate. A more explicit statement would be beneficial.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set the value of an input, textarea, or select element and fire input/change events.
| Name | Required | Description | Default |
|---|---|---|---|
| selector | Yes | CSS selector of the form field | |
| value | Yes | Value to enter | |
| tabId | No | Tab ID — omit to use the active tab | |
| profile | No | Safari profile name (e.g. "Perso", "Pro"). Omit to use the first connected profile. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. It discloses the firing of input/change events, but lacks details on waiting behavior, validation, or error states.
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 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?
Given the tool's simplicity and full schema coverage, the description is adequate but incomplete. It does not mention return values or behavior when required parameters are missing. For a mutation tool with no output schema, some behavioral context 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?
All parameters have descriptions in the schema (100% coverage). The description adds no additional meaning beyond what the schema already provides, so 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 'Set the value', the resource 'input, textarea, or select element', and the action 'fire input/change events'. It distinguishes from sibling tools like safari_click or safari_javascript.
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 explicit guidance on when to use this tool vs. alternatives. It does not mention when not to use it or provide context about prerequisites (e.g., element must exist).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the visible text content of the current page (innerText).
| Name | Required | Description | Default |
|---|---|---|---|
| tabId | No | Tab ID — omit to use the active tab | |
| profile | No | Safari profile name (e.g. "Perso", "Pro"). Omit to use the first connected profile. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the burden of behavioral disclosure. It correctly notes that the content is 'visible' and uses 'innerText', implying hidden text is excluded. However, it omits details like compatibility with iframes, handling of page load states, or whether whitespace is preserved.
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 short sentence that conveys the core functionality without excess. While very concise, it could be marginally improved by adding structure (e.g., bullet points for parameters) but remains effective.
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 covers the primary behavior but lacks specifics on return format (e.g., plain text, trailing whitespace) and edge cases (e.g., empty page, unloaded page). It 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?
Both parameters (tabId, profile) have descriptions in the input schema, achieving 100% schema coverage. The tool description adds no further parameter context, so the 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 action ('Return'), the resource ('visible text content of the current page'), and specifies the implementation ('innerText'). This distinguishes it from sibling tools like safari_read_page (which likely returns HTML) and safari_find (which finds elements).
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 vs alternatives such as safari_read_page or safari_find. The description only states what it does, leaving the agent to infer usage context from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute arbitrary JavaScript in the current page and return the result.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | JS expression or statements. Use return for values. | |
| tabId | No | Tab ID — omit to use the active tab | |
| profile | No | Safari profile name (e.g. "Perso", "Pro"). Omit to use the first connected profile. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Mentions execution of arbitrary JS but omits risks like page mutation, navigation, or data extraction. No disclosure of sandboxing, permissions, or 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, highly efficient. Every word adds meaning. No filler or repetition.
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?
Lacks details on behavior when no return statement is present, error handling, or execution environment. For an arbitrary code execution tool, more context is warranted, especially given no output schema.
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 three parameters with descriptions. Description adds value with 'Use return for values' for code and confirms defaults for tabId and profile, aiding agent 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?
Clearly states verb 'execute', resource 'JavaScript in the current page', and outcome 'return the result'. Unambiguously distinguishes from sibling tools like safari_click or safari_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 from description but no explicit guidance on when to use versus alternatives. Lacks when-not-to-use warnings or examples of appropriate scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all Safari profiles currently connected to the bridge, with their connection status.
| 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 fully explain behavior. It states the tool lists connected profiles and their status, but doesn't define 'connected to the bridge' or mention any potential side effects. Acceptable for a read-only 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 a single concise sentence that delivers key information without unnecessary detail. 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?
For a simple list tool with no parameters and no output schema, the description is adequate but not complete. It doesn't specify the output format (e.g., list of names, statuses). Adding detail about what 'connection status' means 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?
The tool has 0 parameters, so the baseline is 4. The description doesn't add parameter information, but none is needed.
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 'list', the resource 'Safari profiles', and the additional detail 'with their connection status'. It distinguishes from sibling tools like safari_click and safari_navigate by specifying it's a listing 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?
No explicit guidance on when to use this tool versus alternatives, but the purpose is straightforward. Usage is implied as a preliminary step to inspect connected profiles.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the full HTML source, URL, and title of the current page.
| Name | Required | Description | Default |
|---|---|---|---|
| tabId | No | Tab ID — omit to use the active tab | |
| profile | No | Safari profile name (e.g. "Perso", "Pro"). Omit to use the first connected profile. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states the return values but does not mention side effects, auth requirements, rate limits, or error conditions. The lack of any behavioral context is a significant gap.
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, and front-loaded sentence. Every word adds value, and there is no superfluous information.
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 should explain the return format. It mentions HTML source, URL, and title but not how they are structured (e.g., as separate properties). Missing error handling or edge cases, but adequate for a simple read 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?
The input schema covers both parameters with descriptions (100% coverage), so the description does not need to add much. The description adds no extra meaning beyond what the schema provides, meeting the baseline score of 3.
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 'return' and the resources 'full HTML source, URL, and title', making it obvious what the tool does. It also implicitly distinguishes from the sibling 'safari_get_page_text' which likely returns only 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?
No guidance is provided on when to use this tool versus alternatives like 'safari_get_page_text'. The description does not include any when-to-use or when-not-to-use instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scroll the page by x/y pixels, or to a specific position.
| Name | Required | Description | Default |
|---|---|---|---|
| x | No | Horizontal scroll delta in px | |
| y | No | Vertical scroll delta in px | |
| absolute | No | If true, scroll to absolute position instead of delta | |
| tabId | No | Tab ID — omit to use the active tab | |
| profile | No | Safari profile name (e.g. "Perso", "Pro"). Omit to use the first connected profile. |
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 does not disclose side effects, prerequisites (e.g., page must be loaded), or behavior such as whether negative values scroll up/left. The description only repeats what the schema already conveys.
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 efficient with one sentence, but it could be slightly improved by hinting at the optional parameters (e.g., 'on the active or specified tab'). Still, 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?
For a simple tool with 5 optional parameters and full schema coverage, the description is adequate but minimal. It doesn't add context about scroll direction or tab behavior, but the schema fills the gaps. The tool's simplicity keeps it from being incomplete.
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 no extra meaning beyond the schema; it merely restates the two modes already described by the 'absolute' parameter.
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 the page, using either delta (x/y pixels) or absolute positioning. It directly addresses the action 'scroll' on a 'page', and this distinguishes it from sibling tools like safari_navigate, safari_click, 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 explicit guidance on when to use this tool versus alternatives (e.g., using safari_navigate to go to a new URL). The agent must infer usage context from sibling names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Close a tab.
| Name | Required | Description | Default |
|---|---|---|---|
| tabId | No | Tab ID to close — omit to close the active tab | |
| profile | No | Safari profile name (e.g. "Perso", "Pro"). Omit to use the first connected profile. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry full behavioral disclosure. It only states 'Close a tab,' omitting key traits like that closing is destructive, that it may fail with invalid tabId, or that profile selection affects 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?
The description is extremely concise at three words, which is appropriate for a simple action. However, it is too terse to be informative; a slightly longer description could improve clarity without sacrificing 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 the tool's simplicity and sibling tools, the description lacks completeness. It does not explain when to use close vs. list, create, or switch tabs, nor does it describe the result or lack of output.
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 the baseline is 3. The description adds no additional meaning beyond what the input schema already provides for tabId and profile, neither explaining nor augmenting them.
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 ('close') and the resource ('a tab'), making the purpose unambiguous. However, it does not differentiate from sibling tools like safari_tabs_create or safari_tabs_switch, which also deal with tabs.
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 guidance on when to use this tool versus alternatives. It does not mention that omitting tabId closes the active tab or that a profile can be specified, leaving the agent without context for appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Open a new tab, optionally with a URL.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | URL to open (optional — default is blank tab) | |
| profile | No | Safari profile name (e.g. "Perso", "Pro"). Omit to use the first connected profile. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description should disclose behavioral details. Only mentions optional URL and default blank tab. Does not explain tab focus, multiple tab creation, or any 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, front-loaded, no unnecessary words. Concise 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 and simple tool, description is incomplete. Does not clarify if tab selection changes, nor any prerequisites like Safari being open.
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 both parameters with good descriptions. Description adds value by stating default behavior for url (blank tab). Baseline 3 due to 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 opens a new tab and optionally with a URL. It differentiates from sibling tools like safari_tabs_close, safari_tabs_list, etc., but does not explicitly contrast them.
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 versus alternatives like safari_navigate or safari_tabs_switch. Does not clarify prerequisites or context.
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 in the profile with their IDs, URLs, and titles.
| Name | Required | Description | Default |
|---|---|---|---|
| profile | No | Safari profile name (e.g. "Perso", "Pro"). Omit to use the first connected profile. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description implies a read-only operation but does not explicitly state behavioral traits (e.g., performance, permissions, or side effects). With no annotations, more disclosure would be beneficial.
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 front-loaded key information; concise but could be slightly more compact.
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?
Explains output (IDs, URLs, titles) and scope (all tabs in profile). Missing details like ordering or multi-window behavior, but adequate for simple lookup.
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 already describes the single parameter (profile) with 100% coverage; the description adds no further semantic details 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 tool lists all open tabs in the profile and specifies the data returned (IDs, URLs, titles), distinguishing it from sibling tools that close, create, or switch tabs.
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 explicit guidance on when to use this tool versus alternatives like safari_get_page_text or safari_tabs_switch; usage is implied but not clarified.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Switch to (activate) a tab by ID.
| Name | Required | Description | Default |
|---|---|---|---|
| tabId | Yes | Tab ID to activate | |
| profile | No | Safari profile name (e.g. "Perso", "Pro"). Omit to use the first connected profile. |
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 only states the action without mentioning side effects (e.g., the tab becomes the active tab, possibly changing the browser window focus), error conditions (e.g., invalid tab ID), or permissions required. This is insufficient for a tool with no annotation support.
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 sentence, which is maximally concise. However, it sacrifices informativeness. It could include more details without being verbose. Structure is minimal but 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?
Given the lack of output schema and annotations, the description should provide more context about what happens after activation (e.g., no return value, or confirmation). It also omits information about error handling or the need for a valid tab ID. The tool is simple, but the description is still incomplete.
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 descriptions for both parameters. The tool description adds no extra meaning beyond the schema, simply restating 'by ID'. This meets the baseline for high coverage, but the description does not enhance understanding of parameter usage or constraints.
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 (switch/activate) and the resource (tab) with the method (by ID). It distinguishes the tool from sibling tab tools like close, create, or list by specifying activation. However, it could be more explicit about what activation entails (e.g., bringing the tab to the foreground).
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 versus alternatives. The description lacks context about prerequisites (e.g., the tab must exist) or exclusions. The user is left to infer usage from the name and schema alone.
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.0safari_clicksafari_findsafari_form_inputsafari_get_page_textsafari_javascriptsafari_list_profilessafari_navigatesafari_read_pagesafari_scrollsafari_tabs_closesafari_tabs_createsafari_tabs_listsafari_tabs_switchScored across 13 tools
Each tool has a clearly distinct purpose, covering different actions like navigation, page interaction, tab management, and page reading. There is no overlap or ambiguity between tools.
All tools follow a consistent 'safari_verb' or 'safari_noun_verb' pattern using snake_case. This makes the tool set predictable and easy to understand.
With 13 tools, the server covers essential browser automation actions without being bloated. The number is well-scoped for the intended use case.
The tool set covers core browser automation tasks such as navigation, clicking, form input, scrolling, tab management, and JavaScript execution. Minor omissions like explicit wait or screenshot tools are acceptable given the server's likely purpose.
Live browser debugging for AI assistants — DOM, console, network via MCP.
Hyperbrowser MCP — wraps the Hyperbrowser AI-agent browsing API
AI-powered browser automation — navigate, click, fill forms, and extract data from any website.
Undetectable cloud browser sessions for AI agents and scrapers. Navigate, extract, click, captcha.
