Skip to main content
Glama

Publish a website

publish_site
Destructive

Publish files as a live website on the public internet, served over HTTPS. Use it when a report, essay, slide-like narrative, dashboard, marketing surface, or other static artifact reads better at a live URL than as conversation text. Honor an artifact form the user requests. Otherwise choose the artifact form and treatment from its audience, job, and material. A request for a live URL chooses delivery, not one long scrolling page.

Before building or substantially rewriting an artifact, call get_design_system. The organization design system supplies identity, not structure. Follow it wherever it speaks. Artifact guidance and model judgment decide the remaining choices; do not layer the default design system beneath it. Safety, accessibility, and medium correctness may adapt an identity choice. When the artifact is HTML, render it at 390px and verify the document itself does not overflow. Give wide flex or grid children min-width: 0. Use minmax(0, 1fr) for flexible tracks so local scrollers stay local. When a local scroller is necessary, show a visible cue when more content is available. For a table, keep the identifying column visible when practical or use another narrow-screen representation. Inspect computed foreground and background colors and verify rendered text contrast on every surface; safe tokens do not prove the intended selectors matched. Valet may place a bottom-center dock over the published page. When the page scrolls vertically, give its main scroll container bottom padding or equivalent clearance of about calc(6rem + env(safe-area-inset-bottom)) so the final content can scroll fully above the dock. Do not introduce scrolling solely to create this clearance. For fixed-height or slide-like artifacts, keep essential content and controls away from the bottom center when the composition allows.

title and description are required on every publish, and a call missing either is refused: title names the site for a person, and description says in one sentence what it holds. A site's name is a hostname, so those two are what a reader has to go on wherever the site is listed. Write them for the person who will come back to this page in a month.

Content is text written here: HTML, CSS, JavaScript, Markdown, JSON, SVG. Images, PDFs, video, and other binary assets are not supported on this surface — publish those with the Valet CLI.

Publishing uses a connected Valet account by default and creates a permanent, private site. Pass anonymous: true only when the user explicitly wants a temporary public site. It is public to anyone who has the link, and it may be removed 36 hours after it is created, unless it is claimed. The result carries a claim URL that moves the site into a Valet account and makes it permanent, and a site_token that updates the same site on a later call. Give that token back to revise the site instead of publishing a second copy of it; with an account, give the site's name instead.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameNoThe site's name, which becomes part of its URL. Omit to have one generated. Naming a site that already exists republishes it. Requires a connected Valet account.
filesYesRequired. The site's files. One file named index.html is the minimum; add more for stylesheets, scripts, or further pages.
titleYesRequired. What the site is called, written for a person: 'Q3 Migration Audit', not a hostname. It labels the site wherever it is listed, so write the same thing the page's own <title> says.
org_nameNoThe Valet organization to publish into. Omit to use the organization the account joined first.
anonymousNoSet true only when the user explicitly wants a temporary public site without account ownership. Omit for the account-first path, which connects a Valet account when needed.
site_tokenNoThe token an earlier anonymous publish returned. Give it back to update that same site instead of creating another.
descriptionYesRequired. One sentence saying what the site holds, for a person deciding whether to open it. It is shown beside the title wherever the site is listed.
idempotency_keyNoAn opaque key of your choosing. Repeating a call with the same key returns the first call's result instead of publishing a second site, which makes a retry safe.

TDQS

A4.8/5.0
Behavior5/5

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

Beyond the annotations, the description discloses key behavioral traits: publishing creates a permanent private site by default, anonymous sites are temporary and may be removed after 36 hours, a claim URL moves the site into an account, and naming an existing site republishes it. It also explains the design system dependency and page-layout constraints, giving the agent a realistic model of what will happen when the tool runs.

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 description is well-structured and front-loaded, but it is long and includes detailed artifact-composition guidance about 390px rendering, flex layouts, scrollers, and dock clearance that goes beyond what is needed to select or invoke the tool. While that guidance may be valuable, it makes the description less concise and harder to parse quickly.

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 complex tool with eight parameters and no output schema, the description is remarkably complete. It covers authentication behavior, public/private visibility, persistence, update semantics, content format limitations, and even mentions what the result carries (claim URL and site_token). An agent has enough context to use the tool correctly without needing to guess at unspecified behavior.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Although the schema already covers 100% of parameters, the description adds substantial meaning beyond the structured fields. It explains why title and description matter, how name affects the URL and republishing behavior, when anonymous should be true, and how site_token enables updating an existing site. This extra context helps the agent choose and fill parameters correctly.

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: 'Publish files as a live website on the public internet, served over HTTPS.' It further distinguishes this tool from sibling site-management tools by framing it as the delivery surface for static artifacts like reports, essays, and dashboards. This makes the tool's role unmistakable even among many sibling tools.

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 explicitly says when to use the tool: when an artifact 'reads better at a live URL than as conversation text.' It also gives clear exclusions, such as binary assets not being supported and telling the agent to publish those with the Valet CLI. The description even provides routing guidance for updates, saying to use site_token or existing site name rather than publishing a second copy.

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.

TDQS

A4.3/5.0
Disambiguation5/5

Every tool pairs a distinct resource with one action: site, connector, catalog, design system, access, and sharing are separate concerns. The four list_* tools are clearly differentiated by object (sites, site connectors, attachable connectors, catalog connectors), and attach/detach, publish/rename/delete, and set/share are unambiguous.

Naming Consistency5/5

All tool names follow a consistent snake_case verb_noun pattern with no stray camelCase or inconsistent verb styles. The naming is predictable: list_X for discovery, get_X for single reads, create_/delete_/rename_/attach_/etach_ for lifecycle actions, and set_/ share_/ call_ for specific operations.

Tool Count4/5

At 16 tools the server is slightly over the ideal 3-15 range, but each tool addresses a distinct part of the site-publishing and connector-attachment workflow. None feel redundant, and the set remains navigable despite being a bit dense.

Completeness4/5

The site lifecycle is essentially complete: publish, read, list, rename, set access, share, and delete, with updates supported through republishing. The connector lifecycle covers discovery, creation, attachment, listing, calling, and detach, but there is no connector update/delete or share-revocation tool, which are minor gaps agents can work around.

Resources