miromiro

List a website's pages

list_site_pages

Read-onlyIdempotent

Use when the user wants a whole website (or several of its pages) as code, or asks which pages a site has. Free on every plan (0 credits). Returns every page found (from the sitemap, else the homepage links), split into pages with their own layout (home, pricing, about...) and templates: groups of pages that share one layout (blog post x62, product x24) with example URLs - extracting one example gives that layout. suggested covers every layout once. Show the user the list and ask which pages they want before extracting anything: say how many pages and templates there are and what extract_page costs (creditsPerPage credits per page). Never extract every page of a big site unprompted. Then call extract_page once per chosen page. If the result has premium, the user's plan does not include whole-site extraction: tell them premium.reason and give them premium.upgradeUrl; single sections still work with extract_code.

Input Schema

Name	Required	Description	Default
`url`	Yes	The website, e.g. linear.app
`response_format`	No	How much to return. 'concise' keeps lists to 10 entries and strings short - right for a summary or a chat answer. 'detailed' returns everything the tool has (same as limit=200 + full_output=true). Omit for the default, which fits a typical chat context. The generated code is never trimmed in any mode.

Output Schema

Name	Required	Description
`url`	Yes
`pages`	No	Pages with their own layout
`usage`	No	Credit usage for the authed key (spent, remaining, monthly limit).
`source`	No	sitemap \| links - where the page list came from
`premium`	No	Present when the plan does not include whole-site extraction: reason (relay it) and upgradeUrl
`summary`	No	The scan in one sentence - a good opening for your reply
`suggested`	No	Unique pages + one example per template: every layout on the site once
`templates`	No	Groups of pages sharing one layout, biggest first. A guess from the URLs - check an example before promising the user the layouts are identical
`truncated`	No
`totalPages`	No
`creditsPerPage`	No	What extract_page charges per page

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 30, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Beyond the annotations, the description discloses that the tool is free on every plan (0 credits), where pages come from (sitemap, else homepage links), the exact result shape (`pages`, `templates`, `suggested`), template grouping behavior, and premium-gating behavior with `premium.reason` and `premium.upgradeUrl`. This is unusually rich behavioral context for a read-only tool.

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?

The description is front-loaded with the trigger condition and is dense with useful workflow details. It is somewhat long as a single paragraph and could be easier to scan with bullets, but nearly every sentence earns its place and no significant repetition appears.

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?

For a read-only listing tool with an output schema and full annotation coverage, the description is complete: it covers trigger, source of data, result structure, cost, required user confirmation, next-step extraction, and premium failure handling. Nothing an agent needs in order to call it correctly is missing.

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%, so the schema already documents both `url` and `response_format`. The description does not add syntax or format details beyond the schema; its cost discussion (`creditsPerPage`) applies to the follow-up extract_page call rather than this tool's parameters. Baseline 3 is appropriate.

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?

The description states a specific verb and resource: listing a website's pages, either to get the site as code or to answer which pages exist. It clearly distinguishes the tool from extraction siblings by saying to call extract_page only after the user chooses pages.

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?

It gives explicit trigger conditions ('Use when the user wants a whole website... or asks which pages a site has'), a required workflow (show the list, state counts and costs, ask before extracting), an explicit prohibition ('Never extract every page of a big site unprompted'), and a fallback path when `premium` appears. Alternatives and exclusions are both covered.

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

All miromiro tools Inspect

Try in Browser

Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.