firecrawl-mcp

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

The description thoroughly explains the async nature, polling workflow, expected wait times, and return value (job ID). Annotations (openWorldHint: true) are consistent with web research behavior. 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.

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

The description is lengthy but well-structured with sections, bold formatting, and examples. It is front-loaded with key information and every sentence serves a purpose. Slightly verbose but appropriate for the complexity.

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

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

Given the complexity of an async research agent with 3 parameters (one required), the description covers the workflow, polling strategy, expected times, and usage examples. No output schema is needed because the return is a job ID, which is clearly stated.

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

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

Schema description coverage is 0%, but the description compensates by explaining all parameters (prompt, urls, schema) with examples and usage details. It adds significant value beyond the bare schema structure.

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

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

The description clearly identifies the tool as an 'autonomous web research agent' that independently browses and extracts data. It distinguishes from siblings like firecrawl_scrape and firecrawl_search by detailing appropriate use cases and providing explicit alternatives.

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

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

The description offers explicit when-to-use and when-not-to-use guidance, including a 'Best for' and 'Not recommended for' list. It names alternative tools (firecrawl_scrape, firecrawl_search) and explains the async workflow with polling steps.

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

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

Annotations already declare readOnlyHint=true. Description adds polling behavior, statuses, and retrieval details, providing good transparency beyond annotations.

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

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

Well-structured with clear sections: purpose, important notes, usage example, status list. No unnecessary information, front-loaded purpose.

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

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

Covers essential usage details for a simple polling tool. Missing result structure but acceptable given no output schema and the description mentioning 'results'.

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

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

Schema coverage is 0%, description gives an example but does not explicitly document the 'id' parameter meaning. While the example helps, it cannot fully compensate for the lack of formal parameter description.

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

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

The description clearly states the tool checks agent job status and retrieves results. It uses specific verbs and resource, and distinguishes from sibling tools like firecrawl_agent (starts) and firecrawl_check_crawl_status (crawl jobs).

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

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

Explicitly says to use after starting an agent with firecrawl_agent, provides polling intervals and patience advice. Could list alternatives but context is clear.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, indicating a safe read operation. The description adds value by specifying the return: 'Status and progress of the crawl job, including results if available', which goes beyond annotations.

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

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

The description is extremely concise with a single sentence plus a usage example and return note. Every element is purposeful, and the structure is front-loaded for easy comprehension.

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

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

For a simple status-checking tool with one parameter, the description covers the core functionality, usage pattern, and return value. However, it lacks discussion of potential error states or non-existent crawl IDs, which would enhance completeness.

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

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

Schema description coverage is 0%, so the description bears full responsibility for parameter clarity. However, it only gives a usage example with a UUID, without explaining the parameter's origin or constraints (e.g., required format). This adds minimal semantic value.

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

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

The description clearly states 'Check the status of a crawl job', which is a specific verb-resource combination. It effectively distinguishes from sibling tools like firecrawl_crawl (which initiates a crawl) and firecrawl_scrape.

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

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

The description provides no explicit guidance on when to use this tool versus alternatives. It does not mention prerequisites (e.g., needing a crawl ID from firecrawl_crawl) or contextual signals for proper invocation.

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

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

Beyond annotations (readOnlyHint=false, destructiveHint=false), the description adds critical behavioral context: 'Safe Mode: Read-only crawling' for security, warning about large responses and token overflows, and states that it returns an Operation ID for status checking. This fully informs the AI about tool behavior.

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

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

The description is well-structured with sections (Best for, Not recommended, Warning, etc.) and front-loaded with the core action. While it is somewhat lengthy, each section adds value. Minor improvement could be condensing some warnings, but overall it is appropriately sized.

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

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

Given the tool's complexity (15 params, nested objects, no output schema), the description covers main use cases and return type but lacks depth on many parameters and behavior details. It mentions safe mode but not when it applies versus normal mode. The return as operation ID is noted but not the status check endpoint, though it is a sibling. The description is adequate but not fully complete.

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

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

With 0% schema description coverage, the description must explain parameters. It only discusses a few in context (limit, maxDiscoveryDepth) via warnings and a usage example. The remaining 15+ parameters (e.g., delay, excludePaths, scrapeOptions) are not explained, leaving significant gaps for the AI to infer correct parameter usage.

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

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

