Skip to main content
Glama
kjduling

kanbn-mcp

by kjduling
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

kanbn_status

Check Kanbn board status with optional filters for quiet, untracked, due, sprint, and date ranges to get task counts, overdue tasks, sprint stats, and untracked files.

Instructions

Check the current status of the Kanbn board, optionally scoped by the quiet, untracked, due, sprint and dates parameters (board detection checks the methods: initialised, initialized, isInitialized, isInitialised). The response is capped at 100KB by default (configurable via the KANBN_MAX_RESPONSE_SIZE environment variable, in bytes): oversized output automatically falls back to compact JSON, then is truncated with a truncation marker.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dueNoShow overdue tasks and time remaining
pathNoPath to the project root directory
datesNoFilter stats by a date range: a single ISO date or an array of two ISO dates
quietNoReturn partial status (task counts only)
sprintNoShow sprint stats for a named or numbered (1-based) sprint; defaults to the current sprint when omitted
untrackedNoInclude a list of untracked task files (with quiet, returns just that list)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changedv1.1.0
    • addedInput schema / properties / dates
      Added value: +{
+  "description": "Filter stats by a date range: a single ISO date or an array of two ISO dates",
+  "oneOf": [
+    {
+      "type": "string"
+    },
+    {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    }
+  ]
+}
    • addedInput schema / properties / due
      Added value: +{
+  "description": "Show overdue tasks and time remaining",
+  "type": "boolean"
+}
    • addedInput schema / properties / quiet
      Added value: +{
+  "description": "Return partial status (task counts only)",
+  "type": "boolean"
+}
    • addedInput schema / properties / sprint
      Added value: +{
+  "description": "Show sprint stats for a named or numbered (1-based) sprint; defaults to the current sprint when omitted",
+  "oneOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "number"
+    }
+  ]
+}
    • addedInput schema / properties / untracked
      Added value: +{
+  "description": "Include a list of untracked task files (with quiet, returns just that list)",
+  "type": "boolean"
+}
  2. First observedv1.0.2

TDQS

A3.5/5.0
Behavior4/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals specific traits: response capped at 100KB, configurable via an environment variable, fallback to compact JSON, and truncation with a marker. It also mentions board detection methods. These are non-obvious behaviors that an agent would not know otherwise. However, it does not explicitly state whether the operation is read-only (though 'check' implies it) or describe side effects, which would elevate it further.

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?

The description is a single dense sentence that front-loads the main purpose and parameter list, then adds the response-size behavior. It is efficient and each clause adds value, though the parenthetical about detection methods could be considered a minor distraction. The structure is logical: purpose, optional scope, then a critical output constraint. It earns a 4 for being concise and well-organized without wasting words.

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

Completeness2/5

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

There is no output schema, so the description must explain what the status response contains. It only mentions size cap and fallback behavior but never describes the actual content (e.g., task counts, board health, sprint stats). The parameter descriptions hint at some outputs (e.g., 'overdue tasks and time remaining', 'list of untracked task files'), but the overall return structure is unclear. For a tool with 6 optional parameters and no output schema, this is a significant gap. The description is incomplete for an agent to predict the response shape.

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 each parameter's meaning. The description groups them as scoping parameters but adds no new semantic detail beyond what the schema provides. For example, the schema already explains that 'quiet' returns partial status and 'untracked' with quiet returns just that list. The description's mention of 'scoped by...' is a minimal reinforcement, not added meaning. Baseline of 3 is appropriate.

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?

The description states a clear verb ('Check') and resource ('current status of the Kanbn board'), and explicitly lists the optional scoping parameters. This distinguishes it from sibling tools like kanbn_get_task or kanbn_list_boards, which serve different purposes. The purpose is unambiguous.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives, such as kanbn_get_task for a single task or kanbn_burndown for a burndown chart. It also lacks any mention of prerequisites (e.g., board initialization) or conditions under which another tool would be more appropriate. The agent is left to infer usage from the name and description.

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

Deploy Server

Other Tools