frigolog-haccp-mcp

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

With no annotations, the description carries the full burden. It discloses the conflict of interest (Frigolog publishes this MCP) and explains that each solution includes sources and verification status, flagging unverified data. This goes beyond a simple operation statement, though it does not explicitly say the tool is read-only or mention performance behaviors.

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 structured with a French full version and an English summary, which is somewhat redundant. However, it is front-loaded with the core purpose and the enumeration of comparison dimensions is useful for such a complex tool. It earns a 4 rather than 5 due to the duplication.

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?

The description comprehensively covers what the tool returns: all the comparison dimensions (price, commitment, hardware, AI features, sensors, support, etc.), the verification status, and the conflict-of-interest disclosure. For a tool with no output schema and a single optional parameter, this is complete enough for an agent to invoke it correctly.

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 provides 100% coverage of the 'solution' parameter, including values and behavior when provided or absent. The description only mentions 'Optional solution' without adding further meaning, so it does not exceed the schema baseline.

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 specific verb and resource: 'Renvoie un comparatif factuel des principales solutions logicielles HACCP' (returns a factual comparison of HACCP software). It lists the exact solutions and distinguishes itself from sibling tools that focus on regulations, temperatures, and inspections.

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 clearly indicates this tool is for comparing HACCP software, which is a distinct use case from the regulatory-focused sibling tools. It does not explicitly name alternatives or state when not to use it, but the context is clear and unambiguous.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It reveals the tool's scope (only 6 most common non-conformities), the response structure (immediate action, PMS documentation, deadlines, DDPP alert conditions, example), and the optionality of the filter. This is useful context, though it does not address error handling or 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 front-loads the main purpose and uses detailed specifics to convey what the tool returns. The bilingual redundancy is a minor inefficiency, but each sentence provides substantive value, making it appropriately concise for the tool's complexity.

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?

Despite lacking an output schema, the description thoroughly specifies the return content: non-conformity types and the exact fields for each (immediate action, documentation, deadlines, DDPP alerts, example). Given only one optional parameter and full schema documentation, this is complete enough for correct selection and invocation.

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 describes the sole parameter exhaustively, listing allowed values and default behavior when absent (schema coverage 100%). The description only restates that the parameter is optional, adding no new meaning. Baseline 3 is appropriate when 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 identifies the tool as returning regulatory corrective actions for six specific non-conformities, enumerating all six and the detailed content of each response (immediate action, documentation, deadlines, DDPP alert conditions, example). This distinguishes it from sibling tools focused on temperatures, DLC, and HACCP plans.

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 implies the usage context—when you need corrective actions for catering non-conformities—but it does not explicitly state when to prefer this tool over siblings or provide exclusions. The mention of an optional filter is a parameter hint, not usage guidance.

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

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

With no annotations provided, the description carries the full transparency burden. It discloses key behaviors: SIRET ignores other parameters and returns all inspections sorted by date descending, data refresh frequency is periodic, and only controlled establishments since 2017 are covered. There is a minor inconsistency between 'real time' (English) and 'refreshées périodiquement' (French), but overall the behavioral disclosure is strong.

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 information-dense and logically structured: it opens with the main purpose, enumerates returned data, then explains search modes and coverage. The English translation adds length by repeating the French content, but it does not clutter the core message. It is slightly redundant but not wasteful.

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 the tool's complexity (5 optional parameters, no output schema, no annotations), the description provides a thorough picture: what the tool returns, how to search, which parameters to combine, what data is covered, and update cadence. This is sufficient for an agent to select and invoke the tool correctly in most scenarios.

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 descriptions already cover all 5 parameters in detail (100% coverage), which sets a baseline of 3. The tool description adds value beyond the schema by recommending SIRET as the preferred search key, advising combination of 'nom' with 'code_postal' or 'commune' for disambiguation, and clarifying that SIRET overrides other parameters. This extra guidance raises the score to 4.

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's function with a specific verb ('Recherche') and a precise resource ('score Alim'confiance d'un établissement précis dans le dataset officiel de la DGAL'). It lists the return fields and explicitly mentions the dataset source and record count, distinguishing it from sibling tools like get_score_alimconfiance by focusing on a specific establishment lookup.

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 usage guidance: recommends SIRET as the unique identifier, explains when to use name search with optional postal code/commune filters for disambiguation, and notes the data coverage (only establishments inspected since April 2017). However, it does not explicitly contrast this tool with sibling tools or state when not to use it, so it stops short of a full 5.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It thoroughly describes the output content (14 allergens, common/hidden sources, display obligations, penalties) and the optional filter behavior, exceeding what annotations would typically provide. It does not explicitly state side effects, but being a get tool, this is implied.

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 well-structured with the main action upfront, but it is somewhat lengthy due to listing all 14 allergens and includes a near-duplicate English summary. The information is relevant and earns its place, though the redundancy slightly reduces conciseness.

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 tool with one optional parameter and no output schema, the description provides adequate detail about the return content and filter behavior. It could specify the exact output structure (e.g., list of objects), but the overall information is sufficient for an agent to understand the tool's functionality.

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 of the single optional 'allergene' parameter, including acceptable values and behavior when absent. The description only mentions 'Optional allergene' in the English summary, adding no additional meaning 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 tool returns the list of 14 mandatory allergens in France, referencing specific regulations and providing detailed content. This specific verb+resource combination clearly distinguishes it from sibling tools that focus on HACCP, inspections, or temperatures.

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 does not provide explicit guidance on when to use this tool versus alternatives. It implies its purpose through the content but lacks a statement like 'Use this when you need allergen declaration requirements' and offers no exclusions or alternative recommendations.

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

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

