How to connect Firecrawl to Hermes Agent

Pairing is a two-step handshake: run hermes clawlink begin, approve the link in your browser, then run hermes clawlink finish. If you ran finish before approving, or the approval link expired, run hermes clawlink begin again to get a fresh link. Confirm the plugin was installed with --enable, then verify with hermes clawlink test.

Reconnect Firecrawl from the dashboard, then start a fresh chat if the runtime still has the old tool catalog loaded.

Firecrawl tool schemas load on demand the first time a tool runs and are cached after that, so this error usually clears on its own: wait a few seconds and retry the same request. If every Firecrawl call keeps failing with it in a fresh chat, reconnect from the dashboard, and contact support if it still persists — that pattern points to a configuration problem on our side, not something you can fix by reconnecting again.

Two usual causes. The connected account may not have access to the specific workspace, inbox, store, or project in the request — check that first. If access looks right, the agent may have sent a placeholder value (like "YOUR_ID" or an example id from documentation) instead of a real one: ask it to run a list or search tool first, then retry the action with a real id from those results. Most failures at this stage are one of these two, not ClawLink bugs.

Search results teach three causes for this provider, and they are all real against a hosted connection. The first is the key itself: Firecrawl expects it as a Bearer token, and a key that is invalid, missing, or regenerated after setup fails everything from that moment, so re-paste the current key from the dashboard. The second is the account's credit or plan state: out of monthly credits, or a request that needs an endpoint the current plan does not include, both surface as a permissions-shaped error. The third is the target site: Firecrawl being blocked by the site it is trying to scrape reads as a 403 from the outside. The hosted-flow causes remain on top of those: a placeholder argument such as YOUR_ID reaching the API literally, and a stale connected account. The agent should quote the full error and which URL it was scraping before you change anything.

Ask the agent to diagnose it:

Run firecrawl_credit_usage_get and tell me the team credit state, then quote the exact error from the failed call including which URL was involved. Do not retry it yet.

Firecrawl rate-limits its API and the limit interacts with the account's credit tier, and an agent that crawls aggressively is exactly the traffic shape that meets it. Keyless connections hit the capped tier fastest, which is the practical limit of the no-key route. The response is to change the shape of the work: one crawl job with clear filtering instead of many scrape calls, firecrawl_batch_scrape instead of a loop of single scrapes, and a check of firecrawl_credit_usage_get before a large job. Waiting a few minutes and retrying the same shape usually produces the same result.

Ask the agent to diagnose it:

Tell me how many Firecrawl calls you made in the last few minutes and what the crawl pattern was. Quote the exact error text. Do not call Firecrawl again until I reply.

Two failures share this symptom. If no Firecrawl tools appear at all, the connection or pairing is incomplete: confirm the plugin was installed with --enable, that hermes clawlink begin and hermes clawlink finish both ran, and that Firecrawl shows as connected in the dashboard. If most tools work and one name fails, the name is wrong rather than missing, and the error lists the closest real ones. There is also a first-call timing case: schemas load on demand, so the opening Firecrawl call in a fresh session can arrive before the catalog and needs one retry. The frame search results teach for this symptom, an MCP init failure in a client's mcpServers JSON, does not apply to a hosted setup with no local server.

Ask the agent to diagnose it:

List the Firecrawl tools you actually have access to. If there are none, say so plainly and tell me whether Firecrawl shows as connected. Do not guess tool names.

Double-check that the API key for Firecrawl has the right scopes or account access. A valid key can still be too limited for some reads or writes.

Yes. ClawLink is the fastest way to connect Hermes to Firecrawl: link your Firecrawl account once in the browser and Hermes Agent can call the Firecrawl API through 29 ready-made tools — no custom code or token handling.

Install the plugin with hermes plugins install ClawLink-HQ/hermes-plugin --enable, then pair once: run hermes clawlink begin, approve the link in your browser, and run hermes clawlink finish. Connect Firecrawl in the dashboard and Hermes can use it from the next message — no config files, and the Firecrawl key you paste is stored server-side instead of in your environment.

About two minutes. Sign in, click Connect next to Firecrawl in the dashboard, authenticate, and Hermes Agent can use it from the next chat message.

The alternative to ClawLink is usually manual API key setup plus your own token handling, permission troubleshooting, and tool plumbing for Hermes Agent. That is fine if you want to build and maintain the integration yourself. Most teams just want Firecrawl working from chat.

Keyless is Firecrawl's no-key mode: 1,000 free credits a month, agents self-onboard, no key to copy. It is a real option and Google now teaches it as the answer to the no-key query. The tradeoffs are the tier itself: the credit grant is monthly, the mode is rate-limited, and advanced features are gated behind the paid product, which is why the free tier is not the shape for a standing agent that scrapes daily. A pasted key through ClawLink runs on your own Firecrawl balance and plan, so the monthly grant is not the ceiling, and the key is stored server-side rather than sitting in an environment file on a machine. Start with Keyless if the volume is light; connect the key when the agent outgrows it.

A Firecrawl API key from your Firecrawl dashboard, pasted once on the hosted setup page and held server-side. It is the same key you would put in ~/.hermes/.env in the env-file route; the difference is where it lives afterwards. Because it is server-side, rotating it in Firecrawl means updating one place, and disconnecting from the dashboard revokes the agent's use of it immediately.

Yes, which is the useful part for this provider. firecrawl_credit_usage_get and firecrawl_credit_usage_get_historical read the team's credit usage, and firecrawl_token_usage_get reads the token balance for the Extract feature, so the agent can report its own budget instead of guessing. That is worth putting in a prompt before any large crawl.

Scrape single pages and batches, crawl sites with filtering, extract structured data with a schema, search the web and scrape the top results, map a site's URLs, generate llms.txt files, and run agentic extraction jobs with status tracking. The crawl and batch tools are the power surface and the credit surface at once: firecrawl_crawl and firecrawl_batch_scrape are where a big job spends credits, so the credit-check tools above are the right preamble.

Pairing is a two-step handshake: run hermes clawlink begin, approve the link in your browser, then run hermes clawlink finish. If you ran finish before approving, or the approval link expired, run hermes clawlink begin again to get a fresh link. Confirm the plugin was installed with --enable, then verify with hermes clawlink test.