fenbs

fenbs_routines

Destructive

Routine Processes: the checks, scripts and procedures this work depends on -- saved groups managed with fenbs_groups. everyDays sets an optional schedule independently of the group. kind remains a legacy category. Each has howToRun (the steps, in order), checks (what to verify afterwards) and ruleRefs (the decisions and rules that govern it, e.g. DEC-049). fenbs keeps how to run it, never the code. Before deploying or testing something, list them and follow the matching one. After running one, log_run with result ok, issues or failed, notes, the refs of any tasks you filed, and measures: the numbers the run counted, by name (e.g. {name: 'Stuck buy notes', value: 3}). Use the same names every run -- fenbs compares each with the routine's last run that recorded it and returns the change (up 1 since RUN-012), so get the routine first and reuse its last run's measure names. Routines due show in fenbs_get_context under Waiting on you. action list (project, kind, dueOnly, q), get (id, with recent runs and their measures), add, update (id), delete (id), log_run (id, result, notes, tasks, measures). References are permanent and board-local. Use ref or the legacy id. get_run accepts runRef (RUN-001); list_runs accepts optional routine ref/id, itemRef, q, take and beforeId. log_run returns the exact runRef plus routineRef; logged.id remains the routine id. Writes need permission to change tasks.

Input Schema

Name	Required	Description
`q`	No
`id`	No
`ref`	No	RTN reference; numeric id remains supported. If both are supplied they must agree.
`kind`	No
`name`	No
`take`	No	list_runs: 1-100, default 20.
`notes`	No	log_run: what it found.
`tasks`	No	log_run: refs of tasks filed from it.
`action`	Yes
`checks`	No	What to verify afterwards.
`result`	No
`runRef`	No	get_run: RUN reference.
`dueOnly`	No
`groupId`	No	add/update: group from fenbs_groups on this page. 0 removes it from a group; omitted preserves it on update.
`itemRef`	No	list_runs: runs linked to this task.
`project`	No
`purpose`	No	What it checks or does, and why.
`beforeId`	No	list_runs: nextBeforeId from the preceding page.
`howToRun`	No	The steps, in order: a script path, a command, a skill name, or what to do by hand.
`measures`	No	log_run: the numbers this run counted, at most 20, each name once. Reuse the names of the last run so the change is shown.
`ruleRefs`	No	Decision refs that govern it. Replaces the list.
`everyDays`	No	Days between runs, independent of group (1-366); 0 clears the schedule.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 9, 2026

addedInput schema / properties / measures

Added value: +{
+  "description": "log_run: the numbers this run counted, at most 20, each name once. Reuse the names of the last run so the change is shown.",
+  "items": {
+    "additionalProperties": false,
+    "properties": {
+      "name": {
+        "description": "What was counted, up to 60 characters, e.g. \"Stuck buy notes\".",
+        "type": "string"
+      },
+      "unit": {
+        "description": "Optional, up to 12 characters, e.g. \"%\", \"ms\", \"notes\".",
+        "type": "string"
+      },
+      "value": {
+        "type": "number"
+      }
+    },
+    "required": [
+      "name",
+      "value"
+    ],
+    "type": "object"
+  },
+  "maxItems": 20,
+  "type": "array"
+}

Changed8 schema fields changedOct 6, 2026

changedInput schema / properties / action / enum

Previous value: -[
-  "list",
-  "get",
-  "add",
-  "update",
-  "delete",
-  "log_run"
-]New value: +[
+  "list",
+  "get",
+  "add",
+  "update",
+  "delete",
+  "log_run",
+  "get_run",
+  "list_runs"
+]

addedInput schema / properties / beforeId

Added value: +{
+  "description": "list_runs: nextBeforeId from the preceding page.",
+  "type": "number"
+}

changedInput schema / properties / everyDays / description

Previous value: -"A routine: days between runs (1 daily, 7 weekly)."New value: +"Days between runs, independent of group (1-366); 0 clears the schedule."

addedInput schema / properties / groupId

Added value: +{
+  "description": "add/update: group from fenbs_groups on this page. 0 removes it from a group; omitted preserves it on update.",
+  "minimum": 0,
+  "type": "integer"
+}

addedInput schema / properties / itemRef

Added value: +{
+  "description": "list_runs: runs linked to this task.",
+  "type": "string"
+}

addedInput schema / properties / ref

Added value: +{
+  "description": "RTN reference; numeric id remains supported. If both are supplied they must agree.",
+  "type": "string"
+}

addedInput schema / properties / runRef

Added value: +{
+  "description": "get_run: RUN reference.",
+  "type": "string"
+}

addedInput schema / properties / take

Added value: +{
+  "description": "list_runs: 1-100, default 20.",
+  "type": "number"
+}

AddedOct 2, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations declare destructiveHint=true, readOnlyHint=false, idempotentHint=false. Description adds important behavioral context beyond annotations: 'fenbs keeps how to run it, never the code' (clarifies data storage boundary), 'References are permanent and board-local', 'Writes need permission to change tasks', 'Before deploying or testing something, list them and follow the matching one.' However, it doesn't explicitly warn about destructive delete actions or lack of idempotency.

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?

The description is a dense block of text with multiple concepts packed in. While informative, it lacks clear structure (no bullet points or headings) and front-loading is mixed — it starts with the resource definition but then jumps between usage, logging details, and action enumeration. Some sentences could be split or organized for better readability.

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 22 parameters, no output schema, and 64% schema coverage, the description is largely complete for an agent to use the tool correctly. It covers usage scenarios, logging behavior, permission requirements, and parameter semantics. However, it doesn't explain what each action returns (e.g., list vs get output) or how get_run/list_runs results are structured, leaving some gaps for an agent consuming results.

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 64%, so description must compensate. It does: explains actions (list, get, add, update, delete, log_run, get_run, list_runs) and their parameters, describes how measures work (names, comparison with last run), explains ref/id interchangeability, and specifies list_runs paging with take and beforeId. This adds substantial meaning beyond the schema's parameter descriptions.

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 states a specific resource (routine processes: checks, scripts and procedures work depends on) and enumerates its fields (howToRun, checks, ruleRefs, everyDays), giving a clear picture of what the tool manages. It distinguishes itself from siblings by naming fenbs_groups and fenbs_get_context as related tools. However, it doesn't concisely distinguish from all 40+ siblings in one sentence, slightly reducing clarity.

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 states when to use: 'Before deploying or testing something, list them and follow the matching one.' Also provides post-run logging guidance with detailed instructions for log_run, including result values and measure naming. Names alternatives (fenbs_groups) and cross-references (fenbs_get_context).

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

Pay for results, not tokens.Fund a bounty. Let AI agents compete and collaborate to solve your problems.agentbounties.appAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?