mnema

Official

by mnema-work

Overview Schema Source Related Servers Discussions Admin

TypeScript

Local

Bootstrap the session

bootstrap

Read-onlyIdempotent

Loads the opening session context so an agent can resume work: where it left off, live tasks and patterns, decisions in force, and items awaiting judgement.

Instructions

The opening context for this session's actor: where they left off, the LIVE work, the patterns, the DECISIONS IN FORCE (settled here and not replaced) and what is AWAITING A JUDGEMENT. Derived from the chain. Every list is NAMES, never bodies: a task as id, title and state, a pattern as id and name, a decision as id, title and its ADR- label. For the rest, by id: next_actions for a task’s moves, skills for a pattern (asking records the consultation), read_record for a decision’s argument and its label. Only a decision IN FORCE is listed: proposed, rejected or superseded is left out. awaitingJudgement is one list of all three; kind says which, state what is owed: proposed the first ruling, reviewed the adoption call, IN_REVIEW the approve-or-send-back. A DONE or CANCELED task is on NEITHER list; ask search (kind task). Three lists are CUT to the freshest; workTotal, decisionsTotal and awaitingJudgementTotal say how many in all, so a total larger than its list means more is not shown, and search reaches past every cut. Every adopted pattern is listed, so it has no total. EVERY LIST HERE IS ABOUT A TASK, A DECISION OR A PATTERN, so empty lists do NOT mean the record is empty: unread names each kind not looked at, with how much, to pass to search; it is ABSENT when there is nothing to declare. Runs: thisSession is true only when THIS connection opened it: false means another session on this machine, live or abandoned, which the record cannot tell apart. An OPEN run carries ageSeconds, and idleSeconds only once it has recorded something, so NO idleSeconds means it recorded nothing; both compare this clock with the writer’s. EVERY run, open or ended, carries wrote: one {kind, count} per kind recorded in it, commonest first, never absent, EMPTY meaning nothing was recorded; the run’s own start and end are not counted, and audit_timeline serves the facts. An open run is no proof of a live session; mnema run end <id> --which <agent> closes one.

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": "bootstrap"
  }
}

Input Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 9, 2026

TDQS

A4/5.0

Behavior5/5

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

Annotations already mark this read-only, idempotent and non-destructive, and the description layers substantial behavior beyond that: three lists are truncated with `*Total` counters, `unread` is ABSENT when nothing is undeclared, `thisSession=false` cannot distinguish a live from an abandoned run, and `idleSeconds` is omitted when a run recorded nothing. The non-obvious semantics of `wrote` (per-kind counts, excludes the run's own start/end, never absent) and the note that an open run is not proof of a live session are exactly the kind of caveats 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.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The content is valuable but the delivery is a wall of ALL-CAPS clauses, backticks and run-on sentences spanning nearly the entire description with no paragraphing or list structure. Key routing information ('ask `search`') is buried mid-stream, and the run/`wrote` material, which is secondary, occupies a large tail. Front-loading exists but readability suffers badly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema and a high-complexity composite response, the description does the heavy lifting well: it defines truncation, totals, the `unread` escape hatch, judgement `kind`/`state` values, and run timing semantics. The main gap is that it never states the top-level field names for the five main lists (work, patterns, decisions, awaiting, unread) beyond prose, so an agent must infer the actual key names.

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?

The tool takes zero parameters, so the baseline is 4 and the description has nothing to compensate for on the input side. It instead spends its effort on output field semantics, which is the right allocation given the empty schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening clause states the resource concretely: 'The opening context for this session's actor' with an enumerated payload (where they left off, LIVE work, patterns, DECISIONS IN FORCE, awaiting judgement). It also distinguishes itself from siblings by delegating depth to `next_actions`, `skills`, `read_record` and `search`, so an agent knows this is a summary/index rather than a detail 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?

It routes clearly to alternatives in specific situations: 'ask `search` (kind `task`)' for closed tasks, '`search` reaches past every cut' for truncated lists, `next_actions` for a task's moves, `skills` for a pattern, `read_record` for a decision's argument. What is missing is an explicit statement of when to call bootstrap itself (presumably at session open), which is left implied by the title 'Bootstrap the session' rather than the description.

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