MCP server for Huly issue tracking with stdio and Streamable HTTP transports
Server has 11 tools with basic schemas and descriptions, but significant gaps prevent higher scores. All tools have descriptions (10-100 chars, mostly 50-80), and input schemas are present with type definitions. However, descriptions are generic and lack LLM-optimized guidance on WHEN to use each tool or what happens on failure. Parameter descriptions exist but are minimal (e.g., 'Issue identifier' without format hints). Output schemas are not documented, LLMs cannot predict response structure. No error handling guidance. Tools like list_issues and get_issue have overlapping purposes without clear disambiguation. Batch tool (batch_create_issues) lacks per-item error reporting. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear read/write distinction. Naming is verb-first and clear, but parameter naming inconsistencies (e.g., 'issueId' vs 'id') force LLM mapping overhead.
Add a comment to an issue
Add a relation between two issues
Create multiple issues in a single batch operation
Create a new issue in a project
Retrieve a single issue by identifier with optional field projection and nested content expansion
List issues from a Huly project with pagination, filtering, and optional expansion
List all projects in the workspace
Output schemas not documented. LLMs cannot predict response structure, forcing them to guess what fields are returned and what IDs to extract for chaining.
Parameter naming inconsistency: 'issueId' (camelCase) in add_comment vs 'id' (lowercase) in get_issue vs 'childId'/'parentId' in set_parent. Forces LLM to reason about field mappings.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). Server declares Risk levels in metadata but tools lack MCP-standard annotations for agent safety.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 55 | <=2025-11-25 | v2 |
Full-text search for issues in a project
Set the parent issue for a child issue
Get a summary of project statistics and metadata
Update an existing issue
Descriptions lack LLM-optimized guidance. Generic descriptions like 'Retrieve a single issue' do not explain WHEN to use get_issue vs list_issues, or what happens on failure.
batch_create_issues lacks per-item error reporting. If 1 of 50 issues fails, LLM cannot determine which ones succeeded and which need retry.