mcp-server-zuuna
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| ZUUNA_BASE_URL | No | Zuuna base URL — must be an absolute http(s) URL | https://app.zuuna.de |
| ZUUNA_API_TOKEN | Yes | Bearer API token | |
| ZUUNA_TIMEOUT_MS | No | Per-request timeout | 15000 |
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 |
|---|---|
| zuuna_meA | Show the identity of the Zuuna API token in use: organization, plan, granted scopes and (when lapsed) the grace-window deadline. Use this first to check what the token may do. |
| zuuna_boardsA | List the boards of the token's organization (non-archived, non-private). Each entry carries id, title, card key prefix and timestamps. Use the id with zuuna_board. |
| zuuna_boardA | Get one board assembled: its columns (in order) and its cards with key, title, column, priority and type. The card list is capped at one 200-card page so a big board cannot flood the context; when more cards exist the response sets cardsTruncated and a nextCursor — pass that as cardsCursor for the next page. Accepts the board id or its key/title (e.g. the card prefix). |
| zuuna_cardA | Get a card's full detail — description, priority, type, due date, checklist counts, assignees, epic, custom fields, attachments. Accepts the display key (e.g. ZNA-2001) or the card id. |
| zuuna_create_cardA | Create a card on a board. Title is required; give the target column by id or by title (omitted = the board's first column). Returns the new card's id and key. Retries are safe: pass the same idempotencyKey again after a lost response or 5xx and the API returns the original card instead of a duplicate. |
| zuuna_update_cardA | Edit a card: title, description and/or priority (HIGHEST|HIGH|NORMAL|LOW|LOWEST, or null to clear). Only the fields you send change. Accepts a card key (ZNA-2001) or id. |
| zuuna_move_cardA | Move a card to another column. Give the target column by id or by title (resolved against the card's board). Accepts a card key (ZNA-2001) or id. |
| zuuna_commentA | Add a comment to a card. The author is the user who created the API token. Accepts a card key (ZNA-2001) or id. |
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 8 tools
Each tool maps to a distinct resource+action: token identity, board listing, board detail, card detail, card create, card field update, card move, and card comment. The singular/plural pair (zuuna_board vs zuuna_boards) and explicit verb prefixes (create_, update_, move_) keep boundaries clear, and the only near-overlap (update vs move) is resolved by descriptions that separate field edits from column changes.
All tools share the zuuna_ prefix and snake_case, with bare nouns for reads (zuuna_board, zuuna_card) and verb_noun for writes (zuuna_create_card, zuuna_update_card, zuuna_move_card) — a predictable read/write convention. Minor deviations: zuuna_me doesn't fit the noun/verb_noun pattern, and zuuna_comment omits the explicit action (zuuna_add_comment would match the other writers more closely).
Eight tools is well-scoped for a board/card management server: one identity check, two board-level reads, one card read, and four card mutations. Every tool earns its place, with no redundancy or filler.
The core card workflow is covered (create, read, update title/description/priority, move, comment), but the surface is read-heavy: card detail exposes due dates, assignees, epics, and custom fields that no tool can write, and comments can be added but never retrieved. There is also no delete/archive operation for cards, which is an obvious gap in most card lifecycles.