Skip to main content
Glama

独行录 / opcmenu

创建或指派合作任务

create_collaboration_task

【需要登录】在独行录目标中创建任务;assigneeId 省略为自己,指定他人必须是目标合作人,会通知对方。用户授权派给该人后才调用。结果不明或超时后先查询现值,不要自动重发;服务没有持久请求去重键。 创建前后用 get_collaboration_goal 核对。

Input Schema

NameRequiredDescriptionDefault
dueAtNo截止时刻 ISO 8601,须含时区;null 清空,省略保留现值
titleYes
detailNo
goalIdYes
assigneeIdNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.2/5.0
Behavior5/5

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

The single annotation (destructiveHint=false) says almost nothing, and the description more than compensates: it discloses the notification side effect on assignment, the auth requirement, the absence of a durable idempotency key, and an explicit no-auto-retry protocol (re-read current state instead). That is exactly the operational context annotations cannot 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?

Dense but front-loaded: auth, then the create/assign semantics, then the retry hazard and verification tool. Every clause is actionable; only the retry guidance repeats the same idea twice (结果不明或超时 / 不要自动重发).

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?

With no output schema and only a weak annotation, the description covers auth, side effects, idempotency and post-call verification. It never says what a successful call returns (e.g. the task id), which is why it points to get_collaboration_goal rather than stating the result shape.

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

Parameters4/5

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

Schema coverage is only 20% (only dueAt is documented), so the description must carry the load, and it explains the least obvious parameter: assigneeId omitted means self, otherwise it must be a goal collaborator (and triggers a notification). goalId/title/detail are left to their names and maxLength constraints.

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?

Names a specific verb+resource and scope: create a task inside a collaboration goal (独行录目标中创建任务), plus assignment behavior. It does not distinguish this from the very similar siblings create_collaboration_tasks (plural, batch) or create_direct_collaboration_task, so an agent must infer which one to use from name alone.

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?

Gives concrete preconditions (login required; only call after the user authorizes assigning to that person; assignee must already be a collaborator of the goal) and names a companion tool to run before and after (get_collaboration_goal). It lacks any explicit when-not or comparison against the plural/bulk siblings.

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