chatgpt_webui_command

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

With no annotations, the description carries the full disclosure burden. It does reveal the defining behavior — it is a wrapper that converts NL into a prompt call — but leaves the execution model ambiguous: does it merely return the constructed call or does it execute it and wait? Given the wait/poll/mode parameters imply execution and waiting behavior, this ambiguity is a material transparency gap.

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 sentences with no wasted words; the wrapper concept is front-loaded before the illustrative example. The example phrase is somewhat long, but it earns its place by showing the expected input shape. Slightly verbose example keeps it from a 5.

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 4-parameter tool with no annotations and no output schema, the description is thin. It does not say whether the tool executes the prompt or returns the converted call, does not explain how mode/wait/poll relate to the wrapper behavior, and does not guide the agent on choosing this over chatgpt_webui_prompt. An agent is left with material uncertainty about invocation and return behavior.

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 100%, so a baseline of 3 applies even with no parameter detail in the description. The example phrase adds mild value by illustrating what a natural-language 'command' looks like (model and feature tokens embedded in prose), but the schema already documents all four parameters adequately.

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 ('converts') acting on a natural-language command resource, with a concrete example of the input format. It also names its transformation target (chatgpt_webui_prompt call), which begins to distinguish it from that sibling. It does not fully carve out its role against the other siblings (ask, run), so it falls just 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?

Usage is implied: if a user expresses an intent as a natural-language phrase, this tool wraps it. However, there is no explicit when/when-not guidance, no named alternatives beyond the target prompt tool, and no statement about when one would prefer chatgpt_webui_prompt directly. An agent must infer the selection logic.

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