Skip to main content
Glama
achiya-automation

Safari MCP Server

by achiya-automation
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

safari_eval_file

Executes JavaScript from a .js file path, avoiding huge inline scripts and enabling binary uploads via generated base64 files. Uses Safari's extension-first engine with AppleScript fallback.

Instructions

Execute JavaScript read from a FILE path (avoids passing huge scripts inline / manual copy). Same engine as safari_evaluate: extension-first (no focus steal), AppleScript fallback. Use to upload binary via a generated .js containing base64.

Input Schema

NameRequiredDescriptionDefault
pathYesAbsolute path to a .js file whose contents are the script to execute
receiptNoOpaque extension-issued tab receipt — pass the one safari_new_tab returned to keep targeting that tab after an MCP reconnect

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv2.22.5
    • addedInput schema / properties / receipt
      Added value: +{
+  "description": "Opaque extension-issued tab receipt — pass the one safari_new_tab returned to keep targeting that tab after an MCP reconnect",
+  "type": "string"
+}
  2. Addedv2.12.1

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 disclosure burden and does so meaningfully: it reveals the execution mechanism (extension-first with AppleScript fallback) and a key side-effect trait (no focus steal). It omits return-value/error behavior, but the engine and focus details are genuine behavioral value.

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?

Three compact sentences, front-loaded with the core action, with each clause (inline-avoidance, engine/fallback, binary-upload use case) contributing. Slightly dense with parentheticals but no wasted text.

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?

For a script-execution tool with no output schema, the description covers mechanism, sibling relationship, and intended use cases adequately. It could do more on return values and the role of the 'receipt' parameter, but nothing critical to correct invocation is missing.

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 coverage is 100%, so both the 'path' and 'receipt' parameters are already documented in the schema. The description reinforces the file-path intent but adds no syntax or format detail beyond what the schema provides, 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 specific verb and resource ('Execute JavaScript read from a FILE path') and explicitly distinguishes itself from the sibling safari_evaluate by contrasting file-based vs inline execution. An agent can tell exactly what this does and how it differs.

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 clear when-to-use context ('avoids passing huge scripts inline / manual copy') and a concrete use case ('upload binary via a generated .js containing base64'), while naming safari_evaluate as the shared-engine alternative. It implies but does not state the inverse exclusion (use safari_evaluate for small inline scripts), so it stops short of full when/when-not guidance.

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