The description clearly states 'Starts a crawl job on a website and extracts content from all pages.' It uses a specific verb and resource, and distinguishes from siblings like firecrawl_scrape and firecrawl_map+batch_scrape, making it easy for the AI to select the correct tool.

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

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

The description provides explicit guidance on when to use (multiple related pages) and when not to use (single page, token limits, fast results), with alternative tool names. It also includes a 'Common mistakes' section and a prompt example, offering comprehensive usage context.

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

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

Annotations already provide readOnlyHint and openWorldHint. The description adds context about cloud AI vs. self-hosted LLM extraction, but doesn't detail additional behavioral traits like error handling or rate limits. It adds moderate value beyond the annotations.

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

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

The description is well-structured with clear sections, front-loaded purpose, and concise explanations. Every sentence adds value without redundancy.

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

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

Given the tool's complexity (6 parameters, nested objects, no output schema), the description covers purpose, usage guidelines, parameter semantics, and return value. While it omits error handling, the annotations and examples provide sufficient context for correct invocation.

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

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

Schema coverage is 0%, but the description compensates by listing each parameter with a plain-English explanation (urls, prompt, schema, etc.), giving a prompt example, and providing a full usage example. This fully clarifies parameter purpose.

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

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

The description clearly states the tool extracts structured information from web pages using LLM capabilities, differentiating it from siblings like scrape (full content) and search. It provides a specific verb and resource, and includes a 'Best for' section that distinguishes its use case.

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

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

Explicitly states when to use (extracting specific structured data) and when not to (full content, not looking for structured data), with a direct alternative (use scrape). This is high-quality guidance for an agent.

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

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

Annotations indicate readOnlyHint=false (write operation) and destructiveHint=false (non-destructive). Description adds context: it is a feedback submission that may refund credits, and provides the return schema. It also warns against sending large data. This goes beyond annotations, though it doesn't explicitly state it's a mutation. Good but not exhaustive.

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

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

About 200 words, well-structured: purpose, usage preference, parameter list with constraints, and return format. Every sentence adds value; no redundancy. Front-loaded with purpose and key guidelines. Excellent conciseness.

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

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

Given 12 parameters, nested objects, no output schema, and limited annotations, the description covers the core feedback flow well. It explains the main parameters and return object. However, missing descriptions for three optional parameters reduce completeness slightly. Still strong overall.

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

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

Schema coverage is 0%, so description compensates partially. It explains endpoint, jobId, rating, issues, tags, note, url, pageNumbers, and metadata with usage notes and constraints. However, it omits three parameters (missingContent, valuableSources, querySuggestions) which are present in the schema and not trivial. This leaves gaps for an agent.

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

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

Description clearly states it sends structured feedback for a completed Firecrawl v2 job, listing the specific endpoints (scrape, parse, map, or search). It distinguishes from the sibling tool firecrawl_search_feedback by noting that tool is preferred for search-specific feedback. The purpose is immediately clear and well-differentiated.

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

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

Explicit guidance on when to use this tool vs. alternatives: 'For search-result quality specifically, prefer firecrawl_search_feedback when available because it has search-focused guidance.' Also provides constraints like not including large content and using concise notes. This helps the agent choose correctly.

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

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

Annotations provide readOnlyHint=false, destructiveHint=false, openWorldHint=true. Description adds that it reuses sessions via scrapeId, returns output/stdout/stderr/exit code/live views, and explains prompt vs code modes. 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.

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

Well-structured with summary, best-for, targeting methods, arguments list, and examples. Some redundancy (e.g., repeating 'use this OR that') but front-loaded and concise overall.

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

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

For a 7-param tool with nested objects and no output schema, description covers main usage patterns, return types, and targeting strategies. Lacks error handling and exhaustive scrapeOptions details, but sufficient for typical use.

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

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

Schema description coverage is 0%, but description compensates by detailing each parameter's purpose, mutual exclusivity (url vs scrapeId, prompt vs code), defaults (timeout=30, language=node), and giving usage examples. scrapeOptions is mentioned but not fully documented.

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

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

Description clearly states verb 'interact' and resource 'page in a live browser session', with specific actions (click, fill, extract, navigate). Distinguishes from siblings like firecrawl_scrape by focusing on multi-step workflows.

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

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

Explicitly says 'Best for: Multi-step workflows on a single page' and explains two targeting methods with trade-offs. Provides examples but lacks explicit when-not-to-use or alternative tools.

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

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

Annotations indicate destructiveHint=true, and the description adds 'free resources' which provides additional context about the effect beyond the annotation boolean.

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

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

