Skip to main content
Glama

import_landing_page_html

Bring-your-own-HTML: import a landing page by pasting source or fetching a URL. Create a new page or overwrite an existing slug; optionally auto-create stub side pages.

Instructions

Bring-your-own-HTML: import an existing landing page from pasted HTML or a live URL. Synchronous — no polling needed. Pass exactly one of html (paste the full page source) or url (fetch and import from a live page). By default creates a brand-new landing page (optionally with name; the slug is always auto-generated). Pass convertExistingSlug instead to overwrite an existing landing page's content with the imported HTML. Set createMissingSidePages to true to auto-create stub side pages for internal links discovered in the HTML that don't already exist. Returns { landingPage: {id, slug}, report } where report audits the import: externalHosts (third-party domains referenced), relativeAssetPaths (local asset paths that may need re-hosting), placeholders (unresolved template tokens found), internalLinks (each { href, slug, existingSidePage }), themeExtracted (whether a theme was inferred from the HTML), truncated (whether the source HTML was cut down to fit limits), and extractability ({ verdict: 'ok'|'warn', reasons } — 'warn' means framework hydration scripts won't load post-import but static content still renders). If the source is a client-rendered app shell whose content depends entirely on framework scripts that can't be hosted here (e.g. a bare Next.js/React app shell), the import is refused before anything is persisted — this tool returns a non-throwing result { error: 'not_extractable', message, reasons } instead. Relay the reasons to the user and suggest pasting a static/exported HTML instead, or publishing directly from their site builder. Example: import_landing_page_html({ url: 'https://example.com/pricing', name: 'Pricing' }).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlNoLive page URL to fetch and import (URL mode). Provide this or `html`, not both. Scheme-less domains (e.g. "example.com") are accepted and default to https.
htmlNoFull HTML source to import (paste mode). Provide this or `url`, not both.
nameNoDisplay name for the new landing page
brandIdNoBrand ID (defaults to active brand)
convertExistingSlugNoSlug of an EXISTING landing page to overwrite with the imported HTML, instead of creating a new one
createMissingSidePagesNoAuto-create stub side pages for internal links found in the HTML that don't already exist
Behavior5/5

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

With no annotations provided, the description takes on full transparency responsibility and succeeds. It discloses synchronous execution, auto-generated slugs, optional side-page creation, and an exhaustive report structure including truncation and extractability. It even describes the non-throwing refusal behavior for client-rendered app shells and instructs the agent to relay reasons and suggest alternatives, exceeding typical descriptions.

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 dense and front-loaded, starting with the core purpose and then systematically covering inputs, return values, and error handling. It includes a concrete example, which aids comprehension. However, it is a single long paragraph that could benefit from bullet points or shorter sentences to improve scannability, though no content is 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?

Because there is no output schema, the description must fully document return values, which it does in remarkable detail: the report object with all fields, the error result, and the recommended user follow-up. It also covers all parameter interactions and failure modes, making it a self-contained reference for correct invocation.

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?

The schema already has 100% parameter coverage, but the description adds valuable semantics: it explains that html and url are mutually exclusive, that the slug is always auto-generated, and how convertExistingSlug overwrites existing content. These are not inferable from the schema alone, enriching the agent's understanding.

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 clearly states the verb and resource: 'import an existing landing page from pasted HTML or a live URL' and even names the operation 'import_landing_page_html'. It distinguishes from siblings like generate_landing_page by emphasizing 'Bring-your-own-HTML' and synchronous behavior, making the tool's unique role evident.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It provides explicit in-tool usage guidance: 'Pass exactly one of html or url' and explains when to use convertExistingSlug versus creating a new page. It also advises on the not_extractable error, suggesting static HTML as an alternative. However, it never explicitly names sibling tools as alternatives (e.g., generate_landing_page) when no existing HTML is available, so the when-not-to-use context is only implied.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/bitsandtea/postking-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server