Click on "Install 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., "@planka-mcp Create a card 'Review PR' in the To Do list."
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.
A Model Context Protocol (MCP) server for PLANKA kanban boards, purpose-built for Claude and other AI agents.
Full PLANKA 2.0 API support
Type-safe with Zod validation
Optimized for agent workflows (combined operations, sensible defaults)
13 tools covering cards, tasks, labels, comments, and lists
Related MCP server: Another Planka MCP
npm install @gogogadgetbytes/planka-mcpOr run directly:
npx @gogogadgetbytes/planka-mcpVariable | Required | Description |
| Yes | Your PLANKA server URL |
| Yes | Agent user email |
| Yes | Agent user password |
Add to ~/Library/Application Support/Claude/claude_desktop_config.json:
{
"mcpServers": {
"planka": {
"command": "npx",
"args": ["@gogogadgetbytes/planka-mcp"],
"env": {
"PLANKA_BASE_URL": "https://planka.example.com",
"PLANKA_AGENT_EMAIL": "agent@example.com",
"PLANKA_AGENT_PASSWORD": "your-password"
}
}
}
}Add to ~/.claude.json:
{
"mcpServers": {
"planka": {
"command": "npx",
"args": ["@gogogadgetbytes/planka-mcp"],
"env": {
"PLANKA_BASE_URL": "https://planka.example.com",
"PLANKA_AGENT_EMAIL": "agent@example.com",
"PLANKA_AGENT_PASSWORD": "your-password"
}
}
}
}Tool | Description |
| Get projects, boards, and lists hierarchy |
| Get a board with all cards, lists, and labels |
Tool | Description |
| Create a card (optionally with tasks) |
| Update card properties |
| Move card to different list/position |
| Get card details with tasks/comments |
| Delete a card |
Tool | Description |
| Add tasks (checklist items) to a card |
| Update task name or completion |
| Delete a task |
Tool | Description |
| Create/update/delete board labels |
| Add/remove labels from a card |
Tool | Description |
| Add a comment to a card |
| Get all comments on a card |
Tool | Description |
| Create/update/delete lists |
Use planka_get_structure to see all projects and boardsUse planka_create_card with:
- listId: "abc123"
- name: "Implement feature X"
- tasks: ["Research", "Design", "Implement", "Test"]Use planka_move_card to move card from "To Do" to "In Progress"This server is designed for PLANKA 2.0 and handles the API differences from 1.x:
Card creation includes required type field
Label endpoints use /card-labels path
Optional fields handled gracefully
# Clone
git clone https://github.com/gogogadgetbytes/planka-mcp.git
cd planka-mcp
# Install
npm install
# Build
npm run build
# Test
npm testMIT
PLANKA - The kanban board
MCP SDK - Model Context Protocol
Design Document - Technical design details
Add a comment to a card. Use this for status updates, notes, or agent activity logs.
| Name | Required | Description | Default |
|---|---|---|---|
| cardId | Yes | The card ID | |
| text | Yes | Comment text (markdown supported) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must cover behavior. It states 'add' which implies a write operation, but does not mention prerequisites (card existence) or side effects. For a simple tool, minimal disclosure is acceptable.
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, no wasted words. Action and purpose are front-loaded.
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 a simple tool with no output schema, the description covers the essential purpose and common use cases. It could mention that the card must exist, but that is implicit for a comment addition.
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?
With 100% schema coverage, the description still adds value by noting 'markdown supported' for the text parameter, which is not in the schema. It does not redundantly restate parameter descriptions.
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 ('Add a comment to a card') and specifies use cases: status updates, notes, or agent activity logs. It distinguishes from sibling tools like planka_get_comments.
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 suggests when to use this tool ('for status updates, notes, or agent activity logs') but does not explicitly mention when not to use it or alternatives. However, given the sibling toolset, the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new card on a board. Optionally add tasks (checklist items) at the same time.
| Name | Required | Description | Default |
|---|---|---|---|
| listId | Yes | The list to create the card in | |
| name | Yes | Card title | |
| description | No | Card description (markdown supported) | |
| tasks | No | Optional: Task names to add as a checklist | |
| dueDate | No | Due date in ISO format | |
| labelIds | No | Optional: Label IDs to attach |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions creation and optional task addition but lacks details on side effects (e.g., whether tasks replace or append), required permissions, return behavior, or failure scenarios. Minimal disclosure for a mutation 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?
The description is a single sentence with no redundant words, directly stating the primary action and key optional feature. It is well-front-loaded and requires no parsing effort.
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 6 parameters, no output schema, and no annotations, the description is too sparse. It does not explain how tasks relate to the card, the format of dueDate (ISO), or the outcome of providing labelIds. A user unfamiliar with Planka would lack necessary 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% with clear parameter descriptions (e.g., listId: 'The list to create the card in'). The description adds only that tasks are checklist items, which is already inferable from the schema. It does not enrich meaning beyond what is structured.
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 ('Create a new card on a board') and the optional capability ('add tasks (checklist items)'), distinguishing it from sibling tools like planka_create_tasks which separately create tasks, and planka_update_card which modifies existing cards.
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 implies usage when creating a card but does not explicitly discuss when to use or avoid this tool relative to alternatives. Sibling tools exist (e.g., planka_create_tasks) but no guidance is provided, leaving the agent to infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one or more tasks (checklist items) to a card.
| Name | Required | Description | Default |
|---|---|---|---|
| cardId | Yes | The card ID | |
| tasks | Yes | Task names to create |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits, but it only says 'Add one or more tasks', omitting details like permissions, error handling, or whether tasks are appended.
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 a single highly focused sentence, front-loaded with the verb, and contains no extraneous 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?
For a simple create tool with no output schema and no annotations, the description is too minimal, lacking usage context, error conditions, or expected behavior.
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 minimal value by clarifying 'tasks (checklist items)', but otherwise relies on 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 clearly states the verb 'Add', the resource 'tasks (checklist items)', and the target 'to a card', distinguishing it from siblings like planka_create_card or planka_delete_task.
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?
No guidance on when to use this tool versus alternatives (e.g., updating tasks or adding comments), nor any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Permanently delete a card. This cannot be undone.
| Name | Required | Description | Default |
|---|---|---|---|
| cardId | Yes | The card ID to delete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly says 'cannot be undone', informing the agent of the irreversible destructive nature. With no annotations, the description carries the full burden, and it adequately conveys the key behavior.
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 efficient sentences with zero waste. The first states the action, the second reinforces permanence.
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 tool with one required parameter and no output schema, the description is complete enough. It could mention permissions or dependencies, but for minimal viable definition it is adequate.
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% with a clear description for cardId. The tool description adds no additional 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 clearly states 'Permanently delete a card', using a specific verb and resource. It distinguishes from sibling tools that perform different actions like create, update, or comment.
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?
No explicit guidance on when to use this tool versus alternatives. No mention of prerequisites or contexts where deletion should be avoided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a task from a card.
| Name | Required | Description | Default |
|---|---|---|---|
| taskId | Yes | The task ID to delete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states the deletion action but omits details like irreversibility, permission requirements, or effect on related data.
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 concise sentence with no unnecessary words. It is front-loaded and efficient.
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 deletion tool with 1 parameter and no output schema, the description is adequate but minimal. It does not address potential failure cases or return behavior, leaving some gaps.
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 schema covers the sole parameter 'taskId' with a description. The tool description adds no extra meaning beyond the schema, so 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 verb 'Delete' and the resource 'a task from a card'. It is specific and distinguishes from siblings like 'planka_delete_card' and 'planka_create_tasks'.
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?
Usage is implied by the tool name and description, but no explicit guidance is given on when to use or avoid this tool, nor are alternatives mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a board with all its lists, cards, and labels. Use this to see everything on a board.
| Name | Required | Description | Default |
|---|---|---|---|
| boardId | Yes | The board ID | |
| includeTaskCounts | No | Include task completion counts for each card |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes what the tool returns (all lists, cards, labels) which is a key behavioral trait. No annotation contradictions. Could mention that it is read-only, but not necessary given context.
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, no fluff, front-loaded with purpose and usage guidance.
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?
Completely covers purpose, usage, and return structure for a simple read tool with two parameters. No gaps given lack of output schema.
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 covers both parameters fully. Description adds context about what is returned but does not add new parameter-specific meaning beyond 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?
Clearly states verb (Get) and resource (board), specifying included items (lists, cards, labels). Distinguishes from siblings that focus on subsets.
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 explicit usage context ('Use this to see everything on a board') but lacks explicit when-not-to-use or alternative recommendations among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get full details of a card including tasks, comments, labels, and attachments.
| Name | Required | Description | Default |
|---|---|---|---|
| cardId | Yes | The card ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It states what is included but does not elaborate on behavior like whether it only returns summaries, performance implications, or any limitations.
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?
Single sentence, 14 words, front-loads purpose. No unnecessary words.
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 retrieval tool with one parameter and no output schema, the description adequately lists included elements. Could mention nested objects but overall 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?
Only parameter cardId has schema description. Description adds no extra context beyond 'The card ID'. Schema coverage is 100%, so baseline 3.
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 'Get full details of a card' and specifies what is included (tasks, comments, labels, attachments). It distinguishes from sibling tools like planka_get_board and planka_get_comments.
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?
No explicit guidance on when to use this tool vs alternatives. Implied usage is when needing card details, but does not mention when not to use or name alternatives like planka_get_comments for comments only.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all comments on a card.
| Name | Required | Description | Default |
|---|---|---|---|
| cardId | Yes | The card ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description does not disclose behavioral traits beyond the action. It implies a read operation but does not confirm safety, permissions, or side effects.
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 a single, clear sentence with no unnecessary words. It is appropriately concise for a simple tool.
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 description is minimal for a tool with no output schema. It does not explain what comment data is returned (e.g., text, author) or edge cases like empty results. Adequate but with clear gaps.
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?
With 100% schema coverage for cardId, the description adds no extra meaning beyond the schema. Baseline 3 is appropriate since the schema already defines the 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 clearly states 'Get all comments on a card'—a specific verb and resource. However, it does not differentiate from related sibling tools like planka_add_comment, which is acceptable since the actions differ.
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?
No guidance is provided on when to use this tool over alternatives or any prerequisites. The description lacks context for usage decisions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the full project/board/list structure. Use this to understand what projects and boards exist before working with cards.
| Name | Required | Description | Default |
|---|---|---|---|
| projectId | No | Optional: Get structure for a specific project only |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It describes the output as 'full structure' and mentions optional parameter for filtering. However, it does not disclose any side effects, rate limits, or authentication requirements, though for a read operation this is acceptable.
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, front-loaded with action and purpose, no unnecessary words. Highly concise and well-structured.
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?
Simple tool with one optional parameter and no output schema. Description adequately conveys purpose and usage. Could mention return format but is sufficient for selecting and invoking.
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% with one optional parameter. The description does not add significant extra meaning beyond the schema, but the schema is already clear. Baseline of 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 it retrieves the full project/board/list structure, using specific verbs and resources. It distinguishes from siblings that operate on individual cards or boards.
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?
Explicitly says 'Use this to understand what projects and boards exist before working with cards', providing clear when-to-use guidance. Does not explicitly state when not to use, but sibling tools imply alternatives for specific queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create, update, or delete labels on a board.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | Action to perform | |
| boardId | No | Board ID (required for create) | |
| labelId | No | Label ID (required for update/delete) | |
| name | No | Label name | |
| color | No | Label color. Valid colors: berry-red, pumpkin-orange, lagoon-blue, pink-tulip, light-mud, orange-peel, bright-moss, antique-blue, dark-granite, lagune-blue, sunny-grass, morning-sky, light-orange, midnight-blue, tank-green, gun-metal, wet-moss, red-burgundy, light-concrete, apricot-red, desert-sand, navy-blue, egg-yellow, coral-green, light-cocoa, modern-green, piggy-red |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It only states the action type but fails to disclose behavioral traits like permissions required, side effects, or limitations (e.g., label uniqueness, board scope).
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 a single, well-formed sentence that directly states the tool's purpose without any extraneous information. Highly efficient.
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 no output schema, the description should clarify return values. It does not mention what the tool outputs. Additionally, for a mutation tool with 5 parameters, more behavioral context is needed.
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 adds no additional meaning beyond the schema's parameter descriptions; the schema already explains action, boardId, labelId, name, and color with enums.
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 purpose with specific verbs (create, update, delete) and resource (labels on a board). It effectively distinguishes from sibling tools like planka_set_card_labels, which assign labels to cards.
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?
No guidance is provided on when to use this tool versus alternatives such as planka_set_card_labels or planka_manage_lists. Lacks context for appropriate usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create, update, or delete lists on a board.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | Action to perform | |
| boardId | No | Board ID (required for create) | |
| listId | No | List ID (required for update/delete) | |
| name | No | List name | |
| position | No | List position |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description must disclose behavioral traits. It states the tool mutates lists, but provides no information on side effects, authorization needs, or success/failure responses.
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 a single concise sentence that covers the primary purpose. It is front-loaded with the key verb and resource, though it could be slightly expanded for clarity.
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 lacks an output schema and annotations, so the description should explain return values and error handling. It does not, leaving the agent without important contextual information for a mutation 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%, so parameters are well-documented in the schema. The description adds no extra meaning beyond enumerating actions, which is already in the schema via the action enum.
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 it creates, updates, or deletes lists, distinguishing it from sibling tools focused on cards and tasks. However, it does not specify that actions are board-specific, which is inferred from parameters.
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?
No guidance is provided on when to use each action or how to choose between them. The description lacks any decision-making context for the agent.
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 a different list or position. Use this for workflow transitions (e.g., 'To Do' -> 'In Progress').
| Name | Required | Description | Default |
|---|---|---|---|
| cardId | Yes | The card ID | |
| listId | Yes | Target list ID | |
| position | No | Position in the list (lower = higher). Default: end of list |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden. It discloses that the tool moves a card and supports positioning, but lacks details on whether moving to the same list is allowed, side effects, or data preservation. The behavior is predictable for a move operation.
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 unnecessary words. It front-loads the core action and follows with a usage example, making it efficiently scannable for an AI agent.
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 the low complexity of a move tool and the fully described parameters, the description is mostly complete. It covers the main operation and usage. However, without annotations, it could have mentioned if the move always changes list or can also reorder within the same list, but the example implies cross-list move.
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 schema already documents all three parameters with descriptions. The description adds value by clarifying that position 'lower = higher' and defaults to end of list, which goes beyond the schema's 'Position in the list (lower = higher)'.
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 verb 'Move' and resource 'card', and specifies the scope 'to a different list or position'. It also provides a concrete example of workflow transitions ('To Do' -> 'In Progress'), which distinguishes it from sibling tools like planka_update_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 provides clear context for when to use this tool ('for workflow transitions') and gives an example. However, it does not explicitly state when not to use it or mention alternatives like planka_update_card for other modifications.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add or remove labels from a card.
| Name | Required | Description | Default |
|---|---|---|---|
| cardId | Yes | The card ID | |
| addLabelIds | No | Label IDs to add | |
| removeLabelIds | No | Label IDs to remove |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must carry full burden. Only states 'add or remove labels' without disclosing idempotency, permission requirements, or behavior on invalid inputs.
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?
Single sentence, no wasted words. Concisely conveys the core function.
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?
No output schema, but description does not mention what the tool returns (e.g., updated card). Also lacks error handling or side-effect information, leaving the agent underinformed.
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 parameters are documented. Description does not add extra meaning beyond the schema, earning the baseline score.
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?
Clearly states it adds or removes labels from a card, specifying the verb and resource. However, it does not explicitly clarify whether the operation is incremental or replaces all labels, which could cause ambiguity.
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?
No guidance on when to use this tool versus siblings like planka_manage_labels or planka_create_card. The description lacks context on prerequisites or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update a card's properties (name, description, due date, completion status).
| Name | Required | Description | Default |
|---|---|---|---|
| cardId | Yes | The card ID | |
| name | No | New card title | |
| description | No | New description (null to clear) | |
| dueDate | No | New due date (null to clear) | |
| isCompleted | No | Mark card as complete/incomplete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description only states it updates properties. Does not disclose behavioral traits such as partial update behavior, side effects, or account requirements. Minimal disclosure for a mutation 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?
Single sentence, front-loaded with verb and resource, no redundant words. Efficient and concise.
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 5 parameters, no output schema, and no annotations, the description is too minimal. Missing return value, error scenarios, and update behavior details.
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% with descriptions for all parameters. Description adds no extra meaning beyond listing the properties, so 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?
Clear verb ('Update'), resource ('card'), and specific properties listed (name, description, due date, completion status). Distinguishes from sibling tools like create_card, delete_card, etc.
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?
Implied usage when updating card properties, but no explicit guidance on when to use vs alternatives like planka_move_card or planka_update_task. No when-not-to-use conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update a task's name or completion status.
| Name | Required | Description | Default |
|---|---|---|---|
| taskId | Yes | The task ID | |
| name | No | New task name | |
| isCompleted | No | Mark as complete/incomplete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must convey behavioral traits. It only states the function, without disclosing side effects, idempotency, authorization needs, or what happens to other task fields (e.g., overwritten or merged).
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 a single, front-loaded sentence of 7 words with no redundancy. It is appropriately concise for a simple update tool, earning its place without waste.
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 the low complexity (3 parameters, no nested objects) and lack of output schema/annotations, the description covers the basic purpose but omits return value information and potential side effects. It is minimally adequate but not fully 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?
Schema coverage is 100%, so the baseline is 3. The description simply restates the parameters ('name or completion status') without adding new constraints, formats, or behavioral details. It does not improve understanding 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 clearly states the verb 'Update' and the resource 'task', and specifies the attributes that can be updated ('name or completion status'). It distinguishes itself from sibling tools like planka_delete_task (delete) and planka_move_card (move).
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?
No guidelines are provided about when to use this tool versus alternatives. There is no explicit mention of when to update instead of create or delete, nor any context about prerequisites or exclusions.
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. Dates show when Glama detected each change.
v1.0.0planka_add_commentplanka_create_cardplanka_create_tasksplanka_delete_cardplanka_delete_taskplanka_get_boardplanka_get_cardplanka_get_commentsplanka_get_structureplanka_manage_labelsplanka_manage_listsplanka_move_cardplanka_set_card_labelsplanka_update_cardplanka_update_taskEach tool targets a distinct action (create, delete, update, get) on a specific resource (card, task, comment, label, list, board), with no overlapping purposes.
All tools follow a consistent 'planka_verb_noun' pattern using snake_case, such as 'create_card', 'delete_task', 'get_board', making them predictable and easy to navigate.
With 15 tools, the set covers the essential operations for a project management board without being excessive or sparse, striking a good balance for its scope.
Core CRUD operations for cards, tasks, labels, and lists are covered, and comments are readable and addable, but lacking delete/update comment and attachment management represents minor gaps.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Task & board management for AI agents + humans. Kanban, comments, digests via MCP.
Remote MCP for Kanban AI boards—manage projects, tasks, and comments from AI tools.
MCP server for AI agents to plan, verify, and deploy Cloudflare-native apps.
Kanban board for teams and coding agents: manage tasks, subtasks, sprints and wiki pages via MCP.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/gogogadgetbytes/planka-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
