Loading ToolBench
Model Context Protocol server for Huly project and document management platform
This server has serious gaps in definition quality. While 8 tools are defined with schemas and descriptions present, the descriptions are extremely thin (mostly under 100 chars), parameter documentation is minimal, output schemas are completely undocumented, and error handling guidance is absent. The naming is acceptable but not verb-forward. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear write vs read distinction. The manifest shows tool definitions but the handler implementation (not provided) is a black box, we cannot verify actual parameter validation, error responses, or output formatting. This lands firmly in the 'fair to poor' range: definitions exist but lack the depth, structure, and LLM-optimization expected of production tools.
Create a document with Markdown content in a teamspace
Create a new issue in a project with title, description, priority, and due date
Create a new milestone in a project and optionally assign issues to it
Create a new person record with an email communication channel
List documents in a teamspace by name
List issues in a project sorted by last modified date
Find people and their communication channels
Output schemas completely undocumented. Tools declare what they accept but nowhere in the manifest or handlers (not provided) do we see structured descriptions of what they return. LLMs cannot plan downstream tool calls or extract required fields without knowing the response structure.
Descriptions are extremely thin and generic. Examples: 'Find people and their communication channels' (55 chars), 'Find a project by identifier or name' (37 chars), 'List issues in a project sorted by last modified date' (53 chars). Baseline for A+ tools is 50-200 chars with actionable context (WHEN to call, WHAT to expect, PREREQUISITES). These lack specificity about when LLMs should choose this tool vs alternatives, what data structure is returned, and dependency hints.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 46 | 2026-07-28+ | v2 |
| 2026-03-09 | D | 51 | - | v1 |
Find a project by identifier or name
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear semantic distinction: findX tools are read-only; createX tools are writes. Spec 2026-07-28 encourages these annotations for agent safety planning. Agent cannot distinguish safe-to-retry from dangerous operations without them.
Parameter descriptions are minimal or missing context. E.g., 'query' (Search query to filter people by name or email) lacks format guidance. Does case matter? Does it support wildcards? What is the max length? Does partial matching work? LLMs guess and produce incorrect queries.
No error handling guidance in tool descriptions or manifest. When a tool fails (user not found, project doesn't exist, invalid priority), what should the LLM do next? Try a different search? Ask the user? No recovery paths documented.
No pagination parameters (limit, offset, page, cursor) on list/find tools (findPerson, findProject, findIssue, findDocument). Without pagination, large result sets blow context windows. Manifest should declare max results and pagination strategy.
huly.findProject and huly.findPerson accept optional parameters (id/name for project, query for person) but do not describe mutual exclusivity or fallback behavior. What happens if both are provided? Which takes precedence? LLM must guess.
huly.createIssue declares priority as enum (low, medium, high) but does not explain what priority values mean in Huly context or which is default if omitted. Should be in description: 'Priority defaults to medium if omitted. Values: low (3+ weeks), medium (1-2 weeks), high (urgent, <1 week).'
huly.createIssue and huly.createMilestone accept dueDate in ISO format but do not validate or document timezone handling, past-date rejection, or invalid format errors. LLMs will pass malformed dates without guidance on correction.
Handler implementation file (src/mcp/handlers) is not provided. Cannot verify actual parameter validation, error responses, output formatting, or whether responses include all fields needed for chaining (e.g., does findProject return project.id so agent can pass it to createIssue? Does createIssue return issue.id for downstream tools?). Scoring limited by lack of visibility into implementation.