Skip to main content
Glama

fenbs_save_progress

Idempotent

Save progress -- the hand off. Call it before you stop, when the person says "save progress" or "hand off", or before a window is cleared. In one call: where each task you touched stands (overwrites its Where it stands; the old text is kept, and fenbs_get_item shows it) and the steps it ticked (doneSteps), and, with project, where the project was left: what to start on next, what is still running (stop it first if you can), and what is waiting on a person. The next assistant reads all of it in fenbs_get_context. Never put a secret in it. Needs permission to change tasks.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dropNoOnly with append and onOverflow ask: entry numbers to drop, 1-based, with the returned basis. Entries are blocks between blank lines, not whole handoffs; read firstLine before choosing.
basisNoOnly with append, onOverflow ask and drop: the returned hash of the exact current text. A stale basis holds the text and returns fresh entries and a new basis.
tasksNoOne entry per task you worked on.
appendNotrue: add whereWeLeftOff after what is already there (a blank line between) instead of replacing it -- for adding a step to a plan another session left. Past 4000 characters the oldest entries are dropped to make room, and the reply says how many. Rewrite it whole when the old text is out of date.
statusNoThe project's overall progress in a few lines. Replaces the last one; leave out to keep it.
projectNoThe project, by name, for whereWeLeftOff and status.
sessionNoA short name for this session or window, e.g. "Claude Code c--ws 33edc07d". Pass the same one on every call. Every window you open shares this connection, so without it fenbs shows only the connection name and cannot tell your windows apart.
takeoverNoThe session you are taking over from, when it handed the task to you without releasing it (it crashed, or was cleared without a final save). If it names the session working the task, you take it over with no warning and the history notes the handover; if not, you get the usual warning. Applies to every task in this call.
onOverflowNoWith append: trim drops the oldest entries to fit (the default). ask holds only whereWeLeftOff when it would overflow; task updates and project status still save. Read the returned entries, then retry with drop and basis, or rewrite it whole without append. Successful appends return room and a warning below 800 characters left.trim
whereWeLeftOffNoStart here next; still running; waiting on a person; anything across tasks. Replaces the last one, unless append is true.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed8 schema fields changed
    • addedInput schema / properties / basis
      Added value: +{
      +  "description": "Only with append, onOverflow ask and drop: the returned hash of the exact current text. A stale basis holds the text and returns fresh entries and a new basis.",
      +  "type": "string"
      +}
    • addedInput schema / properties / drop
      Added value: +{
      +  "description": "Only with append and onOverflow ask: entry numbers to drop, 1-based, with the returned basis. Entries are blocks between blank lines, not whole handoffs; read firstLine before choosing.",
      +  "items": {
      +    "minimum": 1,
      +    "type": "integer"
      +  },
      +  "type": "array",
      +  "uniqueItems": true
      +}
    • addedInput schema / properties / onOverflow
      Added value: +{
      +  "default": "trim",
      +  "description": "With append: trim drops the oldest entries to fit (the default). ask holds only whereWeLeftOff when it would overflow; task updates and project status still save. Read the returned entries, then retry with drop and basis, or rewrite it whole without append. Successful appends return room and a warning below 800 characters left.",
      +  "enum": [
      +    "trim",
      +    "ask"
      +  ],
      +  "type": "string"
      +}
    • addedInput schema / properties / takeover
      Added value: +{
      +  "description": "The session you are taking over from, when it handed the task to you without releasing it (it crashed, or was cleared without a final save). If it names the session working the task, you take it over with no warning and the history notes the handover; if not, you get the usual warning. Applies to every task in this call.",
      +  "type": "string"
      +}
    • addedInput schema / properties / tasks / items / properties / doneSteps
      Added value: +{
      +  "description": "Step numbers to tick as done, 1 being the first (counted in the list after any steps you pass in the same call). The rest are left as they are.",
      +  "items": {
      +    "minimum": 1,
      +    "type": "integer"
      +  },
      +  "type": "array"
      +}
    • addedInput schema / properties / tasks / items / properties / release
      Added value: +{
      +  "description": "true: you are handing this In Progress task over and stopping work on it. Your claim is released, so the next window takes it without a \"being worked by another session\" warning. Only the session working the task can release it. Pass it in your final save before a /clear or a handover.",
      +  "type": "boolean"
      +}
    • addedInput schema / properties / tasks / items / properties / steps
      Added value: +{
      +  "description": "Remaining steps: the ordered checklist of what is left to do, one short line each (at most 30, each under 300 characters), e.g. [\"Write the SQL\", \"Build the API\", \"Ship\"]. A string is a step not done yet; {text, done} sets done too. get_context shows each task in progress as \"step n of N next: <text>\", so the next assistant always sees what comes next. Tick them off with doneSteps as you go. Replaces the whole list; [] clears it.",
      +  "items": {
      +    "anyOf": [
      +      {
      +        "type": "string"
      +      },
      +      {
      +        "additionalProperties": false,
      +        "properties": {
      +          "done": {
      +            "type": "boolean"
      +          },
      +          "text": {
      +            "type": "string"
      +          }
      +        },
      +        "required": [
      +          "text"
      +        ],
      +        "type": "object"
      +      }
      +    ]
      +  },
      +  "type": "array"
      +}
    • changedInput schema / properties / tasks / items / properties / whereItStands / description
      Previous value: -"Where the work stands right now and what comes next: done so far (commits), not done, next step, anything still running, anything waiting on a person. Short; overwritten each time, the old text kept in History. Plan says how; this says where it is."New value: +"Where the work stands right now: done so far (commits), what is not done, anything still running, anything waiting on a person. Short; overwritten each time -- the old text is kept, and fenbs_get_item shows the earlier versions. The remaining steps live in steps, the checklist: tick them there instead of listing them here. Plan says how; steps say what is left; this says where things are."
  2. Changed2 schema fields changed
    • changedInput schema / properties / append / description
      Previous value: -"true: add whereWeLeftOff after what is already there (a blank line between) instead of replacing it -- for adding a step to a plan another session left. Rewrite it whole when the old text is out of date."New value: +"true: add whereWeLeftOff after what is already there (a blank line between) instead of replacing it -- for adding a step to a plan another session left. Past 4000 characters the oldest entries are dropped to make room, and the reply says how many. Rewrite it whole when the old text is out of date."
    • addedInput schema / properties / session
      Added value: +{
      +  "description": "A short name for this session or window, e.g. \"Claude Code c--ws 33edc07d\". Pass the same one on every call. Every window you open shares this connection, so without it fenbs shows only the connection name and cannot tell your windows apart.",
      +  "type": "string"
      +}
  3. Changed2 schema fields changed
    • addedInput schema / properties / append
      Added value: +{
      +  "description": "true: add whereWeLeftOff after what is already there (a blank line between) instead of replacing it -- for adding a step to a plan another session left. Rewrite it whole when the old text is out of date.",
      +  "type": "boolean"
      +}
    • changedInput schema / properties / whereWeLeftOff / description
      Previous value: -"Start here next; still running; waiting on a person; anything across tasks. Replaces the last one."New value: +"Start here next; still running; waiting on a person; anything across tasks. Replaces the last one, unless append is true."
  4. Added

