Firecrawl MCP Server

Firecrawl interact

firecrawl_interact

Open or reuse a live browser session to navigate pages, click controls, fill fields, or run Bash, Python, or Node code, returning execution output and session URLs.

Instructions

Open or reuse a live browser session to navigate a page, click controls, fill fields, or run browser code. Provide either url or scrapeId, and either a natural-language prompt or executable code; code can run as Bash, Python, or Node with a bounded timeout.

This acts on the live site, so actions such as form submission can create persistent external side effects. Returns execution output, stdout/stderr, exit status, and session viewing URLs.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "firecrawl_interact"
  }
}

Input Schema

Name	Required	Description	Default
`url`	No
`code`	No
`prompt`	No
`timeout`	No
`language`	No
`scrapeId`	No
`scrapeOptions`	No

Output Schema

Name	Required	Description
`url`	No	The URL the session was opened from, when opening failed.
`data`	No	Payload returned by the interaction.
`error`	No	Why the interaction or the session could not run.
`output`	No	Execution output.
`result`	No	Interaction result, when it is not an object of its own.
`stderr`	No	Standard error of the executed code.
`stdout`	No	Standard output of the executed code.
`liveUrl`	No	URL for viewing the live session.
`success`	No	Whether the API call succeeded.
`exitCode`	No	Exit status of the executed code.
`scrapeId`	No	Session identifier; pass it to reuse the session or to `firecrawl_interact_stop`.
`sessionUrl`	No	URL for viewing the live session.
`agent_hints`	No	Optional response guidance from the Firecrawl API.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv3.28.2Nov 4, 2026

TDQS

A3.8/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=false and openWorldHint=true, but the description adds genuinely new behavioral context: that actions occur against the live site and that form submissions can produce persistent external side effects. It also discloses the return payload shape (stdout/stderr, exit status, session viewing URLs), which the agent would otherwise not know. The 'bounded' timeout is mentioned but not defined here.

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?

Three sentences, front-loaded with the core action, followed by input contract, then risk disclosure and return shape. Every sentence adds information an agent needs and none restates the tool title.

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 tool with 7 top-level parameters, deep nested objects, and an output schema, the description covers the key selection rules, the side-effect risk, and the return surface. The notable remaining gap is the large scrapeOptions object, whose semantics are entirely undocumented in both schema and prose.

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 0%, so the description must carry the load; it does explain the url-vs-scrapeId and prompt-vs-code alternatives and notes the three code languages and bounded timeout. It says nothing about scrapeOptions, the single largest and most complex parameter group (actions, formats, proxy, profile, etc.), leaving the agent to infer behavior from bare nested JSON.

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?

The description states a specific verb set (open/reuse a session, navigate, click, fill, run code) against a concrete resource: a live browser session. It clearly differs from firecrawl_scrape by emphasizing an interactive, stateful session, though it never names the closest siblings (firecrawl_scrape, firecrawl_interact_stop) explicitly.

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?

Usage is implied through the action list — interact when you need to click, type, or execute code on a page rather than just fetch content — and the mutual-exclusion rule for url/scrapeId and prompt/code is stated. However, there is no explicit 'use this instead of firecrawl_scrape when…' guidance and no mention of when to stop the session via firecrawl_interact_stop.

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