Skip to main content
Glama
Sign In

PageHub

by dev.pagehub
OverviewDiscussionsAdmin

Import HTML site

import_site

Turn a static HTML site (pages, CSS, JS, images) into a NEW editable PageHub site draft. Inputs, one per call: filePath (local folder or .zip; local server only); size (zip bytes) returns an upload URL, curl line and uploadKey; uploadKey, after the PUT, starts the import; files sends text files inline (≤3MB); restOf (an importId) brings the pages a plan's page limit left out into that import's same site, after an upgrade. Returns an importId for get_import_status.

Input Schema

NameRequiredDescriptionDefault
nameNoSite name (default: home page title).
sizeNoExact zip size in bytes → returns an upload URL.
filesNoInline files: path relative to the site root.
pagesNoArchive paths of the pages to import (e.g. about.html), when the plan's page limit can't take them all. The home page is always included; the limit still applies, in this order.
restOfNoimportId of a capped import: adds the pages it left out to that same site. Needs a plan that takes more pages (get_import_status says when).
uploadKeyNoFrom the size step, after the PUT succeeded → starts the import.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / pages
      Added value: +{
+  "description": "Archive paths of the pages to import (e.g. about.html), when the plan's page limit can't take them all. The home page is always included; the limit still applies, in this order.",
+  "items": {
+    "maxLength": 512,
+    "type": "string"
+  },
+  "maxItems": 2000,
+  "type": "array"
+}
    • addedInput schema / properties / restOf
      Added value: +{
+  "description": "importId of a capped import: adds the pages it left out to that same site. Needs a plan that takes more pages (get_import_status says when).",
+  "maxLength": 64,
+  "type": "string"
+}
  2. Added

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already cover the safety profile (readOnly=false, destructive=false, openWorld=true, idempotent=false); the description adds what the annotations cannot: that the result is a draft site, the upload-then-import sequencing, and that an importId is returned for get_import_status. It omits auth/plan prerequisites other than the indirect 'a plan's page limit' mention.

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-loaded with the purpose and then densely enumerates each input mode; almost no wasted words. It is slightly over-compressed — the semicolon-chained clauses take effort to parse and some qualifiers ('local server only') are easy to miss.

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 six-parameter, all-optional tool with no output schema, the description covers every mode of invocation, the inline size cap, the page-limit/upgrade path, and what is returned. An agent has enough to choose the right parameter and chain the calls to get_import_status.

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 the schema baseline is 3; the description exceeds it by explaining the relational semantics the schema can't express — that size returns an uploadKey, that uploadKey must follow a successful PUT, that restOf targets an existing importId, and that filePath is local-server only.

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 opens with a specific verb and resource: 'Turn a static HTML site (pages, CSS, JS, images) into a NEW editable PageHub site draft.' The asset types and the 'NEW draft' outcome distinguish it from create_site and edit_site_file without needing to name them.

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 spells out the multi-step workflow per parameter: size returns an upload URL and uploadKey, uploadKey after the PUT starts the import, files sends text inline (≤3MB), restOf reuses an importId after an upgrade. This is strong conditional guidance, though it never states when to prefer this over create_site or when not to use it.

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

All PageHub toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources