fenbs

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

Name	Required	Description	Default
`drop`	No	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. Leave whereWeLeftOff out to only take them out; the last entry cannot be dropped that way.
`basis`	No	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.
`tasks`	No	One entry per task you worked on.
`append`	No	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.
`status`	No	The project's overall progress in a few lines. Replaces the last one; leave out to keep it.
`project`	No	The project, by name, for whereWeLeftOff and status.
`session`	No	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.
`takeover`	No	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.
`onOverflow`	No	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. With no whereWeLeftOff, ask lists the entries and basis and changes nothing, so a nearly full handover can be tidied without adding to it. Every saved handover returns room, with a warning at 1000 characters left or fewer.	trim
`whereWeLeftOff`	No	Start 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.

Changed2 schema fields changedNov 1, 2026

changedInput schema / properties / drop / description

Previous value: -"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."New value: +"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. Leave whereWeLeftOff out to only take them out; the last entry cannot be dropped that way."

changedInput schema / properties / onOverflow / description

Previous value: -"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."New value: +"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. With no whereWeLeftOff, ask lists the entries and basis and changes nothing, so a nearly full handover can be tidied without adding to it. Every saved handover returns room, with a warning at 1000 characters left or fewer."

Changed8 schema fields changedOct 17, 2026

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."

Changed2 schema fields changedOct 11, 2026

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"
+}

Changed2 schema fields changedOct 9, 2026

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."

AddedOct 2, 2026

TDQS

A4.2/5.0

Behavior5/5

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

Goes well beyond the annotations: overwrite-but-history-preserved semantics for whereItStands ('the old text is kept, and fenbs_get_item shows it'), permission requirement ('Needs permission to change tasks'), a security constraint ('Never put a secret in it'), and the append/overflow/drop behavior. With destructiveHint=false declared, it correctly clarifies that the lossy paths (append trimming, [] clearing steps) are bounded by prior-version retention.

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?

Front-loaded well with 'Save progress -- the hand off.' But the core sentence is a single ~90-word run-on with nested parentheticals ('(overwrites its Where it stands; the old text is kept, and fenbs_get_item shows it)'), forcing the agent to parse clauses to find the payload. The content earns its place; the packaging does not.

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 10-parameter, zero-required mutation tool with no output schema, the description covers what is written, when to call, who reads it, the secret-hygiene rule, and the permission prerequisite. Remaining details (basis/drop mechanics, overflow return) are documented in the schema, so nothing an agent needs to invoke correctly is missing.

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 the baseline is 3 and the per-parameter text already carries most meaning. The description adds cross-parameter coupling the schema does not state on its own — that tasks entries and project/whereWeLeftOff are written together in one call, and that doneSteps counts against the steps list passed in the same call. That relationship is genuinely useful rather than repetition.

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?

States a specific verb+resource ('Save progress -- the hand off') and enumerates exactly what one call persists: each touched task's whereItStands, its ticked steps, and the project's next/running/waiting state. It also names the reader (fenbs_get_context), which pins the tool's role. It stops short of distinguishing itself from fenbs_update_item, which plausibly writes the same task fields, so the agent must infer the split.

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?

Clear triggering conditions: 'call it before you stop, when the person says "save progress" or "hand off", or before a window is cleared' — concrete moments, plus the release/takeover guidance lives in params. However, no when-not rule and no explicit alternative is named (e.g. use fenbs_update_item for a single field mid-session), which is the one routing decision an agent actually faces here.

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

All fenbs tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?