Request native execution through the lead without starting an agent; the lead uses host collaboration tools and records the returned reference.
Request native execution through the lead. Starts no agent; the lead must use actual host collaboration tools and record their returned reference.
| Name | Required | Description | Default |
|---|---|---|---|
| taskId | Yes | ||
| boardId | Yes | ||
| workflowId | No | ||
| instructions | No | ||
| parentMemberId | No | ||
| expectedTaskRevision | Yes |
Changes observed during successful MCP inspections.
v0.4.6Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare a non-destructive write in a closed world; the description adds a genuinely non-obvious behavioral fact, that no agent is started and the lead must act through real host tools. It stops short of saying what this call actually mutates (a queued request record?) or whether the call blocks, which matters given readOnlyHint=false.
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 dense sentences, front-loaded with the action and immediately followed by the constraint that most affects agent behavior. No filler, no restatement of the name.
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 six-parameter mutation tool with zero schema descriptions and no output schema, the description carries far too little: no parameter meaning, no concurrency semantics for expectedTaskRevision, no description of what is returned or how the recorded reference flows back.
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 description coverage is 0% and the description mentions none of the six parameters. Critically, expectedTaskRevision clearly encodes an optimistic-concurrency precondition, and instructions vs. workflowId vs. parentMemberId are entirely undefined in either the schema or the description.
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 and object ("request native execution") and names the actor that fulfills it ("through the lead"). It also carves out the key negative ("starts no agent"), which tells an agent this is not an agent-spawning call. The phrase "native execution" is unexplained jargon, and no sibling (e.g. team_record_execution) is named to sharpen the boundary.
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?
The description implies when this applies (when the lead, not the tool, must perform host collaboration) and prescribes a follow-up action (record the returned reference). But it never contrasts this with team_record_execution or team_bind_agent_activity, so the choice between siblings is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.