Skip to main content
Glama
Jigglyy

Kanbini

by Jigglyy
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Get Kanbini card

kanbini_get_card

Turn a card number the user gives (like #142) into the full card id the write tools need, returning its details, checklists, comments, and blocking links. Use boardId for numbers.

Instructions

Return one Kanbini card by id OR by its number - #142 or 142, the short #N the app shows on the card, which is how the user refers to cards. Numbers are counted per board, so a number needs its boardId (the board the user means; without one this errors and lists the boards that have that number). Numbers handed out before they were per board are gone: look a card up again rather than trusting an old number. Use this to turn a number the user gives you into the card id the write tools need; boardId is ignored for an id. Includes its number and boardId (keep the two together), title, description, priority (low/medium/high/urgent or null), checklists, comments, attachments, recent activity feed, and its "waiting on" links: blockedBy (cards it waits on) and blocking (cards waiting on it), each with title, completed, archived, board, and list. A card is blocked while any blockedBy card is neither completed nor archived. Works for archived cards too (see kanbini_list_archived). Returns null if the id, or the number on that board, does not exist. When the desktop app is closed, falls back to the last on-disk export.

Input Schema

NameRequiredDescriptionDefault
idYes
boardIdNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.13.0

TDQS

A4.6/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 behavioral burden and does so well: it explains the missing-boardId error, null returns for nonexistent ids/numbers, and the fallback to the last on-disk export when the desktop app is closed. It also details archived-card support and the blocked/blocking semantics.

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 front-loaded with the core lookup behavior and remains organized despite its length. Because there is no output schema, much of the return-field detail earns its place, though the text is dense and could be trimmed slightly.

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?

For a two-parameter read tool with no annotations and no output schema, the description is complete: it covers input resolution, error/null behavior, archived cards, fallback behavior, returned fields, and blocker semantics. An agent has enough context to invoke it correctly.

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 0%, so the description must explain both parameters, and it does: `id` can be an id or a `#142`/`142` number, while `boardId` is needed for numbers because numbers are per board. The only small gap is that it does not explicitly say the number is passed in the `id` field.

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 specific verb and resource: return one Kanbini card by id or by its short number. It clearly distinguishes this lookup tool from list/search behavior and explains its role in resolving user-facing card numbers to ids needed by write tools.

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?

It gives clear when-to-use guidance, including that a number requires `boardId` and that `boardId` is ignored for an id. It also covers stale numbers and archived cards, though it does not explicitly contrast with `kanbini_search_cards` as the main alternative.

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