Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@mcp-server-zuuna show me the cards on the ZNA board in column 'In Progress'"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Agent-native board access for Zuuna — a Model Context Protocol server that lets coding agents (Claude Code, Cursor, Codex) read and work a Zuuna board directly.
Agents work the board. Git keeps it honest.
The agent reads the board via this MCP server, does the work in the repo with its own coding tools, and when the PR merges, Zuuna's git integration moves the card. Zuuna provides the interface and the verifiable board truth — the agent writes the code, not Zuuna.
Working and tested, and published on npm (npx -y mcp-server-zuuna) after an auth
review of the token model, scopes and tool surface. Run from source (bottom) if you want
to hack on it.
Related MCP server: Kanban Zone MCP Server
Tool | What it does | Grounded in (Zuuna v1 API) | Scopes needed |
| Token identity: org, plan, scopes, grace-window deadline |
| any token |
| List boards (non-archived, non-private) |
|
|
| One board assembled: columns in order + cards (key, title, column, priority, type) — capped at one 200-card page; when more exist it returns |
|
|
| Full card detail by display key ( |
|
|
| Create a card (title required; column by id or title; board by id or key; optional |
|
|
| Edit title / description / priority ( |
|
|
| Move a card to a column, by id or title |
|
|
| Comment on a card (author = the token's creator) |
|
|
Behavioral notes:
Errors come back as MCP tool errors with the API's own message (the v1 envelope's
message plus status and machine code) — e.g. 409 wip_limit_reached when a HARD WIP
limit refuses a move.
One request, no retries: 4xx answers are never re-sent. Requests time out after 15 s (configurable) and surface as network errors.
Card display keys like ZNA-2001 work anywhere a card is addressed — the v1 API accepts
the key as the handle.
zuuna_board pages the card list (200 cards per page, the v1 API's own cap) so a big
board cannot flood the agent's context. When a page is not the whole board, the response
says cardsTruncated: true and carries nextCursor; send it back as cardsCursor to
fetch the next page.
zuuna_create_card accepts an optional client-chosen idempotencyKey: re-sending the
same key after a lost response or a 5xx returns the original card (200) instead of
minting a duplicate.
You need an API token from your Zuuna workspace. Give it the scopes for what the agent
should be allowed to do — a read-only observer needs only boards:read + cards:read.
The server is configured per client via environment variables:
Variable | Default | Meaning |
| — (required) | Bearer API token |
|
| Zuuna base URL — must be an absolute http(s) URL (invalid values fail at startup); a plain-http value prints a cleartext-token warning to stderr |
|
| Per-request timeout |
claude mcp add zuuna \
-e ZUUNA_API_TOKEN=zuuna_your_token \
-- npx -y mcp-server-zuunaor in the project's .mcp.json:
{
"mcpServers": {
"zuuna": {
"command": "npx",
"args": ["-y", "mcp-server-zuuna"],
"env": { "ZUUNA_API_TOKEN": "zuuna_your_token" }
}
}
}In ~/.cursor/mcp.json (or the project's .cursor/mcp.json):
{
"mcpServers": {
"zuuna": {
"command": "npx",
"args": ["-y", "mcp-server-zuuna"],
"env": { "ZUUNA_API_TOKEN": "zuuna_your_token" }
}
}
}In ~/.codex/config.toml:
[mcp_servers.zuuna]
command = "npx"
args = ["-y", "mcp-server-zuuna"]
env = { "ZUUNA_API_TOKEN" = "zuuna_your_token" }git clone https://github.com/kenzotp/mcp-server-zuuna
cd mcp-server-zuuna && npm install && npm run buildthen point the client at the built binary instead of npx:
claude mcp add zuuna -e ZUUNA_API_TOKEN=zuuna_your_token -- node /path/to/mcp-server-zuuna/dist/index.jszuuna_board — the agent sees the board and picks a card (or you tell it: "do ZNA-2001").
The agent codes in your repo with its own tools, referencing the card key in commits.
The PR merges — and git truth moves the card: Zuuna's git integration (webhooks/CLI) advances the card through its columns. The agent never has to touch the board manually, and the board cannot drift from the repository.
This server is deliberately board I/O only. There are no deploy tools and no git-write tools — deploys and card movement from commits belong to Zuuna's git-truth engine, not to the agent. Agents do the coding; Zuuna keeps the board honest about it.
npm install
npm run lint # eslint
npm run build # tsc -> dist/
npm test # vitest, fully mocked (no network)Optional live smoke test, strictly read-only (GET /me and GET /boards only — nothing
is ever created, moved or commented):
ZUUNA_E2E=1 ZUUNA_API_TOKEN=zuuna_your_token npm run test:e2eRequires Node.js >= 20.
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).
| Name | Required | Description | Default |
|---|---|---|---|
| board | Yes | Board id, board key (card prefix) or board title. | |
| cardsCursor | No | Opaque nextCursor from a previous zuuna_board response — fetches that board's next page of cards. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavior disclosure. It reveals the 200-card page cap, the cardsTruncated flag, and the nextCursor/cardsCursor continuation mechanism, which are important runtime behaviors not visible in the schema. It does not explicitly state read-only/no side effects, but 'Get' strongly implies it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. It front-loads the core purpose, then efficiently covers pagination and identifier flexibility. Every clause adds useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema, the description does a solid job explaining the response contents, pagination behavior, and accepted inputs. It could explicitly describe the overall response shape or error cases, but an agent has enough to invoke it correctly and interpret pagination.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description largely restates what the schema already says about board identifiers and the opaque cursor, though it adds the helpful clarification that the board key/title can be a card prefix. It does not add substantial meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('one board assembled') and clearly enumerates what is returned: ordered columns plus cards with key, title, column, priority, and type. It distinguishes itself from siblings like zuuna_boards (plural list) and zuuna_card (single card) by scoping to a full board retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly describes what the tool retrieves and explains the pagination workflow with cardsCursor. It does not explicitly name alternatives or state when not to use it, but the 'one board' scope and identifier flexibility give an agent enough context to select it appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It discloses that only non-archived, non-private boards are returned and enumerates the entry fields (id, title, card key prefix, timestamps), which is valuable. However, it doesn't mention pagination, ordering, authentication requirements, or error behavior—moderate gaps for a list tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler. The first sentence states the action and scope; the second lists the return fields and the follow-up tool. The description is front-loaded and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter list tool with no output schema or annotations, the description covers the scope, filters, return fields, and the next logical step. Minor omissions like pagination and ordering are acceptable for a simple board list, so the description is adequately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty, so there are no parameters to describe. With zero parameters, the baseline is 4, and the description doesn't introduce any parameter-related confusion or missing guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('List') and resource ('boards of the token's organization') with explicit filters (non-archived, non-private). It also distinguishes itself from the sibling zuuna_board by noting that the returned id is for use with that tool, making it clear this is the collection-level list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context about what the endpoint returns and directly points the agent to zuuna_board for single-board operations. It doesn't explicitly discuss when to avoid using this tool, but the collection-vs-single-board distinction is sufficient for routing between the two key siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| card | Yes | Card key (e.g. ZNA-2001) or card id. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. The verb 'Get' plus the explicit list of returned attributes makes the read-only behavior and output scope clear. It could explicitly state non-mutation or error behavior, but for a simple retrieval tool this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one efficient sentence followed by a short input note. It front-loads the purpose, uses an em-dash to list the value returned, and contains no filler or redundant explanation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read tool with no output schema, the description is complete: it names the input format, provides an example, and specifies the full scope of returned data. Nothing essential is missing for an agent to select and invoke this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the schema already documents 'Card key (e.g. ZNA-2001) or card id.' The description repeats this with an example, adding slight clarification but no substantial new parameter semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and identifies the exact resource ('a card's full detail'), then enumerates the returned fields. It clearly differentiates this read tool from sibling mutation and movement tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains how to identify the card (key or id) and gives an example, which is helpful. However, it does not explicitly state when to use this tool as opposed to zuuna_create_card, zuuna_update_card, or zuuna_move_card; the usage is only implied by the verb and sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add a comment to a card. The author is the user who created the API token. Accepts a card key (ZNA-2001) or id.
| Name | Required | Description | Default |
|---|---|---|---|
| body | Yes | Comment text (plain text or sanitized HTML; @mentions notify). | |
| card | Yes | Card key (e.g. ZNA-2001) or card id. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral disclosure burden. It adds a meaningful detail: the comment author is the API token creator. However, it does not mention other behavioral aspects such as whether comments can be edited, what happens on failure, or notification side effects beyond what the schema already implies.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no filler. The core action is front-loaded, and the author-attribution detail and identifier guidance each earn their place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with only two fully documented required parameters. The description provides the key operational nuance (author identity) and identifier format. Without an output schema, it could mention the response shape, but for a straightforward comment-creation call the description is largely sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters. The description adds slight value by restating that 'card' accepts a key or id, but it does not add new meaning beyond the schema for either parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Add a comment to a card.' It also clarifies accepted identifiers. No sibling tool is a comment operation, so it is clearly distinguishable from the provided siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives practical input guidance by stating that the card can be identified by key or id. However, it does not state when to prefer this tool over alternatives or provide any exclusion criteria. Usage context is implicit because this is the only comment-related sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | Card title (required). | |
| boardId | No | Board id (from zuuna_boards). Provide this or boardKey. | |
| boardKey | No | Board key/title instead of boardId; resolved via the board list. | |
| columnId | No | Target column id. Provide this or columnTitle. | |
| columnTitle | No | Target column title (resolved against the board's columns). | |
| description | No | Card description (plain text or sanitized HTML). null clears. | |
| idempotencyKey | No | Client-chosen key for safe retries (e.g. "order-4711-card"). If this key was already used in this workspace, the API returns the ORIGINAL card (200) instead of creating a duplicate. Use a fresh key for each new card; reuse one key only for retries of the same logical card. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It clearly discloses key non-obvious behavior: idempotency key retries return the original card instead of duplicating, and an omitted column defaults to the board's first column. It does not cover auth or permissions, but these are less critical for selection and invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two compact sentences with no filler. It front-loads the core creation statement and then packs the most important invocation and retry semantics into the second sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 7-parameter creation tool with no output schema, the description covers key invocation details: required title, column targeting, default column, return values, and retry safety. It does not explicitly state that boardId or boardKey is required, but the schema descriptions provide that context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds meaningful semantics beyond the schema, such as the column default behavior, the ability to target columns by id or title, and the idempotency contract. These details help the agent choose parameter values correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Create a card on a board.' It also adds essential scope details such as requiring a title and targeting a column by id or title, which distinguishes it from sibling mutation tools like update_card and move_card.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes the creation purpose obvious and provides operational guidance, but it does not explicitly state when to prefer this tool over siblings or when to use alternatives like update_card or move_card. Usage context is implied rather than explicitly framed as a decision.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of explaining behavior. It clearly describes the informational nature and the output contents, but it does not explicitly state non-mutating behavior or other side-effect expectations. 'Show' strongly implies a read-only operation, yet that is not made explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler: the first states the primary purpose and output details, the second provides actionable usage guidance. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, no-output-schema introspection tool, the description fully covers what the tool does, what it returns, and when to use it. No critical call-time information is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters and the schema coverage is 100%, so the description has no parameter burden. The phrase 'token in use' correctly signals that no input is needed beyond the ambient authentication context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Show the identity of the Zuuna API token in use'. It enumerates concrete contents (organization, plan, granted scopes, grace-window deadline), making the tool easily distinguishable from sibling board/card tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The closing instruction 'Use this first to check what the token may do' explicitly states when to invoke the tool. It does not name each sibling alternative, but the contrast with the board/card operations is clear from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| card | Yes | Card key (e.g. ZNA-2001) or card id. | |
| columnId | No | Target column id. Provide this or columnTitle. | |
| columnTitle | No | Target column title (resolved against the card's board). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It transparently states the mutation ('move a card') and adds useful detail about column title resolution being board-scoped and accepted card identifiers. However, it does not mention return values, failure behavior, or whether this is reversible.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no redundant phrasing. The primary action is front-loaded, followed immediately by the key disambiguation details for card and column identification.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple move operation with only three parameters, the description is mostly sufficient. The main gaps are the absence of any indication of what the tool returns (there is no output schema) and no mention of error conditions or prerequisites, which an agent might need to handle failures gracefully.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all three parameters. The description repeats this information without adding new semantic detail beyond clarifying that columnTitle is resolved against the card's board—which the schema also states. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Move a card to another column') and the resources involved (card, column, board). It distinguishes itself from sibling tools like zuuna_create_card and zuuna_update_card by naming a unique operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: whenever a card needs to be moved to another column. It also explains how to specify the destination via columnId or columnTitle, though it does not explicitly discuss exclusions or compare against sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| card | Yes | Card key (e.g. ZNA-2001) or card id. | |
| title | No | New title. | |
| priority | No | New priority, or null to clear. | |
| description | No | New description. null clears it. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It states that only sent fields change, which is a partial-update behavior, but it does not disclose what happens on success (return value, confirmation), error conditions (card not found, invalid key), or any side effects. For a mutation tool, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, concise and front-loaded with the purpose. Every word earns its place, and it avoids redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no output schema and no annotations, the description should explain the return behavior or success/failure semantics. It doesn't clarify what the tool returns (if anything) or what happens if the card doesn't exist. The description is too sparse to be fully complete for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters (card, title, priority, description) including the enum and null behavior. The description adds minimal new meaning, essentially restating what the schema provides. Baseline 3 is appropriate because the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Edit a card: title, description and/or priority'. It names the specific resource (card) and the fields it can modify, distinguishing it from siblings like zuuna_create_card and zuuna_move_card. The verb 'Edit' is precise and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: editing existing cards, with the note 'Only the fields you send change' indicating partial updates. While it doesn't explicitly mention alternatives or when not to use it, the sibling names make the distinction obvious. It lacks explicit exclusions but is still reasonably clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.2zuuna_boardzuuna_boardszuuna_cardzuuna_commentzuuna_create_cardzuuna_mezuuna_move_cardzuuna_update_cardScored 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.
Task & board management for AI agents + humans. Kanban, comments, digests via MCP.
Create, read and live-edit visual boards, Kanban plans, Gantt timelines and diagrams with AI agents.
AI agents use CalmBoard MCP to access board data, tasks, insights, and project workflows.
Kanban board for teams and coding agents: manage tasks, subtasks, sprints and wiki pages via MCP.
