Loading ToolBench
MCP server that lets AI agents work with LokalBoards, a self-hosted Kanban project-management tool. Enables reading and managing boards, areas, cards, comments, and attachments on behalf of authenticated users.
LokalBoards MCP server has 15 well-named tools with consistent verb_noun patterns (whoami, listBoards, getBoardTree, listAreas, listCards, searchCards, createCard, updateCard, moveCard, deleteCard, claimCard, releaseCard, writeComment, listComments, listAttachments). All tools have descriptions between 34-98 characters, meeting the 10-1024 character baseline. Input schemas are present and typed for all tools. However, critical gaps exist: (1) Parameter descriptions are minimal or missing, most parameters lack actionable context (e.g., 'The board identifier' for boardId offers no format guidance); (2) Output schemas are entirely undocumented, no field definitions, data types, or structures are specified, forcing LLMs to guess what fields to expect; (3) Error handling is absent, no recovery guidance, retryability classification, or actionable error messages; (4) No pagination support on list tools (listBoards, listAreas, listCards) despite the risk of large result sets; (5) Security considerations are unaddressed, no audit trail, permission checks, or scope declarations visible. The tool set is well-composed (single responsibility, clear names, good chaining potential via IDs), but lacks the depth of documentation and error resilience expected of production tools.
Claim a card (atomic operation). Returns claimed=false if already claimed by someone else.
Create a new card in an area
Delete a card permanently
Load the whole board (areas + cards) in one call
Lists all areas (columns/lists) in a board
List all attachments on a card
Lists all boards accessible to the authenticated user
Lists all cards in an area
Output schemas completely undocumented. No field definitions, types, or structures specified for any tool's response. LLMs cannot plan downstream calls or extract specific fields without reverse-engineering from trial calls.
Parameter descriptions lack actionable detail. Most parameters have minimal descriptions (e.g., 'The board identifier', 'The area identifier') with no format guidance, constraints, or examples. Descriptions should include expected format, range, allowed values, and dependencies.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 53 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 43 | - | v1 |
List all comments on a card
Move a card to a different area
Release a claimed card so someone else can pick it up
Search cards by text or filter by area, done status, and assignment status
Update a card's properties (name, content, done status, due date, people)
Returns the authenticated user (who you are acting as)
Write a comment on a card
No error handling or recovery guidance. No indication of which errors are retryable, which are user-fixable, or what actions to take on failure. Agents cannot self-correct or plan recovery steps.
List tools (listBoards, listAreas, listCards, listComments, listAttachments) lack pagination support. No limit, offset, page, or cursor parameters documented. Large result sets could exhaust context windows.
Destructive operations (deleteCard) have no confirmation step or dry-run capability. Agents could accidentally delete cards without user consent.
No security declarations or audit trail patterns. No indication of required permissions (read:board, write:card, etc.), no permission gates on sensitive operations, and no guidance on who can call what.
idempotencyKey parameter on createCard is present but lacks documentation. No guidance on format, collision behavior, or whether it guarantees idempotency across retries.
updateCard's 'people' parameter is declared as array but lacks element type and format. Should specify: array of user_id (integers), length bounds, and whether it appends or replaces.