Python MCP Hub

Overview Schema Source Related Servers Discussions Admin

huly_get_my_tasks

Retrieve open Huly tasks assigned to the logged-in user, optionally listing all workspace tasks. Read-only lookup for task intake; fails if credentials or network are unavailable.

Instructions

Open Huly tasks assigned to the logged-in user (status category not Done/Canceled).

Strictly READ-ONLY: Never modifies tasks on Huly.
Zero Mock Data: Fails fast if credentials are not configured or network error occurs.

Args:
    workspace_path: Client workspace containing the .env with Huly credentials.
                    Defaults to current working directory if empty.
    include_all: List open tasks of the whole workspace instead of only the user's own.

Returns:
    Task count and the open tasks with ID, title, status name, priority, assignee and due date.

Input Schema

Name	Required	Description	Default
`include_all`	No
`workspace_path`	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

Behavior4/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 well: it declares strict read-only behavior, fail-fast on missing credentials or network errors, and no mock data fallback. It omits pagination limits, result caps, or auth prerequisites beyond the .env credential location.

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?

Front-loaded scope sentence followed by compact behavioral guarantees and structured Args/Returns blocks, so an agent can scan it quickly. The 'Zero Mock Data' framing is slightly informal and could be stated more plainly as a fail-fast guarantee.

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?

Everything needed to invoke correctly is present: filter semantics, credential location, the scope switch, and a return summary (task count plus ID, title, status, priority, assignee, due date). An output schema exists, so the return description is bonus rather than necessity.

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 coverage is 0%, so the description must compensate, and it does: workspace_path is explained as the client workspace holding the .env with Huly credentials, defaulting to the current working directory when empty, and include_all is explained as switching from the user's own tasks to the whole workspace.

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

Purpose5/5

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

States a specific verb and resource plus scope: open tasks assigned to the logged-in user, explicitly excluding Done/Canceled status categories. This clearly separates it from the sibling huly_get_task_detail, which is a per-task lookup.

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 scope statement ('open tasks assigned to the logged-in user') and the include_all switch make the intended use clear, including the whole-workspace alternative. It stops short of naming huly_get_task_detail as the drill-down alternative or stating when not to use it.

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

Deploy Server