Skip to main content
Glama

muninn_artifact_name

DestructiveIdempotent

Give a published artifact a readable address under the handle it lives in, rename it, or remove the name — use when the user says name this page, give it a nicer url, rename that link, change the address, or make the link readable. Turns a long token url into something like chai.munn.is/my-notes, plus a durable twin on muninn.bizat.co that keeps working if the short domain ever changes. The artifact must already be published (muninn_artifact_publish); naming does not publish anything and does not change who can read it. Pass name: null to remove the name — that address stops working immediately, while the token link keeps working. Names are unique per handle, so the same name can exist under two of the user's handles. To change WHICH handle the page is under, use muninn_artifact_move. Plan: giving a page a new or changed name is Paid; removing a name, re-applying the same name, and already-named pages continuing to serve work on every plan, as does the munn.is/a/ link. Returns {success, artifactId, handle, slug, namedUrl, durableUrl}.

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>",
      "name": "<name>"
    },
    "name": "muninn_artifact_name"
  }
}

Input Schema

NameRequiredDescriptionDefault
nameYesThe name, e.g. 'my-notes' — letters, numbers and hyphens, no dots or slashes, unique among the named pages under this artifact's handle. A new or changed name needs the Paid plan. Pass null to remove the current name (free).
artifactIdYesThe artifact's memory ID (full UUID or a unique prefix).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already declare destructiveHint=true and idempotentHint=true, but the description goes well beyond them: naming does not publish and does not change read access, name:null makes the address stop working immediately while the token link survives, names are unique per handle, and a durable twin on muninn.bizat.co is created. Plan behavior (Paid for new/changed names, free for removal/re-apply) is also disclosed. This is exactly the additional context annotations cannot carry.

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 the trigger phrases and the core operation, then layers on constraints, the Plan section, and the return shape. Efficient for its density, though there is minor redundancy between the 'durable twin' sentence and the returned durableUrl field.

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?

No output schema exists, but the description enumerates the return shape ({success, artifactId, handle, slug, namedUrl, durableUrl}) and covers preconditions, plan constraints, removal behavior, and the sibling tool for handle changes. An agent has everything needed to call this correctly.

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%, so both parameters are already documented, including the null-removal semantics and plan requirement. The description's extra notes (null stops the address immediately, uniqueness is per-handle, the returned slug/namedUrl) add some value but largely restate or extend the schema. Baseline 3 is appropriate when the schema does the heavy lifting.

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: give a published artifact a readable address under its handle, rename it, or remove the name. It explicitly distinguishes itself from muninn_artifact_move ('To change WHICH handle the page is under, use muninn_artifact_move') and muninn_artifact_publish ('The artifact must already be published'), so an agent can route correctly without opening any schema.

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 trigger phrases ('name this page', 'give it a nicer url', 'rename that link'), names the alternative tool for the adjacent operation, and states the precondition (must already be published) plus the plan gating for each operation. When-to-use and when-not-to-use are both covered.

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