export_sbsar

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

No annotations are supplied, so the description carries the full behavioral burden and largely drops it. It says nothing about whether this writes/overwrites an existing file at output_path, whether the export consumes or mutates the open package, what happens if Designer is mid-cook, or how failures surface. For a mutating file-writing tool this is a significant 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 short sentences, zero filler, with the primary action front-loaded and the fallback routing immediately after. Nothing is padded or restated.

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?

There is no output schema and no annotations, so the description must cover both behavior and return expectations; it covers the routing decision but not overwrite semantics or the result of the export. For a three-parameter export tool that is minimally viable rather than complete.

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 three parameters, so the description must compensate and does not. The word 'paquete' hints that the optional 'package' argument defaults to whatever is open, but output_path format/constraints and the overwrite flag (default false) are never explained, leaving the most consequential parameter undocumented.

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 and resource (export the open package to .sbsar) plus the execution context (from Designer), which is enough to tell it apart from generic cooking siblings. It stops short of 5 only because 'paquete abierto' is left implicit rather than tied to the optional 'package' parameter.

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?

Explicitly routes the agent: if Designer is not open, use cook_sbs instead. That is a genuine when-not/alternative rule, unusual at this level. It does not state any prerequisite beyond an open Designer session, nor when to prefer this over saving the package first.

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