Skip to main content
Glama

Extract section as code

extract_code
Read-onlyIdempotent

Use when the user asks to rebuild, clone, copy, port, restyle or 'make it look like' part of a real website, or wants a site's section as Tailwind, HTML+CSS, React (JSX) or Vue - or as a file to import into a site builder: framework=elementor for an Elementor template (WordPress), framework=shopify for a Shopify theme section. Give it the URL and, when the user named a part of the page, section (hero, header, footer, pricing, features, testimonials, faq, cta) - never invent a CSS selector. With neither, it auto-detects the hero; every call also returns sections, each other extractable section with a label and a ready selector for a follow-up call. Returns a self-contained component with the page's real resolved styles (true colors, fonts, spacing, copy) plus the tokens and assets it uses, so you adapt real values instead of estimating from a screenshot. Not for: whole-page scraping, page text, or sites that need a login. Loads the page in a real browser and reads the styles, theme and images it actually shows, on every plan at no extra cost - no need to pass render=true. Large inline SVGs (logo walls, illustrations) come back as hosted files so the code stays small enough to use as-is (inline_svg=true keeps them inline). Ask for the format the user wants (framework=jsx for React, vue for Vue) instead of converting one into another. Build on code, never regenerate it: it is the section exactly as the site renders it. Then make it better to use where it can be: clear names for the component, props and variables; reusable small components with props instead of long repeated markup; hard-coded text and repeated items as props or a data array (jsx and vue already collapse repeated structures into .map()/v-for - keep that); shorter code by removing redundant wrappers, moving duplicated class lists into a shared component or constant, and dropping styles that do nothing (box-sizing: border-box is already Tailwind's default); and what the user asked for (their theme colors and fonts, removing parts). If the code is already clean, hand it over as it is. Every change must render the same: copy each className exactly as returned and never change a value (color, size, spacing, font) - retyping styles from memory loses the fidelity - and check your version against previewUrl. Elementor and Shopify files are imported as they are: do not edit them. Give the user downloadUrl, the code exactly as returned as a file in their format (.jsx, .vue, .html, .elementor.json, .liquid), and previewUrl, that code rendered as a page, to compare your version against. When rebuilding a whole page, extract each section and give them pagePreviewUrl: every section extracted so far, assembled in page order, also downloadable.

Input Schema

NameRequiredDescriptionDefault
urlYesThe website URL, e.g. stripe.com
nameNoComponent name for the jsx target (default ExtractedSection). Ignored by tailwind, html and vue. Renaming never re-runs the extraction - it costs 0 credits on a cached section.
freshNoSkip the 24-hour cache and re-extract the live page - use when the site just changed and a cached result would be stale. Charged normally; the fresh result replaces the cached copy.
themeNoWhich colour scheme to extract (default light). Pass 'dark' when the user is looking at the site in dark mode or asks for the dark version: the page's prefers-color-scheme: dark rules and custom properties become the component itself instead of riding along as dark: variants. Works whether the site expresses its themes as @media (prefers-color-scheme) or as a root attribute/class the CSS is scoped to ([data-theme=dark], html.dark). Sites that switch themes purely in JavaScript cannot be selected this way - you get the page default plus a hint saying so. No extra credits.
renderNoForce a real browser so the page's JavaScript runs before it is read. Slower, and adds 5 credits. Usually not needed: when the plain read comes back as a JavaScript app shell or the site refuses it (401/403/406) or timed out, the server already re-runs the page in a browser by itself at no extra cost, and usage.autoRender says so. Pass it for images, videos or Lottie that only load on scroll, with screenshot=true, or when a result is still thin after that automatic pass. If a 403 says the browser was refused too, the site cannot be extracted - do not retry. extract_code always runs in a real browser at no extra cost, so render=true is not needed there (only together with screenshot=true). On extract_design_tokens, render=true only permits the browser: the plain read still runs first, and the 5 credits are charged only if the browser was actually needed.
sectionNoWhich part of the page, by name - use this when the user asked for the pricing, footer, header/nav, features, testimonials, FAQ or call-to-action block. Resolved on the page itself from its ids, classes, headings and, failing those, its content (prices, blockquotes, FAQ items), so it works without seeing the markup and on pages that label nothing. Omit for the hero. If the page has no such section you get the hero plus a `note` listing what is there.
selectorNoCSS selector for the section, ONLY when you have one from a previous result's `sections` list (e.g. "section.pricing-grid"). Do not guess selectors: a selector that matches nothing falls back to the hero with a `note`, and the guess costs a call. Prefer `section` for named parts of a page.
frameworkNoThe code to generate (default tailwind). 'elementor' returns an importable Elementor template: tell the user to save `code` as a .json file and import it in WordPress under Templates > Saved Templates > Import. 'shopify' returns a theme section: save `code` as sections/<name>.liquid in the theme, then add it from the theme editor. Use the theme code editor's sections folder, not a Custom Liquid block (that block is capped at 50 KB and cannot hold the schema). Both arrive as one styled HTML block (edited as code, not as native widgets), with the section's responsive and hover styles included and its CSS scoped so it cannot clash with the theme. Give the user the file contents complete and unmodified.
inline_svgNoKeep large inline SVGs (logos, illustrations) inline in `code` instead of hosted <img> files. Only when the user needs fully self-contained code: a logo wall can add 50+ KB.
screenshotNoRequires render=true. Adds a screenshot field to the result: a public URL of a capture of the page (live 7 days), taken by the same browser that rendered it. Pass true for the 1440x900 viewport or 'full' for the entire page height. No extra credits beyond the render surcharge. Useful for showing the user what the extracted site looks like.
response_formatNoHow 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

NameRequiredDescriptionDefault
cssNoCompanion CSS: always set for framework=html; for tailwind/jsx/vue it carries the @keyframes the section uses (add to the global stylesheet); null for elementor/shopify, whose file already contains its CSS
urlYes
codeNoThe generated, paste-ready component code. For jsx/vue, repeated structures (tiers, cards, list items) are collapsed into a data array rendered with .map()/v-for. For elementor this is the complete template JSON (a .json file); for shopify the complete section file (a .liquid file) - hand either over whole
hintNoOnly present when the extraction looks degraded (client-rendered page, runtime-injected styles, or none of the page's stylesheets could be fetched) - says what to do (the server has already tried a browser where one would help); when the stylesheets failed, retry the same call in a moment; on a render=true call the styles could not be resolved even in a browser, do not retry
nextNoThe most likely follow-up call for this result, with the tool and arguments to use. Offer it to the user when it fits what they are doing.
noteNoPresent when the requested selector or section was not found and the hero was returned instead - says what was asked for and which sections the page does have. Tell the user.
themeNolight | dark: which one the code you just received actually is. Measured from the page (its declared root theme, else the backgrounds the cascade resolved), never echoed from your request - so if you asked for a theme the site cannot serve, this reports what you really got. A site that expresses themes only through a prefers-color-scheme media query returns its light branch unless you pass theme=dark. Tell the user which theme they got when it may not match what they see on the site
usageNoCredit usage for the authed key (spent, remaining, monthly limit).
assetsNoImages/fonts the section references
tokensNoDesign tokens the extracted section actually uses
sectionNoThe named section that was resolved, when one was requested
summaryNoWhat was extracted, at a glance. styledCoverage (0-100) is the quality signal: the % of elements the cascade found styles for
svgNoteNoPresent when large inline SVGs were moved to hosted <img> files - how many and how much smaller the code got
sectionsNoEvery extractable section on the page - call again with one of these selectors for a specific part (an mm-range(...) selector is a block no single element wraps; pass it back the same way)
selectorNoThe CSS selector that was extracted
frameworkNotailwind | html | jsx | vue | elementor | shopify
previewUrlNoA page showing this section rendered from the same extraction (as HTML + CSS), so it looks exactly like the code you got. Give it to the user so they can compare it with the live site
downloadUrlNoThe code exactly as returned, as a file in the requested format (.jsx, .vue, .html, .elementor.json for elementor, .liquid for shopify). Give it to the user so they always have the original file, even after you adapt the code
autoDetectedNoTrue when the hero was auto-detected rather than passed in
pagePreviewUrlNoThe whole page: every section of this URL extracted in the last day, assembled in page order, with a Download HTML button. Grows as more sections are extracted - give it to the user after a whole-page rebuild
truncation_noteNoPresent 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.

  1. Changed1 schema field changed
    • changedOutput schema / properties / sections / description
      Previous value: -"Every extractable section on the page - call again with one of these selectors for a specific part"New value: +"Every extractable section on the page - call again with one of these selectors for a specific part (an mm-range(...) selector is a block no single element wraps; pass it back the same way)"
  2. Changed1 schema field changed
    • addedOutput schema / properties / downloadUrl
      Added value: +{
      +  "description": "The code exactly as returned, as a file in the requested format (.jsx, .vue, .html, .elementor.json for elementor, .liquid for shopify). Give it to the user so they always have the original file, even after you adapt the code",
      +  "type": "string"
      +}
  3. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Goes far beyond the annotations by disclosing browser rendering behavior, caching, credit implications, auto-detection fallback, SVG hosting, Elementor/Shopify import constraints, and the `downloadUrl`/`previewUrl`/`pagePreviewUrl` outputs. The read-only, open-world, idempotent annotations are consistent with an extraction tool, and the description adds operational caveats the agent could not infer from annotations alone.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The opening sentence is front-loaded and useful, but the description is extremely long and dense, mixing invocation guidance with extensive post-extraction editing, cleanup, and handoff instructions. Many sentences are valuable workflow rules, but they make the tool definition hard to scan and exceed what is needed for tool selection.

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 an 11-parameter extraction tool with an output schema, the description is more than complete: it covers framework-specific outputs, caching, rendering, fallback behavior, SVG handling, and follow-up page assembly. An agent has enough context to call it correctly and understand the main caveats.

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 schema carries most parameter definitions. The description still adds meaningful selection guidance around `section` vs `selector`, framework choices, and when to use `fresh` or ask the user for a target format, but much of its parameter detail duplicates the schema text rather than adding wholly 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?

Starts with a specific verb and resource ('extract section as code') and immediately scopes it to rebuilding, cloning, porting or restyling real website sections. It clearly distinguishes itself from the other extract_* siblings by focusing on generated component code rather than assets, tokens, fonts, or media.

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 states when to use it, which frameworks map to which user requests, how to pick `section` vs `selector`, and what not to use it for ('whole-page scraping, page text, or sites that need a login'). It also tells the agent to ask for the desired format rather than converting between formats.

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.