TDQS

A4.3/5.0
Behavior5/5

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

Annotations declare readOnly=false, idempotent=true, destructive=false, but the description adds real behavioral detail beyond them: whereItStands is overwritten yet the old text is retained and viewable via fenbs_get_item, secrets must never be stored, and changing tasks requires permission. These are non-obvious safety and mutability semantics an agent needs.

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?

Front-loaded with the purpose and triggers, then elaborates the write semantics. Mostly earns its length, though the single dense paragraph is somewhat rambling and could be tightened.

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 10-parameter, zero-required mutation tool with no output schema, the description supplies triggers, overwrite/history behavior, permission needs, and the secret warning. The only real gap is not explaining the return payload, since it instead points to fenbs_get_context.

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 coverage is 100%, so the schema already documents all ten parameters thoroughly. The description weaves some of them into a workflow narrative (doneSteps, project) but adds little syntax or format meaning beyond the schema, so 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?

States a specific verb+resource ('Save progress -- the hand off') and details exactly what it writes in one call (task state, steps ticked, project status). It also names sibling tools (fenbs_get_item, fenbs_get_context) so an agent can distinguish this writer from the readers it feeds.

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 explicit triggers: before stopping, when the person says 'save progress' or 'hand off', or before a window is cleared. Clear context for use, though it doesn't contrast against alternative save/update siblings like fenbs_update_item.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources