Firecrawl MCP Server

Overview Schema Source Related Servers Discussions Admin

List Firecrawl monitor checks

firecrawl_monitor_checks

Read-only

Retrieve historical checks for a monitor, filter them by status, and page through results with limit and offset to review past run outcomes.

Instructions

List historical checks for a monitor, optionally filtered by status and bounded by a result limit. Returns one page of check summaries and pagination metadata.

Input Schema

Name	Required	Description	Default
`id`	Yes
`limit`	No
`offset`	No
`status`	No

Output Schema

Name	Required	Description
`data`	No	One page of check summaries.
`error`	No	Error message or error object when the call did not succeed.
`success`	No	Whether the API call succeeded.
`pagination`	No	Pagination metadata for the listing.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv1.0.2Oct 29, 2026

changedInput schema / $schema

Previous value: -"https://json-schema.org/draft/2020-12/schema"New value: +"http://json-schema.org/draft-07/schema#"

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "description": "One page of historical checks for the monitor.",
+  "properties": {
+    "data": {
+      "description": "One page of check summaries."
+    },
+    "error": {
+      "description": "Error message or error object when the call did not succeed."
+    },
+    "pagination": {
+      "description": "Pagination metadata for the listing."
+    },
+    "success": {
+      "anyOf": [
+        {
+          "type": "boolean"
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "description": "Whether the API call succeeded."
+    }
+  },
+  "type": "object"
+}

First observedv1.0.1Jul 5, 2026

TDQS

B3.3/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds that results are "one page of check summaries and pagination metadata," which is genuinely useful for a paged list, but it does not explain how paging is advanced or what the summaries contain.

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

Conciseness5/5

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

Two short sentences, front-loaded with what is listed and followed immediately by what is returned. No filler or redundant restatement of the title.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return-shape detail is rightly omitted. But for a four-parameter paged list with 0% schema coverage, the missing treatment of `offset` and the required monitor `id` leaves the definition thin for correct invocation.

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

Parameters2/5

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

Schema description coverage is 0%, so the description must carry the load, yet it only gestures at two of four parameters (status, limit). The required `id` and the `offset` paging parameter are never mentioned, leaving the paging contract ambiguous.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Specific verb+resource ("List historical checks for a monitor") with scope qualifiers (status filter, result limit). It does not, however, name the near-identical sibling firecrawl_monitor_check (singular) or firecrawl_monitor_list, so an agent must infer the boundary itself.

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

Usage Guidelines3/5

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

"Optionally filtered by status and bounded by a result limit" implies the conditions under which filters are used, but there is no explicit when-to-use, when-not-to-use, or routing to alternatives such as firecrawl_monitor_check for a single check.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.