wb_worker_import

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

With no annotations, the description carries the full burden and does deliver the key safety fact: the default is a non-mutating preview, and it executes via a 'verified' worker. It does not say what an import overwrites, whether it is idempotent, what happens on partial failure, or what the preview returns.

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?

A single compact sentence that front-loads the two modes and ends with the default, which is exactly the ordering an agent needs. Nothing is padded, though the phrase 'without WScript template capture' is only meaningful if the agent already knows the sibling native-template pipeline.

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, no-annotation, no-output-schema tool this is thin: the return values of preview mode, the semantics of output/worker/timeout, and the consequences of run=true are all unstated. An agent could call it, but not confidently.

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 coverage is 0% across six parameters, and the description only clarifies one of them (run, with its default). export_file, output, worker, timeout, and keep_json get no meaning from the description, so an agent must guess at paths, worker selection, and whether keep_json retains intermediates.

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?

Names a clear paired verb (Preview or import) and a specific resource (a WB export), and identifies the execution path (.NET WolvenKit worker rather than WScript template capture). It does not, however, differentiate itself from near siblings such as wb_native_import or wb_build_worker_import, which an agent would also plausibly pick.

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?

'run=false by default' implicitly frames the preview-first workflow, so an agent can infer 'call with run=false to inspect, then run=true to commit'. There is no explicit when-to-use statement and no reference to the sibling import tools that compete for this task.

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