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

The readOnlyHint annotation already communicates that this is a non-mutating operation. The description adds useful behavioral context by limiting inputs to PDF/DOCX and excluding images, but it does not disclose additional behaviors such as output format, behavior on unsupported files, or font-detection limitations.

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 a single compact, front-loaded sentence. It leads with the tool's role, follows with accepted formats, and ends with the key exclusion. No unnecessary filler or repetition of schema details.

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?

For a simple one-parameter, read-only tool with no output schema, the description adequately covers the core scenario: input file types and an important unsupported case. It does not detail return structure, but the tool name and action make the expected output reasonably clear.

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 single 'file' parameter as PDF/DOCX input, so the description is not the only source. However, it adds meaningful semantic value by explicitly stating that images are unsupported, which clarifies the accepted input domain beyond the schema.

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 action ('Detect fonts') and the resource scope ('PDF or DOCX document'), with an explicit exclusion of images. This makes it unmistakable what the tool does and distinguishes it from the many sibling analyze_* tools.

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 provides clear when-to-use context: any PDF or DOCX where font detection is needed. It also gives a when-not-to-use signal by explicitly stating that images are not supported, though it does not name a specific alternative tool.

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