Skip to main content
Glama

Publish a site

artifact_site_publish

Publish AI-generated pages, reports, charts, or prototypes to Artifact Site and receive a shareable link. Provide inline HTML, a file tree, or a completed upload.

Instructions

Save a new AI-generated page, report, chart, prototype or document to the remote Artifact Site library and get its address. Use for 'publish this report' or 'give this page a link'. Supply inline HTML, a UTF-8/base64 file tree, or a completed upload_id. For requests over 2 MiB, use upload_start and upload_write first. Creates a PUBLIC share by default; use share:false for unshared work. To change an existing artifact at the same URL, use update or edit instead. Returns the created artifact and share result; if sharing fails, retry share rather than publishing again.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
htmlNoComplete HTML document; exclusive with files/upload_id.
filesNoComplete relative file tree with UTF-8 or base64 contents; exclusive with html/upload_id.
shareNoShare policy. Defaults to public; false creates no share link.public
titleNoDisplay title; does not change the URL.
officialNoDesignate the uploaded version as the only official version; replaces the old designation without deleting contents.
tenant_idNoDestination tenant for creation; defaults to the account tenant.
upload_idNoCompleted upload ID from upload_start; supply instead of html/files after all files have final:true.
share_tokenNoToken from a user-provided share URL; carries only that share permission.
operation_keyNoPersist a unique key before this write. Reuse exactly the same key and arguments after errors; recover results for seven days using operation_status.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.8/5.0
Behavior5/5

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

Beyond the minimal annotations (readOnly=false, idempotent=false, destructive=false), the description discloses default behavior (public share by default), recovery via operation_key, large-file handling, and the non-idempotent nature of publishing. It gives actionable behavioral guidance without contradicting annotations.

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 longer than average but every sentence adds value, starting with the core purpose first and then covering usage, constraints, and behaviors. It is logically ordered and free of fluff, though slightly dense for a quick scan.

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's complexity (9 params, multiple input modes, sharing behavior, error recovery), the description covers all essential aspects: what it returns, when to use alternatives, size limits, and error-retry guidance. No obvious gaps for an agent to call it correctly.

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 baseline is 3. The description adds meaning by explaining the three input modes (html, files, upload_id), the share default, and the operation_key recovery role, which goes beyond the schema's individual descriptions.

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 tool saves a new artifact to the remote library and returns its address, distinguishing it from update/edit by explicitly saying to use those for changing existing artifacts. It also lists concrete use case phrases like 'publish this report'.

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 provides explicit usage triggers ('Use for publish this report'), a size-based alternative (upload_start/upload_write for >2 MiB), and a clear exclusion (use update/edit for existing artifacts). It also instructs to retry share instead of publishing again on share failure.

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