Skip to main content
Glama
AdvaitR7

Firecrawl MCP Multiple Keys

by AdvaitR7
OverviewSchemaRelated ServersScoreDiscussions
JavaScript
Hybrid

firecrawl_monitor_check

Read-only

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

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

Tool Definition Quality

A4.7/5.0
Behavior5/5

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

Annotations already state readOnlyHint=true and destructiveHint=false. Description adds extensive behavioral details: pagination via next URL, limit max 100, response shape for different formats, and when judgment is present. No contradictions.

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?

Description is long but well-structured with subheadings and a usage example. Front-loaded with purpose. Slightly verbose but earns its length through detail.

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?

No output schema exists, so description fully explains return values with rich examples for markdown, JSON, and mixed modes. Covers pagination, filter, and judgment. Complete for a single check retrieval tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema has 0% description coverage, so description carries full burden. It explains pageStatus enum values, limit's role in pagination, and implies id/checkId as identifiers. 'skip' is not explained but compensated by pagination guidance.

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?

Description opens with 'Get a single check with page-level diff results,' clearly stating the verb and resource. It distinguishes from siblings like firecrawl_monitor_checks (which lists checks) by specifying depth and diff details.

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?

Provides explicit filter guidance ('Filter pageStatus to surface only pages that changed'), example usage, and pagination advice. Does not explicitly contrast with all alternatives but context implies single vs list difference.

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/AdvaitR7/firecrawl-mcp-multiple-keys'

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