Skip to main content
Glama
Mnemosyne-OS

Mnemosyne OS

by Mnemosyne-OS
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

mnemosyne_cockpit_update

Update your status card on the user's cockpit to show working, waiting, blocked, or done, so they can see progress and know when you need their attention.

Instructions

Update your own status card on the user's canvas, the cockpit. Call it when you start a task ("working", with a short title and status), when you need the user ("waiting"), when you are stuck ("blocked"), and when you finish ("done"). "waiting" and "blocked" make the card pulse and the taskbar flash. Send "waiting" IN THE SAME TURN as the question you ask the user, right before you stop: the harness only knows to say "waiting" for a permission prompt, and a question asked in the chat is otherwise just the end of a turn — the user never sees that you are waiting for them. Your "waiting" survives the harness saying the turn ended. You declare the state; the app prints it next to the time since your last call, so keep calling at real milestones or the card goes quiet. The answer carries any message the user left on your card. Read it and act on it. Needs the app window open. This is a card, so nothing is stored in memory.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
stateYes"working" = on it; "waiting" = you asked the human something and stopped; "done" = the task is finished; "blocked" = you cannot continue without them; "closed" = this conversation is over (removes the card).
titleNoWhat this conversation is about, in a few words (the card's title). Give it at least once; later calls may omit it.
detailNoUp to 4 short lines under the status (files, a branch, a count). Optional.
statusNoOne line: what you are doing right now, or what you need. 160 characters max.
desktopNoThe desktop this session should put its cards on, by name, exactly as the human wrote it. Send it once when they tell you; the card stays there for the rest of the conversation without you repeating it. The match is exact apart from case, and an unknown or duplicated name is reported back with the names that exist rather than guessed at. Leave it out and the card goes to whichever desktop answers for this project, which is what most sessions want.
sessionNoOnly when the harness publishes no CLAUDE_CODE_SESSION_ID: a stable id for this conversation, reused on every call.
attentionNoAsk for the human's eye even in "working"/"done" (the card pulses, the taskbar flashes). "waiting" and "blocked" ask on their own.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.6.0-infinity
    • addedInput schema / properties / desktop
      Added value: +{
+  "description": "The desktop this session should put its cards on, by name, exactly as the human wrote it. Send it once when they tell you; the card stays there for the rest of the conversation without you repeating it. The match is exact apart from case, and an unknown or duplicated name is reported back with the names that exist rather than guessed at. Leave it out and the card goes to whichever desktop answers for this project, which is what most sessions want.",
+  "type": "string"
+}
  2. First observedv1.10.0

TDQS

A4.6/5.0
Behavior5/5

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

Annotations are minimal (readOnlyHint=false, destructiveHint=false), so the description carries the burden and does so richly: 'waiting'/'blocked' pulse the card and flash the taskbar, 'waiting' survives the harness ending the turn, the app prints time-since-last-call, the call requires the app window open, and nothing is stored in memory. It also discloses that the response carries the user's message.

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?

Purpose is front-loaded and the guidance is organized logically from states to the 'waiting' caveat to behavioral notes. It is dense and somewhat long, with the 'waiting'/'blocked' behavior touched on in more than one sentence, but for a stateful tool this length is mostly 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?

For a mutation tool with no output schema, the description covers prerequisites ('Needs the app window open'), persistence behavior ('nothing is stored in memory', title given once), the return value (the user's message on the card), and the toolkit's rendering behavior. Nothing an agent needs to invoke it correctly appears to be 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 schema already documents all seven parameters (states, title, detail, desktop, session, attention) with enums and defaults. The description restates the state vocabulary and adds usage context for 'waiting' and title persistence, but adds little semantic detail beyond the schema. Baseline 3 applies.

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 description states a specific verb and resource: 'Update your own status card on the user's canvas, the cockpit.' It identifies the action clearly and distinguishes it from all sibling tools (agenda, todo, memory, agent tools) since it is the only one that writes to this status card.

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 maps each lifecycle moment to a state ('working' at start, 'waiting' when the user is needed, 'blocked' when stuck, 'done' on finish) and explicitly addresses the tricky case: send 'waiting' in the same turn as the question, right before stopping, because the harness only auto-handles permission prompts. This is explicit when-to-use guidance that no sibling conflicts with.

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

Deploy Server

Other Tools