kanban-pro
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| KANBAN_PRO_DB | No | Path to the SQLite database. | ~/.local/share/kanban-pro/kanban.db |
| KANBAN_PRO_ACTOR | No | Who is writing (format: kind:name). | unknown |
| KANBAN_PRO_FLOWS | No | Path to the flows.yaml file for workflow rules. | |
| KANBAN_PRO_PROFILE | No | Which backend to use (profile name). | default |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_boardsA | List all boards. |
| get_boardA | Get one board (includes its columns and label registry). |
| create_boardA | Create a board. Omit Send an idempotency_key (any unique string, REUSED on retry) so a retried call returns the original board instead of creating a duplicate. |
| update_boardB | Partially update a board — only the fields set in |
| delete_boardA | Delete a board permanently. Refused while live cards remain — move/archive first. |
| list_columnsA | List a board's columns (name, order, semantic category, wip_limit). |
| create_columnA | Add a column to a board. |
| update_columnB | Partially update a column (rename, reorder via |
| delete_columnA | Delete a column permanently. Refused while live cards sit in it — move/archive first. |
| list_cardsA | List a board's cards. Archived cards are hidden unless include_archived=true (that's how you find unarchive/purge targets). |
| get_cardB | Get one card (works for archived cards too). |
| create_cardA | Create a card. |
| update_cardA | Partially update a card — only the fields set in |
| record_work_reportA | Update one structured work_report section/item on a card. Current state lives in card.ext["work_report"]; every successful call also emits a work_report.updated changelog event. Use this instead of rewriting the whole ext blob. List sections require item.id and are upserted by that id; singleton sections are replaced. |
| answer_work_report_questionC | Answer one work_report question and mirror the answer as a normal comment. |
| move_cardA | Move a card within a board it's already on (re-column / re-position). Errors if the card has no placement on to_board_id (use add_placement), or if the card's workflow scheme forbids the transition — check list_transitions first. force=true deliberately overrides scheme + WIP validation; the override is always recorded in the change-log, never silent. |
| list_transitionsA | What moves are legal for this card right now, and under which resolved scheme. Sources: the card's flow scheme (flow.yaml; 'free-roam' = unrestricted), the backend's own workflow (e.g. hermes), or free movement when nothing is configured. |
| list_flowsA | Available workflow schemes: every flow.yaml scheme (+ built-in 'free-roam'), with states, allowed transitions, and which scheme is the default. |
| add_placementA | Put a card on an additional board (one placement per board; errors if already on it). |
| remove_placementA | Take a card off one board (its other placements stay). The last placement can't be removed — archive_card instead. |
| archive_cardA | Archive a card (soft, recoverable — the default way to remove one). |
| unarchive_cardB | Restore an archived card. |
| delete_cardA | Permanently purge a card. Only allowed on an ARCHIVED card — archive_card first. |
| list_commentsA | List a card's comments. |
| add_commentB | Add a comment to a card ( |
| delete_commentB | Delete a comment permanently. |
| list_relationsA | List a card's typed relations (blocks, parent/child, duplicates, ...). |
| add_relationA | Link two cards with a typed relation. Subtask = kind 'child' from parent card. idempotency_key (reused on retry) prevents duplicate relations. |
| delete_relationB | Delete a relation permanently. |
| list_workA | What should I work on? Workable cards for |
| claim_cardA | Atomically lease a card so no other agent picks it up (visible in list_work).
The lease expires after ttl_seconds unless renewed via heartbeat_claim — a crashed
agent's card becomes claimable again automatically. |
| heartbeat_claimA | Renew your live lease on a card while still working it. |
| release_claimA | Release your lease (done or giving up). |
| raise_attentionA | Flag a card as needing a decision or input (e.g. a question only a human or a specific agent can answer). Routable: the change-log event carries the reason and the target actor, so notifier agents DM the right party. Put the actual question in a comment; this flag is the signal, not the discussion. |
| clear_attentionA | Clear a card's attention flag (question answered / decision made). Put the
answer in a comment; |
| list_changesA | Change feed: every recorded write after cursor Each event carries seq (the cursor — pass the last seq back as |
| wait_changesA | Long-poll change feed: returns AS SOON AS events exist after cursor |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| event_schema_resource | The full contract for consuming the change-feed — event shapes, data keys, attention routing, and the notifier pattern. Call this once, then loop ``wait_changes`` / ``list_changes`` with confidence. |
| capabilities_resource | Active profile's capabilities, each with its fulfilment (SPEC decision 2): native (backend does it), polyfilled (kanban-pro fulfils it), unavailable. |
| boards_resource | All boards as canonical JSON. |
| work_distribution_resource | The work-distribution contract: how agents claim/lease/work/release cards. ``list_work`` returns a ``WorkQueue {actor, items: [WorkItem, ...]}``. Each ``WorkItem`` has the full ``Card``, the column it's in (id/name/category), whether YOU currently hold the lease (``claimed_by_me``), and the legal transitions from this column (``transitions`` — see ``kanban://workflow``). The life of a claim: 1. ``claim_card(card_id, ttl_seconds=900)`` — CAS lease. Fails with ``conflict`` if another agent holds it. 2. ``heartbeat_claim(card_id, ttl_seconds)`` — keep the lease alive while working. 3. When the worker finishes: move the card + ``release_claim(card_id)``. 4. On crash / timeout: the lease expires, the card is reclaimable. The dispatcher / next agent sees it in ``list_work`` again. Claiming does NOT move or assign the card — convention: claim → assign yourself → move to a started column, all recorded in the change-log. |
| workflow_resource | The workflow contract: how to move cards and what's legal. ``list_transitions(card_id, board_id?)`` returns a ``TransitionInfo``: ``{options: [{column_id, name}, ...], resolved_scheme, source}``. Each ``column_id`` in ``options[]`` is a valid target for ``move_card``. The ``source`` field tells you where the rules came from: - ``flow`` — flow.yaml scheme (the default) - ``free-roam`` — the reserved scheme; any column is reachable - ``backend`` — the adapter's own lifecycle (e.g. Hermes ready/blocked/done) - ``free`` — current column not modeled by the scheme → free movement ``force=true`` on ``move_card`` overrides the scheme + WIP checks. The override is ALWAYS recorded in the change-log — it's for unblocking, never routine. |
| domain_resource | The canonical domain model: types, conventions, and ext namespaces. ``Card`` is the unit of work. A card's ``placements[]`` (≥1) is where it lives — one placement per board. ``ext`` is free-form metadata; these namespaces are reserved: | key | owner | meaning | |---|---|---| | ``kanban_pro.scheme`` | flow engine | workflow scheme name (see kanban://workflow) | | ``kanban_pro.attention`` | attention signal | ``{reason, raised_by, for}`` | | ``kanban_pro.migrated_from`` | migration | provenance ``"<profile>/<board-id>"`` | | ``hermes`` | hermes adapter | backend-specific fields | | ``work`` | kanban-dispatcher | ``{log, attempts, quota_hits, retry_at}`` | | ``session`` | the working agent | ``{actor, log, kind}`` — session log the UI tails live | Patches (``CardPatch``, ``BoardPatch``, …) are PARTIAL UPDATES: only set fields apply. ``ext`` is a SHALLOW MERGE: patch keys → stored dict; a key set to None is REMOVED. This protects concurrent writers from clobbering each other's ext data. |
| work_report_schema_resource | Structured card report schema and write rules. |
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/galvani/kanban-pro'
If you have feedback or need assistance with the MCP directory API, please join our Discord server