With no annotations, the description carries full burden. It explains the computation basis (last training, DDPP control, internal audit, PMS update) and the output (due date, urgency, recommended action), making it clear this is a read-only calculation. It also mentions the automation use case, adding behavioral context beyond a simple query.

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 main purpose and provides essential details in four sentences, plus an English translation. It is appropriately sized for the complexity, though the bilingual duplication adds some length without redundancy in meaning.

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?

The description covers the purpose, inputs, computation logic, and output fields, which is sufficient for an agent to understand the tool. Minor gaps include the role of the optional department parameter (marked 'informatif' but used in frequency calculation) and default behavior when dates are missing, but overall it is complete enough.

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%, providing a baseline of 3. The description adds semantic value by explaining how each date is used (e.g., renewal interval, inspection frequency) and stating that type_etablissement is required while other dates are optional, enriching the schema with usage context.

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 it returns a calendar of upcoming HACCP obligations for an establishment, using the specific verb 'retourne' and identifying the resource. It distinguishes from sibling tools by focusing on the aggregated calendar based on last-action dates, with explicit details about the calculation inputs and output 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?

The description explicitly states it is designed for automation and suggests weekly calls to alert the manager, providing clear usage context. However, it does not explicitly compare itself to alternatives like get_formation_haccp_obligatoire or get_risque_inspection, so it falls short of a 5.

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

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

No annotations are provided, so the description carries the burden. It transparently lists the five categories of checks (visual, temperature, stock, staff hygiene, documentation) and notes that the checklist varies by establishment type. It does not mention side effects or limitations, but as a read-only retrieval tool, no major behavioral disclosures are needed.

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 moderately verbose but front-loaded with the main purpose, followed by a structured list of content categories and a clear English translation. Every sentence adds value, though it could be tightened by removing the English duplicate, but the bilingual format is useful.

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 the simple single-parameter schema and no output schema, the description provides a rich picture of the expected return: a checklist covering all specified areas. It does not explain default behavior for an unrecognized type, but that is covered in the schema. Overall, it is complete enough for an agent to invoke the tool correctly.

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 covers 100% of the parameter with a description, including valid values and fallback behavior. The tool description adds only that the parameter 'adds trade-specific items,' which adds little beyond the schema's description. Therefore, the baseline of 3 applies.

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's function: it returns the full daily pre-opening checklist for a French food establishment, with detailed content categories and reference to HACCP/GBPH. It is distinct from sibling tools like get_haccp_temperatures (temperature-specific) or get_plan_nettoyage_type (cleaning plans), as it covers the holistic checklist.

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 clearly conveys when to use the tool (daily pre-opening verification) and mentions the optional type_etablissement parameter for trade-specific checks. It does not explicitly exclude alternatives or name sibling tools for comparison, but the context is clear enough for an agent to select it over more specialized tools.

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

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

