@kanbio/mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| KANBIO_TOKEN | Yes | Your Kanbio personal access token, starting with kbn_ | |
| KANBIO_API_URL | Yes | URL of the Kanbio API, e.g. https://kanbio.example.com/api (/api is added if missing) |
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": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_projectsA | List the Kanbio projects this token can reach, with their key (used by the other tools) and your role in each. |
| search_ticketsA | Search tickets across your projects, most recently updated first. Every filter is optional and they combine (AND). Returns one compact line per ticket; use get_ticket for the full ticket. |
| get_ticketA | Read one ticket by key: status, type, priority, assignee, sprint, description and its comments (threads, oldest first; "via AI" marks comments written through a token). |
| list_sprintsA | List the sprints of a project (planned and active; completed ones on request), with dates and goal. |
| list_membersA | List the members of a project with their email and role (pm, dev, qa), e.g. to assign or mention someone. |
| my_ticketsA | Tickets assigned to the token owner across their projects, most recently updated first. Open ones only unless include_done. |
| add_commentA | Add a comment to a ticket as the token owner; Kanbio shows it with a "via AI" badge. To mention people, list them in |
| change_statusA | Move a ticket to another status. Kanbio enforces the workflow: To Do → In Progress → [To Merge →] To Test → Done | Rejected; Done and Rejected can go back to To Test or In Progress. To Merge is optional and only reachable from In Progress. An invalid move is rejected with the allowed next statuses. Needs the tickets:status permission. |
| assign_ticketA | Assign a ticket to a project member ("me", email or name), or unassign it with "none". The person must be a member of the ticket's project. Needs the tickets:assign permission. |
| create_ticketA | Create a ticket in a project, reported by the token owner. It starts in To Do. Optionally assign it (needs tickets:assign) or plan it into a sprint (needs sprints:write); otherwise it goes to the backlog. Needs the tickets:create permission. |
| update_ticketA | Edit the fields of a ticket: title, description, type, priority, story points or labels. Only the fields given change. Status, assignee and sprint have their own tools. Needs the tickets:edit permission. |
| move_to_sprintA | Move one or more tickets to a sprint ("active" or a sprint name) or back to the backlog ("backlog"). Completed sprints are not allowed. Needs the sprints:write permission. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 12 tools
Each tool targets a distinct action-resource pair: status, assignee, and sprint moves are deliberately split into change_status, assign_ticket, and move_to_sprint, and update_ticket explicitly excludes them. The only slight overlap is my_tickets vs search_tickets, but the descriptions make the boundary clear (assigned-to-me shortcut vs filtered search).
The set is overwhelmingly consistent verb_noun (list_projects, create_ticket, update_ticket, change_status, assign_ticket, move_to_sprint, search_tickets, get_ticket). The single deviation is my_tickets, a noun-only name with no verb, which breaks the pattern but is still readable.
Twelve tools is well within the ideal range and each one maps to a concrete workflow step (discovery, read, search, create, edit, status, assign, sprint, comment, members). No tool appears redundant or filler.
Ticket lifecycle is well covered: create, read, search, edit, status transitions with documented workflow, assignment, sprint placement, and commenting via get_ticket. Minor gaps exist (no ticket delete/archive, no sprint creation despite list_sprints, no comment editing), but core agent workflows are not blocked.