Skip to main content
Glama

Website page list (site map)

site_map
Read-onlyIdempotent

Use it when an agent needs to know what pages a website has before reading them: where is the pricing page, which docs pages exist, what did the blog publish lately, which product or careers pages are there. Give any URL on the site; returns the site's page URLs with their last-modified dates, like Firecrawl's /map. Reads the sitemaps named in robots.txt, else /sitemap.xml and /sitemap_index.xml, following sitemap indexes (up to 10 child sitemaps, 20,000 URLs) and gzip (.xml.gz) sitemaps; a site with no sitemap is mapped from its home page's links on the same host. Filter with search (every word must appear in the URL, title or date, e.g. "pricing" or "blog 2026") and path_prefix (e.g. "/docs/"); limit up to 1,000 (default 200). next_calls read the first matches with scrape_batch. When the site cannot be reached (502) or no page matches (404), you are not charged. No account or API key. Costs $0.002 USDC per call via x402. Paid per call with x402 inside MCP (see the server instructions).

Input Schema

NameRequiredDescriptionDefault
urlYesThe website, or any page on it, e.g. https://example.com. Its origin (scheme and host) is mapped.
viaNoOptional: the tool whose next_calls suggested this call (filled in for you).
limitNoHow many URLs to return (1-1,000, default 200).
searchNoOnly URLs containing every word of this text (case-insensitive) in the URL, or in the title or lastmod when known, e.g. "pricing" or "blog 2026".
path_prefixNoOnly URLs whose path starts with this, e.g. "/blog/" or "/docs".

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / via
      Added value: +{
      +  "description": "Optional: the tool whose next_calls suggested this call (filled in for you).",
      +  "maxLength": 64,
      +  "type": "string"
      +}
  2. Added

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare readOnly/idempotent/openWorld/non-destructive, so the bar is met, yet the description adds substantial operational detail: sitemap discovery order via robots.txt, index following with concrete caps (10 child sitemaps, 20,000 URLs), gzip support, home-page link fallback, no-charge on 502/404, and x402 pricing with no account/API key.

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-loads the use case and result, then details discovery, filtering, follow-up calls, and cost. Dense but largely earns its length; some clauses (sitemap internals, pricing) run long and could be tightened.

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

Completeness5/5

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

With no output schema, the description supplies the return shape (page URLs with last-modified dates), failure semantics (502/404 uncharged), cost model, and the downstream scrape_batch workflow — everything an agent needs to invoke and then act on the result.

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 goes slightly beyond by giving worked filter examples ('pricing', 'blog 2026', '/docs/') and restating the limit default of 200, but most parameter meaning is already in the schema, so it does not add deep new semantics.

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+resource (map a site's pages/URLs) and immediately gives concrete motivations (find pricing, docs, blog, careers pages). It is clearly distinguishable from siblings like scrape_batch or web_search by framing itself as a pre-read inventory step.

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?

Explicitly says when to use it ('before reading them'), what to give it (any URL on the site), and connects it to the next step ('next_calls read the first matches with scrape_batch'). It even names the behavior it mirrors (Firecrawl's /map), leaving nothing to inference.

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