Loading ToolBench
MCP server that lets AI agents work with LokalBoards, a self-hosted Kanban project-management tool. Provides tools to read and manage boards, areas, cards, comments, and attachments on behalf of authenticated users.
The LokalBoards MCP server provides 12 tools with reasonable naming (verb_noun conventions) and descriptions that generally indicate what each tool does. However, there are critical gaps in schema completeness, parameter descriptions, and output documentation. Reviewing the source at server/mcp/index.ts: All tools have descriptions (10-150 chars, mostly in range), but most lack detailed output schema documentation. Input schemas are partially visible for 6 tools (getBoardTree, searchCards, claimCard, releaseCard, createCard, updateCard, moveCard, writeComment, listAreas, listCards), with parameter type definitions present. However, parameter descriptions are sparse or missing entirely for several tools (e.g., searchCards has 4 parameters, but only partial descriptions visible). No error recovery guidance is provided. The tool naming is clear (get_*, list_*, search_*, claim_*, release_*, create_*, update_*, move_*, write_*), following actionable verb-noun patterns. Composition is good, tools are single-responsibility. The claimCard tool includes atomic semantics documentation ('returns claimed=false if someone else already holds the card'), demonstrating some safety awareness. However, lack of comprehensive parameter documentation, output schemas, and error handling brings the overall score to the low-to-mid 60s.
Claim a card for work. This is ATOMIC - returns claimed=false if someone else already holds the card. Never work a card you did not successfully claim.
Create a new card. Pass an `idempotencyKey` when you might retry, so a repeated call returns the existing card instead of creating a duplicate.
Load the whole board (areas + cards) in one call. Returns the complete board structure including all areas and their cards.
List all areas (columns/lists) in a board.
Find a board by listing all available boards for the authenticated user.
List all cards in an area.
Move a card to a different area or position. The `done` flag is the source of truth; moving is for the humans looking at the board.
Output schemas not documented for any tool. LLMs cannot plan downstream calls or understand what fields to expect in responses. For example, getBoardTree, listBoards, searchCards, listAreas, and listCards do not document the structure of returned board/area/card objects, field types, or pagination.
Parameter descriptions are incomplete or missing for many tools. For example, searchCards parameters 'areaId', 'done', 'unassigned', and 'query' lack full descriptions explaining constraints, defaults, and mutual exclusivity. The rubric requires every parameter to have a non-empty description.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 61 | 2026-07-28+ | v2 |
Release a card without finishing it so someone else can pick it up.
Find cards by text or filter them by area, completion status, or assignment status. Use to find unassigned cards in an area.
Update a card's properties including done flag, name, content, due date, and assigned people.
Returns who you are acting as (the authenticated user).
Write a comment on a card. Content is Markdown.
No error handling or recovery guidance provided. Tools do not document what errors they can throw, whether errors are retryable, or what the LLM should do next. For example, claimCard says 'returns claimed=false' but other tools do not indicate failure modes.
Pagination not documented for list/search tools. listBoards, getBoardTree, searchCards, listAreas, and listCards do not indicate whether results are paginated, what limits are enforced, or how to request additional pages. Without pagination semantics, agents cannot handle large result sets.
No input validation constraints specified. For example, createCard accepts optional 'dueDate' but does not document expected format (ISO 8601, Unix timestamp, or natural language). updateCard accepts 'assignees' as array but no schema for array element types. Without constraints, LLMs pass invalid values.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). The MCP spec allows tools to declare safety properties, read-only tools and destructive operations should be annotated to help LLMs reason about safety. createCard mentions 'idempotencyKey' but tool itself is not marked as idempotent.
Missing chaining context for multi-step workflows. For example, searchCards and listCards do not document whether they return card IDs, board IDs, or area IDs needed for downstream calls like claimCard or updateCard. Without clear field naming and documentation, agents must guess or make extra discovery calls.