frigolog-haccp

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

No annotations are provided, so the description must cover behavioral aspects. It discloses that Frigolog publishes the MCP (conflict of interest) and that data is verified from public sources. However, it does not mention behaviors such as response format, caching, error handling, or rate limits. This is adequate for a read-only comparison tool.

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 all necessary details in a structured list. It is somewhat long due to including both French and English versions and listing all compared attributes, but every sentence adds value. It could be slightly shorter if only one language was used.

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 adequately explains the return content (pricing, hardware, features, etc.) and the list of all seven solutions. It covers the optional filter and the data verification approach. It is sufficiently complete for an agent to understand what the tool provides.

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 adds significant value by enumerating the allowed values for the solution parameter (the seven software names) and clarifying that omitting it returns the full comparison while including it returns details for that solution. This goes beyond the schema's minimal description.

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 that the tool returns a factual comparison of specific HACCP software solutions available on the French market, listing the seven solutions by name. This is a specific verb+resource that distinguishes it from sibling tools, which cover other HACCP-related topics like temperatures, inspections, and recalls.

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 explains when to use the optional 'solution' parameter (for details on a single solution) versus when to omit it (for a full comparison). It also includes a transparency disclosure about the publisher's conflict of interest. However, it does not explicitly state when not to use the tool, though the context of sibling tools implies it.

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 full burden. It describes the returned corrective actions clearly but does not disclose any behavioral traits such as read-only nature, authentication needs, or rate limits. The 'get_' prefix implies idempotency, but this is not explicit.

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 a bilingual approach, front-loading the core purpose. It uses bullet points and examples, but the French and English duplication adds length. Still, every sentence contributes meaningfully to understanding.

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 only one parameter, the description provides a thorough explanation of the return content (immediate action, documentation, deadlines, etc.). It could be more specific about the exact data structure, but examples compensate.

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%, providing a baseline of 3. The description adds value by enumerating the specific non-conformities and their actions, which goes beyond the schema's parameter description. It 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 that the tool returns corrective actions for the 6 most common catering non-conformities, listing each type (fridge too warm, expired product, etc.). It uses specific verbs and resources, and the scope is distinct from sibling tools like get_temperatures_cuisson or get_checklist_ouverture_etablissement.

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 lacks 'when to use' or 'when not to use' instructions, leaving the agent to infer from context alone.

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 bears the burden. It details search behavior (full-text, case-insensitive, minimum chars), data source (DGAL), refresh frequency, date coverage, and what is returned. It also states that only establishments controlled since April 2017 are covered.

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 relatively long but well-structured with French and English sections. It front-loads key information (searching for score, returned fields) and each sentence adds value. Could be slightly more concise, but not verbose.

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 5 parameters and no output schema, the description is comprehensive. It covers all parameters, search behavior, data limitations, and return fields. An agent has sufficient context 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?

Schema description coverage is 100%, so the schema already explains parameters. The description adds value by clarifying SIRET recommendation, behavior when SIRET is provided, default limit (5) and max (20), and sort order. It also mentions minimum 2 characters for 'nom'.

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 looks up an establishment's Alim'confiance score and lists the returned fields. It explicitly distinguishes from siblings by focusing on a single establishment, while siblings like 'compare_solutions_haccp' have different purposes.

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 recommends searching by SIRET for unique results and suggests using other parameters for disambiguation. It explains parameter interactions (e.g., SIRET ignores others). It does not explicitly contrast with sibling tools, but the context is clear enough.

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 describes behavior: it returns a list of allergens with common names, sources, hidden sources, display obligations, and penalties. No destructive actions are indicated.

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 paragraph that front-loads the purpose. It includes a list of allergens which is helpful but 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?

