put_task_output

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

With no annotations present, the description must fully disclose behavioral traits, but it only says 'store output.' It does not address whether the tool overwrites existing output, requires specific permissions, triggers side effects (like sending notifications), or handles errors. The is_final parameter implies a state change, but its exact impact is unexplained. The description is too terse to provide adequate transparency for a write operation.

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 exceptionally concise at seven words and front-loads the key verb and resource. However, the brevity sacrifices informative detail that would be helpful for correctness. It is not verbose, but could benefit from one or two additional sentences without losing conciseness.

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?

Given the tool has three parameters, a nested object, and no output schema, the description is too sparse. It does not explain the structure of the output object, how is_final interacts with task lifecycle, or what happens on success/failure. Compared to more descriptive sibling tool descriptions (e.g., mark_task_completed, which likely includes side effects), this one leaves significant gaps for an agent to navigate.

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%, so the description must compensate, but it does not map its 'working or final output' language to the parameters. It does not clarify that 'output' is a JSON object, nor explain that 'is_final' controls whether the output is considered final or intermediate. The parameter names are self-explanatory only to a limited extent, and the description adds no extra meaning beyond those names.

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 states 'Store working or final output for a task,' clearly identifying the verb (store) and resource (output for a task). It distinguishes between two modes (working or final) via the is_final parameter, which helps differentiate from similar siblings like submit_my_output or validate_task_output. However, it does not elaborate on what constitutes valid output, so it is slightly less specific than ideal.

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 provides no guidance on when to use this tool versus alternatives such as submit_my_output, mark_task_completed, or validate_task_output. There is no mention of prerequisites, ordering (e.g., should this be called before marking completed), or scenarios where it should be avoided. This leaves the agent to infer usage context entirely from the tool name and siblings.

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