Skip to main content
Glama

fenbs

by ai.fenbs
OverviewDiscussionsAdmin

fenbs_list_items

Read-onlyIdempotent

List tasks on a board (a task is called an item in this API). Filter by lane, kind, project, category, resolution or free text. resolution "built" lists Completed work that is not live yet.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
qNoFree text across title, note and ref.
flagNoOnly flagged tasks: "mine" = flagged by the person you act for (only they see it); "business" = flagged for everyone on a team board.
fullNotrue: every field of each task. Otherwise a summary row each; fenbs_get_item gives one task in full.
kindNo
laneNoThe lane, by its key. People see backlog as To Do, next as Next Up, doing as In Progress and done as Completed: use those names when you talk to people.
boardYesBoard slug, e.g. "kitchen-refit" (its name also works).
projectNoOnly tasks in this project, by name.
categoryNoOnly tasks in this category, by name.
resolutionNoOnly Completed tasks with this resolution. built means done, not live yet.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / resolution
      Added value: +{
+  "description": "Only Completed tasks with this resolution. built means done, not live yet.",
+  "enum": [
+    "shipped",
+    "built",
+    "wontfix",
+    "duplicate",
+    "cannotreproduce",
+    "obsolete"
+  ],
+  "type": "string"
+}
  2. Changed1 schema field changed
    • changedInput schema / properties / board / description
      Previous value: -"Board slug, e.g. \"kitchen-refit\"."New value: +"Board slug, e.g. \"kitchen-refit\" (its name also works)."
  3. Changed1 schema field changed
    • addedInput schema / properties / full
      Added value: +{
+  "description": "true: every field of each task. Otherwise a summary row each; fenbs_get_item gives one task in full.",
+  "type": "boolean"
+}
  4. First observed

TDQS

A3.5/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds useful domain semantics (the item/task naming convention and what resolution "built" means), but the schema already states "built means done, not live yet," so the added value is thin and no return-shape, ordering, or pagination behavior is disclosed.

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?

Three short sentences with the core purpose front-loaded, followed by the filter surface and one clarifying semantic note. Nothing is wasted and nothing is buried.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 9 parameters, 4 enums, no output schema, and no stated defaults (e.g., what an unfiltered call returns, whether results are summarized or paginated), the description is adequate but leaves real gaps. The annotations cover safety, but behavior for the many optional filters is only partially addressed.

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 description coverage is 89%, so the schema already carries parameter meaning, and the description only restates the filterable fields (lane, kind, project, category, resolution, free text) without adding syntax, defaults, or combinability rules. Baseline 3 is appropriate when the schema does the heavy lifting.

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 ("List tasks on a board") and pre-empts the item/task terminology mismatch that would otherwise confuse an agent reading sibling names like fenbs_get_item and fenbs_create_item. It does not explicitly name an alternative tool, so it stops short of full sibling differentiation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The filter list implies the tool's role (browse/filter a board's tasks), and the resolution note hints at a use case, but there is no explicit when-to-use guidance, no statement of when to prefer fenbs_search or fenbs_get_item, and no mention of the required board parameter or prerequisites.

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

All fenbs toolsInspect
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