For a simple retrieval tool with one optional parameter and no output schema, the description is very complete, explaining exactly what information is returned and the optional filter.

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% with a parameter description listing valid values. The tool description redundantly restates these values, adding minimal extra meaning.

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 the 14 mandatory allergens under EU regulation, listing specific allergens and what information is provided. It distinguishes itself from sibling tools which cover other HACCP and food safety topics.

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 allergen information and mentions an optional filter, but does not explicitly state when to use this tool versus siblings or when not to use it.

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 transparently states the tool is for returning data (retourne, returns) and designed for automation, implying no side effects. It does not explicitly state read-only, but the context strongly suggests a safe, non-destructive operation.

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 a clear first sentence, detailed output explanation, and final usage note. However, it includes both French and English versions, which is helpful but slightly verbose. Still every sentence adds value.

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 fully explains return values (date, urgency, action) and the underlying logic. It covers all important aspects for an agent to understand and invoke correctly in an automation workflow.

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 baseline is 3. The tool description adds value by explaining the logic (based on last-action dates) and identifying the required parameter (type_etablissement) alongside optional dates, going beyond mere schema descriptions.

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 calendar of upcoming HACCP regulatory obligations for an establishment, specifying it provides due dates, urgency levels, and recommended actions. This distinguishes it from sibling tools like get_actions_correctives or get_risque_inspection which serve different purposes.

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 recommends weekly automation for alerting managers, giving clear usage context. However, it does not mention when not to use this tool or suggest alternatives, missing a small opportunity for completeness.

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 must disclose behavioral traits. It describes the checklist content (visual, temperature, stock, hygiene, documents) but does not mention authentication, rate limits, or side effects. As a read-only retrieval, the description is adequate but not comprehensive.

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 clear bullet points in French and an English summary. It is front-loaded with the main purpose. Some redundancy exists due to bilingual content, but each sentence provides value.

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 should explain the return format. It describes the contents (categories and items) but does not specify whether the output is a list, JSON, or other structure. This leaves a gap for the agent.

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 single parameter. The description adds context beyond the schema's list: it explains that optional type_etablissement adds trade-specific items, which helps the agent understand its effect.

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 full daily pre-opening checklist for a French food establishment, covering HACCP and hygiene practices. It specifies the resource and action, but does not explicitly differentiate from siblings like get_haccp_temperatures or get_regles_dlc, though the comprehensive nature makes it distinct.

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 daily pre-opening checks and mentions that the optional parameter adds trade-specific items. However, it lacks explicit when-to-use or when-not-to-use guidance, and does not reference alternative 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?

With no annotations, the description adequately describes the tool as a read-only data retrieval. It states what is returned (list of documents, common base + specific) but does not disclose details like output format, authentication needs, or limitations. It is adequate but not comprehensive.

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 with two brief paragraphs covering purpose and parameter behavior in both French and English. Every sentence adds necessary context without redundancy.

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 simplicity (one optional parameter, no output schema), the description fully covers what an AI agent needs: purpose, parameter options, and output content. It is complete for this use case.

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%, and the description adds value by explaining the filter values and behavior when absent. This goes beyond the schema's parameter description, earning a score above the baseline of 3.

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 that the tool returns a list of documents for French DDPP sanitary inspections by establishment type, using specific verbs like 'returns' and 'includes'. It distinguishes from sibling tools which focus on other aspects like HACCP solutions or corrective 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?

The description explains when to use the optional filter and the effect of providing or omitting it. However, it does not explicitly state when to use this tool over alternatives, though the uniqueness of its purpose makes it clear.

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 exist, so description carries full burden. It discloses that the tool returns informational data and provides legal basis. It does not contradict any annotations. Could be more explicit about being read-only, but 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 moderately concise, covering key aspects in both French and English. It is front-loaded with the purpose. Every sentence adds value, though bilingual duplication slightly increases 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?

