Loading ToolBench
MCP server for Liha Live Preview: read review feedback and publish new versions from a coding agent.
Strong tool naming and descriptions. All 9 tools follow verb_noun convention (get_, list_, create_, update_, resolve_, read_). Descriptions are detailed (100-250 chars), explaining WHAT, WHEN, and context. Input schemas present with types and descriptions for all parameters. However, output schemas are not documented in the source code provided, LLMs cannot see what fields to expect from responses. Error handling is minimal; no recovery guidance or actionable error messages visible. Parameter constraints (enums, ranges) are present for some tools (e.g., list_comments status enum) but missing for others (e.g., create_preview path has no length/pattern constraint). No tool annotations (readOnlyHint, destructiveHint, idempotentHint) visible in schema definitions, though risk levels are noted in metadata.
Publish a directory or file from this project as a new Liha preview and return its share URL and preview id. The project is linked to the new preview so later update_preview calls need no arguments. Only paths inside the project root are allowed.
Get a single comment in full, including the DOM context captured when the reviewer clicked: CSS selector, tag name, text content, an HTML snippet and the viewport size. Use this to map the feedback onto a specific place in the source before editing.
Get the current state of a Liha preview: title, artifact type, share URL, current version number, version count and open/resolved comment counts. Start here to see whether there is review feedback to act on.
List the review comments on a preview, oldest first. Each comment carries where it points: a CSS selector for web previews, a page number for PDFs, or normalized coordinates. Replies follow their parent and carry its id in parentId, so a whole discussion reads in order. Use it to find what a human asked you to change.
List files in a directory under the project root. Useful for exploring the project structure.
Output schemas not documented. LLMs cannot see what fields get_preview_info, list_comments, list_versions, or create_preview return. This forces agents to guess field names and risks failed downstream tool calls.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) in schema definitions. Risk levels are noted in metadata but not exposed to the LLM via structured annotations. This prevents agents from reasoning about safety and retry semantics.
create_preview and update_preview lack input validation constraints. 'path' parameter has no length, pattern, or character restrictions documented. 'password' has minLength=6 but no maxLength. LLMs may pass invalid paths (e.g., '../../../etc/passwd') or oversized passwords.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 66 | 2025-06-18+ | v2 |
List every version published to this preview, newest first, showing which one the share URL currently serves.
Read a file from the project. Only files under the configured project root can be read. Useful for understanding the structure of the code being reviewed.
Mark a comment as resolved. Only the preview owner can do this. Resolved comments are hidden by default in list_comments.
Publish a new version of an existing preview. The project must be linked to the preview, or preview_id must be passed. Only paths inside the project root are allowed.
No error handling guidance visible. Tools do not document what errors can occur, whether they are retryable, or what the LLM should do next. E.g., if create_preview fails due to invalid path, the agent has no recovery hint.
list_comments and list_versions lack pagination parameters (limit, offset, cursor). If a preview has hundreds of comments or versions, the response could exhaust context. No indication of result limits or how to fetch additional pages.