The description is concise, includes a usage example, and is front-loaded with the core purpose. No wasted words.

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

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

For a simple tool with one parameter, no output schema, and given the annotation coverage, the description provides sufficient context (purpose, when to call, example).

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

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

The schema has 0% description coverage for the single parameter 'scrapeId', and the description does not explain its meaning or format beyond the example JSON.

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

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

The description clearly states the verb 'stop' and the resource 'interact session', and distinguishes it from the sibling firecrawl_interact which starts the session.

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

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

Explicitly says 'call this when you are done interacting', providing clear usage context. Could be improved by stating when not to use, but it's adequate.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, but the description adds context about safety (fast, cheap) and return format (Array of URLs). 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.

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

Well-organized with clear sections and examples, but somewhat verbose with repeated emphasis on the map-before-agent workflow. Could be tightened.

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

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

Fairly complete for a mapping tool: covers workflow, return type, and provides usage examples. However, missing parameter details for 4 out of 6 parameters, and no output schema exists.

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

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

With 0% schema description coverage, the description should compensate but only explains 'search' and implicitly 'url'. Other parameters ('limit', 'sitemap', 'includeSubdomains', 'ignoreQueryParameters') are not described, leaving significant gaps.

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

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

The description clearly states the tool maps a website to discover all indexed URLs. It distinguishes from siblings by specifying when to use map vs scrape, crawl, or agent, and provides a specific verb+resource combination.

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

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

Explicitly provides 'Best for' and 'Not recommended for' sections, mentions common mistakes, and outlines a recommended workflow (map then scrape then agent). This gives clear guidance on when and when not to use this tool.

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

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

Annotations declare readOnlyHint=true, promising safe reads. Description adds rich behavioral details: diff format variants (markdown, JSON, mixed), judgment field, pagination, and snapshot behavior. No contradictions; full transparency.

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

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

Description is lengthy but well-structured with sections, bulleted lists, and code examples. Key info is front-loaded. Could be slightly more concise, but the detail is justified given the tool's complexity.

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

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

Given 5 parameters, no output schema, but complex response, the description is very complete: explains response structure, diff formats, judgment, pagination. Minor gaps: skip parameter not described, id/checkId not explicitly defined beyond example.

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

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

Schema has 0% description coverage; description compensates well by explaining pageStatus enum and its filtering purpose, limit meaning (max 100), and providing a usage example for id and checkId. However, it does not explicitly describe skip or the meaning of id/checkId beyond the example.

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

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

Description clearly states 'Get a single check with page-level diff results.' It explicitly identifies the resource (check) and action (get), distinguishing it from siblings like firecrawl_monitor_checks (list checks) and firecrawl_monitor_get (get monitor).

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

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

Description provides context: filter by pageStatus, pagination via next/link, increase limit to reduce pages. Example usage shows typical arguments. However, it does not explicitly contrast with alternatives like firecrawl_monitor_checks, leaving the agent to infer when to use this tool.

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

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

Annotations already provide readOnlyHint: true and destructiveHint: false, so the description need not repeat that. The description adds 'historical checks' context but no additional behavioral traits such as rate limits or pagination behavior. It is adequate given the annotations.

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

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

The description is very short with one sentence and a code block, which is concise and well-structured. However, the brevity sacrifices necessary detail, so it cannot score a 5. The front-loading is good.

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

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

Given the context (4 parameters, 0% schema coverage, no output schema, but annotations present), the description is incomplete. It fails to explain parameters, return format, or pagination behavior (offset). A list tool benefits from such details for correct invocation.

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

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

Schema description coverage is 0%, so the description must compensate but does not. The usage example shows 'id', 'limit', and 'status' but offers no explanation of what each parameter does or how they affect results. 'offset' is not even mentioned. This is insufficient for an agent to use the tool correctly.

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

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

The description clearly states 'List historical checks for a monitor', which is a specific verb-resource pair. The title from annotations confirms 'List monitor checks'. It distinguishes from sibling 'firecrawl_monitor_check' (singular) which likely retrieves a single check.

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

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

The description includes a usage example but does not explicitly state when to use this tool versus alternatives, nor does it provide any exclusions or prerequisites. Usage is implied as a standard list operation.

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

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

Discloses behavioral traits such as 30-minute default schedule, meaningful-change judge enabled by goal, webhook event types, retention days, and diff modes. Annotations are consistent (no contradiction), and the description adds valuable context beyond them.

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

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

