blink artifact

Create artifact

create_artifact

Create a new empty artifact of a given type and return its id, url, rev, files and the authoring skill. Types: "docs", "slides", "dashboard", "design", "design-system", "whiteboard" (an Excalidraw canvas; takes no system) and "tldraw" (a tldraw canvas; takes no system). For slides, design and dashboard your default design system is installed automatically (see get_skill system.default); pass system: "" to install another one or system: "none" for none. The result then carries system, or systemsAvailable when you have systems but no default, or systemWarning when the default could not be used. Counts toward the same active-artifact quota as publish_html. Call get_skill with the same type for the editing contract.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "type": "<type>",
      "title": "<title>"
    },
    "name": "create_artifact"
  }
}

Input Schema

Name	Required	Description	Default
`type`	Yes
`title`	Yes
`system`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 29, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already cover the safety profile (readOnlyHint=false, destructiveHint=false), and the description adds real context beyond them: automatic design-system installation for slides/design/dashboard, the systemsAvailable/systemWarning result branches, and quota consumption shared with publish_html. It stops short of saying whether an artifact can be discarded or whether creation is reversible, though delete_artifact exists as a sibling.

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?

Purpose and return values come first, then type semantics, then design-system behavior—a sensible priority order. The long parenthetical sentences and duplicated "takes no system" phrasing add bulk without much extra information.

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?

There is no output schema, and the description compensates by naming the returned fields and the conditional result variants (system, systemsAvailable, systemWarning). It also defers editing behavior to get_skill, which is the right boundary. Minor omissions are lifecycle/reversibility details for a mutating tool.

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 carries the full burden and largely succeeds: the type values are enumerated with per-type caveats (whiteboard/tldraw "take no system"), and system is explained with both the id form and the special "none" value plus default-install behavior. Only title is left unaddressed, which is self-evident.

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?

Opens with a specific verb + resource ("Create a new empty artifact") and immediately states the return payload (id, url, rev, files, authoring skill). It enumerates all valid types including the two canvas types, so an agent can distinguish this from publish_html and get_artifact without opening the schema.

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?

Routing guidance is present but indirect: it names publish_html only to warn about shared quota, and points to get_skill "with the same type for the editing contract." It does not explicitly state when to create an empty artifact versus publishing HTML content, so the create-vs-publish choice is left partly to inference.

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

All blink artifact tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?