Firecrawl MCP Server

Firecrawl Government Index search

firecrawl_gov_search

Read-only

Search US federal, state, and local government sources for statutes, regulations, codes, court opinions, and official publications to find governing text and ranked titles, URLs, and snippets.

Instructions

Search an index of primary law and regulatory material from US federal, state, and local government sources (statutes, regulations, codes, court opinions, and other government publications) for legal or regulatory questions that need the governing text or an official source.

Returns ranked results with a position, title, URL, and matched snippet.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "query": "<query>"
    },
    "name": "firecrawl_gov_search"
  }
}

Input Schema

Name	Required	Description	Default
`k`	No	Number of ranked results to return (default 10).
`query`	Yes	Natural-language legal or regulatory question or search phrase, including the jurisdiction, agency, or citation when relevant.

Output Schema

Name	Required	Description	Default
`results`	Yes	Ranked results, in the order the text block lists them.
`agent_hints`	No	Optional response guidance from the Firecrawl API.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv3.28.2Nov 4, 2026

TDQS

A3.8/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds genuine context about the corpus boundaries (US federal/state/local, primary law only), but it spends its second sentence restating a return shape that the output schema already carries, and says nothing about rate limits, freshness, or index coverage gaps.

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 tight sentences: scope and use case first, return shape second. Every clause carries information, with no filler or repetition of the title.

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

Completeness4/5

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

With an output schema present, 100% parameter coverage, and full annotations, the description only needs to establish domain and fit — which it does. The one remaining gap is that it doesn't route between itself and firecrawl_search when a legal question could plausibly go either way.

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 description coverage is 100% and both parameters are documented in-schema, so the baseline of 3 applies. The description adds no syntax, format, or jurisdictional-encoding guidance for the query or the k parameter beyond what the schema already says.

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?

The description gives a specific verb ("Search") and a precisely scoped resource — an index of primary law and regulatory material from US federal, state, and local sources, with concrete content types (statutes, regulations, codes, court opinions). It is clearly differentiable from the general firecrawl_search sibling by domain, though it never names that sibling explicitly.

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?

"for legal or regulatory questions that need the governing text or an official source" states the triggering condition well and implies the alternative (general web search) without naming it. There are no explicit exclusions, e.g. what to do when a general search or firecrawl_search would suffice, but the use case is unambiguous.

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