fenbs-mcp

Official

Overview Schema Source Related Servers Discussions Admin

fenbs_update_decision

Change a decision by reference, updating the fields you pass while keeping its prior version intact. Replace deciders, link or unlink tasks, or supersede a decided decision to avoid rewriting history.

Instructions

Change a decision by ref. Only the fields passed change; the version before is kept whole. deciders replaces the whole list. linkTasks and unlinkTasks add and remove task links without touching the others. To change a decided decision's substance, record a new one with supersedes rather than rewriting history. Needs permission to change tasks.

Input Schema

TableJSON Schema

Name	Required	Description
`ref`	Yes
`type`	No	Product, Technical, Commercial & pricing, Legal & compliance, Operational, Design, People, Other -- or the board's own.
`title`	No
`reason`	No	Why. Quote the person who decided where you can.
`status`	No	open: a question for a person to decide (the default). proposed: a recommendation, not agreed. decided: a person decided it -- needs decision and who decided. superseded / reversed / withdrawn: it no longer holds.
`context`	No	The question, and why it came up.
`project`	No	A project on this board, by name. Leave it out for the whole board.
`deciders`	No	Who decided -- people, never you. Each is { me: true } for the person you work for (the usual case: they told you), a board member by the email they sign in to fenbs with, or somebody outside the board by name and role.
`decision`	No	What was decided. Needed before status decided; empty while it is open.
`reviewBy`	No	yyyy-mm-dd, optional.
`decidedOn`	No	yyyy-mm-dd, the day it was decided -- may be before today. Defaults to today when decided.
`linkTasks`	No
`supersedes`	No	The decision this replaces, e.g. DEC-003. When this one is decided, that one becomes superseded.
`unlinkTasks`	No
`standingRule`	No	true makes it a RULE: it holds from now on, not just this once. Rules are shown in full at the top of every assistant's AI context and every assistant must follow them. Use it whenever the person says how something must always, or never, be done.
`optionsConsidered`	No	The alternatives, and why they were not chosen.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 1, 2026

TDQS

A4.8/5.0

Behavior5/5

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

With no annotations present the description carries the full burden and does so well: it discloses partial-update semantics, that prior versions are retained whole, that deciders is a wholesale replacement while linkTasks/unlinkTasks are additive, and that changing tasks requires permission. These are exactly the mutation-risk facts 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Five compact sentences, front-loaded with the core operation and then the field-level semantics. Every sentence carries distinct operational information; 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 16-parameter mutation tool with no annotations and no output schema, the definition covers the high-risk behaviors (partial update, history retention, list replacement, permission gate). Minor gaps remain around status-transition constraints and return behavior, but the essentials are present.

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 75% and the schema itself documents most fields richly, but the description adds semantics the schema does not: replacement vs additive behavior for deciders, linkTasks and unlinkTasks. It adds real value beyond the structured data rather than restating it.

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 ('Change a decision by ref') and immediately qualifies the scope as a partial update. This clearly separates it from fenbs_add_decision, fenbs_delete_decision and fenbs_get_decision.

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?

Explicitly routes the agent away from this tool for substantive changes to a decided decision, naming the alternative ('record a new one with supersedes rather than rewriting history') and the permission prerequisite. This is a genuine when/when-not/alternative statement.

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

fenbs_update_decision

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools