Muninn (munn.is)

muninn_artifact_password

DestructiveIdempotent

Set, change or remove the password a reader must type to open a published artifact — use when the user says password protect this, put a password on that link, lock this page, change the password, or remove the password. The artifact must already be published (muninn_artifact_publish); the link itself does not change, so anything already shared keeps working and now asks for the password. ⚠️ The password is stored one-way and can NEVER be read back — not by the user, not by support, not by this tool. Say the exact password back to the user when you set it, because this is the only time it is visible; a forgotten one is replaced, not recovered. Pass password: null to remove it and make the link open freely again. Giving two artifacts the SAME password puts them behind one lock, so unlocking either opens both — that is how a locked page can embed another locked page. A different password keeps them separate. This is a gate on the page, not encryption of the artifact. ⚠️ If one artifact fetches another as data, give BOTH the same password (one lock) or leave the data one open — two different passwords means the fetch gets 401. Returns {success, artifactId, hasPassword}.

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

Input Schema

Name	Required	Description	Default
`password`	Yes	The password readers must type, 4-128 characters. Use exactly what the user asked for — never invent one, and never change one without being asked. Pass null to remove the password entirely.
`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?

Beyond annotations, it discloses critical behavior: the password is stored one-way and can never be read back, the exact password must be said back to the user because it is only visible once, and forgotten passwords are replaced rather than recovered. It also explains cross-artifact password sharing, the 401 failure mode for data fetches, and clarifies the password is a page gate rather than artifact encryption.

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?

The description is front-loaded with the core action and trigger phrases, and every major warning is relevant. It is somewhat long and repeats the critical 'cannot read back / say it back' point, but the repetition is purposeful for a destructive, irreversible password operation.

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?

Although there is no output schema, the description supplies the return shape {success, artifactId, hasPassword}. It also covers prerequisites, destructive reversibility constraints, password sharing interactions, and fetch failure behavior, which is complete enough for correct invocation.

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 description coverage is 100%, so the schema already documents password length, null semantics, and artifactId. The description adds operational meaning beyond the schema by explaining that null removes the password, that identical passwords across artifacts create one shared lock, and that different passwords can cause 401 on cross-artifact data fetches.

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?

The description opens with a specific verb+resource: set/change/remove the password a reader must type to open a published artifact. It distinguishes this from publish behavior by noting the artifact must already be published and by explicitly naming muninn_artifact_publish as the prerequisite.

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?

It gives explicit user phrases that should trigger the tool (password protect this, put a password on that link, lock this page, change/remove password) and states the prerequisite that the artifact must already be published. It also explicitly says to pass password: null to remove the password and make the link open freely again.

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?