LightCMS

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

With readOnlyHint=true in annotations, description confirms safety with 'without saving.' Critically, it compensates for missing output schema by disclosing return structure ('rendered_html and any warnings') and specific warning types (missing fields, unclosed tags, unresolved placeholders).

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?

Four efficient sentences: purpose, usage, parameter example with syntax, and return value disclosure. No repetition of schema details, appropriately front-loaded with core purpose.

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?

Thoroughly complete for a preview tool: describes output to compensate for missing output schema, provides parameter usage examples for the nested data object, and clarifies behavioral boundaries (read-only) given the complexity of 3 parameters including nested overrides.

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?

Despite 100% schema coverage (baseline 3), description adds value via concrete JSON example showing override syntax, and reinforces 'not saved' semantics for the data/title overrides. The example provides concrete usage context beyond the schema definitions.

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?

Description uses specific verb 'Render' with resource 'content item's HTML' and explicitly distinguishes from siblings by stating 'without saving or publishing,' clearly differentiating it from update_content and publish_content in the sibling list.

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?

Provides clear when-to-use context ('verify what a page will look like before publishing'), implicitly establishing the workflow relationship with publish_content. Does not explicitly name the alternative tool, so stops short of a 5.

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