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., "@ya-planka-mcp List all cards in the TODO column"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A Model Context Protocol (MCP) server that enables AI clients to read and manage your Planka boards using the Planka REST API.
New here? Four steps to a running, registered server — minimal detail, each one links to the full section below if you need it.
Clone the repo:
git clone https://github.com/andrejberg/ya-planka-mcp
cd ya-planka-mcpInstall dependencies: uv sync (see Installation for the pip alternative).
Get an API key and fill in .env: log in to Planka as an admin,
generate an API key, then:
cp .env.example .env
# edit .env: set PLANKA_BASE_URL and PLANKA_API_KEYFull walkthrough: Obtaining API Credentials.
Register the server with your MCP client — Claude Desktop, Claude Code, or any generic client: see MCP Client Configuration.
That's the whole path. For dependency details, alternate install methods, credential fallbacks, troubleshooting, and everything else, keep scrolling.
Related MCP server: Another Planka MCP
ya-planka-mcp provides a lightweight bridge between MCP clients and your self‑hosted Planka instance. It exposes projects, boards, lists, cards, tasks, and labels through MCP tools, allowing agents to use planka for the full project management and execution live cycle.
List projects, boards, lists, labels, and members — full dump or scoped to one board
Search and retrieve cards with multiple detail levels
Read card checklists with real task IDs and accurate progress counts
Create, update, delete, and bulk-move cards
Create, update, and delete checklist tasks and task lists
Manage labels (create idempotently, assign, remove) and card members
Read and write card comments
Scaffold complete boards (canonical kanban lists + lifecycle labels) in one call
Composite workflow tools: next workable card, mechanical readiness checks, and a computed one-call board status report
Token-optimized: detail levels, scoped responses, slimmed schemas — measured by a committed audit script
Works with any MCP‑compatible client
Example use cases:
"Show all 'In Progress' cards across my workspace."
"Create a new card in <Board> / TODO with subtasks…"
"Find the 'Login bug' card and list all tasks."
"Mark the 'Write tests' task as complete."
"Add the 'Urgent' label to the 'Deploy' card."
Python 3.10+
uv (recommended) or pip + venv
Access to a Planka instance
A Planka account you're comfortable letting the MCP server act as (see Obtaining API Credentials below — the account's role determines what the server can do; see Roles & Permissions)
git clone https://github.com/andrejberg/ya-planka-mcp
cd ya-planka-mcpWith uv (recommended — creates .venv/ and resolves the lockfile):
uv syncThis installs runtime dependencies only. If you also want to run the test
suite (see Running Tests below), install the test extra instead:
uv sync --extra testOr with pip in a manually created virtualenv (the last two lines below —
installing requirements.txt then an editable install — are exactly what CI
runs in .github/workflows/test.yml, just without a venv there):
python3 -m venv venv
source venv/bin/activate
pip install -r requirements.txt
pip install -e .Note the venv directory name differs between the two paths: uv sync creates
.venv/; the pip walkthrough above creates venv/. This matters for the
run_server.sh helper script and the MCP client config below — pick one path
and stay consistent with it.
.env filecp .env.example .envThen fill in the variables below.
Variable | Required? | Purpose |
| Yes | Base URL of your Planka instance (e.g. |
| Option 1 | Recommended. The admin-generated API key from Planka's user administration screen — see Obtaining API Credentials. Checked second, only if |
| Option 2 | JWT access token from the legacy |
| Option 3 | Login credentials. The server exchanges them for a token automatically at startup. Checked last, only if neither token variable is set. |
Precedence is fixed in src/planka_mcp/api_client.py::initialize_auth:
PLANKA_API_TOKEN > PLANKA_API_KEY > PLANKA_EMAIL+PLANKA_PASSWORD — this
only matters if you set more than one. For a fresh setup, set just
PLANKA_API_KEY (the admin-generated key); see Obtaining API Credentials
below for how to get it.
.env.example also documents role-scoped variables
(PLANKA_API_TOKEN_BOARD_MANAGER, PLANKA_API_TOKEN_BOARD_MEMBER,
PLANKA_SMOKE_LIST_ID, PLANKA_SMOKE_LABEL_ID) — these are only read by the
opt-in test suite (see Opt-in permission smoke under Running Tests), not
by the server itself.
This server was developed and tested against Planka Community v2.0.3. In that version, generating an API key requires admin access — there is no self-service "generate my key" option for a regular board member.
Log in to your Planka instance as an admin user.
Open User Administration (the admin-only user management screen).
Generate an API key for the account you want the MCP server to act as — this can be the admin account itself or any other account. The key carries exactly that account's Planka permissions; see Roles & Permissions below for what a given account can and can't do through this server before picking which one to use.
Copy the generated key into .env:
PLANKA_API_KEY=your-generated-api-keyThat's the whole flow. If your Planka instance predates v2.0.3 or otherwise has no admin-generated API key screen, use one of the fallback methods below instead.
Older Planka versions (and any instance without an admin-generated API key
screen) expose a JWT token via the /api/access-tokens endpoint — the same
exchange the Planka web client performs internally on login:
curl -X POST https://your-planka-instance.com/api/access-tokens \
-H "Content-Type: application/json" \
-d '{
"emailOrUsername": "your-email@example.com",
"password": "your-password"
}'Response:
{
"item": {
"accessToken": "..."
}
}Copy the accessToken value into .env as PLANKA_API_TOKEN.
Note: JWT tokens may expire. If you get authentication errors later, repeat the exchange to mint a new one.
If you'd rather not mint a token up front, set PLANKA_EMAIL and
PLANKA_PASSWORD directly — the server performs the same JWT exchange
automatically at startup:
PLANKA_EMAIL=your-email@example.com
PLANKA_PASSWORD=your-passwordThis is only used if PLANKA_API_TOKEN and PLANKA_API_KEY are both unset.
The server is a stdio MCP server; the actual entry point every config below
runs is mcp_server.py (main.py exists only as a legacy wrapper that
subprocesses into mcp_server.py). Replace /path/to/ya-planka-mcp with
your clone's absolute path.
Edit claude_desktop_config.json (macOS:
~/Library/Application Support/Claude/claude_desktop_config.json; Windows:
%APPDATA%\Claude\claude_desktop_config.json).
If you installed with uv sync (step 2 above):
{
"mcpServers": {
"ya-planka-mcp": {
"command": "uv",
"args": ["--directory", "/path/to/ya-planka-mcp", "run", "python", "mcp_server.py"],
"env": {
"PLANKA_BASE_URL": "https://your.domain",
"PLANKA_API_KEY": "<token>"
}
}
}
}If you installed with pip into venv/ (step 2 above), point directly at
that interpreter — use absolute paths for both command and the script
argument, since the client's working directory when it spawns the process is
not guaranteed to be this repo:
{
"mcpServers": {
"ya-planka-mcp": {
"command": "/path/to/ya-planka-mcp/venv/bin/python",
"args": ["/path/to/ya-planka-mcp/mcp_server.py"],
"env": {
"PLANKA_BASE_URL": "https://your.domain",
"PLANKA_API_KEY": "<token>"
}
}
}
}Either add a project-scoped .mcp.json at the root of the project you're
working in (not inside ya-planka-mcp itself):
{
"mcpServers": {
"ya-planka-mcp": {
"type": "stdio",
"command": "uv",
"args": ["--directory", "/path/to/ya-planka-mcp", "run", "python", "mcp_server.py"],
"env": {
"PLANKA_BASE_URL": "https://your.domain",
"PLANKA_API_KEY": "<token>"
}
}
}
}or register it with the CLI:
claude mcp add ya-planka-mcp \
--env PLANKA_BASE_URL=https://your.domain \
--env PLANKA_API_KEY=<token> \
-- uv --directory /path/to/ya-planka-mcp run python mcp_server.pyclaude mcp add defaults to --scope local (visible only to you, in this
project); pass --scope project to commit .mcp.json for teammates, or
--scope user to make the server available across all your projects.
Any client that can spawn a stdio subprocess needs only the same three pieces of information as the configs above:
command/args: uv --directory /path/to/ya-planka-mcp run python mcp_server.py
(or the direct venv-interpreter form if you installed with pip)
env: PLANKA_BASE_URL and one auth variable (see Environment variables above)
run_server.sh is an alternative launcher some clients may prefer over a raw
uv/python command — it activates ./venv (not .venv) if present and runs
mcp_server.py, or falls back to the system python3 running main.py
otherwise. It only auto-detects a venv literally named venv/, so it is
compatible with the pip install path above but not with uv sync's
.venv/; the explicit uv --directory ... / venv-interpreter forms above
work regardless of install method and are recommended.
29 tools, grouped by kind:
Tool | Purpose |
| Workspace structure (projects, boards, lists, labels, users). Pass |
| Authenticated user identity (id, username, role) |
| All labels on a board (fast targeted refresh) |
| Filter and list cards with detail levels ( |
| Search and fetch a specific card |
| Fetch a card with full checklist detail (real task IDs, progress counts) |
| List a card's comments, newest first, with optional prefix filter (e.g. |
Tool | Purpose |
| Scaffold a board with canonical kanban lists and lifecycle labels in one call |
| Create, rename, and reorder board lists |
| Card CRUD |
| Bulk-move 1–50 cards to a list (by id or name), order-preserving, per-card results |
| Checklist management |
| Label CRUD (create is idempotent by name) |
| Assign/remove board labels on cards |
| Assign/remove card members |
| Write a comment to a card |
Tool | Purpose |
| Top card of a list (default TODO) with everything needed to execute it — description, tasks with ids, labels, members, latest comments — in one round-trip |
| Mechanical readiness validation (labels, description sections, checklist shape) |
| One-call board report: per-list counts, in-progress ages, blocked cards with latest |
Responses support response_format (markdown/json) and, where reads can be
large, detail_level and scope filters. scripts/token_audit.py measures the
per-session tool-definition cost and live response sizes against your instance:
uv pip install tiktoken # optional, for exact o200k_base counts
.venv/bin/python scripts/token_audit.py [--board <name>] [--skip-live]Ask your assistant:
"List all my boards."
"Search for cards mentioning 'invoice'."
"Create a card named 'App release checklist' with these subtasks…"
"Move the 'Integrate payment API' card to 'Done'."
"Mark the 'Write tests' task on the 'Backend sprint' card as complete."
"Add the 'Urgent' label to the 'Deploy hotfix' card."
The MCP server does no role handling of its own. It acts as whatever
Planka user the configured API key (or email/password) belongs to — whatever
that account can do in Planka, the server can do through its tools; whatever
it can't, the server can't either. You control what the agent is capable of
entirely by which account's key you put in .env, and by adjusting that
account's rights inside Planka itself.
Planka distinguishes two kinds of board access, and this section uses Planka's own terms throughout:
Board manager — a user in the board's managers list. Only accounts with at least Project Owner or Admin role can be added as a board manager. Board managers get full card/task access plus board-level management (settings, members, labels).
Board member — a user added to a board with either edit or view-only rights. Edit rights allow card/task mutations; view-only is read-only. Board members — even with edit rights — cannot manage the board's members list or most board-level settings.
Capability | Board manager token | Board member token | Evidence |
List cards on a board list ( | Works | Not exercised by the board member live smoke (it never calls this tool) |
|
Create a card, read fresh card detail, delete the card | Works | Works |
|
Create a task list, add/update/delete a task | Works | Not exercised by the board member live smoke |
|
Add / remove a card label | Works | Not exercised by the board member live smoke |
|
Read | Works (implied) | Works — asserted explicitly ( |
|
Assign / remove another board member as a card member | Works | Not exercised — the board member smoke only self-assigns, consistent with board member tokens being unable to enumerate other users (see next row) |
|
Assign / remove yourself as a card member | Works (not the focus of this test) | Works — self-assign then self-remove is the entire point of the test |
|
| Populated | Empty. Planka returns | Source: |
Rows marked "not exercised" are not asserted anywhere in this repo's tests — they are not claimed to fail, only that the board member live smoke does not cover them. Only claim behavior beyond this table after adding a test that proves it.
A 403 on /api/users is invisible by design. If planka_get_workspace
comes back with no users, check the account's board role (planka_get_me)
before assuming a bug — a board member token gets an empty users map on
purpose, not an error.
Non-admin tokens silently see less, not an error. This is a Planka
platform characteristic (not asserted by this repo's own test suite): a
Planka user — and therefore a token scoped to that user — only sees
projects/boards/lists/cards it is a member of. A wrong or under-scoped token
does not raise; planka_get_workspace and planka_list_cards just return
fewer boards/cards than you expect. If something you know exists is
missing, check board membership for that token's user first.
The MCP server accesses only what the authenticated Planka user can access.
API token recommended over email/password.
Use HTTPS when exposing Planka externally.
Consider using a dedicated Planka service user with restricted permissions.
401 Unauthorized
Check token validity and .env configuration.
Client cannot connect to server Verify the correct Python/uv path, firewall rules, and execution permissions.
No boards or cards returned Confirm the Planka user has workspace access.
Task creation fails
Ensure you are passing a valid task_list_id. Use planka_get_card to retrieve real task list IDs from the card's checklist.
This project uses an editable install so the src/ directory is automatically on the Python path.
# Install in editable mode
uv sync
# or: pip install -e .Test dependencies (pytest and friends) live behind the test extra, not
the base install — run this once before the commands below:
uv sync --extra test# Run all offline tests
uv run pytest --cov=src/planka_mcp --cov-report=term-missing
# Run a specific test file
uv run pytest tests/test_cards.py -vThe repo includes an opt-in live smoke path that creates a card, task, and label on a real Planka board, then cleans up. It is skipped unless you opt in.
Required environment variables:
PLANKA_RUN_LIVE_SMOKE=1
PLANKA_BASE_URL
One auth method: PLANKA_API_KEY, PLANKA_API_TOKEN, or PLANKA_EMAIL + PLANKA_PASSWORD
The smoke test targets any writable list on your Planka instance — no disposable list or label IDs are required. Point it at a safe test board (e.g. "Test Project").
pytest does not auto-load .env — source it into the shell first:
set -a; source .env; set +a
uv run pytest -m live tests/test_live_smoke.py -q --no-covSafety contract:
Creates a disposable card and checklist task, then removes them
Label add/remove uses a reusable board label
Cleanup runs in finally even on failure
Fresh-state assertions after task mutation use a new API client (not cached reads)
planka_get_card caches per-card detail payloads for up to 60 seconds. Card mutation tools
that can affect detail output invalidate that card cache: comments, task lists/tasks, labels,
members, custom field values, card updates, moves, and deletes.
planka_list_cards reads the board view live for every call. Preview and summary output use
state present in that board response, including commentsTotal when comment bodies are not
loaded. Detailed list output fetches fresh detail for each paginated card before rendering so
tasks and comments reflect live Planka state instead of a stale detail cache.
For board-permission verification, run the gated permission smoke with role-scoped tokens. Tests are role-dependent:
test_non_owner_live_smoke_permissions uses PLANKA_API_TOKEN_BOARD_MANAGER
test_board_member_live_smoke_permissions uses PLANKA_API_TOKEN_BOARD_MEMBER
Required environment variables:
PLANKA_RUN_PERMISSION_SMOKE=1
PLANKA_BASE_URL (or PLANKA_PERM_BASE_URL)
PLANKA_API_TOKEN_BOARD_MANAGER for board manager-role smoke
PLANKA_API_TOKEN_BOARD_MEMBER for board member-role smoke
Optional explicit disposable targets: PLANKA_SMOKE_LIST_ID and PLANKA_SMOKE_LABEL_ID (or PLANKA_PERM_SMOKE_*)
set -a; source .env; set +a
PLANKA_RUN_PERMISSION_SMOKE=1 uv run pytest -m live tests/test_live_smoke.py -q --no-covnpx @modelcontextprotocol/inspector uv run python mcp_server.pyDev environment setup
git clone https://github.com/andrejberg/ya-planka-mcp
cd ya-planka-mcp
uv sync # editable install, src/ on the Python path
cp .env.example .env # fill in PLANKA_BASE_URL + a token before touching live testsBefore opening a PR
Run the offline suite with coverage — CI (.github/workflows/test.yml) runs
pytest --cov=src/planka_mcp --cov-report=xml --cov-fail-under=80 on every push/PR
to main; match that locally:
uv run pytest --cov=src/planka_mcp --cov-report=term-missing --cov-fail-under=80If the change touches role/permission behavior (anything in
src/planka_mcp/handlers/workspace.py, card membership, or label handling), run
the opt-in permission smoke locally against a real Planka instance with both
role tokens before describing the change as verified — see "Opt-in permission
smoke (role tokens)" above:
set -a; source .env; set +a
PLANKA_RUN_PERMISSION_SMOKE=1 uv run pytest -m live tests/test_live_smoke.py -q --no-covThis is not part of CI (it requires live credentials) — it is a pre-PR check for the author, not a merge gate.
Keep the Roles & Permissions matrix above honest: if a PR changes what a
board manager or board member token can do, update the matrix and its test in the
same PR — don't let the docs drift from tests/test_live_smoke.py.
New tools/handlers follow the existing layout: Pydantic models in
src/planka_mcp/models.py, handler functions in src/planka_mcp/handlers/,
matching tests in tests/.
PR expectations
Offline tests pass and coverage stays at or above 80% (CI enforces this).
No secrets (.env, tokens) committed.
README/docs updated when behavior, tools, or setup steps change.
Planka project: https://github.com/plankanban/planka
Model Context Protocol: https://modelcontextprotocol.io/
This project is a fork of another-planka-mcp by Roel van der Ven, adapted and substantially extended as ya-planka-mcp. The original implementation provided the foundation for Planka MCP integration; this fork introduces significant enhancements, new features, and production-oriented improvements.
MIT License. See LICENSE.
Add a label to a card.
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description only states 'add' without disclosing side effects (e.g., whether adding a duplicate label is ignored or throws error), authentication needs, or idempotency. Minimal 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?
Single sentence, front-loaded with action. No unnecessary words. Could add a bit more context without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool, the description and schema cover basic usage. Missing information about error handling, prerequisites (label must exist, card must exist), and return value. Sibling tools provide some 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?
The tool description adds no parameter information beyond what the input schema already provides (both parameters have clear descriptions in the schema). With 0% schema description coverage in the tool description, it fails to compensate, but the schema descriptions themselves are sufficient.
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 'Add a label to a card' clearly states the action (add) and resources (label and card), distinguishing it from sibling tools like planka_remove_card_label (remove) and planka_create_label (create).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The label_id parameter description hints at using planka_get_workspace, but no direct comparison to other tools is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add a member to a card.
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states the action without indicating side effects, idempotency, permissions, or error conditions.
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 fluff, but it is overly minimal, lacking necessary details that an agent would benefit from. Conciseness is achieved at the expense of completeness.
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?
With no output schema and no annotations, the description is incomplete for an agent to understand the full behavior of the tool. It does not cover what happens on duplicate membership, error states, or return value.
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 description adds no meaning beyond the input schema, which already includes descriptions for card_id and user_id. Baseline of 3 applies as schema covers parameter semantics.
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 'Add a member to a card.' uses a specific verb and resource, clearly distinguishing it from sibling tools like planka_add_card_label or planka_remove_card_member.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, no prerequisites mentioned (e.g., card and user must exist, permissions required), and no exclusions provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add a comment to a card.
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only repeats the tool's name. It omits behavioral details such as whether comments are appended, if there are permissions required, or any side effects. With zero annotation coverage, the description should disclose more.
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 wasted words. It is concise and front-loaded, though it could benefit from a brief usage example or constraint.
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 simplicity of the tool (2 parameters, no output schema, no annotations), the description is minimally adequate but lacks completeness about the operation's impact, such as whether the comment is instantly visible or formatted.
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 provides descriptions for both parameters ('card_id' and 'text'), so the description adds no new meaning. Baseline 3 is appropriate as schema coverage is effectively 100%.
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 'Add a comment to a card.' clearly states the action (add) and the resource (comment on card), distinguishing it from siblings like planka_get_comments (retrieve) or planka_update_card (modify card fields).
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, no prerequisites, and no exclusions. It simply states the action without context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add a task to a card.
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
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 states 'Add a task to a card.' without mentioning side effects, authentication requirements, or how it handles missing parameters (e.g., card_id fallback behavior is only in the schema). This is minimal and insufficient for safe invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise but lacks structure. It does not front-load critical information such as required prerequisites or typical usage patterns. Every sentence should earn its place; this one is too vague to be fully helpful.
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?
Considering the complexity of the tool (5 parameters, fallback logic, no output schema, no annotations), the description is far too minimal. It does not explain how parameters relate, what happens when card_id vs task_list_id is used, or what the expected return value is. The description is incomplete for an AI agent to use reliably.
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 provides detailed descriptions for each parameter (e.g., 'Fallback: resolve a task list from this card when task_list_id is not provided'). The tool description adds no additional meaning beyond the schema. With high schema coverage, a 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 'Add a task to a card.' uses a specific verb and resource, clearly indicating the action. It distinguishes from siblings like planka_create_task_list (creates a list, not a task) and planka_update_task (modifies, not adds). However, it could be more precise about the relationship between tasks, cards, and task 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?
No guidance on when to use this tool versus alternatives such as planka_create_task_list or planka_update_task. No context about prerequisites (e.g., card must exist) or when to avoid using it. The description does not help the agent choose correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One-call board status report: per-list counts, in-progress ages, blocked cards with latest Blocked: comment, unsatisfied gates, done-window points.
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It details the output components (per-list counts, ages, blocked cards, etc.), which is valuable. However, it does not explicitly state that the tool is read-only or mention any side effects, which would be beneficial.
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 packs essential information without wasting words. It is front-loaded and clear.
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 complexity of the tool (multiple report components), the description covers all key aspects. It lacks explicit mention of return format or edge cases, but the output format parameter addresses part of that. Overall adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides descriptions for all parameters (board_id, response_format, done_window_days), so coverage is high. The tool description adds context about what the output includes but does not significantly enhance parameter understanding beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it provides a board status report with specific components like per-list counts, in-progress ages, blocked cards, etc. This verb+resource combination is precise and distinguishes it from siblings like planka_list_cards or planka_get_card.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it (for a board status summary), but does not explicitly state when not to use it or provide alternative tool names. No prerequisites or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Mechanically validate a card against the card-schema readiness rules.
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must carry full burden. It only says 'mechanically validate' without explaining side effects, validation results, or permissions needed. Minimal behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no wasted words, but extreme brevity sacrifices necessary detail. Appropriate for very simple tools but borderline here.
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?
Tool has one required parameter and no output schema. Description is minimally adequate for a simple validation check, but lacks details on return values or error conditions.
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 0%, meaning the schema descriptions are insufficient. The tool description adds no parameter meaning beyond the parameter names and types, leaving the agent uninformed about how to use parameters correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description states 'validate a card against the card-schema readiness rules', clearly indicating a validation action on a card. However, it does not distinguish from sibling tools like planka_get_card or planka_find_and_get_card, which are retrieval-oriented.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. No context about prerequisites or when validation is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new board with canonical lists and lifecycle labels.
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only mentions creation of a board with lists and labels, but provides no details on destructive nature, permissions, or side effects. With no annotations, this is insufficient for an agent to understand the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise sentence, but it lacks structure and critical information. It is not front-loaded with the most important details.
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 three parameters and no output schema or annotations, the description is incomplete. It does not describe return values, prerequisites, or the implications of creating a board with canonical lists.
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?
Although the input schema includes descriptions for parameters, the context signal indicates 0% schema description coverage. The tool description does not explain the parameters like board_type or project_name, failing to add meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a new board' which is a specific verb+resource combination. However, 'with canonical lists and lifecycle labels' is vague and does not differentiate from sibling tools like planka_create_list or planka_create_label.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as planka_create_list. There is no mention of prerequisites or context for board creation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new card in a specified list.
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description lacks information on side effects, permissions, error handling, or what happens upon success. Minimal behavioral disclosure beyond the action itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no redundancy. Concise but could be slightly expanded for clarity. However, conciseness is good.
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?
Missing information about return values, error conditions, and behavior despite having many sibling tools. Incomplete for a creation tool with no output schema or annotations.
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 description does not add meaning beyond the input schema, which already contains detailed descriptions for each parameter. Schema coverage is high, so no penalty for missing param info in description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('create') and the resource ('a new card in a specified list'), but does not distinguish from sibling tools like planka_update_card or planka_add_card_label.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. Does not mention prerequisites, exclusions, or context-specific usage hints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a custom field inside a custom field group.
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It does not disclose any behavioral traits like immediate availability, permissions, or side effects. Minimal disclosure beyond the action itself.
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 fluff, but it is too concise, lacking necessary context. Every sentence should earn its place, and this one could be expanded to add value without becoming verbose.
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 multiple parameters (name, position, show_on_front_of_card), no output schema, and no annotations, the description is incomplete. It does not explain what a custom field is or the implications of parameters like show_on_front_of_card.
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 0% per context, but the description adds no value beyond the schema. It does not explain parameters like custom_field_group_id, name, position, or show_on_front_of_card. The description fails to compensate for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (create) and resource (custom field inside a custom field group). However, it does not differentiate from sibling tools like planka_update_custom_field or planka_delete_custom_field, lacking specificity about the scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, such as updating an existing custom field. No prerequisites or context about when creation is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a board-wide or card-specific custom field group.
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description only states creation. Does not disclose behavioral traits such as idempotency, authorization needs, or side effects. Minimal transparency beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with key action and scope. No extraneous words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple creation tool with well-documented schema, but lacks details on return values, error cases, or relationship to sibling tools. Bare minimum completeness.
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 includes detailed descriptions for all parameters (coverage high). The tool-level description adds no additional parameter meaning, so baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb ('create'), the resource ('custom field group'), and the scope ('board-wide or card-specific'). It distinguishes from sibling tools like 'planka_create_custom_field' (which creates a field within a group) and 'planka_delete_custom_field_group'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, when to choose board-wide vs card-specific, or any prerequisites. The description lacks context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a label on a board (idempotent by name).
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description adds the behavioral trait 'idempotent by name' which is useful for understanding re-invocation safety. Lacks details on permissions, side effects, or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no redundancy, efficiently conveying the core action and idempotency. Front-loaded with key 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?
With no annotations, no output schema, and minimal parameter coverage, the description lacks context for proper use. Missing usage scenarios, duplicate handling, and differentiation from numerous siblings. Incomplete for a creation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% (schema description is generic), and the tool description does not elaborate on parameters beyond the schema. The schema itself contains adequate descriptions for name, color, and board_id, but the tool description adds no extra semantic value.
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?
Description explicitly states 'Create a label on a board' with the idempotency trait. Distinguishes from siblings like planka_update_label and planka_delete_label by focusing on creation and idempotency.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or alternatives are provided. The idempotency hint is useful but does not advise on when to prefer this over other label-related tools. Basic guidance is implicit but limited.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a list on a board.
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description only says 'Create a list', implying mutation but lacking disclosure of behavioral traits such as permissions, idempotency, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loaded with the core action. However, it lacks structure or details that could be included without bloat.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description should provide context about return values, effects, or constraints. It fails to do so, leaving gaps for a 3-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not add any meaning beyond the input schema, which already has descriptions for name, board_id, and position. Schema coverage is 0% meaning the description adds no value.
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 'Create a list on a board' clearly states the action and resource, distinguishing it from sibling create tools like create_board or create_card.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like planka_update_list or planka_create_card. No exclusions or prerequisites mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a named task list on a card.
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description implies a write operation ('Create') but provides no additional behavioral context such as authorization requirements, side effects, or limitations. With no annotations present, the burden is on the description, which falls short.
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 efficient sentence that is front-loaded with the action and object. There is no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple tool (two required string params, no output schema), the description lacks context about what a task list is, how it relates to cards, or any behavior beyond creation. The parameter descriptions in the schema help, but the tool description itself is 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 tool description adds no meaning beyond the input schema. Although the schema itself includes descriptions for 'name' and 'card_id', the coverage metric shows 0% because the description does not reference or elaborate on parameters. The description fails to compensate for low schema_description_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 'Create a named task list on a card' clearly states the action and resource. It is specific enough to distinguish from siblings like 'planka_add_task' (adds a task to a list) or 'planka_create_list' (creates a list on a board), though it does not explicitly compare them.
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 usage guidance is provided. The description does not specify when to use this tool versus alternatives, nor does it mention prerequisites like the need for an existing card.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a card from Planka.
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavioral traits. It only states the action without mentioning that deletion is irreversible, requires specific permissions, or may cascade effects. This is insufficient for an AI agent to understand the consequences.
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—a single sentence. It is front-loaded with the key information. However, it could benefit from additional context without losing efficiency.
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 destructive operation with one parameter and no output schema, the description lacks completeness. It does not mention irreversibility, error conditions, or expected outcomes, leaving the agent underinformed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, card_id, is described in the input schema itself. The tool description adds no further meaning, but since the schema already defines its purpose, the baseline score of 3 is appropriate despite 0% schema description coverage indicated in context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete a card from Planka' clearly states the action (delete) and the resource (card), making the purpose unambiguous. However, it does not differentiate from sibling tools like planka_remove_card_label, which also remove something from a card, but the distinct action is clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as planka_update_card or planka_find_and_get_card. There is no mention of prerequisites, constraints, or conditions for safe usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a custom field.
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description lacks behavioral details such as irreversibility, side effects on cards or other entities, or authorization requirements. With no annotations, the description should carry this burden but does not.
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 short sentence, which is concise but lacks substance. It is front-loaded but could be expanded with relevant context without losing 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 single-parameter deletion tool with no output schema or annotations, the description is incomplete. It does not explain prerequisites, the effect on related data, or the expected outcome, leaving the agent with insufficient information.
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 0%, so the description must compensate for parameter meaning. It does not add any context beyond what the schema already provides for custom_field_id, such as format, constraints, or usage tips.
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 'Delete a custom field,' which is a specific verb-resource pair. However, it does not differentiate from sibling tools like planka_delete_custom_field_group or planka_delete_custom_field_value, which have similar naming and 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 provided on when to use this tool over alternatives. For example, it does not explain when deletion is appropriate versus using update, or any prerequisites like ensuring no cards depend on the custom field.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a custom field group.
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and description only says 'Delete' without disclosing side effects (e.g., impact on cards), auth requirements, or irreversibility.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence is concise, but could include additional context without becoming verbose.
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?
Minimal description lacks return value info, constraints, or operational context, making it insufficient for confident use.
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?
Parameter description in input schema already explains the required ID; tool description adds no new semantic value.
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?
Description clearly states 'Delete a custom field group' using specific verb and resource, distinguishing it from create, update, and get siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., planka_update_custom_field_group), no prerequisites or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a custom field value from a card.
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist. The description only states the basic action without disclosing behavioral traits such as idempotency, side effects, permissions required, or error handling. For a destructive operation, more detail is needed.
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, focused sentence that is efficient and front-loaded. However, it could incorporate a bit more context without losing 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 simple deletion tool, the description adequately states the core function. However, lacking output schema and behavioral details, it feels incomplete, especially given the complexity of the parameter structure and sibling operations.
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 tool description does not add any meaning beyond what the input schema already provides. Although the schema includes parameter descriptions, the description misses the opportunity to clarify relationships or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete'), the resource ('custom field value'), and the context ('from a card'). It effectively distinguishes from sibling tools like 'set_custom_field_value' (modify) and 'delete_custom_field' (delete entire field).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, when deletion is appropriate, or how it differs from modifying or clearing the value.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a label from a board.
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only states 'delete' without mentioning idempotency, error handling (e.g., deleting non-existent label), or cascading effects on cards.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no extraneous words. Perfectly concise for the basic action described.
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 simple one-parameter delete operation, the description is minimal. It lacks details on return value, side effects, or typical usage scenarios, making it incomplete for an agent.
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 description adds no meaning beyond the schema's parameter description ('Label ID to delete'). It doesn't explain what constitutes a valid label ID or any additional constraints.
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 'Delete a label from a board,' specifying a specific verb and resource. It distinguishes from siblings like 'planka_create_label' or 'planka_update_label'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., updating or removing label assignments). No context on preconditions or when it should be avoided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a task from a card.
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility for behavioral disclosure. It states 'Delete' but does not mention any side effects, irreversibility, required permissions, or return behavior. This is insufficient for a destructive action.
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?
A single, brief sentence that efficiently conveys the core function with no extraneous words. It is well-structured and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is too sparse for a delete tool with no output schema, no annotations, and many sibling tools. It does not cover prerequisites, effects, or output, leaving the agent underinformed for correct invocation.
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 only parameter, task_id, is described in the input schema as 'ID of the task to delete', which is clear. The tool description adds no extra context (e.g., where to obtain the ID). Despite the context indicating 0% schema coverage, the schema actually provides a description, so the description's contribution is minimal but acceptable.
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 'Delete a task from a card' clearly states the action (delete) and the target (task from a card). It effectively distinguishes this tool from sibling tools like planka_add_task and planka_update_task, though it could be more specific about the context (e.g., task as a checklist item).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool vs alternatives such as planka_delete_card or planka_delete_label. The description lacks explicit context for selection, assuming the agent knows to use it only for deleting a task from a card.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find and get card details by search query.
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits (e.g., read-only vs. destructive, pagination, return format). The description only says 'find and get', implying a read operation, but nothing about limits, scope, or side effects. Insufficient for safe agent usage.
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?
Extremely concise single sentence. No wasted words, but missing critical details that could be added without length penalty. Front-loads the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description fails to cover expected behavior like return format, whether multiple results are returned, or error conditions. For a search tool, this is 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 description adds no new meaning beyond the input schema. The schema already describes 'query' as searching names/descriptions and 'board_id' as board filter. Baseline 3 is appropriate given schema descriptions are present, even though context indicates 0% coverage (likely an error).
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 'Find and get card details by search query', which indicates the main action (search cards) but does not differentiate from sibling tools like planka_get_card (get by ID) or planka_list_cards (list all). It lacks specificity about what 'get card details' entails.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. For example, it doesn't mention that this is for searching by query, while planka_get_card is for direct ID lookup. No when-not-to-use or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific card.
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
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 only states 'Get detailed information' without mentioning any behavioral traits such as read-only nature, authorization requirements, rate limits, or what constitutes 'detailed'. This is minimal transparency for a retrieval 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, front-loaded sentence with no extraneous words. Every part is essential.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description does not explain the return format or content. While the schema provides parameter details, for a retrieval tool, some indication of what 'detailed information' includes would improve completeness. The description is adequate but not thorough.
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 describes parameters (card_id, response_format, response_context) with detailed descriptions. The tool description adds no extra meaning beyond the schema. With schema description coverage effectively not 0% (despite context signal), baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get detailed information about a specific card' clearly states the verb (Get) and resource (detailed information about a specific card). It distinguishes from sibling tools like planka_list_cards (which lists cards) and planka_find_and_get_card (which finds and then gets).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when specific card details are needed, but no explicit when-to-use, when-not-to-use, or alternatives are provided. With siblings like planka_find_and_get_card and planka_list_cards, guidance on when to choose this tool over others is lacking.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List comments on a card.
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only states the basic action. It does not disclose whether the tool is read-only, how comments are ordered, or any side effects. The limit parameter implies pagination but not explained.
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 wasted words. It could be slightly more informative, but it is front-loaded with the essential action.
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?
With 4 parameters, no output schema, and no annotations, the description is insufficient. It omits details about default behavior, filtering, pagination (limit, prefix), and output format options, leaving the agent without enough context to 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 contains descriptions for each parameter (e.g., card_id, limit, prefix_filter, response_format), so the description does not add extra meaning. Baseline score of 3 is appropriate as the schema already documents parameters.
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?
Description clearly states 'List comments on a card' with a specific verb and resource. It distinguishes from sibling tools like planka_add_comment (write) and planka_get_card (different resource), though no explicit differentiation is given.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as filtering via prefix_filter or handling pagination. The description does not mention alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read a custom field group with its fields and values.
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
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 correctly indicates a read-only operation ('Read'), but it does not mention any potential errors (e.g., resource not found), authentication requirements, or additional behavioral traits beyond reading. The return format is hinted but not explicitly stated, leaving some ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that conveys the core purpose without unnecessary words. However, it could be slightly more informative by mentioning the output format options or typical usage context, without violating 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?
Given the low complexity (1 parameter, no nested objects, no output schema), the description is minimally adequate. It explains what is retrieved (fields and values) but lacks details on the structure of the response, error handling, or any pagination. For a simple read tool, it is sufficient but not thorough.
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?
Despite the context signal indicating 0% schema description coverage, the actual input schema includes descriptions for both parameters (custom_field_group_id and response_format). However, the tool description adds no extra meaning beyond what the schema already provides. It does not explain how to construct the ID or when to use the response_format parameter, leaving the agent to rely solely on the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Read' and clearly identifies the resource as a 'custom field group.' It also specifies that the output includes 'its fields and values,' setting clear expectations. This distinguishes it from sibling tools like planka_create_custom_field_group or planka_get_card.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool should be used when you need to retrieve a custom field group with its details, but it does not explicitly state when to prefer this tool over alternatives (e.g., planka_get_card for cards) or provide usage context like prerequisites (e.g., needing the group ID). However, for a simple read operation, the usage is self-evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all labels on a board (fast targeted refresh without full workspace re-fetch).
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden for behavioral disclosure. It mentions 'fast targeted refresh' but does not disclose what happens if the board is not found, whether the operation is read-only, or any rate limits or authentication requirements. The description adds minimal behavioral context beyond the schema.
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 unnecessary words or fluff. It efficiently communicates the core purpose and a key benefit.
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 lack of output schema and annotations, the description is incomplete. It does not describe the return format (e.g., a list of labels or objects), what happens on error, or any state changes. The single parameter and simple functionality are not fully covered, leaving important gaps for an AI agent.
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 description coverage is reported as 0%, meaning the description must compensate. However, the description does not mention the board_id parameter or provide any additional meaning beyond the schema's basic definition. It does not explain where to find the board ID or how it relates to the refresh behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'all labels on a board', and adds a performance benefit (fast targeted refresh) that distinguishes it from sibling tools that create, update, or delete labels. This provides a specific and distinct 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?
The description implies when to use this tool ('fast targeted refresh without full workspace re-fetch'), suggesting efficiency for label retrieval without re-fetching the entire workspace. However, it does not explicitly state when not to use or compare to alternatives like planka_get_workspace.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get authenticated user identity (id, username, role).
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full behavioral disclosure burden. It correctly indicates a read operation (get), but does not specify behavior on authentication failure, side effects, or rate limits. For a simple identity fetch, it is minimally adequate.
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 immediately conveys the tool's purpose and output. It is front-loaded with the important information and contains no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with one optional parameter and no output schema, the description is complete. It states what the tool returns (id, username, role) and implies the target identity (authenticated user). No additional context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has one parameter 'response_format' with a default and enum, and the schema provides a description. However, the tool description itself adds no extra meaning beyond the schema; it does not mention the parameter at all. Given 0% schema description coverage, the description should compensate but fails to do so.
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 the authenticated user's identity, listing the specific fields (id, username, role). It uses a specific verb 'get' and resource 'authenticated user identity', and distinguishes well from sibling tools which focus on other entities like cards, boards, labels, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is to be used when the agent needs the current user's identity, but there is no explicit guidance on when to use this versus other tools. No alternatives or exclusions are mentioned, though the use case is straightforward.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get complete workspace structure (projects, boards, lists, labels, users). Pass project_name or board_name to scope the response — resolving a single board? board_name returns a fraction of the full dump.
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral transparency. It honestly describes that the tool returns a 'complete workspace structure' and that using 'board_name' yields a 'fraction of the full dump,' implying a read-only operation. No contradictions exist, though it could mention auth needs or rate limits.
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: two sentences that front-load the purpose and immediately provide actionable guidance on parameter usage. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the tool (returning workspace structure) and the absence of an output schema, the description is somewhat vague about the exact return format or structure. It lists components but does not detail nested hierarchies or data format, which could leave the agent uncertain about the response.
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 provides parameter descriptions with high coverage. The description adds further value by explaining scoping trade-offs (e.g., 'cheaper than a full dump' for board_name) and explicitly linking parameters to the behavior. This goes beyond the schema's minimal definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get complete workspace structure (projects, boards, lists, labels, users).' It uses a specific verb ('Get') and resource ('workspace structure'), and distinguishes itself from sibling tools like 'planka_get_card' or 'planka_get_labels' by offering a comprehensive dump with optional scoping.
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 good usage guidance: 'Pass project_name or board_name to scope the response' and explicitly notes that 'board_name returns a fraction of the full dump.' This helps the agent decide when to use parameters. However, it does not explicitly compare to alternative sibling tools for specific queries, leaving some room for interpretation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List cards with filtering and pagination options.
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It merely states the tool lists cards with filtering and pagination, but does not disclose any behavioral traits such as ordering, caching, rate limits, or whether it returns only non-archived cards.
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 (one sentence) but lacks structure and substance. It could be expanded to include key details without becoming verbose.
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 number of parameters (9) and no output schema, the description is incomplete. It does not explain filtering options, pagination behavior, output formats, or detail levels, leaving the agent to rely solely on the 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 0%, so the description must compensate but fails to add any meaning beyond parameter names. While the schema itself has good descriptions for each parameter, the tool description does not explain how the parameters interact or their relevance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and resource ('cards'), and mentions filtering and pagination. However, it does not differentiate this tool from sibling tools like 'planka_get_card' or 'planka_find_and_get_card', which also involve listing or retrieving cards.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description lacks any context about prerequisites, typical use cases, or scenarios where this tool is preferred over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Bulk-move cards to a target list for kanban ceremonies.
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must convey behavioral traits. It states 'bulk-move' but omits details about destructiveness, idempotency, prerequisites, or what happens to existing card order. The schema hints at ordering behavior via keep_order, but the description does not clarify.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no filler. It front-loads the verb and resource, making it efficient for an agent to parse.
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 complexity of a bulk-move operation, the description lacks details about return formats, error handling, maximum card count (only in schema), and ordering behavior. With no output schema or annotations, the description is insufficient for an agent to fully understand the tool's 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?
The input schema already contains descriptions for all parameters, though context signals erroneously report 0% coverage. The tool description adds no additional semantic value beyond what the schema provides, so a 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 action ('bulk-move cards') and the target ('to a target list'), with a specific context ('for kanban ceremonies'). It distinguishes from sibling tools that perform other operations like create, delete, or update.
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 during kanban ceremonies but does not specify when to use this tool versus alternatives (e.g., update_card for single moves). No explicit exclusions or when-not-to-use guidance are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the top card of a list (default TODO) with full execution context.
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and description lacks behavioral details. Does not indicate whether the tool is read-only or if it modifies state (e.g., marks card as in progress). 'Full execution context' is vague and undefined.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no clutter. Every word serves a purpose, though 'full execution context' could be more precise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, and the description does not explain the return value or what 'execution context' means. An agent cannot infer the structure of the response or how to handle the output.
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 0% according to context, and the tool description adds no explanations for parameters beyond what the schema provides. The description does not help an agent understand board_id, list_name, or response_format semantics.
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?
Description clearly states verb 'Get', resource 'top card of a list', and default list name 'TODO'. It distinguishes from siblings like planka_get_card and planka_list_cards by specifying 'top' and 'default list'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. Does not mention exclusions, prerequisites, or why one would choose this over planka_find_and_get_card or planka_list_cards.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remove a label from a card.
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description does not disclose side effects, reversibility, or authentication requirements. Only states obvious behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, no wasted words. Could be more informative without being longer, but efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Simple tool, but no output schema or annotations. Description is minimal; misses error conditions or success indications.
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?
Parameter descriptions in schema are clear, but tool description adds no extra meaning beyond them. Baseline 3 given 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 states the action (remove) and the resource (label from a card), distinguishing it from sibling tools like planka_add_card_label.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool, prerequisites, or when not to use it. Lacks context compared to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remove a member from a card.
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as destructiveness, permission requirements, side effects, or reversibility. The agent lacks essential context for safe invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no extraneous information. However, it could be slightly improved by including minimal usage context.
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 lack of annotations and output schema, the description is too minimal. It does not provide enough context for an agent to understand the tool's behavior, failure modes, or return information.
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 includes descriptions for both parameters (card_id and user_id), so the tool description adds no extra meaning. With high schema coverage, a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Remove') and the resource ('member from a card'). It is specific and distinguishes from sibling tools like planka_add_card_member.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives, nor does it mention prerequisites (e.g., member must exist on card) or scenarios where it should not be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set a custom field value on a card.
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits. It only says 'set', omitting details like whether it overwrites, behavior on non-existent fields, or required permissions.
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?
One sentence is very concise, but it omits critical details. It is not optimally front-loaded; the single sentence is the entire description.
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 4 required parameters, no output schema, and no annotations, the description is insufficient. It lacks explanation of parameters, return format, and side effects.
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 0%, meaning the tool description adds no parameter context. The schema has descriptions, but the description does not compensate for the low 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 states the action ('Set'), resource ('custom field value'), and context ('on a card'). It distinguishes from sibling tools like create or delete custom field operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., creating a custom field, deleting a value). No prerequisites or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an existing card's properties.
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavioral traits. It only states 'Update an existing card's properties' without mentioning side effects, idempotency, or partial update behavior. Minimal transparency for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with key information (verb + resource). No wasted words. Efficiently communicates the core 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 7 parameters and no output schema, the description is too sparse. It does not explain partial update behavior, optional fields, or what happens with defaults. Incomplete for effective use.
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 0% as the description adds no parameter info. The schema itself has descriptions, but the tool description does not compensate for low coverage. It does not add meaning beyond the input schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'Update' and resource 'existing card's properties', distinguishing it from siblings like planka_create_card and planka_delete_card. However, it lacks specificity about which properties can be updated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives (e.g., planka_add_card_label for adding labels). Does not mention prerequisites or scenarios where other tools are preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update a custom field.
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits. It only states 'update', implying mutation, but gives no details about idempotency, side effects, permissions, or required state of the field.
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 short sentence, but it is under-specified rather than concise. It fails to convey necessary information efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and multiple parameters, the description is critically incomplete. It does not explain return values, side effects, or how to use the parameters.
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 0%, so the description must compensate for parameter meaning. It does not mention any parameters, leaving the agent to rely solely on the schema, which lacks descriptions (per context).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update a custom field' provides a verb+resource but is generic and does not distinguish from sibling tools like planka_create_custom_field or planka_set_custom_field_value. It lacks specificity about what aspects of a custom field can be updated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus other custom field tools (e.g., create, delete, set value). The agent has no context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update a custom field group's name and/or position.
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description indicates an update (mutation) but provides no details on side effects, permissions, reversibility, or atomicity. With no annotations, the burden falls entirely on the description, which falls short.
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, which is efficient but lacks structure. While it is not verbose, it sacrifices informativeness for brevity, earning a middle score.
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 4 parameters, no output schema, and no annotations, the description is insufficient for an agent to understand the tool's full behavior. It does not cover return values, constraints, or typical usage patterns, making it incomplete for the complexity level.
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?
Despite the schema having parameter descriptions, the tool description itself only mentions 'name and/or position', omitting the required 'custom_field_group_id' and optional 'response_format'. With 0% schema description coverage (as per context), the description should compensate but fails to explain all parameters clearly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it updates a custom field group's name and/or position, using a specific verb and resource. However, it does not differentiate from sibling tools like create or delete custom field group, which is a minor gap.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., create_custom_field_group, delete_custom_field_group). There is no mention of prerequisites, context, or when not to use it, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update a label's name or color.
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must fully convey behavior. It states 'update' but does not mention mutation side effects, whether updates are partial or full, or any authorization requirements. 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 a single sentence of 6 words, extremely concise and front-loaded. Every word is essential.
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?
With no output schema and no annotations, the description fails to explain partial update behavior, return values, or error conditions. It is too minimal for a tool with three parameters.
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 0% (context signal), so the description must compensate. It only names 'name or color' without explaining the color palette or the requirement for label_id. The schema descriptions provide some detail, but the tool description adds little value.
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 'Update a label's name or color.' It specifies the verb (update) and resource (label), and distinguishes from sibling tools like create_label and delete_label.
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. It is implied that it is for modifying existing labels, but no when-not-to-use or context is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Rename and/or reorder a board list.
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only states the action ('rename and/or reorder') but does not disclose behavioral traits like side effects, required permissions, error handling, or idempotency. With no annotations provided, the description fails to compensate for missing 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 a single, front-loaded sentence with no unnecessary words. Every word contributes to understanding the tool's core function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple update tool with three parameters and no output schema, the description is sufficiently complete. It directly states the supported operations (rename and reorder) and implies optional parameters. However, lacking annotations or additional behavioral details prevents a perfect score.
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 description summarizes the parameters (name and position) via 'rename and/or reorder,' but the schema already provides clear parameter descriptions. With 0% schema description coverage (as per context), the description adds minimal value; however, it correctly maps to the key parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('rename and/or reorder') with a clear resource ('board list'), directly indicating the tool's function. It distinguishes itself from sibling tools like planka_create_list (create) and planka_update_card (update card), making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance provided on when to use this tool versus alternatives (e.g., creating a new list or updating a card). The description lacks context on prerequisites, such as needing the list_id or the intended workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update a task's completion status.
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description omits that the tool updates position in addition to completion status. No disclosure of side effects, permissions, or behavior beyond basic update.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence is concise, but lacks necessary detail; could be expanded for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Incomplete given no output schema and the tool's actual functionality; fails to mention position updates or provide sufficient behavioral info.
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?
Description adds no value beyond schema property descriptions; it even contradicts by implying only completion status, ignoring position.
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?
Description claims only updating completion status, but schema includes position parameter. Does not accurately represent the tool's full 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?
No guidance on when to use this tool versus alternatives like planka_update_card or other task-related tools. Lacks context for appropriate use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0planka_add_card_labelplanka_add_card_memberplanka_add_commentplanka_add_taskplanka_board_statusplanka_card_ready_checkplanka_create_boardplanka_create_cardplanka_create_custom_fieldplanka_create_custom_field_groupplanka_create_labelplanka_create_listplanka_create_task_listplanka_delete_cardplanka_delete_custom_fieldplanka_delete_custom_field_groupplanka_delete_custom_field_valueplanka_delete_labelplanka_delete_taskplanka_find_and_get_cardplanka_get_cardplanka_get_commentsplanka_get_custom_field_groupplanka_get_labelsplanka_get_meplanka_get_workspaceplanka_list_cardsplanka_move_cardsplanka_next_cardplanka_remove_card_labelplanka_remove_card_memberplanka_set_custom_field_valueplanka_update_cardplanka_update_custom_fieldplanka_update_custom_field_groupplanka_update_labelplanka_update_listplanka_update_taskScored across 38 tools
Most tools have clearly distinct purposes, such as creating, updating, deleting, or retrieving specific entities. However, slight overlap exists between 'planka_find_and_get_card' and 'planka_get_card', and 'planka_get_labels' may be redundant with workspace data, but descriptions clarify intent.
The vast majority follow a consistent 'planka_verb_noun' pattern (e.g., planka_create_card, planka_delete_label). A few outliers like 'planka_board_status' and 'planka_card_ready_check' break the pattern, and 'planka_next_card' uses an adjective as verb, but overall naming is predictable.
38 tools is on the higher end but appropriate for a full-featured project management server covering boards, lists, cards, labels, custom fields, tasks, comments, and members. Each tool serves a specific action, and while a few could be merged, the count is reasonable for the domain.
The tool set covers most core operations (CRUD for cards, labels, custom fields, tasks, comments), but lacks board update/delete, list delete, and comment delete. The presence of specialized tools like 'planka_board_status' and 'planka_card_ready_check' indicates attention to workflows, yet gaps remain.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Model Context Protocol server for the Apideck Unified API. Connect any MCP-compatible agent framework to 100+ accounting systems, HRIS platforms, file storage providers, and more through one integration. More information https://www.apideck.com/mcp-server
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
Task & board management for AI agents + humans. Kanban, comments, digests via MCP.
