render_pdf

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

No annotations are provided, so the description carries the full burden. It discloses several behavioral traits: Chinese font stack details, default write location (managed temp dir with TTL cleanup) vs explicit output_path (not auto-deleted), and the Windows GTK/Pango/Cairo dependency with a render_failed error. This is strong disclosure, though it doesn't describe output structure/return format beyond the path.

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 well-structured with clear section headers (When to call, Template, Notes) and front-loaded purpose. It's moderately long but every section earns its place — behavioral notes, error codes, and template variants are all meaningful. A slight trim could tighten it but organization is strong.

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?

The tool has 3 parameters with 0% schema coverage, nested objects, an output schema, and no annotations. The description compensates well by covering template options, output path semantics, dependencies, fonts, and error codes. It could be stronger on resume_data shape expectations, but it otherwise provides a complete picture for this workflow-final tool.

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%, so the description carries the burden. It explains the template parameter's options (modern default, compact, unknown → template_not_found) and the output_path lifetime semantics (managed temp vs explicit). However, it doesn't detail the resume_data structure/expected shape, relying on the generic object schema. Given 0% coverage, this is solid compensation, just missing resume_data specifics.

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 states a specific verb+resource — Jinja2 HTML template + WeasyPrint to render a structured resume into PDF and return the absolute file path. It explicitly mentions the template options and error behaviors, and its role as the final workflow step clearly distinguishes it from siblings like parse_resume, generate_bullet_points, and merge_into_resume.

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?

The 'When to call' section explicitly states to invoke this after the user confirms the merge result (optionally via diff_resume_versions), as the final step of the workflow. It also clarifies template selection behavior and error codes, giving clear when-to-use guidance against the sibling pipeline tools.

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