Given no output schema, the description adequately explains return content including legal basis, exemptions, penalties. It is complete for a legislative info tool, though it could mention that returns are textual.

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% with one optional parameter. The description adds meaning by explaining the parameter is informational and lists possible values like 'restaurant', 'food_truck', etc., going beyond 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 that the tool returns mandatory HACCP training rules, specifying who must train, exemptions, content, duration, cost, and penalties. It explicitly distinguishes from sibling tools by focusing on legal obligations, not advice or compliance.

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 use for obtaining legal obligations and includes an optional filter. It notes that the obligation is the same for all establishment types, but does not explicitly state when not to use or suggest alternatives among siblings.

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 the tool returns reference data and flags sectors without a validated guide. It mentions key output details. While it does not specify whether the data is static or fetched live, the transparency is adequate for a non-mutating tool.

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 informative but somewhat lengthy due to bilingual content and repetition. The core purpose is front-loaded, and each sentence adds value. It could be slightly more concise, but overall well-structured.

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 thoroughly explains what the output contains (title, editor, year, price, pages, link, key points, regulatory links) and handles edge cases (sectors without distinct guide). This is complete and actionable for an agent.

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%, with the parameter 'secteur' listing possible values. The description adds minimal extra meaning (only 'Arg secteur' in English), so it does not significantly enhance understanding 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 returns the official GBPH reference for a French food-trade sector, listing specific output fields (title, editor, year, etc.). It distinguishes from siblings, which are action-oriented (e.g., get_actions_correctives, get_checklist_ouverture_etablissement) by being a reference retrieval tool.

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 when needing the guide for a specific sector. It does not explicitly state when not to use or provide alternatives, but the context of sibling tools provides differentiation. The description is clear enough for an agent to decide.

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 implies a read-only lookup operation with no side effects. It references regulatory context but does not explicitly state safety or permissions. Acceptable for a simple query tool.

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 has two language versions (French and English), making it slightly redundant. It is otherwise concise but could be streamlined to a single language for efficiency.

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 and a single optional parameter, the description sufficiently covers what the tool returns (regulatory temperatures by category) and the filter. It references the legal basis, adding authority.

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% with a detailed description of the optional 'categorie' parameter and its values. The description adds context about regulations and categories but does not significantly enhance parameter understanding 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 it returns French regulatory food temperatures for storage, cooling, and serving by product category, referencing specific regulations. It is a specific verb+resource combination, but does not explicitly distinguish from siblings like get_temperatures_cuisson.

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?