With no annotations, the description carries the burden. It discloses the read-only nature via 'Renvoie la liste' and describes the content of the returned list (common base + specific docs). It also explains the effect of the optional parameter. It does not mention auth or rate limits, but for a simple getter, this is sufficient.

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 bilingual (French + English), adding redundancy but remains structured and front-loaded with the main purpose. It includes useful examples of documents, which adds value despite some extra length.

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?

The tool has one optional parameter and no output schema. The description sufficiently explains the purpose, the filter behavior, and the content types (12 documents, business types). It does not detail the return format, but for a list-returning tool, the description is adequate.

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 description covers 100% of the parameter, including filter and absence behavior. The tool description only repeats the optional parameter name at the end, adding no extra meaning beyond what the schema already provides.

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 returns a list of documents for DDPP sanitary inspections in France, by establishment type. It distinguishes the tool from siblings by focusing on the full document list, including the 12-document common base and business-specific documents.

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 context on when to use the tool: when needing DDPP inspection documents. It explains the optional parameter behavior (filtered vs. unfiltered) but does not explicitly mention alternatives or exclusions. The scope is well-defined and the use case is unmistakable.

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

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

With no annotations provided, the description carries the full burden. It richly discloses behavior by enumerating what will be returned (obligations, exemptions, content, duration, average cost, certified organisms, validity, penalties) and the legal grounding. It also clarifies the parameter's informational nature. No side effects or auth details, but this is a read-only informational tool, so this level is sufficient.

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 detailed and well-organized, starting with the main purpose and then listing specific components. It is duplicated in French and English, which adds length without extra substance, but every sentence earns its place by conveying concrete information. Could be more concise by dropping one language version, but still 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 sufficiently explains the expected return: a comprehensive set of training rules, including exemptions, duration, cost, and penalties, plus the legal basis. For a tool with one optional parameter and moderate complexity, this level of detail is adequate for an agent to understand what the tool does and what it returns.

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 description coverage is 100% for the single parameter, and it already explains that type_etablissement is optional, informational, and provides accepted values. The tool description merely repeats this without adding new meaning, so the baseline score 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's function: returning mandatory HACCP training legal obligations in French commercial catering. It specifies the exact content (who must train, exemptions, duration, cost, penalties) and legal basis, distinguishing it from sibling tools like get_sanctions_ddpp (sanctions) or get_documents_controle_ddpp (documents). The verb 'Retourne' is specific and the resource is well-defined.

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 context by scoping the tool to France and commercial catering, and explicitly states that the type_etablissement parameter is optional/informational, implying it works for all category types. However, it does not name alternative tools or explicitly say 'use this instead of X', so it falls short of full guidance.

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

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

With no annotations, the description carries the full transparency burden. It discloses the detailed return fields (title, editor, year, price, pages, link, key points, regulatory obligations) and explicitly states the behavior for sectors without a distinct guide (flagged). This gives the agent a clear understanding of the tool's outputs and edge-case handling, though it does not mention error handling or response format.

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 well-structured, starting with the core purpose in French, followed by a concise English summary. It is front-loaded with the essential information and includes detailed return fields without unnecessary verbosity. The bilingual text adds slight redundancy but remains efficient and informative.

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?

The description is complete for a single-parameter tool with no output schema. It enumerates all returned fields, explains the regulatory link, and addresses edge cases (sectors without a dedicated guide). The bilingual summary reinforces key points. No additional information is needed for the agent to use the tool correctly.

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 'secteur' parameter, listing all allowed values. The tool description adds no new parameter-specific semantics beyond restating that it applies to French food-trade sectors. Since the schema fully documents the parameter, a baseline score 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 returns the official Good Hygiene Practice Guide (GBPH) reference for a French food-trade sector. It specifies the exact verb ('Retourne la référence') and resource (GBPH officiel), and lists the fields returned. This distinguishes it from sibling tools that focus on HACCP actions, temperatures, or regulatory obligations.

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 implies usage for retrieving the official guide reference for a sector, but does not explicitly state when to use this tool instead of alternatives. It does note that sectors without a distinct validated guide are flagged, which gives context on expected results. However, there is no direct exclusion statement or comparison with sibling tools.

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

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

