wb_build_native_import

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

With no annotations at all, the description carries the full behavioral burden, and it does disclose the most important trait: the tool is safe by default because run=false previews rather than writes. It also hints at a precondition ("prepared workspace"). What it never states is what running actually mutates, whether an import overwrites existing files, whether it is reversible, or what a preview returns — significant gaps for an unannotated write-capable tool.

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, front-loaded with the action and resource, with the safety default stated immediately after. No filler. The compressed compound phrasing ("template-bundle + WolvenKit JSON-deserialize import") is dense but each clause carries information.

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?

This is a six-parameter, mutation-capable import tool with no annotations, no output schema, and zero schema description coverage, so the description is the only documentation an agent has. It leaves four parameters unexplained and says nothing about consequences, return shape, or failure modes. Adequate only as a one-line hint, not as a usable definition.

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% across six parameters, so the description must compensate and largely does not. Only run (default false) is explained; cli, timeout, and keep_json are entirely undocumented in both schema and description, and bundle/workspace are only obliquely referenced through prose. Two of six parameters are meaningfully covered, which is a real gap even accounting for the clear run-default note.

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 names a specific action pair (preview or run) and a specific resource: a template-bundle plus WolvenKit JSON-deserialize import into a prepared workspace. An agent can tell this is a build/import operation rather than a query. It does not, however, distinguish itself from near-neighbours such as wb_native_import or wb_worker_import, which is the only thing keeping it off 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?

"run=false by default" implicitly signals a preview-then-commit workflow, which is useful context for sequencing calls. There is no explicit statement of when to choose this over wb_native_import, wb_worker_import, or wb_build_worker_import, and no stated prerequisites beyond the vague "prepared workspace".

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