Skip to main content
Glama
Sign In
Safari MCP Server

Safari MCP Server

by achiya-automation
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

safari_snapshot

Capture the page accessibility tree with ref IDs for interactive elements, letting agents click or fill by reference instead of fragile CSS selectors.

Instructions

PREFERRED way to see page state. Returns accessibility tree with ref IDs for every interactive element. Use refs with click/fill/type instead of CSS selectors. Workflow: snapshot → see refs → click({ref:'0_5'}). PREFER THIS over safari_screenshot (cheaper, structured text vs heavy image) and over safari_read_page (includes interactive refs). Use safari_screenshot only when you need to see visual layout/styling.

Input Schema

NameRequiredDescriptionDefault
diffNoReturn only the lines that changed since this tab's previous snapshot (+ added, with fresh refs; - removed). Much smaller after a click or a fill
receiptNoTab receipt from safari_new_tab — pins this call to that tab (survives reconnects/subagents)
selectorNoCSS selector for subtree (default: full page)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv2.23.0
    • addedInput schema / properties / diff
      Added value: +{
+  "description": "Return only the lines that changed since this tab's previous snapshot (+ added, with fresh refs; - removed). Much smaller after a click or a fill",
+  "type": "boolean"
+}
  2. Changed1 schema field changedv2.18.1
    • addedInput schema / properties / receipt
      Added value: +{
+  "description": "Tab receipt from safari_new_tab — pins this call to that tab (survives reconnects/subagents)",
+  "type": "string"
+}
  3. Addedv2.11.6
  4. Removedv2.11.3
  5. Addedv2.10.9
  6. Removedv2.10.8
  7. Addedv2.10.5
  8. Removedv2.10.4
  9. First observed

TDQS

A4.1/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the burden and does OK: it discloses the return shape (accessibility tree with refs), the cost tradeoff (cheaper than image), and how refs tie into downstream calls. It never says the call is read-only/non-mutating or mentions the diff/selector scoping behavior, which are the main behavioral gaps.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the preferred-status claim and the core return value, then the workflow, then the alternatives. Slightly repetitive emphasis ('PREFERRED way' / 'PREFER THIS over') but no sentence is wasted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, and the description compensates by describing the returned tree and refs. For a 3-param, zero-required read tool this is nearly sufficient; only the diff-mode behavior and the read-only nature are unstated.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents diff, receipt, and selector in detail. The description adds nothing about any parameter — notably it omits diff, the highest-value option for reducing payload after a click — so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a concrete verb+resource (returns the accessibility tree of the current page state) and immediately clarifies the output contract: ref IDs on every interactive element. It explicitly contrasts itself with safari_screenshot and safari_read_page, so an agent can place it without opening a schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives an explicit workflow (snapshot → refs → click({ref:'0_5'})) and a clear when-not ('use safari_screenshot only when you need visual layout/styling'). It leaves out the very similar sibling safari_accessibility_snapshot, so the agent has no guidance on which accessibility-tree tool to pick.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools