Loading ToolBench
Lattice MCP server for project, spec, task, and question workflows.
Lattice demonstrates solid tool definition quality with consistent naming patterns (verb_noun), comprehensive parameter descriptions, and structured schemas. All 22 tools follow the lattice_* prefix convention and include clear descriptions (avg ~80 chars). Input schemas are present with typed parameters and descriptions. However, output schemas are not documented in the visible code, parameter constraints lack enums for status/priority/review_state fields, and error handling guidance is minimal. No tool annotations (readOnlyHint/destructiveHint) detected despite clear risk classifications. Composition is strong, tools chain well (e.g., create_task → update_task → move_task) and accept human-friendly identifiers (project slug, task_ref). Batch operations (create_tasks_bulk) reduce sequential call overhead.
Answer an open question.
Create a project with explicit slug confirmation and optional initial spec.
Create an open question on a task.
Create a subtask under a task.
Create a task and return its display key.
Create multiple tasks in one call.
Delete a subtask.
Output schemas not documented. Tool descriptions state what is returned (e.g., 'Get project details and board summary counters') but visible code does not show structured response schemas. LLMs cannot plan downstream tool calls or extract specific fields without knowing response structure.
Enum constraints missing for status, priority, and review_state parameters. Tools like lattice_create_task and lattice_update_task accept 'status' (e.g., 'backlog', 'in_progress') and 'priority' (e.g., 'medium') but no enum is declared. LLMs may hallucinate invalid values; validation errors provide no guidance on valid options.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 66 | 2026-07-28+ | v2 |
Delete a task and all its associated data.
Get project details and board summary counters.
Get all structured spec sections for a project.
Get revision history for one spec section.
Get one spec section by name.
Get full task details including subtasks, questions, attachments, and history.
List projects with board and open-question summary counts.
List open questions for a task.
List recent activity across all projects or a specific project.
List tasks by project, with optional status/label/review filters.
Move a task to a different position in the board.
Update a project's goal text.
Update one spec section and append a revision.
Update a subtask's title or done status.
Update task fields like title, description, status, priority, labels, and review_state.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) in MCP registration. Risk classifications are provided in the evaluation (READ_ONLY, WRITE, DESTRUCTIVE) but not exposed to the MCP client via tool annotations. Agents cannot determine which tools are safe to retry or have side effects without external documentation.
Error handling lacks recovery guidance. No visible error responses that tell LLMs what to do next (e.g., 'Project not found. Try lattice_list_projects() to see available projects'). Raw error codes or generic messages provide no actionable path forward.
Confirmation pattern missing for destructive operations. lattice_delete_task and lattice_delete_subtask lack a dry-run or confirm_before_execute parameter. Agents may accidentally delete tasks without a safety gate.