Skip to main content
Glama
firecrawl

firecrawl-mcp-server

firecrawl_monitor_check

Read-only

Retrieve a single monitor check with page-level diff results. Filter by page status to surface only changed, new, or removed pages.

Instructions

Get a single check with page-level diff results. Filter pageStatus to surface only the pages that changed (or were new, removed, etc.).

Each entry in data.pages[] has url, status (same | new | changed | removed | error), optional judgment when goal-based judging ran, and — when changed — a diff and possibly a snapshot. The shape of diff depends on the monitor's formats configuration:

  • Markdown mode (default). diff.text is the unified markdown diff; diff.json is a parse-diff AST ({ files: [...] }). No snapshot.

  • JSON mode (changeTracking with modes: ["json"]). diff.json is a per-field map keyed by JSON path into the extraction, e.g. plans[0].price, with each value being { previous, current }. snapshot.json is the full current extraction. No diff.text.

  • Mixed mode (modes: ["json", "git-diff"]). Both diff.text (markdown sidecar) AND diff.json (per-field map) are present, plus snapshot.json.

Example JSON-mode response pages[] entry:

{
  "url": "https://example.com/pricing",
  "status": "changed",
  "diff": {
    "json": {
      "plans[0].price":       { "previous": "$19/mo",        "current": "$24/mo" },
      "plans[1].features[2]": { "previous": "10 GB storage", "current": "25 GB storage" }
    }
  },
  "snapshot": { "json": { "plans": [/* current full extraction matching the monitor's schema */] } },
  "judgment": {
    "meaningful": true,
    "confidence": "high",
    "reason": "The pricing changed, which matches the monitor goal.",
    "meaningfulChanges": [
      {
        "type": "changed",
        "before": "$19/mo",
        "after": "$24/mo",
        "reason": "The tracked plan price changed."
      }
    ]
  }
}

When summarizing a check for the user, prefer diff.json paths (e.g. "plans[0].price changed from $19/mo to $24/mo") over re-printing the markdown diff — it's more concise and grounded in the schema fields they asked for.

When judgment is present, use it to decide what to surface. judgment.meaningful: false means the change was classified as noise for the monitor's goal. When judgment.meaningfulChanges is present, prefer those goal-relevant changes over raw diff hunks; each item includes type, before, after, and reason.

The endpoint paginates via a top-level next URL; this tool returns one page at a time. Increase limit (max 100) to fetch fewer pages.

Usage Example:

{
  "name": "firecrawl_monitor_check",
  "arguments": {
    "id": "mon_abc123",
    "checkId": "chk_xyz",
    "pageStatus": "changed"
  }
}

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYes
skipNo
limitNo
checkIdYes
pageStatusNo
Behavior5/5

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

Annotations indicate readOnlyHint=true; the description adds extensive behavioral detail: different diff modes (Markdown, JSON, Mixed), pagination via `next` URL, judgment structure with meaningful flags, and snapshot formats. No contradiction with annotations.

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

Conciseness4/5

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

The description is lengthy but well-structured with sections for different diff modes, a JSON example, and a usage example. It front-loads the purpose. Every sentence adds value, though some detail could be trimmed (e.g., repeated JSON examples).

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?

Given no output schema, the description thoroughly covers response structure, pagination, judgment, and diff variations. It anticipates common use cases (filtering, summarizing changes) and explains edge cases like 'meaningful: false'. Complete for this tool's complexity.

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 coverage is 0%, but the description adds meaning for pageStatus and limit (explaining their use). However, id, checkId, and skip are not described beyond their names. The description partially compensates but leaves gaps.

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?

The description starts with a specific verb+resource: 'Get a single check with page-level diff results.' It clearly identifies the tool's function and distinguishes it from siblings like firecrawl_monitor_checks (list checks) and firecrawl_monitor_get (get monitor config).

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

Usage Guidelines4/5

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

The description provides explicit usage guidance: how to filter by pageStatus, preference for diff.json over markdown, how to use judgment, and pagination hints (increase limit, next URL). It includes a usage example. However, it does not explicitly state when not to use this tool or list alternative tools.

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

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/firecrawl/firecrawl-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server