mcp-agent-hub

list_tasks

Retrieve tasks and filter them by status, assignee, tag, parent task, or creator to find relevant work items for coordination or review.

Instructions

列出任务。可按 status/assignee/tag/parent_id 过滤。status ∈ ('open', 'claimed', 'in_progress', 'blocked', 'done', 'cancelled')。

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "list_tasks"
  }
}

Input Schema

Name	Required	Description	Default
`tag`	No
`limit`	No
`status`	No
`assignee`	No
`parent_id`	No
`created_by`	No

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 27, 2026

TDQS

B3.2/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden. It implies a read operation but says nothing about the default limit of 50, paging, ordering, or whether an empty filter returns everything — material behavior for a listing tool with many siblings.

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?

Three short sentences, front-loaded with the action and then the filters, with zero filler. The status enumeration could have been placed in the parameter description rather than the tool description, but it is still compact.

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?

The presence of an output schema relieves the description of explaining return values, but with 0% schema coverage it should still account for limit and created_by and describe pagination behavior. It is adequate for a simple list tool but leaves real gaps.

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 description coverage is 0%, so the description must compensate. It adds real value by enumerating the legal status values, which the schema does not, but it omits two of six parameters (limit and created_by) and gives no format hints for assignee, tag, or parent_id.

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 ('列出任务') and names the filterable dimensions, so the agent knows exactly what the tool returns. It does not differentiate from siblings such as my_assignments or list_rooms, which also surface tasks, so the agent must infer the distinction.

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

Usage Guidelines3/5

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

Filterability is stated ('可按 status/assignee/tag/parent_id 过滤'), which implies when the tool is useful, but there is no explicit guidance on when to prefer it over my_assignments or list_agents, nor any exclusion conditions.

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