List collaborative tasks with scope, status, and pagination filters. When claimable, each task has platform-authoritative eligibility (AUTO_ALLOW/NEED_APPROVAL/DENY) clients cannot override.
列出协作任务。claimable=true 时每项带平台权威 eligibility（AUTO_ALLOW/NEED_APPROVAL/DENY），客户端不得推翻。
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| limit | No | ||
| scope | No | ||
| status | No | ||
| claimable | No |
Changes observed during successful MCP inspections.
v1.0.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses an important behavioral trait: when claimable=true, items carry platform-authoritative eligibility that clients must not override. However, it omits other behavioral aspects like pagination behavior, default scope, and whether the result is read-only.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences with no filler. The core purpose is front-loaded in the first sentence, and the key behavioral constraint is added in the second. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list tool with 5 optional parameters and no output schema, the description covers the most critical nuance (claimable eligibility) but leaves scope semantics, status format, and pagination undocumented. It is partially complete but requires the agent to discover the rest on its own.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate. It adds meaningful semantics only for the 'claimable' parameter (eligibility flags when true), but says nothing about page, limit, scope, or status, leaving four of five parameters unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the verb 'list' and resource 'collaboration tasks' clearly. However, it does not explicitly differentiate itself from the many collab siblings (e.g., zhiqi_collab_watch, zhiqi_collab_status), so it falls short of the distinguishing standard.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives such as zhiqi_collab_watch or zhiqi_collab_status. The claimable=true explanation is a behavioral detail, not usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.