Muninn (munn.is)

muninn_artifact_move

DestructiveIdempotent

Move an artifact to another of the user's handles — use when the user says move this to my company handle, put that under chai, this belongs on the other address, or file it under a different handle. An account can hold several handles, each a separate public address, and an artifact lives under exactly one. The target must be a handle this account holds; any other is refused and nothing changes. ⚠️ If the artifact has a named page, its OLD named address (old-handle.munn.is/name) stops working immediately and does NOT redirect; the page answers at the new handle instead. Tell the user, since links they shared on the old address will break. The munn.is/a/ link is unaffected. If the target handle already has a page with that name the move is refused; pass name to move it under a different name (a new name needs the Paid plan). An artifact under a suspended handle cannot be moved. Does not publish or unpublish anything. Returns {success, artifactId, handle, moved, slug, namedUrl, durableUrl, previousNamedUrl}.

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": {
      "artifactId": "<artifactId>",
      "handle": "<handle>"
    },
    "name": "muninn_artifact_move"
  }
}

Input Schema

Name	Required	Description
`name`	No	Only for a named page: the name to use under the new handle, when its current name is already taken there or the user wants a different one. Omit to keep the current name.
`handle`	Yes	The handle to move it under, e.g. 'chai'. Must be one this account holds — muninn_artifact_list returns the list.
`artifactId`	Yes	The artifact's memory ID (full UUID or a unique prefix).

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 22, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Goes well beyond the destructive/idempotent annotations by naming exactly what breaks: the old named address stops working immediately with no redirect, shared links break, while the token link is unaffected. It also discloses refusal semantics (target name collision, non-owned handle = nothing changes) and the full return shape.

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 trigger phrases, then the critical breaking-change warning is visually flagged so it is not lost. The opening sentence's four paraphrased user quotes are slightly redundant, but the overall length is earned by the number of refusal and side-effect rules.

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 destructive, open-world mutation with no output schema, the description covers prerequisites (owned handle, not suspended), failure modes, irreversible side effects, and even enumerates the returned fields — nothing an agent needs to call it safely 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%, so the baseline is 3, but the description adds meaning the schema does not: a new `name` requires the Paid plan, and an omitted `name` silently keeps the current name while a collision causes refusal. The `handle` constraint (must be owned, list via muninn_artifact_list) is largely mirrored from 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 and resource ('Move an artifact to another of the user's handles') and pins the domain model ('an artifact lives under exactly one handle'), which cleanly separates it from siblings like muninn_artifact_name, muninn_artifact_publish, or muninn_bundle_edge_move.

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 concrete user phrasings that should trigger it ('move this to my company handle', 'file it under a different handle') and explicit when-not conditions: the target must be a held handle, suspended-handle artifacts cannot move, and it 'Does not publish or unpublish anything' — routing the agent away from publish/unpublish siblings.

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

All Muninn (munn.is) tools Inspect

Try in Browser

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?