Skip to main content
Glama

muninn_artifact_add

Store a text-based artifact you generated — markdown, plain text, csv, json, code, a mermaid diagram, svg, or an HTML page — so it outlives this session and can be retrieved by any model or from the web app. Use this for OUTPUT you produced (a document, a table, a diagram, a page), not for notes or facts about the user; those are muninn_memory_add. The source is stored in full, never a link. Artifacts are deliberately excluded from semantic search, so give a clear title and tags — that is how they are found again. Returns {success, memoryId, format, url, length, connect}. For html/svg: runs in a sandboxed iframe on a separate origin. LINKS: write a plain absolute — a Muninn page opens in the same tab, anything else in a new tab; no target attribute needed. READING ANOTHER ARTIFACT: fetch its absolute /raw url. READING AN OUTSIDE API: the sandbox blocks fetch() to any non-Muninn host unless the artifact declares it in connect (bare hostnames, e.g. ["api.open-meteo.com"]) — readers are shown the list, and the host must answer Access-Control-Allow-Origin: *. Full rules: muninn_help, section "Authoring artifacts". TO EDIT ONE LATER there is no muninn_artifact_update — an artifact's artifactId IS its memoryId, so redraft it with muninn_memory_update (whole body), muninn_memory_anchor_replace (one span) or muninn_memory_append. Editing replaces in place, and a published artifact's public link refreshes automatically. The supported formats and the mime value for each are listed in the mime parameter below and in muninn_help. HANDLES: an account can hold several handles (e.g. a personal one and a company one), each a separate public address; an artifact lives under exactly one, and its named page only ever answers there. Pass handle only when the user says which one; omit it and the artifact goes under their default (oldest) handle. Move it later with muninn_artifact_move.

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": {
      "source": "<source>",
      "format": "<format>"
    },
    "name": "muninn_artifact_add"
  }
}

Input Schema

NameRequiredDescriptionDefault
mimeNoThe artifact's media type, from the closed list. Sets the file extension on download and nothing else — a mermaid source is text/vnd.mermaid so it exports as .mmd, not .txt. Defaults to text/html.
tagsNoTags, same as muninn_memory_add. The main way an artifact is found later.
titleNoDisplay name for the artifact, e.g. 'BUI org chart'. Strongly recommended: artifacts are not semantically searchable, so the title carries the findability.
formatYesWhat kind of source this is — selects the renderer. md, txt, csv, json, code, mermaid, svg, or html.
handleNoWhich of the user's handles this artifact lives under, e.g. 'chai' — only if the user named one. Must be a handle this account holds; any other is refused and nothing is saved. Omit for the default (oldest) handle. Does NOT publish anything.
sourceYesThe artifact's full source text, stored verbatim.
connectNohtml/svg only: outside hosts this artifact fetches data from at runtime, as bare lowercase hostnames — ["api.open-meteo.com"]. No scheme, path, port, wildcard or IP; at most 8; Muninn's own hosts are already reachable and are refused here. Declare exactly what the source calls: the sandbox blocks fetch() to any host not listed, and every page that shows the artifact names this list to the reader. Not needed for <script src>, images, fonts or styles from a CDN. Change it later with muninn_artifact_connect.
projectNoProject slug to scope this artifact. Omit for user-global.
sourceModelNoWhich model produced this, for provenance, e.g. 'claude-opus-5'.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only state readOnly=false, destructive=false, non-idempotent, openWorld=false; the description adds a great deal beyond that: source stored in full never a link, artifacts deliberately excluded from semantic search, the return shape {success, memoryId, format, url, length, connect}, sandboxed iframe on a separate origin, the connect/CORS gating rule for fetch(), and that editing replaces in place with the public link refreshing automatically.

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?

Front-loaded with purpose and the sibling contrast, and the sectioned structure (LINKS / READING / EDITING / HANDLES) makes it scannable. It is long, however, and partially duplicates schema content — the mime enumeration and connect constraints are restated from parameter descriptions — which costs a point.

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?

For a 9-parameter write tool with no output schema, the description covers the return shape, the edit lifecycle, handle scoping, sandbox/link behavior, and routes to muninn_help for full rules. Nothing an agent needs in order to invoke it correctly is missing.

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% and the schema descriptions are already detailed, so the baseline is 3; the description nonetheless adds the rationale that makes parameter choices meaningful ('artifacts are deliberately excluded from semantic search, so give a clear title and tags — that is how they are found again') and explains the default-handle behavior in prose. It does not re-list per-parameter syntax beyond the closed format set, which is already in the schema.

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?

States a specific verb+resource ('Store a text-based artifact you generated') and enumerates concrete artifact types (markdown, csv, json, mermaid, svg, html). It explicitly draws the boundary against the nearest sibling: 'not for notes or facts about the user; those are muninn_memory_add.'

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?

Gives explicit when-to-use ('OUTPUT you produced'), explicit when-not ('not for notes or facts about the user'), and names alternatives for both the wrong case (muninn_memory_add) and the deferred case (muninn_memory_update / muninn_memory_anchor_replace / muninn_memory_append since there is no update tool). Handle selection is also conditioned: 'Pass handle only when the user says which one.'

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.

Resources