mnema

Official

by mnema-work

Overview Schema Source Related Servers Discussions Admin

TypeScript

Local

Focus: what I am touching now

focus

Read-onlyIdempotent

Show this session’s open work runs on this machine to see what is in flight right now; read-only and derived from the record, it writes nothing.

Instructions

Show the open runs of THIS session’s actor: the work in flight right now. Use it to answer "what am I in the middle of". Read-only: it derives from the chain and writes nothing. Reports only this machine’s own open runs (the actor is the session, never a supplied value). 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": "focus"
  }
}

Input Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 9, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Annotations already cover the safety profile, and the description adds real substance on top: it derives from the chain and writes nothing, it sees only this machine's runs, `thisSession` cannot distinguish a live session from an abandoned one, and a missing `idleSeconds` means nothing was recorded. It even names the close path (`mnema run end <id> --which <agent>`), which no annotation conveys.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

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

It is front-loaded and every clause carries information, but the middle is a run-on wall of field semantics (thisSession, ageSeconds, idleSeconds, wrote) that a reader must parse twice. The `wrote` paragraph also describes properties of ended runs the tool never returns, so some of the density is scope creep rather than compression.

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 no parameters, the description carries the return shape and does so well: `thisSession`, `ageSeconds`, conditional `idleSeconds`, and `wrote` counts with their ordering. It stops short of covering run identity fields or the ordering/limit of the returned run list, which an agent inspecting the output will need.

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 parameters, so the baseline is 4; the description correctly forecloses a parameter that an agent might expect by stating the actor "is the session, never a supplied value." The field-level meaning it supplies applies to the response rather than inputs, since there are none to disambiguate.

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 with scope nailed down: "Show the open runs of THIS session's actor: the work in flight right now." It also pre-empts the natural confusion with the audit siblings by noting where the underlying facts come from and that the actor is never a supplied value.

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 concrete selection test: "Use it to answer 'what am I in the middle of'", and redirects to `audit_timeline` for the underlying facts, which implicitly separates this view from the audits. It lacks an explicit when-not (e.g. do not use it to check whether another agent is alive), though it gestures at that with "no proof of a live session".

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