No annotations are provided, so the description carries the burden. It discloses the legal basis and covered categories, implying a read-only lookup. However, it does not mention output format, potential errors, authentication needs, or whether the data is static. The description is transparent about what it returns but lacks deeper behavioral context.

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 bilingual and somewhat verbose, but each sentence carries useful information: purpose, legal references, category coverage, and optional filter. It is front-loaded with the main purpose and remains efficient despite the length.

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 could clarify what fields are returned per category (e.g., multiple temperature types, units). It mentions categories and temperature types but not the exact output structure. Given the simple tool nature and rich sibling context, it is adequate but not fully complete.

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 covers 100% of the parameters, with a full description of the 'categorie' parameter and its allowed values. The description adds regulatory context but does not go beyond the schema in explaining parameter semantics. Baseline 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 returns French regulatory food temperatures for storage, cooling, and service by product category. It uses a specific verb ("Renvoie") and resource, and distinguishes from sibling tools like get_temperatures_cuisson by focusing on non-cooking temperatures.

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?

Usage context is implied through the scope description (regulatory storage/cooling/service temperatures), but there is no explicit comparison to alternatives or when-not-to-use conditions. The sibling tool get_temperatures_cuisson is not mentioned, so the agent lacks explicit guidance for choosing between them.

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

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

No annotations are provided, so the description carries the burden of disclosure. It explicitly lists the return contents (cleaning stations, frequency, product, method, verification) and regulatory compliance. It does not mention fallback behavior for unknown types, but the schema description covers that. Overall, the description provides solid behavioral detail beyond the schema.

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 concise, front-loaded with the main purpose, and covers all key aspects in a few sentences. It includes both French and English, adding a bit of redundancy but still efficient. Every sentence adds value, though the English translation could be seen as duplicative.

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 low-complexity tool with one parameter and no output schema, the description is complete. It specifies exactly what the plan contains (zones, frequency, products, method, verification) and which establishment types are covered. The schema handles the parameter details, so no critical information 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?

Schema description coverage is 100% and the parameter `type_etablissement` is fully described with allowed values and fallback behavior. The description merely mentions the argument name without adding extra semantics, so it meets the baseline but does not exceed it.

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 returns a model cleaning plan for French food establishment types, with specific details (zones, frequency, products, method, verification). It distinguishes itself from siblings like get_temperatures_cuisson or get_guide_bonnes_pratiques_secteur by focusing specifically on cleaning plans for establishment types.

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 context (French food establishments, GBPH compliance) and covers which types are supported. It does not explicitly state alternatives or exclusions, but the scope is well-defined enough to infer when to use it. The sibling list includes similar regulatory tools, but the description clarifies this is about cleaning plans.

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

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 that the tool returns active recalls, filters automatically based on establishment type, and uses get_rappels_produits_actifs internally. The examples of product families add transparency about the filtering logic, though details like response format or data freshness are not mentioned.

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 main purpose and includes useful examples, but it is somewhat verbose due to full French/English duplication. The final line about the required parameter is redundant with the schema, adding minor bloat.

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 the tool's moderate complexity (single parameter, no output schema), the description covers the purpose, behavior, parameter semantics, and typical use case. It is sufficient for an agent to decide when and how to invoke it, though it omits details like pagination or exact response fields.

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% for the single required parameter, and the schema already lists valid values. The description adds semantic meaning by giving concrete examples of which product families each establishment type receives (e.g., bakery vs. fishmonger), helping the agent understand the filtering behavior 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 tool returns active RappelConso recalls filtered by establishment type, using a specific verb and resource. It distinguishes itself from the sibling get_rappels_produits_actifs by explicitly mentioning it filters results and even names the internal tool used.

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 context for when to use the tool (e.g., morning automated checks) and contrasts it with manually searching all categories. It does not explicitly list when not to use it or name alternative tools, but the establishment-specific filtering context is evident.

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

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

There are no annotations, so the description carries the burden of disclosing behavior. It clearly states the tool returns only active recalls in real time from an official source, which conveys the temporal scope and data provenance. It does not describe response format or error behavior, but for a read-only retrieval tool this is adequate.

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 adds the data source and use cases. The bilingual English sentence is somewhat redundant but not excessive. Overall, it is concise enough while remaining informative.

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 the tool has no output schema and no annotations, the description covers the main contextual needs: source, temporal scope, and when to use it. It lacks details about the exact response shape, but the described use cases and parameter information allow an agent to select and invoke the tool correctly.

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 has 100% coverage with detailed descriptions for all three parameters (limit, categorie, date_depuis). The description merely lists the filter names without adding new meaning beyond the schema, so it meets the baseline but does not exceed it.

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 explicitly states that the tool returns active French food-product recalls in real time from the official RappelConso (DGCCRF) dataset. It names the specific resource and distinguishes this tool from sibling tools like get_rappels_par_categorie_etablissement by focusing on active recalls/pulls and the official data source.

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 use cases: checking food safety before service, determining if a product reference is recalled, and consulting the latest official health alerts. It does not explicitly mention when not to use this tool or name an alternative, but the intended context is well defined.

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

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

