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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description goes beyond this by detailing the field structure (name, label, type, editable, readOnly, options), explaining the decision to pre-fill, and the value formatting rules (string vs array, omit empty strings). This adds substantial behavioral context that annotations do not cover.

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 front-loaded with the critical usage instruction ('Always call this immediately after get_template'), then systematically explains the field properties, the conditional action, and the value format rule. Every sentence adds essential information without redundancy, making it well-structured and efficient.

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?

Given there is no output schema, the description fully explains the return structure (field attributes) and how to interpret it for subsequent actions. It covers the workflow (pre-fill decision), value format rules, and edge cases (omit empty strings). Nothing an agent needs to call and use the tool correctly is missing.

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 the only parameter templateId with a description ('Unique identifier of the template'), achieving 100% coverage. The description does not add new semantic details about the parameter itself, though it implies the templateId comes from get_template. Since schema coverage is high, the baseline of 3 is appropriate.

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 clearly states the tool reveals whether a template has pre-fillable form fields, with a specific verb ('reveals') and resource ('template fields'). It is implicitly distinguished from sibling tools like get_document_fields and get_file_fields by the context of 'template' and the instruction to call it after get_template, so an agent can select it correctly.

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 description explicitly says 'Always call this immediately after get_template — before collecting signer details', giving a precise timing and workflow context. It also provides conditional guidance on asking the user about pre-filling when editable fields exist, and states the value format rule for different field types, which is essential for correct invocation.

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