Well-structured with sections, code examples, and bullet points. Front-loaded with key summary. Every sentence earns its place, providing thorough guidance without redundancy.

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

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

Given the complexity of 10 parameters, nested objects, and no output schema, the description is complete. It covers simple and advanced flows, goal guidance, diff modes, webhooks, and references the response shape via firecrawl_monitor_check.

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

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

With 0% schema coverage, the description fully compensates by explaining each parameter in detail (page, pages, goal, scheduleText, email, webhookUrl, body, includeDiffs, timezone) with usage examples and constraints, adding significant meaning.

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

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

The description clearly states the tool creates a recurring scrape/crawl monitor that diffs results, and distinguishes between simple and advanced usage paths. It differentiates from sibling tools like firecrawl_monitor_check and firecrawl_monitor_update.

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

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

Explicitly guides users to prefer the simple path with 'page' or 'pages' plus 'goal', and explains when to use 'body' for advanced requests. Provides examples and goal-writing guidance, covering when to use different modes like JSON tracking.

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

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

Annotations already provide destructiveHint=true, and the description adds 'This cannot be undone' and 'stop its schedule', reinforcing permanence and clarifying side effects. No contradiction.

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

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

The description is short with clear purpose, front-loaded, and includes a helpful usage example. Could be slightly more concise without the example, but it's efficient.

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

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

For a delete tool with one parameter, the description covers key behaviors (permanence, schedule stopping). However, it lacks explanation of return values or error conditions, leaving some completeness gaps.

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

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

Schema has no description for the only parameter 'id' (0% coverage). The description includes a usage example with 'mon_abc123' suggesting it's a monitor ID, but does not explicitly define the parameter or its format.

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

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

The description clearly states the action ('permanently delete'), the resource ('monitor'), and emphasizes irreversibility. It distinguishes from sibling tools like create, update, etc.

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

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

The description provides no guidance on when to use this tool versus siblings (e.g., when to delete vs update/stop). No context on prerequisites or alternatives.

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

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

Annotations already indicate readOnlyHint=true and destructiveHint=false. The description adds no additional behavioral context beyond 'Get', which is consistent with annotations but does not provide extra value.

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

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

Extremely concise: two sentences and a code example. No extraneous content.

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

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

For a simple get-by-ID tool with one parameter and no output schema, the description is mostly sufficient. However, the lack of parameter documentation given 0% schema coverage slightly reduces completeness.

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

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

Schema description coverage is 0% - no description for the 'id' parameter in the schema. The tool description only says 'by ID' and the usage example shows 'mon_abc123', but this is minimal. The description does not adequately explain the parameter format or source.

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

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

Description states 'Get a single monitor by ID' which clearly specifies the action (get), resource (monitor), and method (by ID). It is distinct from sibling tools like firecrawl_monitor_list which retrieves all monitors.

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

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

No explicit when-to-use or alternatives provided. The description only includes a usage example but lacks context on when this tool is preferable over other monitor-related tools.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds that the tool lists 'all monitors for the authenticated account', which is consistent but adds only minimal behavioral context beyond the annotations.

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

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

The description is one sentence plus a concise usage example. It is front-loaded with the main purpose and contains no unnecessary words.

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

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

The description omits critical details like return format, pagination behavior, default values, and relationship to sibling tools. Given no output schema and zero parameter descriptions, the agent lacks sufficient information to use the tool effectively.

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

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

Schema description coverage is 0%, so the description should compensate for parameter explanations. However, the description only provides a usage example with limit:20, without explaining the semantics of limit or offset, leaving their purpose unclear.

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

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

The description clearly states the verb 'List' and the resource 'all Firecrawl monitors for the authenticated account', which distinguishes it from sibling tools like create, delete, or get.

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

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

No explicit guidance on when to use this tool vs alternatives (e.g., monitor_get for a single monitor). The usage example shows a typical call but does not explain context for choosing this tool.

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

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

Annotations already declare non-readOnly and non-destructive. Description adds that it is a trigger and returns a queued check, but lacks details on error handling, rate limits, or what happens if monitor is already running.

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

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

Two sentences and a code block are efficient, but the example adds minimal value. Information is front-loaded and no redundant content.

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

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

For a simple trigger tool with one parameter and no output schema, the description covers the core action but omits prerequisites (e.g., monitor existence) and interpretation of the response ('queued check'). Adequate but not thorough.

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

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

