Skip to main content
Glama
leetomo2528

firefox-use

by leetomo2528
OverviewSchemaSourceRelated ServersScoreDiscussionsAdmin
JavaScript
Local

javascript_tool

Execute JavaScript in a live Firefox tab and return the last expression's value. Runs in the page's context, supports top-level await, and reports thrown errors with details.

Instructions

Evaluate JavaScript inside a page and hand back what its final expression produced. All three fields are required: action pinned to javascript_exec, text carrying the source, and tabId naming the page. The snippet runs in the page's own world, so the document, window, and whatever globals the site defined are all within reach, and anything it changes is really changed. It behaves like a console rather than a function body: top-level await is allowed, and the value of the last expression comes back by itself, so finish with the expression instead of a return statement. Results are stringified (objects as indented JSON) and cut off at 10000 characters, with a line saying how long the full text was. A throw from the page fails the call with its message and the frame that raised it. Two things script cannot do here: fill a file input, which needs file_upload or upload_image, and get past its own alert or confirm - that parks the page until firefox_dialog answers it, which in Firefox is recoverable rather than the end of the session.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
textYesThe source to evaluate. Console semantics: top-level await works, and the last expression is the result, so write `document.title` or `await fetch('/api/status').then(r => r.json())` and skip the return; statements ahead of it run normally. It executes in the page context, with the DOM, window and page globals available and its writes sticking to the live document. Anything past 10000 characters of output is trimmed.
tabIdYesThe page to run in; required, never guessed. Use an id tabs_context_mcp listed for this session - a tab outside the group, or one already closed, is refused.
actionYesFixed string: send javascript_exec, spelled exactly that way. Any other value is turned away before the page is touched.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

A5/5.0
Behavior5/5

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

No annotations provided, so the description carries full burden. It thoroughly discloses execution context (page's own world), side effects (writes stick to live document), output trimming at 10000 characters, error behavior (throw fails the call), and limitations (file input, alert/confirm). This is exceptionally transparent.

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

Conciseness5/5

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

Every sentence contributes unique information: purpose, parameter details, execution semantics, output handling, error behavior, and limitations. It is front-loaded with the primary purpose and avoids redundancy, despite being detailed.

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

Completeness5/5

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

Fully complete for the tool's complexity: explains output format and truncation, error propagation, execution context, side effects, parameter requirements, and alternatives. No output schema exists, but the description covers return behavior adequately, leaving no critical gaps for an agent to invoke correctly.

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

Parameters5/5

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

Schema descriptions already thoroughly cover each parameter (console semantics, tabId source, fixed action value), and the tool description adds extra meaning beyond schema—notably the explicit limitations and alternatives. Given 100% schema coverage, the description still enriches understanding, warranting above baseline.

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 precisely: evaluates JavaScript in a page and returns the final expression's value. The verb 'evaluate' and resource 'JavaScript inside a page' are specific, and it clearly distinguishes from sibling tools like navigate, read_page, and form_input.

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

Usage Guidelines5/5

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

Explicitly explains when to use it (console semantics, top-level await, page context) and when not to (cannot fill file inputs or handle alerts, pointing to file_upload/upload_image and firefox_dialog as alternatives). Also directs the agent to obtain tabId from tabs_context_mcp, covering prerequisites.

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

Install Server

Other Tools