ArtifactSmith

publish

Store a finished page as a versioned artifact and get an ID to track processing status. Supports HTML, Markdown, PDF, DOCX, XLSX with built-in safety scans.

Instructions

Store a page you have already finished. Use this when you already have the finished page. No model call. Returns artifact_id, version, and job_id immediately. Then call status(job_id, wait=90). When the job is done, status and inspect list safety_changes for each safety edit that changed the page. HTML publish does not turn bare URLs into links. The document title is stored as given and escaped in the page. note is optional. Inspect shows a non-empty note beside "Published a finished page." It is not the text a later edit sends to the model. A secret, private link, or over-long note is rejected before a row exists.

Want a styled page? Pass Markdown and it is styled automatically. Omit format when you pass
markdown and no html. style is house, bold, editorial, playful, terminal, or swiss (default house)
and is applied when the page is opened. The stored file stays Markdown. You can still pass
format=markdown. On a new artifact, if you also pass html, html is the page unless you set format.
Raw HTML is shown
exactly as given, with no ArtifactSmith styling. If that HTML has little or no CSS, the result
includes warning. Pass format for pdf, docx, or xlsx.

html is the complete HTML document when format is html. markdown is the finished Markdown when
format is markdown, pdf, docx, or xlsx. You may pass the other field as well: it is checked for
secrets and private links and is not rendered. PDF, DOCX, and XLSX do not use the HTML style sheet.

New artifact: pass display_name or slug (same rules as create). New version of an existing artifact:
pass artifact_id and base_version (the latest done version). Omit format on an html or markdown
artifact and markdown with no html is markdown; html with no markdown is html; both fields keep
the artifact's format. A pdf, docx, or xlsx artifact keeps that format when format is omitted and
the new page is markdown. Pass format to choose html, markdown, pdf, docx, or xlsx. Pass display_name
to rename the card when this version finishes. Omit display_name and a changed page title (the HTML
title, or the first Markdown heading) becomes the card title. The artifact id and slug stay the same.
Older versions keep the format they were published with.

The page runs the same safety pipeline as model output: size caps, secret scan, private-link checks,
the sanitizer, the renderer for format (including PDF, DOCX, and XLSX), and the final sweep. A rejected
page ends as failed, and error names the check that failed. publish does not create a share link.
It counts toward the per-token build quota and requires the publish permission.

summary and assumptions are optional card fields. Each is rejected when the call arrives if it is
longer than the metadata cap (the same 'metadata exceeds N characters' error the job would report).
They are also scanned like model output. On markdown, style changes the opened page. On HTML, style
is recorded and the submitted page is not restyled.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`html`	No
`note`	No
`slug`	No
`style`	No
`format`	No
`summary`	No
`markdown`	No
`workspace`	No
`artifact_id`	No
`assumptions`	No
`base_version`	No
`display_name`	No
`idempotency_key`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 17, 2026

TDQS

A4.4/5.0

Behavior5/5

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

With no annotations, the description carries the full burden and does so thoroughly: the complete safety pipeline (size caps, secret scan, private-link checks, sanitizer, renderer, final sweep), rejected pages ending as failed with the failing check in error, quota and permission requirements, that no share link is created, and the note/summary/assumptions rejection and scanning behavior.

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 purpose and return values are correctly front-loaded, but the opening two sentences are redundant and the middle is a dense, unevenly chunked run of paragraph fragments ('Want a styled page?', format-omission rules, style-on-HTML rules) that takes real effort to parse. Length is partly justified by 13 parameters, but the organization costs readability.

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 13-parameter, annotation-free mutation tool this is close to complete: format/style interaction rules, new-vs-new-version requirements, permission/quota/failure behavior, and the follow-up status+inspect loop are all present. The output schema covers returns, and the remaining gap is the undocumented workspace and idempotency_key parameters.

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 0%, so the description must compensate, and it largely does: format values (html/markdown/pdf/docx/xlsx), style enum (house, bold, editorial, playful, terminal, swiss), html vs markdown field roles, artifact_id/base_version, display_name and slug. It leaves `workspace` and `idempotency_key` entirely unexplained, which matters for a publish call that counts against a quota.

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?

It states a specific verb and resource ('Store a page') and immediately scopes it ('you have already finished', 'No model call'), which cleanly separates it from the model-backed create/edit path. It also references `create` for slug/display_name rules, confirming which sibling it is parallel to rather than duplicating.

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?

Usage context is strong: when to use it (finished page in hand), the immediate follow-up workflow (call status(job_id, wait=90), then inspect safety_changes), and how to pick format/style. It never states an explicit exclusion or names the alternative to reach for when the page is not yet finished, so route selection for the main purpose is only implied.

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

Deploy Server