The schema has one required string parameter 'id' with 0% coverage. The description only shows it in an example without explaining its meaning (e.g., monitor ID). No additional semantic value beyond schema.

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

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

The description clearly states the verb 'Trigger' and resource 'monitor check', and distinguishes from normal schedule. It also mentions the return value, making the purpose unambiguous.

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

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

The description implies use when immediate check is needed ('outside its normal schedule'), but does not explicitly state when to use or alternatives. No exclusions or sibling differentiation provided.

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

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

Annotations already show destructiveHint=true and readOnlyHint=false, so the description's 'Update' aligns. It adds value by listing patchable fields and providing a usage example. No contradictions, but could mention if unspecified fields reset or not.

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

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

Extremely concise: one sentence outlining functionality, a bullet list of patchable fields, and a clear JSON example. No fluff; every element earns its place.

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

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

The description covers usage well but omits return value format (no output schema). Given no output schema and 0% schema coverage, it's nearly complete but could specify what the tool returns (e.g., updated monitor object).

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

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

Schema has 0% coverage (no property descriptions). The description compensates fully by enumerating all patchable fields (name, status with enum, schedule, etc.) and showing a usage example. This is critical for correct invocation.

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

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

The description clearly states 'Update a monitor' using a specific verb+resource, and distinguishes from sibling tools like create, delete, get, list, run, check, etc. The purpose is unambiguous.

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

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

The description indicates partial update via 'Pass any subset of fields to patch', which is good context. However, it does not explicitly state when not to use this tool or prerequisites (e.g., monitor must exist). Sibling differentiation is implicit but not elaborated.

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

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

The description extensively details behavioral aspects beyond annotations: two modes (local vs hosted), two-call flow for hosted mode, supported/unsupported options, privacy setting, and return types. Annotations provide readOnlyHint and destructiveHint, but the description adds crucial operational context.

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

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

The description is well-structured with headings, bullet points, and examples. It is somewhat lengthy but each section adds value. Front-loading the main purpose and best practices aids quick comprehension.

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

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

Given the tool's complexity (two modes, many parameters, no output schema), the description provides comprehensive guidance: explains return values, phase examples, unsupported options, and critical usage notes. It covers all necessary context for accurate tool invocation.

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

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

Despite low schema coverage (21%), the description explains the most critical parameters (filePath, uploadRef, formats, parsers, pdfOptions) and their roles in the two-phase flow. It also covers format selection with JSON vs markdown. Not all 19 parameters are detailed, but the key ones are sufficiently clarified.

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

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

The description clearly states the tool parses a local file using Firecrawl's /v2/parse endpoint. It distinguishes itself from sibling firecrawl_scrape by specifying it is for local documents, not remote URLs. The verb 'parse' and resource 'file' are specific and unambiguous.

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

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

The description includes explicit 'Best for' and 'Not recommended for' sections, directly guiding when to use this tool versus alternatives like firecrawl_scrape. It also lists common mistakes, providing clear usage boundaries.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the description does not need to restate these. It adds that the output is markdown with specific fields, which is useful but not required beyond what annotations imply. 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.

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

Two sentences, no wasted words. The first sentence states the action precisely, and the second gives usage guidance. Perfectly front-loaded and efficient.

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

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

For a simple fetch tool with one parameter and no output schema, the description adequately covers purpose, usage context, and return format. Minor improvement would be error handling hints, but overall complete enough.

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

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

The single parameter paperId is fully covered by the schema description (100% coverage) with examples. The tool description adds no extra semantic detail beyond what the schema provides, so baseline score of 3 is appropriate.

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

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

The description clearly specifies fetching canonical metadata for one paper, listing specific fields (title, abstract, etc.) and output format (markdown). It distinguishes from siblings by indicating it is used after search/related results for detailed metadata.

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

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

The description explicitly states when to use the tool ('after search/related results') and what it returns, providing clear context. However, it does not mention when not to use it or provide explicit alternatives among siblings.

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

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

Annotations provide readOnlyHint and openWorldHint. The description adds that it returns best-matching passages or a notice if full text is unavailable. No contradictions, and the description adds value beyond annotations.

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

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

The description is two sentences with no waste: first sentence states the action and resource, second provides use case and outcome. Well front-loaded.

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

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

For a read tool with 3 parameters and no output schema, the description covers purpose, outcome, and a notice for unavailable text. Minor gap: does not describe behavior for high k values or error conditions beyond unavailable text. Still sufficient.

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

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

