miromiro

Extract a whole page as code

extract_page

Read-onlyIdempotent

Use after list_site_pages, or when the user wants one complete page (not a single section) as code. Returns every section of the page top to bottom as code in the requested framework, plus pagePreviewUrl: the whole page assembled, with a Download HTML button. Flat credits per page (see usage.creditsSpent), whatever its length; a page already extracted in the last 24 hours is free. Paid plans only: on a free plan this returns an error explaining why - relay it and point the user to extract_code for single sections. Call it once per page the user picked, one at a time, and tell them how many are left as you go. If complete is false, call again with the same url: the done sections come from cache and the page is not charged again. Build on each section's code the same way as extract_code's (never regenerate it), and give the user pagePreviewUrl for every page.

Input Schema

Name	Required	Description
`url`	Yes	The page URL, e.g. linear.app/pricing - one of the pages from list_site_pages
`theme`	No	Which colour scheme to extract (default light)
`framework`	No	The code to generate for every section (default tailwind)

Output Schema

Name	Required	Description
`url`	Yes
`usage`	No	Credit usage for the authed key (spent, remaining, monthly limit).
`failed`	No	Sections that could not be extracted, with the reason
`complete`	No	False when the page had more sections than fit in one call - call again with the same url (free) to finish
`sections`	No	Every section, top to bottom
`framework`	No
`sectionCount`	No
`pagePreviewUrl`	No	The whole page assembled in order, with a Download HTML button. Give it to the user
`truncation_note`	No	Present when the result was trimmed to fit chat context - says what was dropped and how to get more (limit / full_output arguments, or the REST API).

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 annotations, it discloses billing behavior (flat credits per page, free within 24 hours), paid-plan restrictions, the free-plan error response, retry semantics when `complete` is false, cache behavior, and guidance not to regenerate section code. This is exactly the kind of operationally important context annotations cannot express.

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 and every sentence carries useful operational guidance, but it is a dense single paragraph mixing purpose, billing, retries, and workflow instructions. It could be structured more cleanly, though little is truly wasted.

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?

Given the complex paid extraction workflow, retry behavior, and sibling alternatives, the description covers what an agent needs before calling. An output schema exists, so it does not need to fully explain return values, and its mention of `pagePreviewUrl` and `complete` is sufficient.

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 `url`, `theme`, and `framework`, including enums and defaults. The description reinforces that the URL should come from `list_site_pages` and that the framework applies to every section, but it does not add substantial parameter syntax or format detail beyond the schema.

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: extract one complete page as code, returning every section top to bottom in the requested framework plus `pagePreviewUrl`. It explicitly distinguishes itself from `extract_code` by contrast with single sections, so an agent can route correctly among siblings.

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 when-to-use guidance: after `list_site_pages`, or when the user wants a complete page rather than a single section. It also states when-not/alternative guidance by directing users to `extract_code` for single sections and explains paid-plan-only behavior and the free-plan error path.

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.