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

With no annotations provided, the description carries the full burden. It discloses data provenance ('les prix viennent des grilles publiques des éditeurs'), flags unverified information ('ce qui n'est pas publié... est signalé comme tel'), and even reveals a conflict of interest ('Frigolog publie ce MCP'). This exceeds typical transparency expectations for a read-only comparison tool, though it does not explicitly state it causes no side effects.

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 core purpose and then lists the compared solutions and criteria. It is bilingual, which adds some redundancy, but each sentence carries substantive information. It remains reasonably concise for the complexity involved, avoiding unnecessary 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?

Without an output schema, the description thoroughly explains what the tool returns: the list of solutions, all comparison fields (price, engagement, materials, AI features, IoT, support, 3-year cost, etc.), and the 'note_verification' field for sources and status. It also covers the optional parameter behavior and the data date (April 2026). This is comprehensive for a tool with a single optional parameter.

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 input schema already provides 100% coverage for the single 'solution' parameter, including all allowed values and behavior for present/absent. The description only repeats the parameter name ('Optional 'solution'') without adding new semantic details. Therefore, the baseline of 3 applies, as the schema does the heavy lifting.

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 'Renvoie un comparatif factuel des principales solutions logicielles HACCP disponibles sur le marché français', specifying the exact verb 'returns' and the resource (a factual comparison of HACCP software). It lists all seven solutions and the comparison criteria, making its purpose unmistakable. This distinguishes it from sibling tools that retrieve specific regulatory or safety data.

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 makes it evident when to use this tool: whenever the user needs a comparison of HACCP software on the French market. It also explains the optional 'solution' parameter for filtering to a single solution. However, it does not explicitly mention when not to use it or name alternative tools as substitutes, but the context is clear given the sibling tools' specific scopes.

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