Skip to main content
Glama
JackZhao98

chrome-automation-mcp

by JackZhao98
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

run_script_background

Run a JavaScript automation file from a path or URL in the background and return immediately with task info, saving script output to JSON and log files.

Instructions

📁 Execute a JavaScript file in the background with browser automation. Returns immediately with task info while script runs in background. Output is saved to files. Must provide either scriptPath OR scriptUrl (not both).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
argsNoArguments to pass to the script. Common: {query: 'search term', url: 'target.com'}
scriptUrlNoRemote URL to the JavaScript file (e.g., 'https://example.com/scripts/automation.js'). Cannot be used with scriptPath.
sessionIdNoSession ID to use for script execution. If not provided, uses current session. If provided, will connect to the specified session's browser.
screenshotNoTake a screenshot after script execution. Default: false
scriptPathNoLocal disk path to the JavaScript file (e.g., 'scripts/login-workflow.js'). Cannot be used with scriptUrl.
autoCloseTabNoAutomatically close the tab after script completes (only works when createNewTab is true). Helps prevent tab accumulation.
createNewTabNoCreate a new tab for this script execution. Each script runs in isolation with its own tab. Useful for running multiple scripts in parallel without interference.
projectFolderNooutput folder: Set this to specify where output files (.json and .log) will be saved. If not provided, defaults to system temp directory /tmp/{session_id}. Example: '/Users/username/my-project/outputs'
autoCloseBrowserNoAutomatically close the browser after script execution completes. Default: true

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.3.8

TDQS

B3.4/5.0
Behavior3/5

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

With no annotations present, the description carries the full burden. It does disclose two important traits — that it returns immediately while work continues, and that output is persisted to files — which is real value. But it omits failure behavior, concurrency limits, and whether it requires an existing browser/session, which matters for a 9-parameter automation tool.

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 short sentences, front-loaded with what the tool does before the constraint. The leading emoji is noise, but the prose itself is tight and wastes little.

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

Completeness3/5

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

For a 9-parameter tool with nested args and no output schema, the description covers execution semantics and the output-file behavior reasonably. It does not address session/tab lifecycle implications (createNewTab, autoCloseBrowser) or what the returned 'task info' contains, which the absent output schema leaves unexplained.

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 every parameter is already fully documented, setting the baseline at 3. The description only reinforces the scriptPath/scriptUrl exclusivity that the schema already states, adding no meaning beyond it.

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

Purpose4/5

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

States a specific verb (Execute) and resource (a JavaScript file) plus the distinguishing mode ('in the background') and the immediate-return behavior. It does not, however, contrast itself with the sibling run_script, so an agent must infer the foreground/background split on its own.

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

Usage Guidelines3/5

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

The description gives one hard usage rule ('Must provide either scriptPath OR scriptUrl (not both)'), which is genuinely helpful for invocation. It offers no guidance on when a background run is preferable to run_script or when to pass a sessionId, leaving the primary use-case decision to inference.

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