dynamic_workflow_next_assignment

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

Annotations already cover the safety profile (readOnlyHint=false, idempotentHint=true, destructiveHint=false), and the description adds the exclusive-claim semantics of 'lease' and the strictness implied by 'exact' role binding, which goes beyond the annotations. There is no contradiction with the annotations. However, the description does not disclose what happens when no matching assignment exists, whether a lease is consumed or expires, or the consequences of an expected_revision mismatch.

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?

The description is a single 8-word sentence with no wasted words and a front-loaded verb. But it is under-specified for a tool with 8 required parameters and a stateful lease protocol — the terseness is achieved at the direct expense of needed semantic content, so it is not appropriately sized.

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?

The output schema covers return values and the annotations cover idempotency and non-destructiveness, so the description is not responsible for those. But this is a stateful lease operation with 8 required parameters inside a multi-step workflow protocol, and the one-line description provides no sequencing information, no explanation of how to obtain a session_receipt, no definition of a host binding, and no description of what expected_revision protects against. A single clause is materially incomplete for this complexity level.

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% — all 8 required parameters carry only titles like 'Session Receipt', 'Expected Revision', and 'Host Binding Ref' with no explanatory text. The description gestures at role binding, which maps loosely to host_role and host_binding_ref, but says nothing about session_receipt, idempotency_key, expected_revision, or the three ref parameters. With 8 undocumented params, the description fails almost entirely to compensate for the schema gap.

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 uses a specific verb ('Lease') with a clear resource ('next assignment') and a scoping condition ('the caller's exact role binding'), which distinguishes it from workflow siblings like dynamic_workflow_start, dynamic_workflow_status, and dynamic_workflow_cancel. However, the 'lease' concept is jargon that is never explained, and no sibling is named explicitly, so an agent must infer what leasing entails and how this differs from dynamic_workflow_attach.

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 call this tool versus the many dynamic_workflow_* siblings (start, attach, submit_plan, submit_builder_result, submit_evaluator_verdict, cancel). The description states no prerequisites — such as needing a prior session_receipt, what expected_revision guards against, or whether a workflow run must already be active — leaving the correct invocation point in the workflow protocol completely unspecified.

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