No guidance on when to use this tool versus alternatives (e.g., get_temperatures_cuisson for cooking temps, get_seuils_microbiologiques for micro thresholds). No when-not or usage context provided.

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 explicitly states that if the type_etablissement value is not recognized, a generic 'restaurant' plan with an accompanying note is returned. It also details the content of the return (zones, frequency, product, method, verification criterion), providing transparency.

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 comprehensive but somewhat lengthy, especially with bilingual content (FR and EN). However, every sentence adds value: listing establishment types, detailing plan contents, and noting the fallback. It is front-loaded with the core purpose and then provides structured details. Slightly verbose but well-organized.

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 only one parameter and no output schema, the description fully covers what the tool needs (input values, fallback behavior) and what it returns (zones, frequency, product, method, verification criterion). It is complete for an agent to decide when to use it and what to expect.

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% (the single parameter type_etablissement is described in the schema with allowed values and default behavior). The description repeats these values and adds the fallback note, but does not add new semantic meaning beyond what the schema already provides. 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 it returns a model cleaning plan for a specific French food-establishment type, compliant with GBPH and EU regulation. It lists the covered establishment types and details what the plan contains (zones, frequency, product, method, verification criterion), distinguishing it from sibling tools that deal with HACCP corrective actions, allergies, inspections, etc.

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 tool is for obtaining a cleaning plan for a given establishment type. While sibling tools cover different topics (e.g., corrective actions, temperatures, allergens), making the usage context clear, there is no explicit guidance on when not to use this tool or direct comparison to alternatives.

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 full weight. It explains the filtering logic (identifying relevant product families) and mentions design for automation. It does not disclose side effects, but the tool is a read-only query. The behavioral context is sufficient for an agent to understand its operation.

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 a clear statement of purpose, followed by examples and usage context. It is concise but includes both French and English, which adds some redundancy. Overall, it efficiently communicates the tool's value without unnecessary fluff.

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 one parameter, no output schema, and no annotations, the description is complete. It explains purpose, filtering logic, examples, and internal dependency (get_rappels_produits_actifs). An agent can confidently determine when and how to use this tool.

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 has 100% coverage with description of the parameter and allowed values. The description adds meaning by explaining that 'restaurant' and 'traiteur' monitor all categories and by providing concrete examples of product families for each type. This goes beyond the schema's basic description.

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, distinguishing it from sibling tools like get_rappels_produits_actifs. It uses a specific verb (retourne/filters) and specifies the resource (rappels) and scope (par catégorie d'établissement).

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 mentions internal use of get_rappels_produits_actifs and provides automation context (e.g., calling each morning). It gives examples of product families per establishment type. However, it does not explicitly state when not to use it or list alternatives, though it implies that for unfiltered recalls one should use the sibling tool.

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 must fully disclose behavior. It states the tool returns active recall data in real time from an official source. It mentions that results are sorted by most recent first in the schema. However, it lacks details on response format, pagination, data freshness guarantees, or any potential side effects. This is adequate but not rich.

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 includes both French and English versions, making it redundant. While front-loaded with purpose, the dual-language approach adds length without additional value. It could be more concise by merging languages or providing a single version.

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 no output schema, so the description should explain the return structure, but it only says 'returns active recalls' without detailing fields. For a simple tool with three parameters, the overall context is adequate but not fully complete, as aspects like error handling or output format are omitted.

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%, with each parameter well-documented in the input schema itself. The description only briefly lists the filters, adding minimal meaning beyond what is already in the schema. Baseline 3 is appropriate as the schema carries the weight.

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 that the tool returns active French food-product recalls from the official RappelConso source, including typical use cases like checking food safety before service. However, it does not explicitly differentiate from sibling tools such as get_rappels_par_categorie_etablissement, which may have overlapping functionality.

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: verify product safety, check if a reference is subject to recall, or consult latest official alerts. It does not, however, mention when not to use this tool or reference alternatives, which would be helpful given the 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 full burden. It discloses the return content format (DLC in days, temperature, source) and scope, which is sufficient for a read-only query tool. It does not discuss rate limits or side effects, but those are not expected for such a tool.

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 reasonably concise and front-loaded with purpose. However, it includes both French and English sections which are largely redundant, slightly increasing length without adding value.

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 single optional parameter and no output schema, the description comprehensively covers return content, regulatory source, and listed categories. No additional context is needed for effective use.

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 has 100% coverage with a clear description for 'type_preparation'. The tool description adds further context by explaining keyword search and the fallback behavior when absent, providing meaningful added value 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 DLC rules for specific preparations in French restaurants, listing covered categories. It distinguishes from sibling tools by focusing on use-by-date rules rather than other HACCP or regulatory topics.

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 explains the optional 'type_preparation' filter but does not provide explicit when-to-use or when-not-to-use guidance, nor does it compare with sibling tools. Usage is implied but lacks exclusion or alternative context.

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 data sources (Alim'confiance, DGCCRF), seasonal patterns, and the return structure (risk score, months, frequency, recommendations). However, it does not mention limitations like potential data staleness or permission requirements.

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 slightly redundant by including both French and English versions, but each sentence adds value. The purpose is front-loaded. It could be more concise without losing meaning, but it is not excessively wordy.

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 lack of output schema, the description adequately details what is returned (risk score, high-risk months, frequency, recommendations). It also states data sources and intended usage frequency. However, it does not cover all edge cases (e.g., department code validation) or specify the format of risk score.

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 baseline is 3. The description repeats that type_etablissement and departement are required but adds no new information about parameters. The optional dernier_controle_ddpp is not mentioned in the description, though it is documented in 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 an estimated DDPP inspection risk level for a given establishment type and department. It uses specific verbs ('retourne', 'estimation') and distinguishes the resource (risk level) from sibling tools that focus on raw data or checklists.

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 mentions the tool is designed for automation and can be called quarterly, but it does not provide explicit guidance on when to use this tool versus alternatives like get_alimconfiance_etablissement or get_score_alimconfiance. No exclusions or when-not-to-use are stated.

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 provided, so the description carries the burden. It transparently states the tool returns sanction levels, triggers, fines, and legal basis, with an optional filter. No destructive behavior is indicated, which is appropriate for a read-only reference tool.

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 quite long, listing many details. While informative, it could be more concise. It front-loads the main purpose but includes both languages, which adds 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?

For a complex tool with no output schema, the description covers sanction levels, thresholds, fines, legal basis, and the optional parameter. It is complete enough for an agent to understand 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?

Schema coverage is 100% (only one parameter with description). The description repeats the schema's enumeration of 'gravite' values, adding no new meaning. Baseline 3 is correct.

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 sanctions and risks for DDPP inspections in French food businesses, listing specific levels (observation, mise en demeure, etc.) and details. This distinguishes it from sibling tools which cover HACCP, allergens, temperatures, etc.

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 explains the optional 'gravite' filter and its values, implying when to use it. It doesn't explicitly state when not to use or contrast with siblings, but the distinct topic makes usage clear.

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 provided, but the description states it 'returns' the explanation, implying a read-only informative operation. It does not disclose any behavioral traits beyond that, but given no parameters, it 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 clear and front-loaded with the main purpose, but it is slightly lengthy with both French and English versions. Could be more concise, but the structure is logical 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?

Given no parameters and no output schema, the description fully explains what the tool returns: scoring levels, criteria, inspection frequency, and improvement actions. It is complete for an informational tool.

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?

No parameters exist, and the schema coverage is 100%. The description adds value by explaining what the tool does without needing parameters. Baseline for 0 params 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 clearly states the tool returns the complete functioning of the Alim'confiance score, detailing levels, criteria, frequency, and improvement actions. It distinguishes from sibling get_alimconfiance_etablissement by specifying it is for understanding the system, not a specific establishment.

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?

Explicitly suggests when to use this tool (to understand scoring system) and when to use the sibling (for one establishment's score). Provides clear context and an alternative.

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?

Without annotations, the description carries the full burden. It fully discloses the tool's read-only behavior (returns criteria), details the content covered (safety and hygiene criteria, sampling plans, future regulation change), and mentions optional parameter behavior. It does not cover error handling or output formatting, but the simple lookup nature makes this acceptable.

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 but is longer than necessary due to including both French and English full text. It could be more concise by eliminating the full English translation or merging key points. It earns a 3 as it is adequate but not lean.

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 tool's function, parameter usage, and even future regulatory changes. For a simple retrieval tool with no output schema, it provides sufficient context for an agent to understand the returned data. Slight improvement could be a note on output format, but not essential.

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 parameter 'categorie' is already documented with allowed values and default behavior. The description repeats this information ('Optional 'categorie'' and lists values) but adds no new semantic info beyond the schema. 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 EC regulations, listing safety and hygiene criteria types and key details like sampling plan and application stage. This unambiguously defines its purpose and distinguishes it from sibling tools focused on other regulatory aspects (e.g., DLC, temperatures, cleaning 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 provides no guidance on when to use this tool versus alternatives (e.g., when to use get_temperatures_cuisson instead). There is no mention of when not to use this tool or any differentiation from siblings. This leaves the agent without context for selection.

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?

The description details the data returned: core temperatures, cooling/reheating rules, and safety recommendations for sensitive populations. No annotations exist, so the description carries the full burden. It implies a read-only query with no side effects, which is appropriate.

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 and front-loaded with the main purpose. It includes both French and English text, which is slightly redundant but still efficient overall.

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 lookup tool with one optional parameter, the description is fairly complete. It covers what data is returned, distinguishes from a sibling, and explains parameter usage. However, it does not specify the return format (e.g., list of objects), which would be helpful given no 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 coverage is 100% with a clear description of the optional filter. The tool description adds value by providing example search terms (e.g., 'volaille', 'refroidissement') and explaining the 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, with specific examples (volaille 74°C, etc.). It also explicitly distinguishes from the sibling tool get_haccp_temperatures, which handles conservation 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 explains the optional filter and clearly distinguishes this tool from get_haccp_temperatures ('Distinct des températures de conservation'). However, it does not explicitly state when not to use it or provide alternative tool names for other scenarios.

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