huly-mcp-selfhost

list_issues

Read-only

Retrieve and filter project issues by status, priority, milestone, component, label, assignee, parent, due date, or title to locate specific work items.

Instructions

List issues of a project; filters: status, priority, milestone, component, label, assignee, parent

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "projectIdentifier": "<projectIdentifier>"
    },
    "name": "list_issues"
  }
}

Input Schema

Name	Required	Description
`due`	No	Due date: overdue, set or none
`limit`	No
`title`	No	Title contains this text
`offset`	No
`status`	No	Status name, "open" (default) or "all"
`assignee`	No	Person name; null = unassigned
`priority`	No	Filter by priority
`labelName`	No	Filter by label name
`workspace`	No
`componentLabel`	No	Component name; null = none
`milestoneLabel`	No	Milestone name; null = none
`parentIdentifier`	No	Direct sub-issues of this issue; null = top-level only
`projectIdentifier`	Yes	Project key

Schema Changelog

Changes observed during successful MCP inspections.

First observedv3.5.1Nov 12, 2026

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

readOnlyHint=true already tells the agent this is a safe read, so the description carries only the residual burden — and it adds nothing: no default behavior (status defaults to "open", limit defaults to 50), no pagination/ordering note, and no indication that omitting status hides closed issues. For a 13-parameter listing tool those defaults materially change results.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single front-loaded sentence with the resource first and filters after the semicolon — no filler. It is slightly under-specified rather than verbose, but nothing in it is wasted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 13-parameter, high-complexity listing tool with no output schema, the description omits default filter behavior, pagination via limit/offset, and result ordering. Those gaps are the ones most likely to cause an agent to mis-call, though the schema partially compensates.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 77% and the schema documents parameter meanings and enums itself. The description only re-enumerates seven filter names already present in the schema and adds no syntax, matching behavior, or default semantics beyond it; baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('List issues'), scoped to a project, and enumerates the filter facets. It does not distinguish itself from nearby siblings such as search_issues or list_sub_issues, so an agent must infer which lister to choose.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this versus search_issues, list_sub_issues, or bulk_update_issues, and no mention of prerequisites or when-not to use it. The filter list implies a browsing use case but never states it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server