What happened
Eve has published a Firecrawl integration in its connection registry. The documented installation command is eve add connection/firecrawl. According to the integration page, that command writes an initial connection definition under agent/connections/ and installs an authentication dependency when one is needed. The next step is a file named agent/connections/firecrawl.ts; in Eve, the filename establishes the Firecrawl connection.
The connection is an MCP client configuration. Its example points to https://mcp.firecrawl.dev/v2/mcp and describes Firecrawl’s available surface as search, scrape, map, crawl, parse, and monitor web content. This is not presented as a new Firecrawl API or a new Eve runtime. It is a packaged path for exposing an existing web-data service to an Eve agent through the framework’s connection model.
The example is deliberately conservative about authorization. It imports Eve’s always approval helper and sets approval: always(), meaning every Firecrawl call requires approval. Eve explains the reason directly: Firecrawl calls can consume usage or create persistent work. The documentation also says that users should keep approval enabled, or apply tool filters and approval rules that prevent unattended cost-sensitive or persistent actions.
Credentials are configured through the server-side FIRECRAWL_API_KEY environment variable. The page says Eve sends that key directly to Firecrawl and does not expose it to the model. An API key enables Firecrawl’s full tool surface, subject to the customer’s Firecrawl plan and team policy. The source does not state a new price, a free allowance, or any changed Firecrawl limit; access remains governed by the applicable plan and policy.
For an Eve project, the practical change is therefore small but concrete: a developer can add a prebuilt, named web-capability connection rather than hand-writing the initial MCP configuration. The supplied definition also establishes a default operating posture—server-held credentials and per-call approval—before a team decides which Firecrawl actions, if any, can run without a person in the loop.
What the archive adds
This is a new fact in the known Eve story, not a restatement. Our earlier note on agent domain purchases through Vercel CLI focused on making human approval part of an agent-facing workflow. The Firecrawl connection applies a similar boundary to web-data actions that may incur usage or create persistent work.
Trend signal
This supports Harness architecture outlives model choice. The material value here is not a model claim: it is the harness layer that names a connection, carries server-side credentials, invokes an MCP endpoint, and enforces approval. That packaging can remain useful even as the model inside an Eve agent changes.
Why it matters
Web access is often where an agent stops being a demonstration and becomes an operational system: it needs to find pages, extract structured material, crawl a site, or monitor a changing source. But those actions bring two ordinary production concerns with them—spend and persistence. A connection that treats both as authorization concerns gives a team a clearer starting point than attaching an unrestricted scraping tool to a prompt.
For builders, the notable design choice is that access control sits alongside the connection definition. The API key remains on the server, while approvals, tool filters, and rules can determine what the agent may actually do. This separates the question “can the model ask for web work?” from “may this particular operation run now?” That separation is useful when prototypes turn into shared systems with budgets, policies, and reviewers.
Limits and uncertainty
The source is integration documentation, not a benchmark or a reliability report. It does not establish the quality, latency, coverage, or extraction accuracy of Firecrawl’s tools when invoked from Eve. It also does not specify which Firecrawl plans, quotas, or team policies apply in a particular deployment, nor does it enumerate the exact behavior of every tool filter or approval rule. The example uses approval for every call, but the documentation does not show a production policy for a specific workload. Teams still need to decide which actions are safe to automate and test the resulting controls.
Skill to build now
Create a minimal agent connection with eve add connection/firecrawl, store FIRECRAWL_API_KEY only in a server-side environment variable, and keep per-call approval enabled for the first workflow. Then list the few web operations your agent actually needs—such as search and page parsing—and define a review path for each one. Treat crawling, monitoring, or any operation that can create ongoing work as a separate policy decision rather than as a default capability.
Reader takeaway
Eve’s Firecrawl connection makes web data available to an Eve agent through a prebuilt MCP configuration, but its more durable lesson is the default boundary: credentials stay server-side and actions that can spend money or persist work require approval. Build the permission model with the connection, not after deployment.
Open question
Will teams retain per-call approval as they scale web-enabled agents, or replace it with sufficiently narrow filters and policy rules for specific recurring tasks?