Skip to main content
Glama

FirstSited

Find sites

find_sites

Find newly launched sites matching any combination of technology, category, country, region (a state or province), distance from a place, date range and contact availability. This is the main search tool. For example: sites in the UK built with WordPress that launched this week and have a contact email, Shopify shops within 30 miles of Bristol, or new sites in Texas. Each site carries its town and region, and its distance when near is given. For counts, shares or 'which X do these sites use', call stack_breakdown instead; it answers in one call. Counts one site from the monthly allowance for each site not already returned to you this period; you may be asked to confirm before a large result is returned.

Input Schema

NameRequiredDescriptionDefault
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 return, 1-100. Default 50.
sinceNoEarliest LAUNCH date, YYYY-MM-DD. Use this for questions about when products launched, e.g. 'launched this week'.
untilNoLatest LAUNCH date, YYYY-MM-DD. Inclusive: the whole of that day is included, so since and until set to the same date returns that one day.
cursorNoPaging token from a previous call's nextCursor. Repeat every other filter exactly as it was when the token was issued.
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 for the United Kingdom, US, DE. Country names such as 'United Kingdom' are also accepted. Country is an ESTIMATE with a confidence score, so see minCountryConfidence.
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, e.g. wordpress.
observedSinceNoEarliest date we first recorded the site, YYYY-MM-DD. Use this instead of 'since' when polling for new rows on a schedule: sites are discovered a median of 2 days (and up to about a week) after they launch, so a poller tracking 'since' never learns about them.
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.
minCountryConfidenceNoLeast country confidence to accept, 0 to 1. Country is estimated from the site, and scores near the 0.45 floor are weak guesses: a site whose own title says it is in Bangladesh can score 0.48 for the UK. Genuine matches usually score 0.6 or better, so pass 0.6 when the country needs to be right rather than merely likely. Every row carries its own countryConfidence too.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.7/5.0
Behavior5/5

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

Annotations say readOnlyHint=false, which would otherwise confuse an agent for a search call; the description resolves this by disclosing the credit model ('Counts one site from the monthly allowance for each site not already returned to you this period') and the confirmation gate for large results. It also states what each row carries (town, region, distance when near), so the response shape is predictable.

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?

Front-loaded with the capability statement, then examples, then the cost caveat — a sensible ordering for a 17-parameter tool. The 'This is the main search tool' line is slightly redundant with the opening sentence, but nothing else is wasted.

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 17-parameter search with no output schema, the description covers cost, confirmation, result contents and the primary alternative. Minor gap: it doesn't mention paging or result limits, though the cursor and limit parameters document that in the schema.

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 100%, so baseline is 3; the description adds value by showing how filters combine ('Stripe sites that mention photogrammetry' is technology plus keywords) and by framing the filters as an 'any combination' set. It doesn't add syntax detail beyond the schema for individual parameters, so it stays just above baseline.

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?

Opens with a specific verb+resource ('Find newly launched sites') and enumerates the filter axes it supports. The line 'This is the main search tool' plus the explicit hand-off to stack_breakdown lets an agent distinguish it from every sibling without opening a 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?

Gives three concrete natural-language queries ('sites in the UK built with WordPress that launched this week and have a contact email', 'Shopify shops within 30 miles of Bristol') that map intent onto filter combinations. It also names the alternative and the exact condition that selects it: counts, shares or 'which X do these sites use' → stack_breakdown.

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