Skip to main content
Glama

Resume: where I left off

resume
Read-onlyIdempotent

Show where the current session’s actor left off by reporting their most recent run and current focus, helping you answer “where was I” at the start of a session.

Instructions

Show where THIS session’s actor left off: their most recent run (open OR already ended) plus their current focus. Use it at the start of a session to answer "where was I": even a run that ended carries the goal that reminds you. When this session has a run of its own here, that is the one reported. Read-only: it derives from the chain and writes nothing. 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": "resume"
  }
}

Input Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Beyond the read-only and idempotent annotations, it discloses chain-derived behavior, connection-specific `thisSession` semantics, the inability to distinguish live from abandoned sessions, clock comparisons, recording-count rules, and how to close an open run. The warning that an open run does not prove a live session is especially valuable, and nothing contradicts the annotations.

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?

The purpose and primary use case are front-loaded, and nearly all subsequent details are operationally relevant. However, the long single paragraph, semicolon-heavy clauses, and ALL-CAPS emphasis make the output semantics unnecessarily difficult to scan; bullets would convey the same information more clearly.

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, the description usefully supplies run-selection precedence, important return-field meanings, ordering and empty-value rules for `wrote`, and liveness caveats. It does not state what happens when no run or current focus exists, a common first-session case, so it is thorough but not fully complete.

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 there are no input semantics requiring clarification and the baseline score is 4. Its explanations of `thisSession`, `ageSeconds`, `idleSeconds`, and `wrote` are useful output documentation rather than parameter guidance.

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 opening sentence gives a specific action and scope: show the current session actor's most recent open or ended run plus their current focus. The later pointer to `audit_timeline` for underlying facts further distinguishes this session-resumption view from the audit sibling.

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 explicitly says to use the tool at session start to answer "where was I" and explains why an ended run remains useful. It also provides run-selection precedence and names `audit_timeline` as the alternative for the underlying facts.

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