Creates a local peer collaboration task from a goal with complementary roles and a 1–8 attempt budget; no model call is made.
Create a local peer collaboration task with complementary duties and 1..8 attempt budget. No model call.
| Name | Required | Description | Default |
|---|---|---|---|
| goal | Yes | ||
| lead_brief | No | 共同提出方案、追问、反驳与补证；负责可执行修改与测试，明确修正自己的判断。 | |
| reviewer_brief | No | 共同提出方案、追问、反驳与补证；发挥独立推理优势，明确修正自己的判断。 | |
| max_model_turns | No |
Changes observed during successful MCP inspections.
v0.5.2Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the non-read-only, closed-world, non-destructive profile, and the description adds real context beyond them: the task is local, spawns no model call, and carries a bounded 1..8 attempt budget. It still omits what is persisted and whether the task is durable, which is why this is not a 5.
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 short, front-loaded sentences with no filler; the key distinguishing fact ('No model call') is deliberately placed last as a differentiator.
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?
It is a creating/mutating tool with no output schema, so the description should say what the agent receives back (a task/handle needed by agy_discussion_turn) to be actionable. It covers the creation semantics and budget but leaves the handoff to sibling tools unstated.
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?
Schema coverage is 0%, so the description must carry the load; it does clarify that 'complementary duties' maps to the two brief parameters and that the budget maps to max_model_turns, adding a 1..8 range the schema lacks. However, 'goal' (the only required parameter) is never explained, and the brief semantics remain vague.
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?
States a specific verb ('Create') and resource ('local peer collaboration task'), plus scope qualifiers ('complementary duties', '1..8 attempt budget', 'No model call'). It implicitly separates this from agy_council_create by naming 'peer collaboration' but never explicitly contrasts the two, so it stops short of a 5.
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 model call' implies this is a setup step that later drives agy_discussion_turn/read, but the description never states when to choose this over agy_council_create or what precondition must hold before calling it. Usage is only inferable from the wording, not spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.