Muninn (munn.is)

muninn_onboard

Read-onlyIdempotent

Set up a brand-new Muninn account with the user. Call this when the user asks to set up Muninn, says they have just signed up, says their memory is empty, or when muninn_session_boot comes back with nothing in it. Returns {memoryCount, verified, hasIdentity, firstRunScript, starterInstruction}. memoryCount is what the user's Memory Map shows, so 0 means an empty map. firstRunScript is a three-question interview to run with the user, one question at a time, saving each answer with muninn_memory_add; do not paste it back at them. starterInstruction is an optional standing instruction, written for the assistant in use, that the user can paste into their own assistant settings if they want Muninn loaded at the start of every conversation. Offer it only after at least one memory is saved, or if they ask why their assistant does not use Muninn on its own, and tell them what it does before they paste it. verified:false means the account is read-only until the user clicks the link in their "Verify your Muninn account" email, so every save will be refused; say that plainly instead of running the interview. hasIdentity:true means an identity memory already exists, so do not re-run the interview unprompted.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "muninn_onboard"
  }
}

Input Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 22, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Goes well beyond the annotations: it discloses the read-only failure mode (verified:false blocks every save via muninn_memory_add), the gating for starterInstruction, and the effect of hasIdentity. The only friction is that 'set up a brand-new account' implies mutation while the annotations declare readOnlyHint=true and the actual writes are delegated elsewhere — the description never explicitly reconciles that, though the mechanism becomes inferable.

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, then the return shape, then per-field handling rules — a sensible order with little wasted text. It is dense and run-on in the middle (return-field prose reads as one long sentence), so structure could be tightened, but every clause carries operational information.

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?

With no output schema, the description fully carries the return-value burden, explaining each of the five fields and the correct agent action for the two error-ish states (unverified account, existing identity). Nothing an agent needs to run the onboarding conversation 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?

Zero input parameters, so the schema baseline is 4. The description instead spends its detail on the return shape (memoryCount, verified, hasIdentity, firstRunScript, starterInstruction), which is the right use of space given no output schema exists.

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 ('Set up a brand-new Muninn account') and immediately distinguishes itself from sibling muninn_session_boot by naming the exact condition where boot delegates here. An agent can pick between onboarding flow and normal session boot without opening either 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?

Enumerates concrete invocation triggers (user asks to set up Muninn, just signed up, memory is empty, session_boot returns nothing) and explicit when-not conditions: don't run the interview if verified:false or hasIdentity:true. It also names the alternative tool (muninn_session_boot) and the required follow-on tool (muninn_memory_add).

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?