No annotations are provided, so the description must carry behavioral disclosure. It does state the output fields (DLC in days, required storage temperature, regulatory source) and lists covered preparation types. However, it omits details about behavior on empty searches, matching logic, or potential variations in output formatting.

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 main purpose and well-organized. It is somewhat longer than necessary due to the bilingual (FR/EN) repetition, but each sentence contributes useful detail about scope, categories, and output structure.

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 read-only tool with one optional parameter and no output schema, the description covers the essential aspects: purpose, scope, regulatory basis, covered categories, and return fields. It could strengthen completeness by referencing sibling tools for different use cases, but the tool is adequately specified on its own.

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 of the single optional parameter 'type_preparation', including examples and default behavior. The description only repeats the parameter's existence and examples, adding no new semantic meaning beyond what the schema already specifies.

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 uses a specific verb ('Renvoie' / 'Returns') and a clear resource ('règles de DLC pour les préparations maison'). It specifies the geographic and regulatory scope (France, DGAL guide) and enumerates covered categories, distinguishing it from sibling tools like get_temperatures_cuisson or get_seuils_microbiologiques.

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 context for when to use the tool: when needing DLC rules for in-house preparations in French restaurants. It does not explicitly mention alternatives or exclusions, but the scope is well-defined and implicitly differentiates from temperature or allergen tools.

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

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

