Skip to main content
Glama
Sign In
Kanbini

Kanbini

by Jigglyy
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Get a list's cards

kanbini_get_list_cards

Retrieve cards from a Kanbini board list, optionally filtering by status, label, priority, due date, or text and paging long lists with offset and limit.

Instructions

One list's cards, optionally filtered and paged. listId is the list's id or exact name, on boardId (id or name). Filters, all optional and combined: status "open" | "completed" | "all" (default); label (name or id) the card carries; priority (low/medium/high/urgent, or "none"); dueFrom / dueTo (YYYY-MM-DD, inclusive; a card without a due date never matches them); hasDue true/false; query (text in the title or description, any case). Returns { boardId, list: { id, name, cardCount }, matched (cards matching the filters), offset, cards, more (true when another page follows: call again with offset + cards.length) }. Cards come in the order the list shows them, as the same one-line summaries kanbini_get_board gives; detail: "full" returns them with all of their content (descriptions, checklists, comments, history). limit defaults to 50, max 200. Good for "what is still open in To Do", "every Bug card", or walking a long list page by page. When the desktop app is closed, falls back to the last on-disk export.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "boardId": "<boardId>",
      "listId": "<listId>"
    },
    "name": "kanbini_get_list_cards"
  }
}

Input Schema

NameRequiredDescriptionDefault
dueToNo
labelNo
limitNo
queryNo
detailNo
hasDueNo
listIdYes
offsetNo
statusNo
boardIdYes
dueFromNo
priorityNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.17.0

TDQS

A4.7/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does so: it discloses return shape (boardId, list, matched, offset, cards, more), page-size defaults (50 default, 200 max), ordering semantics ("the order the list shows them"), the summary-vs-full detail distinction, and the important fallback to a stale on-disk export when the desktop app is closed.

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?

Front-loads the core purpose, then groups filters in one semicolon-delimited block and closes with return shape and use cases. Almost every clause carries information, though the filter enumeration is a dense run-on that is slightly harder to scan than a list would be.

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?

There is no output schema, and the description fully documents the return object, pagination contract, and detail modes. For a 12-parameter read tool with no annotations, the only minor gap is the absence of guidance versus kanbini_search_cards, which is not required to call this tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate for 12 parameters, and it does: it defines status values with a stated default, priority values plus the "none" case, inclusive YYYY-MM-DD date formats with the caveat that undated cards never match due filters, case-insensitive query scope, and that listId/boardId accept either id or exact name.

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?

Opens with a precise verb+resource+scope: "One list's cards, optionally filtered and paged." It distinguishes itself from kanbini_get_board by explaining the card summaries are "the same one-line summaries kanbini_get_board gives," making the relationship to a sibling explicit rather than leaving the agent to guess.

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?

Provides concrete usage scenarios ("what is still open in To Do", "every Bug card", walking a long list page by page) and explains the pagination loop condition ("call again with offset + cards.length"). It does not explicitly route the agent to kanbini_search_cards for cross-board text search, which is the main omission.

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