Skip to main content
Glama

Valet

by io.github.valetdotdev

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 becomes part of its URL, 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 the last segment of its URL, https://<org>.valet.run/<name>. 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.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed1 schema field changed
    • changedInput schema / properties / name / description
      Previous value: -"The 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."New value: +"The site's name, which becomes the last segment of its URL, https://<org>.valet.run/<name>. Omit to have one generated. Naming a site that already exists republishes it. Requires a connected Valet account."
  2. Changed5 schema fields changed
    • changedInput schema / properties / description / description
      Previous value: -"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."New value: +"Required. 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."
    • changedInput schema / properties / files / description
      Previous value: -"The site's files. One file named index.html is the minimum; add more for stylesheets, scripts, or further pages."New value: +"Required. The site's files. One file named index.html is the minimum; add more for stylesheets, scripts, or further pages."
    • changedInput schema / properties / files / items / properties / content / description
      Previous value: -"The file's complete text content."New value: +"Required. The file's complete text content."
    • changedInput schema / properties / files / items / properties / path / description
      Previous value: -"Path within the site, relative and with no leading slash: index.html, styles/main.css. It may not contain '..'."New value: +"Required. Path within the site, relative and with no leading slash: index.html, styles/main.css. It may not contain '..'."
    • changedInput schema / properties / title / description
      Previous value: -"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."New value: +"Required. 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."
  3. Changed1 schema field changed
    • addedInput schema / properties / anonymous
      Added value: +{
+  "description": "Set 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.",
+  "type": "boolean"
+}
  4. Changed3 schema fields changed
    • addedInput schema / properties / description
      Added value: +{
+  "description": "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.",
+  "maxLength": 1024,
+  "minLength": 1,
+  "type": "string"
+}
    • addedInput schema / properties / title
      Added value: +{
+  "description": "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.",
+  "maxLength": 1024,
+  "minLength": 1,
+  "type": "string"
+}
    • changedInput schema / required
      Previous value: -[
-  "files"
-]New value: +[
+  "files",
+  "title",
+  "description"
+]
  5. First observed

TDQS

A4.9/5.0
Behavior5/5

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

Annotations declare destructiveHint=true, and the description explains the underlying destructive/overwriting behavior: naming an existing site republishes it, and anonymous sites may be removed after 36 hours. It also reveals the default account-connected permanent private behavior, the claim URL, and the site_token update mechanism, all beyond what the annotations alone provide.

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 front-loaded with purpose and usage, and the structure is logical: purpose, usage, build guidance, required fields, content constraints, and publishing semantics. It is longer than strictly necessary due to the detailed design-system paragraph, but most of that content earns its place by steering artifact behavior before publishing.

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?

Given the tool has 8 parameters, no output schema, and destructive annotations, the description covers the critical context: required fields, authentication and account behavior, anonymity and lifetime, URL naming, content format limitations, republishing semantics, and the returned claim URL/site_token. An agent has enough information to invoke it correctly and avoid common mistakes.

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?

Schema coverage is 100%, so the baseline is 3, but the description significantly expands meaning for key parameters. It explains why title and description are required and how they affect the URL and listing, clarifies that anonymous:true should only be set on explicit user request, and explains how site_token updates an existing site instead of creating a duplicate.

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, resource, and delivery mechanism: 'Publish files as a live website on the public internet, served over HTTPS.' It also lists concrete artifact types and explicitly carves out binary assets for the Valet CLI, so an agent can distinguish this publishing tool from the connector and site-management siblings.

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?

The description gives explicit when-to-use guidance: use when a report, essay, dashboard, or similar static artifact reads better at a live URL. It also gives key exclusions and alternatives: binary assets should go through the Valet CLI, and get_design_system should be consulted before building an artifact. This is strong usage guidance.

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

All Valet toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.4/5.0
Disambiguation5/5

Every tool targets a distinct resource and action. The three list_* connector tools are clearly separated by scope (catalog vs attachable vs attached), and the site management tools are unambiguous.

Naming Consistency5/5

All tool names follow a uniform verb_noun snake_case pattern. Each name directly states the action and object, with no mixed conventions or vague verbs.

Tool Count4/5

16 tools is slightly above the typical well-scoped range, but the set covers two clear domains—site publishing and connector management—and each tool has a distinct role. The count is justified, if a bit heavy.

Completeness4/5

Site lifecycle is well covered: publish, list, get, rename, delete, access, and share. The connector lifecycle covers create, attach, detach, and call, but lacks delete/update connector operations, which are a minor gap.

Resources