Skip to main content
Glama

独行录 / opcmenu

列我的合作任务

list_collaboration_tasks
Idempotent

【需要登录】按 assigned_to_me(待我做)或 assigned_by_me(我派给他人)列独行录任务;done=true 查看已了结记录,goalId 缩小到某目标。归档目标不在此列表,归档目标任务用 get_collaboration_goal。任务查询会幂等补周期期次。reachingLimit=true 表示可能截断,不代表总数。

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
boxNoassigned_to_me
doneNo
limitNo
goalIdNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Beyond annotations (idempotentHint=true, destructiveHint=false), the description discloses the required login, the idempotent period-filling side effect ('任务查询会幂等补周期期次'), and the meaning of reachingLimit as possible truncation rather than total count. These are genuinely informative and consistent with the annotations.

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

Conciseness5/5

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

Three dense sentences each add value: authentication, core filters, archived-goal exclusion, idempotent period behavior, and truncation semantics. Information is front-loaded, and there is no filler or repetition.

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

Completeness4/5

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

Given no output schema, the description covers authentication, filtering options, side effects, and truncation semantics. It does not describe the general shape of the returned task list, and the limit parameter is omitted, but the core call contract is still well communicated.

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 meaning for box (待我做/我派给他人), done (查看已了结记录), and goalId (缩小到某目标), but it gives no explanation of the limit parameter at all. The schema supplies type and constraints, but the semantic role of limit is left unstated, leaving a notable gap.

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?

The description states a specific verb ('列' / list) and resource (collaboration tasks), and clearly distinguishes the two relevant boxes (assigned_to_me and assigned_by_me). It also differentiates itself from the sibling get_collaboration_goal by explicitly saying archived goals are not in this list.

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

Usage Guidelines5/5

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

It gives direct usage conditions: filters by box, done, and goalId, and explicitly routes archived-goal cases to get_collaboration_goal. It also clarifies the reachingLimit semantics, so an agent knows when results may be incomplete.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources