Loading ToolBench
An MCP server for project management, work item tracking, and knowledge base management with LLM-powered chat interfaces
ldash demonstrates solid tool design with clear naming conventions (verb_noun pattern), comprehensive parameter descriptions, and well-structured schemas. All 10 tools have explicit definitions with JSON Schema validation. Descriptions are detailed and contextual (avg ~180 chars), guiding LLM selection. However, output schemas are not formally documented, responses are JSON strings without declared field structures. Error handling is minimal (generic 'Error: ...' strings). Tool composition is strong: search→read→write workflows are well-sequenced, and tools accept human-friendly identifiers (doc titles, ticket keys) alongside IDs. Missing: tool annotations (readOnlyHint, destructiveHint), structured error recovery guidance, and pagination for list operations.
Post a comment on an item. Use this to record decisions, summaries, or follow-up notes from this conversation so they are visible on the ticket. Markdown is accepted.
Create a new item (epic, story, task, bug, or investigation) on the project board. Call this when the user has agreed to add a piece of work. Epics represent large themes (weeks of work), stories represent a coherent user-facing feature or component (days), tasks represent a single concrete unit of work (hours). Bugs are defects to fix and investigations are research or diagnosis work — both behave like tasks on the board. Always place epics in the Backlog column unless the user specifies otherwise.
Get full details of an item including its description, current column, flags, and all comments. Use this before discussing or modifying a ticket other than the one this chat is attached to.
Read one knowledgebase document in full, including its markdown content. Accepts the document key (e.g. "LDA-KB-1"), its id, or its title (case-insensitive). Use this to read or explain a document the user asks about, or before touching it up.
List the current items on the board for this project. Use this to check what already exists before creating duplicates, or to find the id of an item you want to update or set as a parent.
Output schemas not formally documented. Tools return JSON strings but field structures are not declared in tool definitions. LLMs cannot plan downstream calls without knowing response shape.
Error handling is generic ('Error: ...' strings). No recovery guidance or error classification. LLMs cannot determine if errors are retryable, user-fixable, or fatal.
Tool annotations missing. No readOnlyHint, destructiveHint, or idempotentHint declarations. LLMs cannot infer which tools are safe to retry or have side effects.
Inferred effective spec: 2026-07-28+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 63 | 2026-07-28+ | v2 |
List the knowledgebase documents in this project (key and title only, no content). Use this to see what is already documented before answering or creating a new document.
Move a TASK, BUG, or INVESTIGATION to a different status column. Only these leaf work items can be moved — story and epic status is derived from their child work items automatically, so never call this on them. Use when the user asks to start, finish, or reprioritize a work item.
Create or update ("touch up") a knowledgebase document in this project. This is an UPSERT keyed on title: if a document with the same title already exists (case-insensitive), its content is replaced; otherwise a new document is created. Mermaid diagrams are supported via ```mermaid code blocks. Only write when the user asks you to create, edit, or improve a document. When touching up an existing document, read it first with get_kb_doc and pass the full revised content (content is replaced entirely, not merged).
Search this project's knowledgebase by free text. Matches document titles AND markdown content (case-insensitive substring) and returns a snippet of content around the first match for each hit. Use this to find which document covers a topic, then read it with get_kb_doc.
Update the title, description, or type of an existing item. Use this to refine an item you just created, or to improve a pre-existing item based on the planning conversation. Type changes are only allowed between task, bug, and investigation — epics and stories cannot be converted.
list_kb_docs and list_items lack pagination parameters (limit, offset, cursor). Large result sets could exhaust context window.
create_item requires column_id but description says 'Use the column id from the project context', no guidance on how to discover valid column IDs.