Skip to main content
Glama

notebook

Destructive

Store game notes, assign purposes to units or cities, and queue multi-turn orders so plans survive context resets.

Instructions

My memory, kept beside the game per seat and surviving a context reset: free-text notes, assignments (what a unit or city is for) and multi-turn orders for units. Use it for what future-me must know; the game itself holds no plan. action, with its args -- remember {text, tag?, replace_id?}: write a note (returns the note with its id; new notes ride on the next briefing / finish); recall {tag?, limit?}: list notes; forget {note_id}: delete a note for good. assign {role, purpose, unit_ids? / city_ids?}: give units or cities a purpose that shows in their rows; assignments: list them; amend {assignment_id, purpose? / role?}; close {assignment_id}. give_order {unit_id, steps}: a plan of steps run one per turn at each finish; orders: the plans with their status; cancel_order / resume_order {order_id}. Returns {ok: true, ...} with the row written or the rows listed, or {ok: false, err, accepts, example}. A note written on a turn later than the one on screen (a save was loaded) comes back marked later_timeline.

Input Schema

NameRequiredDescriptionDefault
argsNothe action's arguments by name: text / tag / replace_id, note_id, role and purpose with unit_ids / city_ids, assignment_id, unit_id and steps, order_id
actionYesremember | recall | forget | assign | assignments | amend | close | give_order | orders | cancel_order | resume_order
action_idNoa token of my choosing: a retry with the same action_id replays the stored result

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv2.1.0

TDQS

A4.2/5.0
Behavior5/5

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

Beyond annotations, the description discloses important behavior: notes survive context resets, new notes ride on the next briefing/finish, 'forget' deletes permanently, orders run one step per turn, errors return {ok: false, err, accepts, example}, and notes from a later timeline are marked later_timeline. These details materially help an agent use the tool correctly.

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?

The description is front-loaded with purpose and then covers actions compactly. It is dense and somewhat run-on, using semicolons and slashes, but every part contributes useful information for an 11-action tool.

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?

Given the tool's complexity and lack of an output schema, the description is largely complete: it covers action purposes, return shape, error shape, and a timeline edge case. The main gap is that the structure of 'steps' for give_order is not described.

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?

Schema description coverage is 100%, so the baseline is 3. The description adds useful action-specific argument semantics, such as remember {text, tag?, replace_id?}, assign {role, purpose, unit_ids? / city_ids?}, and give_order {unit_id, steps}, though it does not fully explain the shape of 'steps'.

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 description clearly states that this is a per-seat memory tool for notes, assignments, and multi-turn unit orders, and it enumerates the supported actions. It does not explicitly differentiate itself from the sibling 'order' tool or other siblings, so it falls short of the top score.

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 gives clear usage context: 'Use it for what future-me must know; the game itself holds no plan.' That helps an agent understand when the tool is appropriate, but it does not name alternatives or state when not to use it.

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