Skip to main content
Glama

FirstSited

Export sites

export_sites

A bulk export of matching sites, up to 5,000 at once, for building a list or loading into a spreadsheet. Same filters as find_sites. Ask for csv output if the result is going into a file. For counts, shares or 'which X do these sites use', call stack_breakdown instead; it answers in one call and needs no export. Counts one site from the monthly allowance for each site not already returned to you this period, so this is the call most likely to ask you to confirm first.

Input Schema

NameRequiredDescriptionDefault
csvNoAlso return the rows as CSV text, ready to save as a file.
nearNoOnly sites near a place: a town or city, a postcode, or 'lat,lng', e.g. Bristol. Use with radius. Sites we could not place are left out.
limitNoHow many sites to export, 1-5000. Default 1000.
sinceNoEarliest launch date, YYYY-MM-DD.
untilNoLatest launch date, YYYY-MM-DD. Inclusive of the whole day.
radiusNoHow far from near, e.g. 30mi or 50km (a bare number is km). From 5 to 248 miles (8 to 400 km).
confirmNoSet true to skip the cost confirmation and return the data immediately.
countryNoCountry as an ISO 3166-1 alpha-2 code, e.g. GB. Names are accepted too.
regionsNoOnly sites in these states, provinces or other regions, e.g. ["Texas", "Oklahoma"]. Each a name, a name and country such as 'Georgia, US', or an id such as US-TX. A site matches if it is in ANY of them. Sites we could not place are left out.
categoryNoProduct category, e.g. ecommerce.
keywordsNoWhole words to look for in a site's name, title or description, e.g. photogrammetry. Matches ANY of them; a multi-word entry is a phrase. Three characters or more, up to ten words. Combines with every other filter, so 'Stripe sites that mention photogrammetry' is technology plus keywords. The same rule create_watch uses, so a word that filters here is the word a watch would fire on.
technologyNoTechnology name, exactly as returned by list_technologies.
observedSinceNoEarliest date we first recorded the site, YYYY-MM-DD. Use this rather than 'since' when building an incremental export on a schedule.
hasContactPageNoOnly sites that have a published contact page. Needs the 'contacts' permission.
includeQualityNoInclude quality bands for each site.
hasContactEmailNoOnly sites that have a published contact email. Needs the 'contacts' permission.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.8/5.0
Behavior5/5

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

Goes well beyond the annotations: it discloses that each new site consumes one from a monthly allowance and that this call is 'the most likely to ask you to confirm first', which explains the non-readOnlyHint and the existence of the confirm parameter. The quota/confirmation behavior is the single most decision-relevant fact about this tool and it is stated plainly.

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?

Four sentences, each carrying distinct information: scope/size, filter parity, CSV guidance, alternative tool, and cost model. The cost warning is placed last, which is the right emphasis for a quota-consuming call, and there is no filler.

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?

For a 16-parameter, no-output-schema tool, the definition covers purpose, alternatives, quota cost, and confirmation. It does not describe what fields come back in the export or any pagination/truncation behavior at the 5,000 ceiling, which would matter when a caller is deciding between one large export and several smaller ones.

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

Parameters4/5

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

Schema coverage is already 100%, so the baseline is 3; the description still adds cross-parameter meaning by pointing at csv for file output and by noting the filter set mirrors find_sites. It does not re-explain individual filters, which is appropriate since the schema documents them thoroughly.

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?

States a specific verb and resource ('bulk export of matching sites'), adds a concrete ceiling ('up to 5,000 at once') and an intended use ('building a list or loading into a spreadsheet'). It also names the sibling that shares its filters ('Same filters as find_sites'), so the agent can place it in the toolset without opening another schema.

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

Usage Guidelines5/5

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

Explicit routing: use this for lists/files, 'Ask for csv output if the result is going into a file', and 'For counts, shares or "which X do these sites use", call stack_breakdown instead'. It even explains why the alternative wins ('answers in one call and needs no export'), which is exactly the when-not guidance an agent needs.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources