Skip to main content
Glama

Documarium

Create a preview site

create_preview

Turns markdown pages into a live preview site and returns a link to it. It takes the content already converted to markdown, one entry per page, and a record of where the content came from, exactly as it happened: a code repository, a documentation site's address, a product landing page's address, writing supplied directly in this conversation, or a file attached to this conversation, with the address when there is one. It also takes the product's name and, when the source shows one, the address of its logo. Which pages come over from a source with many pages is the person's choice, made after they see what was found and before it is converted: everything, one part, or a new structure. When they have already named the pages, that choice is made. The preview is temporary and belongs to no one until somebody keeps it. Pages arrive finished and carry no notes, placeholders, open questions or marks; a page with a note to its author, such as [GAP], [?] or TODO, is refused. Where the source is silent, a page carries the best answer and what was assumed is said in the conversation. On a legal page, the business's legal name, its address, the country whose law applies and who else handles its customers' data come only from the person or their source; a page missing one of them still reads complete without it, and what was assumed is said in the conversation. The page list is short: every page should be one a reader would open on its own; contact details and short notes belong inside another page. Every page, title and heading is in the site's language, passed as languages, like ["de"]. A translated copy is every page again, translated, at the same address under // (/es/guides/setup), with its code listed after the site's own. The result says what to check, page by page, before the link is shared.

Input Schema

NameRequiredDescriptionDefault
pagesNoThe pages, already converted to markdown. One entry per page.
sourceYesWhere this content came from, exactly as it happened.
logo_urlNoA direct https address of the product's logo as the source shows it in its header — the mark, not a banner or a picture made for social media. Leave it out if the source has none.
languagesNoThe site's language as a code, like en, ru or pt-BR — the language every page, title and heading is written in.
site_nameNoThe name of the product or company the site is about, as the source writes it. It is shown at the top of every page.
attributionNoWhere this arrival came from.
logo_shows_nameNotrue when the logo image itself spells the name, so the name is not printed again beside it. Leave it out otherwise.

Output Schema

NameRequiredDescriptionDefault
capsNo
createdNo
summaryNo
draft_idNo
next_stepsNo
preview_urlNo
short_pagesNo
no_front_pageNo
page_problemsNo
pages_createdNo
rights_noticeNo
before_sharingNo
fetched_sourceNo
bytes_submittedNo
notes_to_authorNo
pages_submittedNo
expires_in_hoursNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.6/5.0
Behavior4/5

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

Annotations already establish this is a non-read-only, non-destructive, non-idempotent operation, so the bar is lower, and the description still adds real behavior: the site is temporary and unclaimed until kept, a link is returned, the response includes per-page items to check, and pages containing notes such as [GAP], [?] or TODO are refused. It does not cover auth requirements, expiry window, or viewer access for the preview link, which are the remaining gaps.

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

Conciseness3/5

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

The first sentence is well front-loaded, but the remaining text is a run-on stream mixing content policy, legal-field rules, translation paths and page granularity with no paragraph or list structure. Most sentences carry a genuine constraint, yet phrasing like 'exactly as it happened' and 'a page missing one of them still reads complete without it' costs clarity. It needs restructuring more than trimming.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a seven-parameter, nested-schema tool with an output schema, the description covers the parts structured fields cannot: content acceptance rules, source-selection behavior, legal-page constraints, and translation layout. Return values need not be explained because an output schema exists. Missing are operational details such as how long the preview lives, who can access the link, and any size or rate limits.

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 baseline is 3 and the schema already explains pages, source.kind, logo_url and languages. The description adds some meaning, notably that languages drives all page text and headings and that translated copies appear at /<code>/ paths, but most parameter prose restates the schema's own wording rather than extending it.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The first sentence gives a concrete verb and resource: turns markdown pages into a live preview site and returns a link. That is enough to tell it apart from siblings like read_page, list_pages or propose_edit. It never names publish or claim_draft explicitly, so the boundary between previewing and keeping/publishing a site is only implied by 'temporary and belongs to no one until somebody keeps it'.

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

Usage Guidelines3/5

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

Usage is implied rather than stated: the preview is temporary and the result tells you what to check before sharing the link, which suggests it precedes publish, but no alternative is named and no when-not condition is given. The bulk of the text is content-entry requirements (page granularity, no TODOs, legal fields) rather than tool-selection guidance. An agent would infer the workflow but not be routed explicitly.

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.

Resources