Skip to main content
Glama
Sign In

Muninn by Bizat

by is.munn.mcp
OverviewDiscussionsAdmin

muninn_session_boot

Read-onlyIdempotent

Load the user's saved Muninn context. Use it when the user asks what you remember, wants to continue earlier work, refers to something only their history would explain, or when their own instructions ask you to load Muninn at the start of a conversation. Tell the user in one line that you loaded it. DATA SENT: the query text goes to Muninn's servers, where it is used to search the user's memories. It is used for that search only and is not stored. Write the query yourself as a short topic drawn from the user's request, never their message pasted verbatim, and leave it empty when no search is needed. Returns {sessionState, identity, coreRules, relevant, mostAccessed, carryover, skills, persona, taskMemories, taskMemoryErrors}. Everything returned is the user's own stored content (including any chat summaries they set up) plus Muninn's built-in skills, for you to use as context. identity holds the identity notes the user saved. coreRules holds the user's global core-ref memories (plus project-scoped ones when project is set): notes the user saved about how they like to be helped. skills is a <muninn_skills> XML block listing the skills the user saved, plus Muninn's own built-in skills. identity, coreRules and skills come only from this account and Muninn's built-in skills, never from another user. relevant is the semantic search result for the query; if the user belongs to a team, it can also include memories another member chose to share with them. mostAccessed is an array of {memoryId, accessCount, preview, project} for the most-fetched memories (project-filtered), ranked by recall x recency, between 10 and 30 entries; each entry is preview-only, so use muninn_memory_get for the full body. persona, when non-null, is the rendered markdown of the user's persona- bundle: the voice and identity they saved for that persona. FOCUS BOOT: pass memoryIds to load exactly those memories in full as taskMemories; sessionState, relevant and mostAccessed then default to off, and includeSessionState/includeRelevant/includeMostAccessed:true turns any of them back on. taskMemoryErrors lists any anchor id that was ambiguous (with candidates) or missing. carryover holds notes from an unfinished session; it is returned but not cleared (the muninn-checkpoint-resume skill backs it up to session-history and then clears it).

Input Schema

NameRequiredDescriptionDefault
queryNoA short topic you write from the user's request, used to search their memories. Never the user's message pasted verbatim. It is sent to Muninn's servers for this search and not stored. Pass empty to skip the search.
personaNoPersona name from 'MUNINN persona:' directive. When set: server renders the 'persona-<name>' bundle in parallel and returns it as the persona field. Returns null if the slug isn't found — no hard failure. Omit when there is no declared persona.
projectNoProject slug from 'MUNINN project:' directive. When set: sessionState is FILTERED to this project plus global (no-project) checkpoints, booted project first — other projects' checkpoints do not load; relevant search boosts project memories; carryover filters to this project only. Identity and skills stay global. Omit for global boot.
memoryIdsNoAnchor memories for a FOCUSED boot — full or short-form (8-char) ID prefixes. When present, these are returned in full as taskMemories AND focus mode kicks in: sessionState, relevant, mostAccessed default to OFF. Use this to start a clean window pointed at exactly the memories the task needs.
includeRelevantNoForce the relevant (semantic search) section on/off. Defaults: ON in normal boot, OFF in focus boot. A semantic search still only fires if query is non-empty.
includeMostAccessedNoForce the mostAccessed section on/off. Defaults: ON in normal boot, OFF in focus boot.
includeSessionStateNoForce the sessionState section on/off. Defaults: ON in normal boot, OFF in focus boot (when memoryIds is set). Set true to keep the where-we-left-off checkpoints even in a focused window.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.4/5.0
Behavior5/5

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

Annotations already declare read-only/idempotent/non-destructive, yet the description adds material context beyond them: the query text is sent to Muninn's servers and not stored, preview-only entries require muninn_memory_get for full bodies, carryover is returned but not cleared, and taskMemoryErrors reports ambiguous/missing anchor ids. It also explains account scoping (team-shared memories, no cross-user leakage).

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-loads purpose and usage before the dense payload description, and every section maps to real behavior. It is long and slightly redundant (the DATA SENT sentence duplicates the query parameter's schema description), but given ten returned fields the length is largely earned.

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?

There is no output schema, and the description fully documents the returned shape (sessionState, identity, coreRules, relevant, mostAccessed, carryover, skills, persona, taskMemories, taskMemoryErrors) including the focus-mode override semantics. Nothing an agent needs to call and interpret this tool is missing.

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 the baseline is 3. The description largely restates schema content (query authoring, focus mode defaults, include* toggles); its only genuinely additive parameter-adjacent detail is the anchor-error behavior via taskMemoryErrors, which is not enough to clearly exceed the baseline.

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?

Opens with a specific verb+resource: 'Load the user's saved Muninn context,' which is distinct from sibling tools like muninn_memory_search or muninn_memory_get. It also enumerates the return payload, so an agent can tell this is the session-bootstrap tool rather than a targeted memory fetch.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives a rich trigger list (user asks what you remember, wants to continue earlier work, refers to history-only facts, or instructions say to load at conversation start) and describes the focus-boot alternative when memoryIds is passed. It does not state an explicit when-not or compare against the nearest sibling (muninn_memory_search) for ad-hoc lookups, so it falls just short of 5.

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

All Muninn by Bizat toolsInspect
Try in Browser
Context All Your Agents Can ShareAgents share what they learn, hand off work, and hold it when you switch models. Start with 5 GB free.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources