Read one durable Operator task in the selected product with its step states, action states, safe summaries, version, and progress. Does not return executable arguments or raw provider errors.
| Name | Required | Description | Default |
|---|---|---|---|
| task_id | Yes | Task id (UUID format, e.g. 550e8400-e29b-41d4-a716-446655440000) |
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already carry the read-only, idempotent, non-destructive profile, so the safety bar is met elsewhere. The description still adds real value by disclosing negative scope ('Does not return executable arguments or raw provider errors') and naming what is returned, which meaningfully distinguishes it from control_operator_task.
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 tight sentences, the positive statement of contents is front-loaded ahead of the exclusion clause, and no sentence is redundant with the schema or annotations.
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?
With no output schema, the description usefully enumerates the fields returned and what is withheld, which compensates well. It omits minor operational details such as behavior when the task_id is unknown or stale, and it does not define what a 'durable Operator task' is for an unfamiliar agent.
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?
Only one parameter and schema description coverage is 100%, so the schema already documents the UUID format and example. The description adds nothing further about task_id (e.g. where to obtain it), so the baseline 3 applies.
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 ('Read') and resource ('one durable Operator task') with the scope 'one', which separates it from list_operator_tasks, and enumerates the returned contents (step states, action states, version, progress). An agent can distinguish it from the read sibling and from control_operator_task without opening a schema.
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?
Usage is only implied: the required task_id and the singular 'one ... task' suggest this is the lookup-by-id counterpart to list_operator_tasks, but no sentence says when to reach for this tool versus listing or controlling a task. No prerequisites or alternatives are named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.