Get Resume Template

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive, so the safety profile is covered, and the description adds real domain context: the returned source differs by engine (Jinja2+LaTeX vs raw .typ), how templates opt into fmt.* knobs, the defaults, and a typst-specific quirk where date_format is always supported server-side. This is meaningful behavior beyond the annotations, though it does not discuss failure modes.

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 purpose is front-loaded in the first clause, which is good, but the body then expands into a long enumeration of fmt.* knobs and defaults that is more relevant to rendering/tailoring than to merely fetching a template. The density is high and could be trimmed or moved, making it verbose for the stated action.

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?

With no output schema, the description correctly takes on the burden of describing return values and does so thoroughly (source, engine, engine_available, supported_fmt_keys, and the fmt namespace semantics). It is close to complete, with only error/missing-template behavior left unspecified.

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 single template_id parameter has 0% schema coverage, so the description carries the burden, but it never defines the id's format or where it comes from beyond an implicit nod via '(see list_templates)'. It does add substantial context about what a template object contains, which indirectly clarifies the resource, but the parameter itself is only weakly explained.

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 verb (get) and resource (template) and enumerates exactly what is returned: full source, engine, engine_available, and supported_fmt_keys. It also distinguishes itself from list_templates by referencing it, so an agent can tell the retrieval tool apart from the listing tool without opening schemas.

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 only routing cue is the parenthetical '(see list_templates)', which implies that list_templates supplies the template_id this tool consumes. There is no explicit when-to-use/when-not statement, no prerequisite about needing a valid template_id, and no mention of error behavior for a missing template.

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