Skip to main content
Glama

artifacts_update

Republish an existing artifact with new HTML. The slug and URL stay the SAME; a new version is stored (older versions are retained up to a cap). Use this to refresh a shared dashboard — anyone with the link sees the new snapshot.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
htmlNoThe new full self-contained HTML page (same contract as artifacts.create). Omit when passing analytics_card_ids.
labelNoOptional human name for this version (e.g. 'Q3 final').
templateNoOptional: attach/replace the data-driven template (HTML with {{placeholder}} tokens) on this existing artifact, so later artifacts.refresh(data={...}) can re-render it server-side. Pass the html rendered from this template. Omit to leave the template unchanged.
artifact_idYesThe artifact to republish.
in_workspaceNoRun this one call in this workspace id instead of the session's. Nothing is stored; other sessions are not affected.
analytics_card_idsNoIds of saved analytics dashboard cards to make this artifact's source, keeping its link: the cards are attached and the page is rebuilt from them now; afterwards artifacts.refresh(artifact_id) alone rebuilds it again. Mutually exclusive with html.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • addedInput schema / properties / analytics_card_ids
      Added value: +{
      +  "description": "Ids of saved analytics dashboard cards to make this artifact's source, keeping its link: the cards are attached and the page is rebuilt from them now; afterwards artifacts.refresh(artifact_id) alone rebuilds it again. Mutually exclusive with html.",
      +  "items": {
      +    "type": "string"
      +  },
      +  "type": "array"
      +}
    • changedInput schema / properties / html / description
      Previous value: -"The new full self-contained HTML page (same contract as artifacts.create)."New value: +"The new full self-contained HTML page (same contract as artifacts.create). Omit when passing analytics_card_ids."
    • changedInput schema / required
      Previous value: -[
      -  "artifact_id",
      -  "html"
      -]New value: +[
      +  "artifact_id"
      +]
  2. Changed1 schema field changed
    • addedInput schema / properties / in_workspace
      Added value: +{
      +  "description": "Run this one call in this workspace id instead of the session's. Nothing is stored; other sessions are not affected.",
      +  "type": "integer"
      +}
  3. First observed

TDQS

A4/5.0
Behavior5/5

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

Goes well beyond the annotations by disclosing that the slug/URL remain stable, a new version is stored, older versions are retained up to a cap, and anyone with the link immediately sees the new snapshot. These versioning and sharing semantics are exactly the context an agent needs and are consistent with idempotentHint=false.

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

Conciseness5/5

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

Three tight sentences: purpose first, then the critical versioning constraint (URL stays the same), then a use case. No filler and the most decision-relevant fact is front-loaded.

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 mutation tool with full annotation coverage and a detailed schema, the description covers behavior, side effects, and a use case well; no output schema exists so return values need not be explained. It stops short of mentioning permission/auth requirements, which is the only notable gap.

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% and the schema is unusually rich (mutual exclusivity of html vs analytics_card_ids, template/refresh interaction, workspace scoping). The description only echoes 'new HTML' and adds no syntax or format detail beyond what the schema already documents, so the baseline 3 applies.

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?

States a specific verb ('Republish') and resource ('an existing artifact') with clear scope, and the HTML/version behavior distinguishes it from artifacts_create. However, it never names the closest siblings (artifacts_create, artifacts_refresh), so the differentiation is behavioral rather than explicit.

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?

'Use this to refresh a shared dashboard' provides a concrete positive use case, implying when the tool applies. There is no when-not guidance or named alternative (e.g., use artifacts_create for a new artifact), so routing between the artifact tools is left to inference.

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.