Create a draft asset — returns an inline preview image

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

Annotations are minimal (only openWorldHint:false), so the description carries the full burden of behavior disclosure. It covers success semantics ('config validated AND rendered'), visibility state ('Nothing is public until publish_asset'), style behavior ('Style comes from the defaults and your brand'), and hard limits (~100 KB rows, 2 MB asset cap). This is substantive behavioral context beyond the schema.

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 dense and front-loaded, with the core purpose and workflow stated early. Every sentence contributes, but the length and paragraph-style structure make navigation slightly harder than it could be; a short workflow summary plus bullets for data shape and limits would be crisper.

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 complex 7-parameter tool with no output schema, the description covers lifecycle, validation/rendering semantics, limits, and template behavior well. The main gap is that it never explicitly enumerates the response fields (e.g., the asset id) an agent would need to chain update_asset or get_asset; it only implies those are returned.

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?

The schema already documents all 7 parameters in detail, including title-alias precedence and date parsing, so the baseline is 3. The description adds value by reinforcing the row-major data shape, advising when not to set config fields, and clarifying the large-dataset alternative. It does not fully replace the schema but supplements it meaningfully.

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 opens with a clear verb and resource ('Creates a draft') and immediately states the concrete deliverable: an inline low-res PNG preview. It also names the lifecycle siblings (update_asset, publish_asset) and distinguishes draft creation from publishing, so an agent cannot confuse this with related tools.

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?

Explicit routing guidance is given: iterate with update_asset, publish later with publish_asset or pass publish:true when final, and use set_data_source or replace_asset_data for large datasets instead of this tool. It also references template as the fastest starting point. This is clear when-to-use and when-not-to-use coverage.

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