Skip to main content
Glama
Sign In
musterd

musterd

Official
by musterd-io
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

team_memory_save

Saves this seat's working state for the next session or occupant: what you were doing, decisions mid-flight, and where you left off. Use at wrap-up or handoff, not mid-task.

Instructions

SEAT-PRIVATE (the team_ prefix is the tool namespace, not the audience — for the whole team use team_insight_save). Saves this seat's working state for the next session or occupant: what you were doing, decisions mid-flight, where you left off. Working state ONLY — durable knowledge (traps, technique, learned facts) goes in docs/wiki/ pages, not here (ADR 259). Use at wrap-up or handoff, not mid-task. One note per seat, last-write-wins. headline ≤120 chars (shown on the next occupy); body ≤8KB. Private to this seat; never store secrets.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "headline": "<headline>"
    },
    "name": "team_memory_save"
  }
}

Input Schema

NameRequiredDescriptionDefault
bodyNothe full note (≤8KB); omit for headline-only
headlineYesone-line subject (≤120 chars)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.7.1

TDQS

A4.5/5.0
Behavior4/5

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

With no annotations, the description carries the load and does it well: discloses overwrite semantics ('one note per seat, last-write-wins'), privacy scope ('private to this seat'), size ceilings (headline ≤120, body ≤8KB), and a safety constraint ('never store secrets'). What it omits is what the call returns or whether prior content is recoverable after an overwrite — meaningful for a last-write-wins store, so short of the top mark.

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?

Dense and front-loaded: the audience/prefix clarification comes first, then content scope, then routing exclusion, then operational constraints. The nested parentheses in the opening sentence are slightly convoluted, but every clause carries information and nothing is padding.

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?

For a two-parameter write tool with no annotations and no output schema, the description covers audience, content scope, overwrite model, limits, and safety. The only gap is return/confirmation behavior after a save, which matters because there is no output schema to fall back on.

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 coverage is 100%, so baseline is 3, but the description adds real meaning: the headline is 'shown on the next occupy' (its downstream consumer, not obvious from the schema) and body is characterized by content type (what you were doing, decisions mid-flight, where you left off). It does not restate the length limits redundantly in a confusing way — they match the schema.

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+resource ('Saves this seat's working state') and immediately disambiguates the confusing 'team_' prefix, naming the sibling that serves the team-wide case (team_insight_save). An agent can distinguish it from team_memory_read and team_insight_save without opening any schema.

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?

Gives explicit when ('at wrap-up or handoff') and when-not ('not mid-task'), plus a routing rule for a competing destination for durable knowledge (docs/wiki pages, ADR 259). The alternative tool is named by name, so the choice is fully determined.

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