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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered by structured data. The description's real contribution is downstream operational rules (value format must be an array for checkbox/combobox/listbox, never pass empty strings, tink-scan-id fields embed the signer's ID image and require explicit consent) rather than behavior of this call itself. Useful, but it describes how to act on the result, not what this tool does beyond a read — and it never states error behavior if templateId is unknown or the template has no fields.

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 sequencing rule is correctly front-loaded, followed by the return shape, then the pre-fill decision, then format and consent rules — a sensible priority order. It is on the long side for a single-parameter read call, and the detailed value-format rules are arguably reference material for a field-setting tool rather than for retrieval, but no sentence is pure filler.

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, so the description carries the full burden of describing the response — and it does, listing every returned attribute and the options array shape for choice fields. Combined with the invocation ordering and the editable/consent decision flow, an agent has enough to call this correctly and act on the result.

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?

Only one parameter, and its schema description ('Unique identifier of the template') already gives 100% coverage. The description never mentions templateId or how to obtain it, though the 'call after get_template' sequencing implies the ID comes from that prior call. Baseline 3 applies when the schema carries parameter meaning.

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 ('Reveals whether the template has form fields the user can pre-fill') and enumerates exactly what a field object contains (name, label, type, editable, readOnly, options). The instruction to call it 'immediately after get_template' positions it unambiguously against sibling tools like get_template and get_document_fields.

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?

Gives an explicit invocation rule ('Always call this immediately after get_template — before collecting signer details') and a concrete branch after the call: if any fields have editable: true, ask the user whether to pre-fill or leave for the signer. It also names a hard exclusion gate — get explicit yes before sending when scan-trigger fields are present.

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