planka-mcp

by omnicoreos

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation4/5
Most tools target distinct resources and actions, but a few boundaries are slightly fuzzy: planka_get_card includes comments and labels while planka_get_comments is comment-specific, and planka_set_card_labels vs planka_manage_labels could be confused at a glance. Overall, descriptions clarify the intended use well enough.
Naming Consistency5/5
All tools follow a consistent planka_<verb>_<noun> snake_case pattern. Verbs like get, create, update, delete, move, add, set, and manage are used predictably, and the naming style is uniform throughout.
Tool Count5/5
15 tools is well-scoped for a Kanban/project-management server. Each tool covers a meaningful operation on cards, tasks, comments, lists, labels, or board structure without unnecessary redundancy.
Completeness4/5
The card lifecycle is fully covered (create, read, update, delete, move), and tasks, lists, labels, and comments have solid coverage. Minor gaps exist: there is no board/project creation or deletion, and comments cannot be updated or deleted, but these are not severe dead ends for typical workflows.
Average 3.8/5 across 14 of 15 tools scored. Lowest: 3.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 7 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears the full burden of behavioral disclosure. It only states the action types without explaining that the action parameter determines which IDs are required (boardId for create, labelId for update/delete), that delete is permanent, or any side effects. The description adds no behavioral context beyond the literal action words.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no verbose filler. It front-loads the core verb and resource. While some might argue it is too terse for full completeness, the conciseness itself is exemplary; no words are wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity—five parameters, an enum action, and conditional required fields—the description is far from complete. It does not explain how the action parameter drives the input requirements, nor does it mention return values or any usage context. An agent would need to inspect the schema carefully to understand the conditional logic, which a well-formed description should preempt.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 does not elaborate on any parameter semantics—it merely repeats the action types. The conditional requirements (e.g., boardId for create, labelId for update/delete) are already encoded in the schema's descriptions, so the description adds no additional value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb-resource combination: 'Create, update, or delete labels on a board.' It covers all three CRUD actions and clearly distinguishes from sibling tool planka_set_card_labels, which handles assigning labels to cards rather than managing label definitions. This is precise and immediately scopes the tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 is provided. It does not mention that this is for managing label metadata (e.g., names, colors) as opposed to assigning labels to cards, nor does it reference any sibling tool. The agent is left to infer context from the name alone, which is insufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 behavioral disclosure. It indicates a mutation but does not explain side effects, whether omitted fields are preserved, permission requirements, or what the response contains.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler, and the core action and affected fields are front-loaded. It is concise and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 3-parameter update tool, the description plus fully documented schema is minimally viable, but it lacks usage guidance and behavioral context such as partial update behavior or return value. No output schema or annotations exist to compensate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter already described ('New task name', 'The task ID', 'Mark as complete/incomplete'). The description adds little beyond mapping 'completion status' to isCompleted, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Update') and resource ('a task'), and names the exact fields affected ('name or completion status'). This clearly distinguishes it from sibling tools like planka_create_tasks and 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.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to choose this tool over alternatives such as planka_create_tasks or planka_update_card, and no exclusions or prerequisites are stated. Usage is only implied by the word 'update'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. It implies a mutation operation (update) but doesn't state whether it's destructive, if it requires specific permissions, or if it partially updates only provided fields. The description adds a hint of safety by implying it's a targeted update, but there's no explicit disclosure of 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the primary purpose and lists the key fields. It's efficient and easy to parse, with no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 5 parameters, a simple schema, and no output schema, which reduces complexity. The description covers the core action and fields but doesn't explain partial update behavior or return values, which could be useful. Given the simplicity, the description is mostly complete but could be slightly richer with usage context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 parameters. The description re-lists some fields (name, description, due date) but doesn't add new meaning like behavior when parameters are omitted or how null values clear fields. The schema's descriptions already cover these semantics, so the description adds minimal value beyond the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool updates a card's properties and lists specific fields (name, description, due date, completion status), distinguishing it from sibling tools like create_card or move_card. It is specific enough for an agent to understand the resource and action, though it doesn't name a sibling to differentiate from.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for modifying existing cards, which is clear from the context. However, it doesn't provide explicit guidance on when to use this versus alternatives like planka_create_card or planka_move_card, nor does it mention any prerequisites (e.g., card must exist). This is adequate but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 action and optional task inclusion, without mentioning side effects, idempotency, permissions, or error handling. As a mutating operation, more transparency is expected to prevent misuse.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no fluff. The primary action is front-loaded, and the optional task feature is stated secondary. It is easily scannable and to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a create tool with full schema coverage, the description is minimal but sufficient for basic invocation. However, it does not reference the sibling tool planka_create_tasks, which could lead to misuse when adding tasks to an existing card. Additionally, no return value or post-creation behavior is mentioned, though no output schema exists to fill that gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides complete descriptions for all six parameters, so the baseline is 3. The description adds no extra parameter insight beyond restating that tasks are checklist items, which the schema already mentions. Therefore, it does not enhance parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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' with a specific verb and resource. It also mentions the optional task functionality, distinguishing it from tools like planka_create_tasks. This makes the purpose unambiguous and distinct from sibling operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage context is implied: you use this tool to create a card. However, there is no explicit guidance on when to use alternatives like planka_create_tasks for adding tasks later, nor any exclusions or conditions. The phrase 'at the same time' hints at a timing option but does not clarify the separation of concerns.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. It states the mutation ('Add') but does not disclose what happens to existing tasks, whether the operation is idempotent, what response is returned, or any authorization requirements. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, no filler, with the action and target front-loaded. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, two-parameter tool with a fully described schema, the description plus schema is largely sufficient for invocation. It does not cover behavioral edge cases like duplicate task names or whether an existing checklist is appended to, but the low complexity makes this minor.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 cardId and tasks. The description only reinforces 'one or more' and 'to a card' without adding syntax, format, or relationship details, which matches the baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Add'), resource ('tasks'), and clarifies they are checklist items attached to a card. This distinguishes it from sibling tools like create_card or update_task, so an agent can identify the operation immediately.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool—when adding one or more checklist tasks to a card—but gives no explicit guidance about alternatives or exclusion criteria. It does not mention update_task/delete_task or clarify prerequisites such as card existence.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full burden. 'Get' clearly signals a read-only operation, and the description discloses what content is returned. It does not cover auth requirements, cost, or rate limits, but for a simple fetch tool this is a reasonable baseline.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that front-loads the verb and resource, then enumerates the included content without filler. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter read tool with full schema coverage and no output schema, the description is largely sufficient — an agent needs only cardId to invoke it correctly. It could name sibling tools for routing, but nothing essential is missing for a correct call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% — cardId is already described as 'The card ID'. The description adds no further meaning about parameter format, how to obtain the ID, or expected values, which matches the baseline for fully documented schemas.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Get), resource (card), and the content scope (tasks, comments, labels, attachments). The listed contents implicitly distinguish it from planka_get_comments (scoped to comments only), though this differentiation is implied rather than explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied through the listed content — an agent can infer that retrieves the full card payload versus sibling tools like planka_get_comments or planka_get_structure. However, there is no explicit when-to-use or when-not-to-use statement, nor mention of alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the scope ('all comments') and implies a read-only operation via 'Get', but it does not mention any behavioral traits such as ordering, limits, or the shape of returned data. This is adequate for a simple retrieval but adds minimal context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no unnecessary words. It is front-loaded with the core action and resource, making it immediately scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get operation with one required parameter and no output schema, the description is complete. It states the resource ('comments on a card') and implies the need for a card ID. Nothing an agent needs to call this tool correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100% with a clear description for cardId. The tool description does not add any additional meaning beyond what the schema already provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get all comments on a card' clearly states the specific action (get) and resource (comments on a card), making it distinct from sibling tools like planka_add_comment or planka_get_card. The scope is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. It does not name any sibling tools or describe contexts where another tool might be more appropriate. Usage is only implied by the name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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. However, it only restates the action verbs already present in the schema enum and does not disclose side effects, irreversibility, permissions, or what happens to cards/tasks when a list is deleted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence. Every word contributes: the verbs identify the operations and 'lists on a board' identifies the target resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The input schema is complete and the description is clear enough for basic use. However, there is no output schema, no annotations, and no mention of what the tool returns, how errors surface, or the consequences of each action, so the context is only minimally sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all parameters are already documented in the schema. The description adds no parameter-level meaning, which matches the baseline for a schema that covers every parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
It names the primary operations (create, update, delete) and the specific resource (lists on a board). Among the siblings, only planka_manage_labels is similarly phrased but for a different resource, so this tool is clearly differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'lists on a board' makes it clear when this tool applies: for list lifecycle operations. It does not explicitly name an alternative or state exclusions, but there is no sibling dedicated to lists, so the usage context is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 behavioral disclosure. It indicates a mutation ('Add') but does not mention permissions, idempotency, side effects, or what the response contains. This is a significant gap for a write operation with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences convey the action and use cases without any wasted words. The core purpose is front-loaded, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with no nested objects and no output schema, the definition gives enough context to invoke it correctly. It does not describe return values or side effects, but the use-case framing and schema coverage make the tool's operation reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters are already documented in the input schema. The description adds no extra parameter-level detail, but the baseline of 3 applies because the schema handles the parameter semantics sufficiently.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb-resource pairing: 'Add a comment to a card.' This clearly identifies the action and target, and naturally distinguishes it from sibling tools like planka_get_comments and planka_set_card_labels.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Use this for status updates, notes, or agent activity logs' gives practical context for when to invoke the tool. It does not explicitly name alternatives or exclusions, but the intended use cases are clear enough for an agent 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden and it does disclose the most critical trait: the delete is permanent and cannot be undone. This is exactly what an agent needs before invoking a destructive tool; it stops short of describing cascading effects or response shape.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with zero filler. The core action is front-loaded ('Permanently delete a card') and the irreversibility warning earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter tool this is close to sufficient, but with no annotations and no output schema the description still leaves unspecified whether deleting a card also deletes its tasks/comments and what the caller can expect in the response. The irreversibility warning mitigates but does not fully close this gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is only one parameter and schema description coverage is 100%, so the schema already defines cardId as 'the card ID to delete.' The description adds no extra semantic detail, but none is necessary at this complexity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('delete') and resource ('card') and adds the permanence qualifier, so an agent can distinguish it from get_card, update_card, move_card, and create_card. No tautology or ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implied: choose this when a card should be permanently removed. However, it does not explicitly state when not to use it or compare it to alternatives, and it gives no preconditions beyond selecting a cardId.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must carry the behavioral burden. It indicates a read-only operation via 'Get' and states what is returned, but it does not disclose any further behavioral details such as response structure or how includeTaskCounts affects results.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the operation and scope. The second sentence adds a clear usage instruction without redundancy, so every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple board-fetching tool with one required parameter and one documented optional parameter, the description is sufficient. It states what is returned, and the schema covers parameter semantics. No output schema exists, but the description compensates by naming the returned content.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameter meanings are already documented. The description adds no extra meaning beyond the schema, meeting the baseline for a fully documented schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Get') and a specific resource ('a board') with an explicit scope: all its lists, cards, and labels. This clearly distinguishes it from narrower siblings like get_card or get_comments.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear usage context: use this when you want to see everything on a board. It does not explicitly list alternatives or exclusion cases, but the intended use is obvious and unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. 'Get' clearly frames this as a read operation)Skip, which is adequate. However, it doesn't state anything explicit about side effects (there are none expected), data size, or whether the response nests cards. For a pure retrieval tool that is evidently read-only, this is acceptable but not exemplary.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the primary purpose. Every sentence earns its place — the first states the action, the second gives usage intent. No filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool (1 optional param, no output schema), the description covers what it returns (full project/board/list structure) and when to use it (before working with cards). It might briefly mention how this relates to planka_get_board, but for a discovery tool this is largely sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% — the projectId parameter is fully described in the schema ('Optional: Get structure for a specific project only'). The description itself adds no parameter-level meaning beyond what the schema already provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Get') plus a concrete resource ('full project/board/list structure') and names the navigation intent. It is clearly distinct from siblings like planka_get_board or planka_get_card, which retrieve narrower targets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs when to use it: 'before working with cards' to discover what projects/boards exist. It doesn't spell out when not to use it or how it compares to planka_get_board (which is a sibling), so it misses a small exclusion note, but the primary use case is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full behavioral burden. It discloses a notable behavior: 'Reports what actually landed on the card, verified by re-reading it,' revealing a post-operation verification step. Yet it does not mention whether the change is idempotent, how errors on invalid label IDs are handled, or whether it merges or replaces the label set—though the schema's add/remove semantics imply merging. Thus it is partially transparent but incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and well-structured: two short sentences that front-load the core action, then provide a key input caveat, and finally disclose the verification behavior. Every sentence earns its place, with no filler or repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 parameters (one required), no output schema, and no annotations, the description covers the essential aspects: purpose, input source for IDs, and post-action verification. It omits edge cases like error handling or behavior when no labels are specified, and it does not explicitly state the return value, but the verification note implies a response. Given the tool's moderate complexity, this is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so all parameters are documented. The description adds valuable semantic guidance beyond the schema by directing the agent to use label IDs from planka_get_board rather than names, and by implicitly clarifying the behavior of addLabelIds vs removeLabelIds through the description's 'add or remove' phrasing. This compensates for any potential ambiguity about the alias relationship, which is already in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear verb and resource ('Add or remove labels from a card') and adds crucial specificity by instructing to pass label IDs from the board rather than names, referencing planka_get_board. This differentiates it from sibling tools like planka_manage_labels, which likely handles label definitions, by focusing on card-level assignment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives an explicit operational guideline: 'Pass label IDs from the board (planka_get_board lists them), not label names.' This tells the agent exactly what input to fetch and how to structure the call. However, it does not explicitly state when to prefer this tool over alternatives such as planka_manage_labels, leaving some comparison implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must itself convey side effects. It only says 'delete', which implies removal but does not explicitly state irreversibility or any potential cascading effects. This is a minor gap for a destructive operation, so a score of 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, straightforward sentence without redundant information. It is concise and to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete operation with one parameter and no output schema, the description covers the essential context. It does not mention preconditions (e.g., task must exist) but that is generally implied and not critical for such a simple operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter 'taskId' is described as 'The task ID to delete', which fully explains its purpose and type. No further elaboration is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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 'task', making the purpose unambiguous. It distinguishes the tool from sibling tools like 'planka_delete_card' without needing further clarification.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies the action and resource, which is sufficient for a delete operation. It does not explicitly compare with alternatives, but given the tool name and sibling context, usage is clear. It could have added a note about when to use it versus other task-related tools, but that is not necessary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It clearly indicates a mutation action ('Move') and hints at the effect on card state (changing list/position). It doesn't disclose possible side effects like sorting behavior or potential errors, but the main behavioral trait (moving between lists) is transparent. The example also gives a practical cue.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no waste. The core purpose is front-loaded, and the example is a single parenthetical. It's appropriately sized for a tool with three parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (3 params, no output schema, no annotations), the description covers the essential context: what it does, when to use it, and the position parameter semantics. It lacks explicit mention of return behavior (e.g., returns updated card or success message), but for a move action, that may not be critical. The sibling list provides navigation context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already describes all three parameters. The description adds the workflow context and clarifies that position is optional (default end). However, it doesn't add detail beyond the schema's own descriptions, but since the schema is complete, the baseline is 3, and the description's example slightly elevates it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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 a different list or position') with specific verbs and resources, and immediately distinguishes it from sibling tools like planka_update_card (which updates card fields) and planka_create_card. The example workflow ('To Do' -> 'In Progress') makes the purpose concrete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool: for workflow transitions. It doesn't explicitly mention alternatives or exclusions, but the sibling list makes the context clear. Since it's a specific move action, the usage context is fairly self-evident, but it could have noted that this is distinct from updating card fields (planka_update_card).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![planka-mcp MCP server](https://glama.ai/mcp/servers/omnicoreos/planka-mcp/badges/card.svg)](https://glama.ai/mcp/servers/omnicoreos/planka-mcp)

Score Badge

Copy to your README.md:

[![planka-mcp MCP server](https://glama.ai/mcp/servers/omnicoreos/planka-mcp/badges/score.svg)](https://glama.ai/mcp/servers/omnicoreos/planka-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/omnicoreos/planka-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server