v0.2.0 · live
CAPFRAME
← leaderboard/Firecrawl MCP/tool · firecrawl_monitor_create
§ toolsandboxFirecrawl MCP

firecrawl_monitor_create

on npm:firecrawl-mcp@3.20.2

Severity

critical0
high1
medium3
low0
info0

4 findings on this tool

  1. highexcessive agencyf-r3-firecrawl_monitor_create

    Tool `firecrawl_monitor_create` name implies a side effect that is not declared

    `firecrawl_monitor_create` looks like a side-effecting tool (its name contains a mutation verb), but its `side_effects` declaration is []. A policy synthesizer cannot produce safe rules for this tool because it cannot tell what it actually does.

    fix: Declare the tool's true side effects explicitly. If the tool is genuinely read-only, rename it to match (e.g. `email.preview` rather than `email.send`).

    OWASP LLM08NIST MEASURE-2.6ATLAS T0051
  2. mediumunconstrained inputf-r1-firecrawl_monitor_create

    Tool `firecrawl_monitor_create` accepts unconstrained string input

    The following string parameter(s) have no `maxLength` constraint: `email`, `goal`, `name`, `page`, `scheduleText`, `timezone`, `webhookUrl`. Unbounded strings let an attacker stuff arbitrary payloads through the tool, including indirect-injection content.

    fix: Add a `maxLength` to each string property, or constrain with an `enum` or `pattern`. Most legitimate tool inputs fit under a few hundred bytes.

    OWASP LLM01NIST MEASURE-2.3ATLAS T0051
  3. mediumexcessive agencyf-r5-firecrawl_monitor_create

    Tool `firecrawl_monitor_create` description mentions money but no `money` side-effect is declared

    Description: " Create a Firecrawl monitor — a recurring scrape or crawl that diffs each result against the last retained snapshot. Prefer the simple path: pass `page` or `pages` plus `goal`. The tool will create a scrape monitor with a 30-minute schedule and meaningful-change judging enabled by the API. Use `body` only for advanced requests such as crawl targets, JSON change tracking, custom retention, or manual `judgeEnabled` control. Meaningful-change judge: set `goal` to a plain-language description of what the user actually cares about. `judgeEnabled` defaults to true when `goal` is set, so providing `goal` is enough. Page webhooks expose `isMeaningful` and `judgment` on `monitor.page` events. Simple fields: - `page`: one page URL to monitor. - `pages`: multiple page URLs to monitor. - `goal`: plain-English instruction for what changes matter. Required for the simple path. - `scheduleText`: optional natural-language schedule, default `every 30 minutes`. - `email`: optional email recipient for summaries. - `webhookUrl`: optional webhook URL. Configures `monitor.page` and `monitor.check.completed`. Goal guidance: - Expand the user's one-line monitoring intent into a concise 2-3 sentence monitor goal. - State what should trigger an alert, restate any scope the user gave, and include intent-specific exclusions only when obvious from the user's request. - Generic noise such as whitespace, formatting-only changes, request IDs, tracking params, generic metadata, and unrelated page chrome is already handled by the judge; do not repeat it in every goal. - If the user is vague, keep the goal broad rather than guessing exclusions. If the user asks for broad monitoring or "any change", preserve that and do not add exclusions that hide changes. - If the user says they do not care about something, include that explicitly. It is okay to ask whether they want to ignore specific noise when it is likely to matter. - Do not invent page-specific sections, thresholds, entities, or business rules unless the user mentioned them. Full `body` requests require: `name`, `schedule` (with `cron` or `text`), and `targets` (one or more `{ type: 'scrape', urls: [...] }` or `{ type: 'crawl', url: '...' }`). Optional: `goal`, `judgeEnabled`, `webhook`, `notification`, `retentionDays`. **Markdown-mode (default):** Each check produces a unified text diff of the page's markdown. No extra configuration needed. ```json { "name": "firecrawl_monitor_create", "arguments": { "page": "https://example.com/blog", "goal": "Alert when a new blog post is published or an existing headline changes.", "email": "alerts@example.com" } } ``` **Multiple pages:** ```json { "name": "firecrawl_monitor_create", "arguments": { "pages": ["https://example.com/pricing", "https://example.com/changelog"], "goal": "Alert when pricing, packaging, or launch messaging changes.", "webhookUrl": "https://example.com/webhooks/firecrawl" } } ``` **JSON-mode change tracking:** To detect changes in **specific structured fields** (price, headline, in-stock flag, list items) instead of the whole page, add a `changeTracking` format with `modes: ["json"]` and a JSON schema to the target's `scrapeOptions.formats`. The check response will then carry a per-field diff (keyed by JSON path, e.g. `plans[0].price`) and a `snapshot.json` with the full current extraction. See `firecrawl_monitor_check` for the response shape. ```json { "name": "firecrawl_monitor_create", "arguments": { "body": { "name": "Pricing watch", "schedule": { "text": "hourly", "timezone": "UTC" }, "goal": "Alert when a pricing tier, price, billing period, limit, or headline feature changes. Ignore unrelated marketing copy unless it changes the pricing offer.", "targets": [{ "type": "scrape", "urls": ["https://example.com/pricing"], "scrapeOptions": { "formats": [{ "type": "changeTracking", "modes": ["json"], "prompt": "Extract pricing tiers and headline features for each plan.", "schema": { "type": "object", "properties": { "plans": { "type": "array", "items": { "type": "object", "properties": { "name": { "type": "string" }, "price": { "type": "string" }, "features": { "type": "array", "items": { "type": "string" } } } } } } } }] } }] } } } ``` **Mixed mode (JSON + git-diff):** Use `modes: ["json", "git-diff"]` to get both per-field diffs and a markdown sidecar. The page is marked `changed` whenever either surface changed. " -- this references money/payment/refund/etc., but the declared side_effects ([]) don't include `money`. A capframe-bind policy that relies on declared side_effects to scope spend caveats will under-scope this tool.

    fix: Add `money` to the tool's `side_effects` declaration, or rewrite the description to clarify that no actual money moves.

    OWASP LLM08NIST MEASURE-2.6ATLAS T0040
  4. mediumindirect injectionf-r6-firecrawl_monitor_create

    Tool `firecrawl_monitor_create` fetches external web content -- indirect-injection surface

    Description: " Create a Firecrawl monitor — a recurring scrape or crawl that diffs each result against the last retained snapshot. Prefer the simple path: pass `page` or `pages` plus `goal`. The tool will create a scrape monitor with a 30-minute schedule and meaningful-change judging enabled by the API. Use `body` only for advanced requests such as crawl targets, JSON change tracking, custom retention, or manual `judgeEnabled` control. Meaningful-change judge: set `goal` to a plain-language description of what the user actually cares about. `judgeEnabled` defaults to true when `goal` is set, so providing `goal` is enough. Page webhooks expose `isMeaningful` and `judgment` on `monitor.page` events. Simple fields: - `page`: one page URL to monitor. - `pages`: multiple page URLs to monitor. - `goal`: plain-English instruction for what changes matter. Required for the simple path. - `scheduleText`: optional natural-language schedule, default `every 30 minutes`. - `email`: optional email recipient for summaries. - `webhookUrl`: optional webhook URL. Configures `monitor.page` and `monitor.check.completed`. Goal guidance: - Expand the user's one-line monitoring intent into a concise 2-3 sentence monitor goal. - State what should trigger an alert, restate any scope the user gave, and include intent-specific exclusions only when obvious from the user's request. - Generic noise such as whitespace, formatting-only changes, request IDs, tracking params, generic metadata, and unrelated page chrome is already handled by the judge; do not repeat it in every goal. - If the user is vague, keep the goal broad rather than guessing exclusions. If the user asks for broad monitoring or "any change", preserve that and do not add exclusions that hide changes. - If the user says they do not care about something, include that explicitly. It is okay to ask whether they want to ignore specific noise when it is likely to matter. - Do not invent page-specific sections, thresholds, entities, or business rules unless the user mentioned them. Full `body` requests require: `name`, `schedule` (with `cron` or `text`), and `targets` (one or more `{ type: 'scrape', urls: [...] }` or `{ type: 'crawl', url: '...' }`). Optional: `goal`, `judgeEnabled`, `webhook`, `notification`, `retentionDays`. **Markdown-mode (default):** Each check produces a unified text diff of the page's markdown. No extra configuration needed. ```json { "name": "firecrawl_monitor_create", "arguments": { "page": "https://example.com/blog", "goal": "Alert when a new blog post is published or an existing headline changes.", "email": "alerts@example.com" } } ``` **Multiple pages:** ```json { "name": "firecrawl_monitor_create", "arguments": { "pages": ["https://example.com/pricing", "https://example.com/changelog"], "goal": "Alert when pricing, packaging, or launch messaging changes.", "webhookUrl": "https://example.com/webhooks/firecrawl" } } ``` **JSON-mode change tracking:** To detect changes in **specific structured fields** (price, headline, in-stock flag, list items) instead of the whole page, add a `changeTracking` format with `modes: ["json"]` and a JSON schema to the target's `scrapeOptions.formats`. The check response will then carry a per-field diff (keyed by JSON path, e.g. `plans[0].price`) and a `snapshot.json` with the full current extraction. See `firecrawl_monitor_check` for the response shape. ```json { "name": "firecrawl_monitor_create", "arguments": { "body": { "name": "Pricing watch", "schedule": { "text": "hourly", "timezone": "UTC" }, "goal": "Alert when a pricing tier, price, billing period, limit, or headline feature changes. Ignore unrelated marketing copy unless it changes the pricing offer.", "targets": [{ "type": "scrape", "urls": ["https://example.com/pricing"], "scrapeOptions": { "formats": [{ "type": "changeTracking", "modes": ["json"], "prompt": "Extract pricing tiers and headline features for each plan.", "schema": { "type": "object", "properties": { "plans": { "type": "array", "items": { "type": "object", "properties": { "name": { "type": "string" }, "price": { "type": "string" }, "features": { "type": "array", "items": { "type": "string" } } } } } } } }] } }] } } } ``` **Mixed mode (JSON + git-diff):** Use `modes: ["json", "git-diff"]` to get both per-field diffs and a markdown sidecar. The page is marked `changed` whenever either surface changed. " -- this tool pulls externally-controlled content into the agent's context window, the canonical indirect-injection vector. Even when the user supplies the URL, content at that URL can carry hostile instructions.

    fix: Sandbox the fetched content: strip prompts before forwarding to the model, constrain to an allow-list of domains, and route through capframe-guard with a `domain in [...]` caveat.

    OWASP LLM01NIST MEASURE-2.3ATLAS T0051

About this tool

firecrawl_monitor_create is one of 20 tools exposed by Firecrawl MCP. The server scored 0/100 overall against the capframe rule engine (source: sandbox). Last scanned 2026-06-05.

The findings above are emitted by the public capframe.findings.v1 schema. Disagree with one? Open an issue.