Python MCP Hub

Overview Schema Source Related Servers Discussions Admin

huly_get_task_detail

Read a Huly issue's full context—description, status, priority, assignee, acceptance criteria, sub-issues, comments, and linked sources—to gather requirements and download files for spec writing.

Instructions

Read the FULL context of one Huly issue the user names (READ-ONLY on Huly).

Returns: title, description text, status name + category, priority, assignee name, due date,
explicit acceptance criteria (with source), parent, direct sub-issues (status, assignee, AC),
comments (author, time, text) and `sources`: every PO document mention, image, attachment,
file link (e.g. a PDF linked in a comment) and external link the ticket points to, each with
a status: READ (document text included), DOWNLOADED (saved file path), AVAILABLE (call again
with download=true), UNREACHABLE (this account cannot open it: ask the user) or EXTERNAL.

Args:
    task_id: The issue the user named: an ID ('APP-123'), a number ('123', only if unique),
             a Huly _id, or a Huly issue link pasted from the browser.
    workspace_path: Client workspace containing the .env with Huly credentials.
    include_sub_issues: Also return direct child issues (one level) with their own criteria.
                        A parent issue is one feature: write one spec and use the children as
                        planning input. A child issue: scope the spec to it; parent is context only.
    download: Save files, images, attachments and readable documents to
              <workspace>/.superpowers/sources/<ISSUE-ID>/ so they can be opened and read
              (PDF, images). Use it before writing requirements. A linked Figma frame is
              saved to figma/ (PNG, node JSON, summary) as a `figma` source: READ,
              NOT_PROVIDED (no FIGMA_TOKEN in the .env) or UNREACHABLE (401/403/404).

Input Schema

Name	Required	Description	Default
`task_id`	Yes
`download`	No
`workspace_path`	No
`include_sub_issues`	No

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv3.3.1Oct 29, 2026

TDQS

A4.5/5.0

Behavior5/5

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

With no annotations, the description carries the full burden and does so: it declares READ-ONLY, enumerates every returned field group, defines the `sources` status vocabulary (READ/DOWNLOADED/AVAILABLE/UNREACHABLE/EXTERNAL), explains the account-permission failure mode ('this account cannot open it: ask the user'), and discloses the FIGMA_TOKEN prerequisite plus its NOT_PROVIDED/UNREACHABLE outcomes. This is far beyond what a schema or annotation set would convey.

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?

Well front-loaded: the read-only scope and the one-issue target come first, followed by a structured 'Returns:' block and then 'Args:'. It is on the long side — the download paragraph restates save behavior and figma handling in one dense run — but nearly every sentence carries operational information rather than filler.

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

Completeness5/5

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

An output schema exists, yet the description still summarizes the return shape, which is useful rather than redundant because it lists the `sources` semantics that a JSON schema would not explain. Combined with the credential prerequisite, the download side effects, and the per-argument behavior, an agent has everything needed to invoke it correctly without trial and error.

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

Parameters5/5

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

Schema description coverage is 0%, so the description must define all four parameters, and it does: task_id enumerates accepted formats ('APP-123', '123' only if unique, Huly _id, pasted issue link); workspace_path is tied to the .env holding Huly credentials; include_sub_issues is bounded to one level with planning implications; download specifies the exact save path and file-type coverage. No parameter is left ambiguous.

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?

The description states a specific verb and resource ('Read the FULL context of one Huly issue') and pins the scope to an issue 'the user names', which implicitly separates it from the sibling listing tool huly_get_my_tasks. It never names that sibling explicitly, so the differentiation is left to inference rather than stated.

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

Usage Guidelines4/5

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

The Args section carries real usage guidance: 'Use it before writing requirements', 'A parent issue is one feature: write one spec and use the children as planning input', and 'A child issue: scope the spec to it'. What's missing is the explicit inverse — no guidance on using huly_get_my_tasks to discover an issue id first, and no statement of when this tool is the wrong pick.

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

Deploy Server