Schema coverage is 67% (k and paperId have descriptions; question has none). The description adds meaning to the question parameter by linking it to verification, but does not explain format beyond the use case. Adequate but not exceptional.

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

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

The description clearly states the tool reads 'in-body passages of ONE specific paper' for verification. It distinguishes from sibling tools like search and inspect by specifying the unique action (read passages) and the use case (verification of constraints).

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

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

The description explicitly says 'Use this to VERIFY whether a candidate actually satisfies a constraint' and gives examples. It does not list explicit exclusions, but the context of sibling tools makes the appropriate usage clear.

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

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

Beyond the read-only and non-destructive annotations, the description discloses that a similar call internally runs deep multi-round expansion with re-seeding, so no need to chain many calls. It also mentions the return format (candidates plus pool size). This adds meaningful behavioral context beyond what annotations provide.

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

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

The description is concise (about 80 words) and front-loaded with the main purpose. Every sentence adds value: purpose, usage, modes, advice, internal behavior, and return description. No redundancy, well-structured.

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

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

Given the tool's complexity (5 parameters, no output schema) and the moderate schema coverage, the description covers the essential aspects: seed selection, modes, intent filtering, and returns. It omits full output structure but provides enough for an agent to use it effectively. The reference to 'pool size' is incomplete but acceptable.

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

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

With only 20% schema coverage, the description compensates well by explaining the key parameters: seed_ids (arXiv IDs of strongest hits), mode (similar, citers, references), and intent (natural-language filter). While k and rerank are not detailed, rerank has a schema description, and k is straightforward. The description adds significant meaning beyond the schema.

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

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

The description clearly states the tool's purpose: to expand from anchor papers via the citation graph, ranked and filtered by a natural-language intent. It uses specific verbs (expand, pass, returns) and resources (anchor papers, citation graph, arXiv IDs), and distinguishes itself from sibling tools like search or read operations.

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

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

The description provides clear guidance on when to use the tool: 'use it on your best hits before finishing' and explains that it reaches papers plain search misses. It advises to pass arXiv IDs of strongest hits, and notes that a single similar call is sufficient. However, it does not explicitly state when not to use the tool, though the context is clear.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the description adds limited value. It notes that full content is available 'when available', which is useful but does not significantly expand on the annotation-provided safety profile.

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

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

The description is a single sentence with no wasted words, but it could benefit from slightly more detail without becoming verbose.

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

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

Given 2 parameters, 0% schema coverage, and no output schema, the description is insufficient. It fails to document input constraints and provides only a high-level output description, leaving significant gaps for the agent.

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

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

Schema description coverage is 0%, yet the description does not explain the query parameter (what constitutes a valid search) or the k parameter (likely max results). This omission forces the agent to infer parameter meaning from context alone.

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

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

The description clearly states it searches GitHub issue/PR history and repository readmes, and it distinguishes from sibling tools like firecrawl_search (general web) and firecrawl_research_search_papers (research papers).

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

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

The description implies using this tool for GitHub-specific search but does not explicitly state when to use it versus alternatives, nor does it mention when not to use it.

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

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

Annotations already declare readOnlyHint and destructiveHint. The description adds valuable context: the search method (HyDE), that results are ranked, and the specific fields returned. 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.

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

Four sentences, front-loaded with purpose, no redundant information. Every sentence adds value, including usage tips and output details.

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

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

Despite no output schema, the description explains return fields (arXiv id, title, abstract). It covers search domain, method, and query strategy, making it self-contained for an agent.

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

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

Schema description coverage is 67%. The description adds meaning for the undocumented query parameter (natural-language) and k (default 40, returns up to k results), compensating for gaps while schema covers other params.

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

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

The description clearly states it is the primary entry point for finding arXiv papers by topic, using semantic (HyDE) search over abstracts, returning ranked papers with arXiv id, title, and abstract. This distinguishes it from siblings like inspect_paper, read_paper, etc.

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

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

The description explicitly advises running several distinct framings of the question for better recall and specifies that the query should be a natural-language description. It does not, however, explicitly mention when not to use this tool or name alternatives, though context implies it.

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

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

Annotations indicate readOnlyHint=true and destructiveHint=false, and the description adds context like safe mode (read-only, no interactive actions), performance with maxAge, lockdown for air-gapped use, and privacy via redactPII. 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.

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

