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

Annotations already establish readOnly/openWorld/non-destructive, so the description adds real value beyond them: results are ranked 'as the app ranks them,' the database holds over a million entries, and it requires the user's Cotlet API key with access to this app. This is useful operational context (ranking behavior, auth requirement) not derivable from the annotations.

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?

It is front-loaded with the core purpose and each sentence carries information about content, parameters, or auth. There is mild redundancy between the opening ('Search the Fitatu database of products and meals') and the second sentence ('Searches the Fitatu product and meal database...'), which costs it a point.

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 does the work of indicating the return content (calories and macros per 100 g/ml) and the ranking, plus auth requirements and the food_id chaining path. It is complete enough for a read-only search tool, though exact result fields and pagination are not itemized.

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 coverage is 100%, so the baseline is 3, but the description adds meaning over the schema: it clarifies 'database' as choosing the database country and elaborates from_fitatu_only as generic entries 'checked by its dietitians,' which is richer than the schema's 'not tied to a brand.'

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 precise verb+resource ('Search the Fitatu database of products and meals') and adds scope detail (calories/macros per 100 g or 100 ml, over a million entries). It also distinguishes itself from the sibling fitatu_log_food by noting 'Pass food_id to log_food,' letting an agent separate search from logging without opening either schema.

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?

It gives clear usage context: choose the database country or restrict to Fitatu-vetted generics, and use the returned food_id in log_food. It stops short of explicit when-not-to-use guidance or naming a competing search alternative, but the search-vs-log workflow is clear.

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