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., "@Planka MCP Server show my projects"
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.
An MCP server that enables AI assistants (Claude, VS Code Copilot, etc.) to interact with Planka - a real-time Kanban board application.
Node.js 18+ or Docker
Planka instance running and accessible
Planka user account with appropriate permissions
Add to your claude_desktop_config.json:
{
"mcpServers": {
"planka": {
"command": "npx",
"args": ["@chmald/planka-mcp"],
"env": {
"PLANKA_BASE_URL": "http://localhost:3000",
"PLANKA_API_KEY": "your-api-key"
}
}
}
}Add to .vscode/mcp.json:
{
"servers": {
"planka": {
"type": "stdio",
"command": "npx",
"args": ["@chmald/planka-mcp"],
"env": {
"PLANKA_BASE_URL": "http://localhost:3000",
"PLANKA_API_KEY": "your-api-key"
}
}
}
}{
"mcpServers": {
"planka": {
"command": "docker",
"args": [
"run", "-i", "--rm",
"-e", "PLANKA_BASE_URL=http://host.docker.internal:3000",
"-e", "PLANKA_API_KEY=your-api-key",
"chmald/planka-mcp:latest"
]
}
}
}Note: Use
host.docker.internalinstead oflocalhostwhen running Docker.
Related MCP server: Planka MCP Server for Claude
Variable | Required | Default | Description |
| Yes |
| Your Planka instance URL |
| No* | - | Planka API key sent as |
| No* | - | Planka username or email |
| No* | - | Planka password |
| No |
| MCP transport mode: |
| No |
| HTTP port used when |
| No |
| Max retry attempts for transient HTTP/network failures per request |
| No |
| Base retry delay in milliseconds (exponential backoff) |
| No |
| Enable all 27 tools |
| No |
| Enable admin tools |
| No |
| Enable optional tools |
* Authentication is required. Provide either PLANKA_API_KEY, or both PLANKA_USERNAME and PLANKA_PASSWORD.
API key (recommended): Set PLANKA_API_KEY.
Username/password: Set PLANKA_USERNAME and PLANKA_PASSWORD.
If both are set, the server uses PLANKA_API_KEY.
Retries apply to transient failures (408, 429, 5xx) and network request errors.
Delay uses exponential backoff: PLANKA_HTTP_RETRY_BASE_DELAY_MS * 2^attempt.
PLANKA_HTTP_MAX_RETRIES controls additional attempts after the initial request.
By default, 10 core tools are enabled for essential Kanban operations:
Category | Tools | Description |
Core | 10 | Auth, projects, boards, lists, cards, tasks, comments, labels (always enabled) |
Optional | 13 | Attachments, custom fields, notifications, etc. |
Admin | 4 | User management, webhooks, config |
Enable more tools:
"env": {
"ENABLE_ALL_TOOLS": "true"
}Each tool uses an action parameter. Example: { "action": "list" } or { "action": "get", "id": "123" }
Tool | Actions |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Tool | Actions |
|
|
|
|
|
|
|
|
Tool | Actions |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
For team deployments where multiple clients share one server:
docker run -d \
--name planka-mcp \
-p 3001:3001 \
-e MCP_TRANSPORT=sse \
-e PLANKA_BASE_URL=http://your-planka-server:3000 \
-e PLANKA_API_KEY=your-api-key \
chmald/planka-mcp:latestConnect clients to http://localhost:3001/sse.
Verify your API key (or username/password) is correct
Check that PLANKA_BASE_URL is accessible
Use host.docker.internal instead of localhost
Ensure Planka is running
Ensure Node.js 18+ is installed: node --version
Try: npm cache clean --force
npx @chmald/planka-mcp 2>&1 | tee debug.logCheck CHANGELOG.md for full version-by-version details.
The auth tool moved from optional tools to core tools and is now always available.
API key authentication is now supported with PLANKA_API_KEY (X-Api-Key).
If both API key and username/password are configured, PLANKA_API_KEY is used.
GitHub Issues - Report bugs
Planka - The Kanban board application
CONTRIBUTING.md - Development & publishing guide
CHANGELOG.md - Versioned API and tooling updates
SECURITY.md - Security policy
MIT - see LICENSE
Authentication operations for login flows, token management, and terms acceptance.
| Name | Required | Description | Default |
|---|---|---|---|
| data | No | Auth data: { emailOrUsername?: string, password?: string, token?: string, code?: string } (required for: login, acceptTerms, oidcExchange, revokePending) | |
| query | No | Query parameters for filtering/pagination | |
| action | Yes | Action to perform: 'login' - Login with credentials; 'logout' - Logout current session; 'acceptTerms' - Accept terms during auth; 'oidcExchange' - Exchange OIDC code; 'revokePending' - Revoke pending token; 'getTerms' - Get terms document |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description provides only a high-level summary without disclosing behavioral details such as session creation/destruction, token expiration, or side effects of accepting terms. This leaves the agent with incomplete expectations.
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-structured sentence that front-loads 'Authentication operations'. It is appropriately concise, though it sacrifices detail for brevity.
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 tool's complexity (6 enum actions, nested data object, no output schema), the description is too sparse to be complete. It does not describe return values, error conditions, or action-specific 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?
All parameters are documented in the schema with clear descriptions, and the tool description adds no additional semantic value. Per the rubric, baseline is 3 given high schema coverage.
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 identifies this as the authentication tool with specific areas (login flows, token management, terms acceptance), distinguishing it from the project management sibling tools. However, it lacks enumeration of the exact actions available, which are only in the schema.
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 for authentication operations but does not explicitly specify when to use this tool vs alternatives or when not to use it. It also lacks guidance on choosing between the different actions (e.g., login vs oidcExchange).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Manage Planka boards. Boards contain lists and cards for organizing work.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Board ID (for get, update, delete) or Project ID (for create, use projectId in data) (required for: get, update, delete) | |
| data | No | Board data: { name: string, projectId?: string (for create), position?: number, defaultView?: 'kanban'|'grid'|'list' } (required for: create, update) | |
| action | Yes | Action to perform: 'get' - Get board details by ID; 'create' - Create a new board in a project; 'update' - Update board settings; 'delete' - Delete a board |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations provided, so the description must fully disclose behavioral traits. It fails to mention that 'delete' is destructive, that actions may require specific permissions, or any side effects. The word 'manage' hints at mutation but does not transparently describe effects or 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?
The description is concise with only two sentences. The first sentence identifies the resource, and the second provides minimal domain context. It is front-loaded, but the second sentence is marginally useful and could be considered padding, so it earns a 4 rather than a 5.
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?
Despite the rich schema, the description does not provide enough high-level context for an agent to understand when to use this tool, how it relates to projects, or what actions are available. It lacks behavioral and usage context, making it incomplete for a CRUD tool with no 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 description coverage is 100%, and the parameter descriptions are detailed (including conditional requirements for 'id' and structured 'data' fields). The tool description itself adds no parameter semantics, so the baseline of 3 applies.
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 says 'Manage Planka boards' which is a generic verb and does not specify the specific operations (get, create, update, delete) that the tool performs. It adds context about boards containing lists and cards, but the core purpose is vague and does not distinguish it from sibling tools like lists or 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 provides no guidance on when to use this tool versus alternatives such as 'lists' or 'cards'. It does not mention any prerequisites, scenarios, or exclusions. There is no information about when to choose 'boards' over other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get Planka application bootstrap data including current user, projects, boards, and notifications.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | Action: 'get' - Retrieve bootstrap data |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full transparency burden. It uses the verb 'Get' suggesting a read operation, but does not disclose authentication needs, side effects, rate limits, or any safety related behavior beyond the implicit read.
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 that states the action and resource without redundancy. Every word contributes meaning, making it highly concise and 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?
Given the absence of an output schema, the description provides useful context by enumerating the key return components (user, projects, boards, notifications). It doesn't exhaustively list all possible fields, but is sufficient for a simple bootstrap tool with one parameter.
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 fully covers the only parameter 'action' with an enum and description, achieving 100% coverage. The description adds no parameter-specific details, so the baseline score 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 the tool retrieves Planka bootstrap data, listing the included resources (current user, projects, boards, notifications). This distinguishes it from sibling tools that each manage a single resource, making the purpose unmistakable.
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 choose this tool over siblings like 'projects' or 'boards'. The description implies it fetches a consolidated snapshot, but doesn't explicitly say to use it for app initialization or instead of multiple individual calls.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Manage user assignments on Planka cards.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Card ID (required for: add, remove) | |
| data | No | Membership data: { userId: string } (required for: add, remove) | |
| action | Yes | Action to perform: 'add' - Assign a user to a card; 'remove' - Remove a user from a card |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'Manage user assignments' and gives no information about side effects, permission requirements, or consequences of add/remove actions. This is a significant gap 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 concise sentence with no filler. It is front-loaded and efficient, though its brevity sacrifices some clarity for purpose.
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 tool has no annotations and no output schema, the description should provide more context about return values, prerequisites, or effects, but it does not. The description is too minimal to fully inform the agent about how to use the tool safely and effectively.
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 has 100% description coverage for all three parameters, so the baseline is 3. The description adds no extra semantic value beyond the schema, but the schema itself is sufficiently descriptive.
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 'Manage user assignments on Planka cards' uses the generic verb 'manage' and does not specify the concrete actions (add/remove) that are only defined in the schema. It does identify the resource (card members) and distinguishes it from sibling tools, but lacks the specificity needed for a clear purpose.
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 given on when to use this tool versus alternatives like cards or comments. The description does not mention use cases, prerequisites, or exclusions, leaving the agent to infer from the schema alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Manage Planka cards. Cards are individual work items on a board.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Card ID (for get, update, delete) or List ID (for list, create) (required for: list, get, update, delete) | |
| data | No | Card data: { name: string, type?: 'project'|'story', listId?: string (for create/move), description?: string, dueDate?: string, isDueCompleted?: boolean, position?: number, stopwatch?: { startedAt: string, total: number } } (required for: create, update) | |
| query | No | Query parameters for filtering/pagination | |
| action | Yes | Action to perform: 'list' - Get cards from a list (requires listId); 'get' - Get card details by ID; 'create' - Create a new card; 'update' - Update card properties; 'delete' - Delete a card |
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 only says 'Manage' without indicating that create/update/delete actions are destructive, whether special permissions are required, or what side effects occur. The schema lists actions but that is structured data, not descriptive 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?
The description is only two sentences with no redundancy or filler. It front-loads the purpose and provides a clear definition of the domain. Though it is sparse, it is appropriately concise for what it contains, earning a 4.
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 tool's complexity—four parameters, nested objects, five distinct actions, and no output schema—the description is far too minimal. It does not explain return values, action-specific behavior, or how to choose between actions. The schema covers parameters but not the broader usage context, leaving the description incomplete.
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 provides 100% coverage with detailed descriptions for all parameters, including the action enum and nested data object. The description adds no additional parameter semantics, but also does not need to compensate since the schema is thorough. 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 states 'Manage Planka cards' which identifies the resource and a general action verb. Adding 'Cards are individual work items on a board' provides domain context. However, 'Manage' is broad and does not explicitly distinguish the tool from sibling tools like tasks or lists, so it is clear but not fully differentiating.
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?
There is no guidance on when to use this tool versus alternatives such as lists, tasks, or comments. No context around prerequisites, common use cases, or exclusions is provided. The description only defines what cards are, not when to invoke this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Manage comments on Planka cards.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Card ID to get/add comments (required for: list, create) | |
| data | No | Comment data: { text: string } (required for: create) | |
| query | No | Query parameters for filtering/pagination | |
| action | Yes | Action to perform: 'list' - Get comments for a card; 'create' - Add a comment to a card |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully disclose behavioral traits. It merely says 'manage' without indicating whether operations mutate data, require permissions, or have side effects. It does not mention that 'list' is read-only or that 'create' is a write 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 a single sentence with no waste, but it is under-specified for a tool with four parameters and multiple actions. It is not a tautology, yet it lacks substantive 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 the absence of annotations and an output schema, the description should explain the available actions and expected return values. The one-sentence description is incomplete for a tool with four parameters and nested objects, leaving the agent without crucial 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 description coverage is 100%, so the input schema already documents all parameters and their meanings. The description adds no additional parameter-specific value, making the baseline score of 3 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 uses the vague verb 'manage' and does not enumerate the specific actions (list, create) that appear in the schema. It names the resource ('comments on Planka cards') but lacks the specificity needed to distinguish it from sibling tools or clarify its exact functionality.
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?
There is no guidance on when to use this tool or how it relates to alternatives. The description provides no context on which action to select or how this tool differs from siblings like cards or tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Manage labels on Planka boards and cards. Labels help categorize and filter cards.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Board ID (for create), Label ID (for update, delete), or Card ID (for addToCard, removeFromCard) (required for: create, update, delete, addToCard, removeFromCard) | |
| data | No | Label data: { name?: string, color: string, position: number } for create/update, { labelId: string } for addToCard/removeFromCard. Colors: muddy-grey, autumn-leafs, morning-sky, antique-blue, egg-yellow, desert-sand, dark-granite, fresh-salad, lagoon-blue, midnight-blue, light-orange, pumpkin-orange, light-concrete, sunny-grass, navy-blue, lilac-eyes, apricot-red, orange-peel, silver-glint, bright-moss, deep-ocean, summer-sky, berry-red, light-cocoa, grey-stone, tank-green, coral-green, sugar-plum, pink-tulip, shady-rust, wet-rock, wet-moss, turquoise-sea, lavender-fields, piggy-red, light-mud, gun-metal, modern-green, french-coast, sweet-lilac, red-burgundy, pirate-gold (required for: create, update, addToCard, removeFromCard) | |
| action | Yes | Action to perform: 'create' - Create a label on a board; 'update' - Update a label's name, color, or position; 'delete' - Delete a label from a board; 'addToCard' - Add a label to a card; 'removeFromCard' - Remove a label from a card |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral disclosure burden. It only states the tool 'manages' labels without revealing side effects, permission requirements, destructive actions (e.g., delete), or any other behavioral traits. The action enum in the schema describes operations, but the description itself adds no transparency.
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 extremely concise, consisting of two short sentences. Every word earns its place, with no redundant or irrelevant content, making it easy to parse quickly.
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 tool's multi-action nature and nested data, the schema is thorough, but the description remains minimal. It does not explain the polymorphic use of 'id' (board, label, or card depending on action) nor any permissions or side effects. The schema covers most details, so completeness is adequate but not enriched.
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%, and the action parameter's enum and data object descriptions are quite detailed. The tool description adds no extra meaning beyond the schema, so the baseline score 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 identifies the tool as managing labels on Planka boards and cards, which clearly distinguishes it from sibling tools like 'boards' or 'cards'. However, the verb 'manage' is generic, and the full range of operations is only revealed via the action parameter in the schema.
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 no explicit guidance on when to use this tool versus alternatives. The second sentence ('Labels help categorize and filter cards') hints at a use case but does not explain when to choose labels over other entities like lists or cards, nor does it list exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Manage Planka lists. Lists are columns on a board that contain cards.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | List ID (for get, update, delete) or Board ID (for create, use boardId in data) (required for: get, update, delete) | |
| data | No | List data: { name: string, boardId?: string (for create), position?: number, type?: 'active'|'closed' } (required for: create, update) | |
| action | Yes | Action to perform: 'get' - Get list details and cards; 'create' - Create a new list on a board; 'update' - Update list settings; 'delete' - Delete a list |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of disclosing behavioral traits. The description only says 'Manage Planka lists' and defines what a list is; it does not disclose side effects of create/update/delete, permission requirements, reversibility, or return values. The schema describes actions, but the description adds no behavioral 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?
The description is concise, with two short sentences that contain relevant information without waste. It is front-loaded with the core purpose and then clarifies the domain concept. However, it is quite brief, which limits its helpfulness but does not detract from conciseness.
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 handles four distinct CRUD actions on a nested object schema, yet the description provides only a minimal definition. With no output schema or annotations, the description is incomplete for guiding an AI agent on when to use each action or what outcomes to expect. The schema partially fills this gap, but the description itself is too thin for the tool's complexity.
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 itself adds no parameter-specific meaning beyond the schema; it only provides the general context that lists are columns on a board. The schema already provides sufficient detail for id, data, and action, so the description does not need to compensate.
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 'Manage Planka lists' clearly specifies a verb and resource, and the additional sentence 'Lists are columns on a board that contain cards' helps distinguish this tool from the sibling tools for boards and cards. However, it does not enumerate the specific actions (get/create/update/delete) which are only available in the schema, so it is clear but not fully self-contained.
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 phrase 'Lists are columns on a board that contain cards' implies that this tool handles list-level operations, but there is no explicit guidance on when to use this tool versus alternatives like cards or boards. No exclusions or alternative tool names are mentioned, so usage context is only weakly implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Manage Planka projects. Projects are top-level containers for boards.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Project ID (required for: get, update, delete) | |
| data | No | Project data: { name: string, description?: string, backgroundType?: 'gradient'|'image', backgroundGradient?: string } (required for: create, update) | |
| action | Yes | Action to perform: 'list' - List all accessible projects; 'get' - Get project details by ID; 'create' - Create a new project; 'update' - Update project settings; 'delete' - Delete a project |
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 says 'manage,' which implies CRUD operations but fails to mention destructive actions, permission requirements, side effects, or return formats. This is a significant gap for a tool with delete/update actions.
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 very concise at two sentences, with no redundant phrasing. It front-loads the main purpose and adds a clarifying context about project hierarchy. However, it is slightly under-specified for the tool's complexity, but that is more a completeness issue than conciseness.
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 CRUD tool with 5 distinct actions and a nested data object, the description lacks critical context about when to use each action, what results to expect, or error scenarios. The schema helps with parameter semantics, but without output schema or behavioral notes, the description is incomplete for an agent to fully understand the tool's capabilities.
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 already has 100% coverage with detailed descriptions for all three parameters, including the action enum and data object. The description adds no additional parameter meaning beyond what the schema provides, so the baseline of 3 applies.
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 'Manage Planka projects' which clearly identifies the resource but uses the generic verb 'manage' rather than a specific action. It does differentiate by noting projects are 'top-level containers for boards,' distinguishing from sibling tools like boards and lists.
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?
There is no explicit guidance on when to use this tool vs alternatives. The usage is implied by the tool's name and the context of being the projects resource, but no exclusions or alternative recommendations are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Manage task lists and tasks on Planka cards. Tasks are checklist items within a card.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Task List ID (for getList), Card ID (for createList), Task List ID (for create, use taskListId in data), or Task ID (for update) (required for: getList, createList, create, update) | |
| data | No | Data: { name: string, cardId?: string (for createList), taskListId?: string (for create), isCompleted?: boolean (for update), assigneeUserId?: string } (required for: createList, create, update) | |
| action | Yes | Action to perform: 'getList' - Get a task list by ID; 'createList' - Create a task list on a card; 'create' - Create a task in a task list; 'update' - Update a task |
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, but it only says 'manage' without revealing that operations create, update, or delete, or any side effects or permissions. This is vague and provides minimal transparency.
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, front-loaded with the purpose, and contains no fluff. Every word earns its place, making it 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?
Despite a detailed schema, the description is too minimal for a tool with four actions and a nested data object. It omits usage guidelines and behavioral context, leaving the agent without sufficient information to select and use the tool effectively.
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 has 100% parameter description coverage, so the baseline is 3. The description adds no additional meaning beyond the schema, which already explains IDs and data fields in detail.
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 identifies the resource being managed—task lists and tasks on Planka cards—and distinguishes this tool from siblings like cards and lists. However, the verb 'manage' is generic and could be more specific about CRUD operations, so it doesn't reach a 5.
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 by stating that tasks are checklist items within a card, suggesting this tool is for checklist-related operations. However, it provides no explicit exclusions or alternatives, such as 'for card details use the cards tool.'
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.
v2.0.4authboardsbootstrapcardMemberscardscommentslabelslistsprojectstasksScored across 10 tools
Each tool targets a distinct Planka resource or function: projects, boards, lists, cards, comments, tasks, labels, cardMembers, plus bootstrap and auth. There is no overlap in primary purpose, and even the potentially confusing lists vs. tasks are clearly differentiated by their descriptions (columns vs. checklist items).
Tool names are mostly single lowercase nouns representing resources (projects, boards, lists, cards), which is a consistent pattern. However, 'cardMembers' uses camelCase breaking the all-lowercase convention, and 'bootstrap' and 'auth' are not resource CRUD names, creating minor semantic deviation.
With 10 tools covering core Planka entities and operations, the count is well-scoped for the domain. It is neither too thin nor overly heavy, fitting comfortably within the typical 3-15 tool range for a focused CRUD server.
The tool set covers the primary resource lifecycle for projects, boards, lists, cards, comments, tasks, labels, and members, which is sufficient for most workflow needs. Minor gaps exist (e.g., no explicit search, activity log, or attachment support), but these are not critical for baseline operations.
Read and manage your EasyKanban kanban boards: to-do summaries, create, update, and move cards.
Remote MCP for Kanban AI boards—manage projects, tasks, and comments from AI tools.
Task & board management for AI agents + humans. Kanban, comments, digests via MCP.
Create and manage MeisterTask projects, tasks, and notes from your AI assistant.