The description is very long and detailed, with bullet lists, headings, and code blocks. While well-structured and every sentence is useful, the length may overwhelm an agent. The critical info is front-loaded, but the format selection section is overly verbose.

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

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

Given the tool's complexity (22 parameters, no output schema), the description is quite complete: it covers usage, format selection, fallback strategies, key parameters, and return formats. Missing some details on less common parameters, but overall comprehensive.

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

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

With 0% schema description coverage, the description compensates by explaining key parameters (formats, jsonOptions, queryOptions, waitFor, maxAge, lockdown, redactPII, etc.) with examples and usage contexts. Not every parameter is covered, but the most critical ones are well documented.

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

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

The description clearly states the tool scrapes content from a single URL with advanced options, and distinguishes it from sibling tools like crawl (multiple pages), search (unknown location), and agent (dynamic pages). It also highlights its reliability and speed.

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

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

Provides extensive guidance: best for single page, not recommended for multiple pages or unknown location, common mistakes, critical format selection (JSON vs markdown vs query), handling JavaScript-rendered pages with step-by-step fallback, and examples. Explicitly mentions alternatives like firecrawl_map and firecrawl_agent.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. Description adds that it searches the web, returns a JSON envelope with id and creditsUsed, and mentions that scrapeOptions should be limited to avoid timeouts. Also explains the feedback mechanism. No contradictions 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.

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

Well-structured with sections and front-loaded purpose. However, it is lengthy due to a detailed operator table and multiple examples. Could be slightly more concise by trimming redundant guidance, but the complexity of the tool justifies the length.

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

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

Given 10 parameters with 0% schema coverage and no output schema, the description covers query, sources, domain filters, scrapeOptions, limit, and provides workflow and return format. However, it omits explanations for schema properties like tbs, filter, location, and enterprise. The inclusion of non-schema parameters in examples is a concern.

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

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

Schema coverage is 0%, so description carries full burden. It explains query with a detailed table of search operators, sources (web, images, news), domain filters with explicit rules (do not use both includeDomains and excludeDomains together, hostnames only), and scrapeOptions with usage advice. However, examples include 'lang' and 'country' which are not in schema, causing potential confusion.

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

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

Clearly states 'Search the web and optionally extract content from search results.' Explicitly differentiates from siblings like scrape, map, and crawl by stating 'Best for' and 'Not recommended for' sections. The description leaves no doubt about what the tool does.

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

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

Provides explicit 'Best for' and 'Not recommended for' sections, including common mistakes. Additionally gives optimal workflow: 'Search first using firecrawl_search without formats, then after fetching the results, use the scrape tool.' Also explains when to use sources and domain filters.

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

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

Annotations only provide readOnlyHint=false and destructiveHint=false. The description adds extensive behavioral context: idempotency per searchId, refund mechanics (only billable searches, preview teams blocked), time window enforcement, daily refund cap with stop calling instruction, and error handling details (HTTP 400/409). No contradictions 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.

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

The description is verbose but exceptionally well-structured: it starts with purpose, then details parameters in a list format, includes examples, and covers edge cases. While it could be slightly shorter, the comprehensive guidance justifies the length. It earns a 4 for being clear and organized despite not being maximally concise.

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

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

Given the tool has 5 parameters (2 required) and no output schema, the description fully explains the return shape (success, feedbackId, creditsRefunded, etc.) and error scenarios (400 for invalid input, 409 for expired window). It covers all failure modes and behavioral quirks like daily caps and idempotency. The description is complete for an agent to use correctly.

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

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

Schema coverage is only 20% (only missingContent array described). The description compensates by detailing each parameter: rating enum values with exact strings, valuableSources structure with url and reason, missingContent array with required topic and optional description plus examples, and querySuggestions as a free-text string. Examples illustrate usage for good and bad ratings.

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

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

The description clearly states the tool's purpose: "Send structured feedback on a previous firecrawl_search result." It distinguishes from sibling tools by specifying it is for search feedback and must be called immediately after a search. The verb 'send feedback' + resource 'firecrawl_search result' is specific and unambiguous.

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

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

The description provides explicit when-to-use guidance: "Call this immediately after a search where you used the results." It also specifies when not to call: beyond 2 minutes returns HTTP 409, and daily cap limits further calls. It mentions alternatives implicitly (moving on after failures) and provides clear behavioral rules like 'do not retry-loop' for 4xx responses.

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