With no annotations provided, the description carries the full transparency burden. It clearly discloses what the tool returns (risk score, high-risk months, average frequency, recommendations) and the underlying data sources (Alim'confiance, DGCCRF), which gives the agent a solid understanding of the tool's behavior. It falls short of explicitly stating it is a read-only operation, but this is strongly implied by the 'get' verb and the estimation nature.

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 provides structured output details. It is duplicated in French and English, which adds length, but each language version is clear and the bilingual approach may serve multilingual agents. No unnecessary filler is present.

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 tool with no output schema and no annotations, the description gives a comprehensive picture: it lists all output components, cites data sources, explains the underlying logic (surge periods), and provides automation context. It does not specify the exact return data structure or error handling, but the described output fields are sufficient for an agent to understand and invoke the tool correctly.

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 description coverage is 100%, so the baseline is 3. The description repeats that 'type_etablissement' and 'departement' are required but adds no additional meaning beyond the schema descriptions, which already explain the department code format, allowed establishment types, and that 'dernier_controle_ddpp' is optional and refines the risk score.

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 returns an estimated DDPP inspection risk level for a given establishment type in a French department. It specifies the output components (risk score, high-risk months, frequency, recommendations) and distinguishes itself from sibling tools like get_alimconfiance_etablissement or get_score_alimconfiance by focusing on a composite risk estimate based on multiple data sources.

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 usage context, explicitly noting it is designed for automation and should be called quarterly to adjust vigilance. It does not explicitly exclude alternatives or compare with sibling tools, but the automated quarterly cadence gives a concrete when-to-use scenario.

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

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

With no annotations provided, the description carries the full burden. It transparently details what the tool returns: sanction levels, triggers, deadlines, fine amounts, imprisonment risks, and legal basis. It does not mention side effects or permissions, but the read-only nature is implied and the content disclosure is strong.

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 main purpose and detailed content, but it is somewhat long, including an English summary that repeats the French content. It is still informative and not wasteful, though it could be slightly more concise.

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 the tool's complexity and lack of output schema, the description is exceptionally complete. It explains the four sanction levels, triggers, deadlines, fine amounts, legal basis, and optional filter. This fully compensates for the absence of an output schema.

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 description coverage is 100% for the only parameter (gravite). The description adds a brief mention of 'Optional gravite' but does not provide additional syntax or meaning beyond the schema. Baseline 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's function: it returns DDPP inspection sanction levels and risks for French restaurants, listing the four specific levels (observation, mise en demeure, procès-verbal, fermeture administrative). This is a specific verb+resource that distinguishes it from sibling tools like get_risque_inspection or get_documents_controle_ddpp.

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 context for when to use the tool ('lors d'un contrôle DDPP en restauration et métiers de bouche en France'). It does not explicitly mention exclusions or alternatives, but the context is specific enough to guide appropriate use.

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

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

With no annotations, the description fully discloses the nature of the tool: it returns an explanatory overview of the scoring system, including specific content areas. It also provides context about the official source and date. There is no contradiction.

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 main purpose and includes a helpful pointer to the sibling tool. However, the bilingual repetition (French and English) makes it longer than necessary, though the repeated information is condensed in English.

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?

The description is complete for a no-parameter informational tool: it lists the key topics covered, gives the official context, and provides an alternative for specific queries. No output schema exists, but the description adequately sets expectations.

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 tool takes no parameters (0 parameters, 100% schema coverage). The description correctly does not attempt to describe parameters, and the baseline for 0 parameters is 4.

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 uses the verb 'Retourne' and specifies the resource ('le fonctionnement complet du score Alim'confiance'), clearly distinguishing it from the sibling tool for retrieving a specific establishment's score. It explicitly states what the tool provides (4 levels, 6 criteria, frequency, actions).

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 explicitly states an alternative: 'Pour récupérer le score d'un établissement précis, utilisez get_alimconfiance_etablissement,' and the description's scope implies when to use this tool (general info). This is clear guidance.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It transparently states the scope (both food-safety and process-hygiene criteria), the specific data returned (sampling plan, stage, actions), and the special note about the Listeria criterion change in 2026. It also discloses the fallback behavior for the 'categorie' parameter. While it doesn't mention auth or rate limits, these are irrelevant for a read-only query tool. The description could go deeper on return format, but it provides solid behavioral context.

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 bilingual, presenting the same information in French and English. While this serves a multilingual audience, it doubles the length without adding new information per sentence. The core content is well-structured and front-loaded, but the redundancy and verbosity prevent a higher score.

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?

Despite having no output schema, the description thoroughly covers the tool's behavior: it lists the types of criteria, the pathogens, the sampling plan fields, the application stages, the actions on exceedance, and the regulatory update. It also explains the optional parameter's behavior. This is complete enough for an agent to fully understand what the tool returns and how to invoke it.

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 description coverage is 100%, and the parameter description is already detailed with valid values and fallback behavior. The tool description adds only a brief mention of the optional 'categorie' parameter, which does not meaningfully enhance what the schema already provides. Hence, a baseline score 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 returns regulatory microbiological criteria for foodstuffs under specific EU regulations, enumerating the types of criteria and parameters included. This is a specific verb+resource combination that distinguishes it from all sibling tools, none of which address microbiological standards.

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 context for when to use this tool (when applying EU microbiological criteria, checking sampling plans, or verifying Listeria changes) by outlining exactly what it returns. However, it does not explicitly mention when not to use it or alternative tools, so it lacks the explicit exclusions required for a score of 5.

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

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

With no annotations, the description carries the full burden. It discloses that it includes rapid cooling, reheating rules, and recommendations for sensitive populations. It also notes the optional filter behavior. However, it does not describe the return format or any potential limitations (e.g., pagination), but the provided detail is substantial.

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 bilingual and compact, with each sentence adding new information. It front-loads the core purpose and includes examples, while explicitly noting the distinction from a sibling tool. No redundancy or 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?

Given no output schema, the description manages to convey the full scope of results: mandatory temperatures, cooling, reheating, and vulnerable populations. It is complete enough for a lookup-style tool with one optional parameter, though it could mention the return format or data structure.

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 parameter with 100% coverage. The description adds value by explaining the search behavior (keyword match in identifier or label) and giving concrete examples ('volaille', 'boeuf', 'poisson'). It also clarifies the default behavior when the parameter is absent.

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 returns mandatory core cooking temperatures by food type in French catering, with specific examples (volaille 74°C, bœuf haché 70°C). It also distinguishes itself from the sibling get_haccp_temperatures, making its purpose unambiguous.

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 explicitly states this tool is distinct from 'températures de conservation' available via get_haccp_temperatures, providing a clear alternative. It also describes the optional 'type_aliment' filter behavior, telling users they can filter by food type or process.

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