frigolog-haccp-mcp

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 that the tool returns a factual comparison with data verified from public sites, lists included fields, and notes the data is from April 2026. This gives agents a good understanding of the tool's behavior, though it doesn't mention any side effects or rate limits.

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, information-dense paragraph. It front-loads the main purpose and then lists specific data points. While not extremely concise, it avoids redundancy and each 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 the tool has one parameter, no output schema, and no annotations, the description covers the essential aspects: what it does, what data it returns, and how the parameter affects output. It is complete enough for an agent to use without additional context.

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?

Input schema has one optional parameter with 100% description coverage. The description adds meaning by explaining that if 'solution' is provided, it returns details for that solution, and if absent, returns the full comparison. This clarifies the two modes of operation 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 explicitly states the tool returns a factual comparison of HACCP software solutions, listing seven specific names and details. The verb 'Renvoie un comparatif' clearly identifies the action, and the resource is well-defined, distinguishing it from sibling tools about documents, temperatures, and regulations.

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 when a comparison of HACCP solutions is needed, but lacks explicit guidance on when not to use it or how it differs from alternatives. No context about prerequisites or limitations is 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?

No annotations provided, but the description details what is returned (immediate action, documentary action, resolution time, DDPP alert conditions, example). It implies a read-only retrieval without side effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single verbose paragraph that front-loads purpose but includes extensive detail. Could benefit from bullet points or clearer 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?

Given low complexity (1 optional parameter, no output schema), the description is comprehensive, covering what is returned for each non-conformity and examples.

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 adds context about default behavior ('tous'), but does not significantly extend the schema's parameter 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 it returns regulatory corrective actions for 6 specific non-conformities in restaurants, listing examples and detailing content for each. This is specific and distinct from sibling tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies use for the listed non-conformities, but does not explicitly state when not to use or point to alternatives. However, sibling tools are clearly differentiated in purpose.

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 bears full burden. It discloses search behavior (SIRET overrides, full-text search, sorting, limit defaults), data refresh periodicity, and coverage scope (post-April 2017 controls). It does not explicitly state read-only nature, but it's clearly a 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 is well-structured with the purpose first, followed by return fields, search methods, and context. It is dense but each sentence adds value. Slightly verbose in listing all fields, but that's necessary without output schema.

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 no annotations, the description covers purpose, return fields, search methods, behavior (sort, limit, overrides), and data source. It lacks mention of empty results handling or error cases, but is otherwise complete for a query 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?

Schema coverage is 100%, so baseline is 3. The description adds value by explicitly recommending SIRET as unique, noting that it overrides other parameters, and clarifying search behavior for 'nom'. This goes beyond the 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 searches for the Alim'confiance score of a specific establishment, using a specific verb ('Recherche') and resource. However, it does not explicitly differentiate from sibling tools like 'get_score_alimconfiance', though the name and context imply it's for individual establishments.

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 scores of a specific establishment, and provides guidance on using SIRET vs name+optional filters. However, it does not explicitly state when to use this tool instead of alternatives, nor does it mention 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?

No annotations are provided, but the description fully covers the tool's behavior: it returns a list, supports optional filtering, and details the data included for each allergen. There is no deceptive or missing behavioral information.

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 but is dense with relevant information and front-loaded with the purpose. While not overly concise, every sentence adds value, and no redundancy 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?

With no output schema, the description thoroughly explains the return content and filter options. For a simple tool with one optional parameter, it provides complete context for correct invocation and interpretation.

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 describes the 'allergene' parameter with 100% coverage, and the description adds extra semantics by stating the default behavior when the parameter is absent or set to 'tous', providing guidance 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 the specific EU regulation. It specifies the content per allergen (common names, sources, hidden sources, display obligations, sanctions), distinguishing it from sibling tools like HACCP or DLC checks.

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 parameter and its allowed values, and implies usage for French regulatory allergen information. However, it does not explicitly state when not to use the tool or mention 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 the full burden. It discloses that the tool returns a calendar with urgency levels and recommended actions based on input dates. It does not mention error conditions or data freshness, but overall behavior is transparent.

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 three short sentences in French and English, front-loaded with the main purpose, then listing inputs and outputs. Every sentence adds value with no 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?

The tool has 6 parameters (1 required) and no output schema. The description adequately explains what will be returned (date, urgency, action). For a tool meant to be called weekly, it is sufficiently 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?

Schema coverage is 100%, but the description adds significant context: it explains why each date is needed (e.g., renewal obligation for HACCP training, average inspection frequency for DDPP). This goes beyond the schema descriptions to clarify purpose.

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 regulatory obligations for an establishment, based on specific dates. It distinguishes itself from sibling tools like get_actions_correctives or get_formation_haccp_obligatoire by focusing on a consolidated calendar with urgency levels and recommended 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 explicitly says it is designed for automation and an AI agent can call it weekly to alert about deadlines. It provides context for when to use it, but lacks explicit exclusions or alternatives. However, the sibling tools are sufficiently different, making 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?

With no annotations provided, description must fully disclose behavior. It explains the tool returns a checklist and the optional parameter effect, but does not clarify data source, freshness, or if the checklist is static/dynamic. Adequate but not thorough.

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 functionality in French, followed by an English translation. It is well-structured but the bilingual nature adds redundancy; 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 checklist retrieval with one optional parameter, the description covers the main content categories and parameter effect. Missing output format details (e.g., structured list vs text) but adequate 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 detailed description of the optional parameter type_etablissement. The tool description reinforces the parameter's role (adding trade-specific items) and lists valid values, adding slight 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 that the tool returns a complete daily pre-opening checklist for French food establishments following HACCP/GBPH standards, covering multiple inspection categories. This distinguishes it from sibling tools like get_haccp_temperatures and get_plan_nettoyage_type which focus on specific sub-domains.

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 an agent needs a comprehensive opening checklist, and the optional parameter tailors it to trade types. However, it does not explicitly compare or exclude sibling tools, missing an opportunity to guide selection among related 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, and the description only says 'returns the list'. It does not disclose behavioral traits such as authentication needs, rate limits, or side effects. The description carries the full burden but adds minimal 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 two sentences, front-loaded with the purpose, and efficiently elaborates on content. Every sentence is necessary and there is no 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?

The tool has one optional parameter and no output schema. The description explains the parameter behavior and content, but does not specify the output structure (format of the list) or handle edge cases, leaving some gaps for a fully complete specification.

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 the parameter already described. The description adds marginal value by explaining the logic of common vs specific documents, but does not provide additional semantic depth 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 a list of documents for a DDPP health control, distinguishing it from sibling tools like compare_solutions_haccp or get_haccp_temperatures by focusing on inspection 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 implicitly indicates usage for retrieving required documents, but lacks explicit guidance on when to use it versus siblings or exclusion criteria. The context makes it clear by topic.

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 what the tool returns (obligations, exemptions, content, etc.) and that it is informational. For a read-only tool, this is sufficient, though no side effects or auth requirements are 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 a single sentence but covers all necessary aspects. It is front-loaded with the main purpose. While concise, a structured list could improve readability, but the current form is still clear.

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 the return content (obligations, exemptions, duration, cost, etc.). The tool is low complexity with one optional parameter, and the description provides complete information for an agent to understand 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?

The input schema has 100% coverage with a single parameter. The description adds value beyond the schema by clarifying that the filter is informational because the obligation is the same for all establishment types.

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 legal obligations for HACCP training in commercial catering, using a specific verb ('Retourne') and resource. The description distinguishes it from sibling tools (e.g., compare_solutions_haccp, get_temperatures_cuisson) by focusing on legal requirements.

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 when to use: to get legal training obligations. It does not explicitly state when not to use or provide alternatives, but given the clear sibling differentiation, agents can infer usage 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?

The description indicates the tool returns a reference (read operation) and mentions that sectors without a validated guide are flagged. However, it does not disclose any potential side effects, authentication needs, or data source freshness. With no annotations provided, the description provides reasonable but not comprehensive 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 moderately concise, but the bilingual (French/English) repetition adds length without new information. The key points are front-loaded in the first sentence, but the English summary is redundant.

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 schema (1 parameter) and no output schema, the description sufficiently details the output fields (title, editor, year, price, pages, link, key points, regulatory obligations) and flags cases without a guide. This provides complete context for an agent to understand what the tool 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 covers 100% of the parameter description, listing all allowed values for 'secteur'. The description adds little beyond restating the parameter name and values, so it meets the baseline but does not add significant new 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 official Good Hygiene Practice Guide (GBPH) reference for a specific French food-trade sector. It lists the output fields (title, editor, year, etc.) and distinguishes itself from sibling tools by focusing solely on the guide reference.

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 explicit guidance is provided on when to use this tool versus alternatives like get_actions_correctives or get_checklist_ouverture_etablissement. The description does not explain when to prefer this tool over others for regulatory or compliance tasks.

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 the behavioral burden. It only states what the tool returns without disclosing read-only nature, permissions, rate limits, or error handling. The description is insufficient for a tool with no annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single paragraph that front-loads the main purpose. Each sentence adds value, though it could be slightly more concise. It is well-structured for 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?

For a simple retrieval tool with one optional parameter and no output schema, the description covers the purpose and categories comprehensively. It lacks details on return format but is mostly complete given the tool's simplicity.

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 documents the parameter with possible values. The description repeats the category list but adds minimal meaning. 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 temperatures for conservation, cooling, and service of food products by category, citing specific regulations. It is distinct from siblings which cover different aspects (comparing solutions, control documents, DLC rules).

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 temperature data by category but does not explicitly state when to use this tool versus alternatives. No when-not-to-use or alternative comparisons are provided, though the list of categories gives some 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 of behavioral transparency. It discloses that the plan is a model, GPBH-compliant, and details the output components (zones, frequency, product, method, verification). Additionally, it mentions that an unrecognized type defaults to 'restaurant' with a note, which provides useful behavioral context beyond basic functionality.

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, with each sentence adding meaningful information. It front-loads the primary purpose in the first sentence. The bilingual presentation adds length but serves multilingual agents. Overall, it is well-structured and avoids excessive verbosity.

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 parameter, no output schema, and no annotations, the description provides sufficient context. It explains what the tool returns (cleaning plan details) and the input requirements (establishment type with default behavior). It does not detail the output format (e.g., JSON structure), but for a simple tool, this 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 input schema already provides 100% coverage with description and allowed values for the single parameter. The description adds value by clarifying that an unrecognized type defaults to 'restaurant' with a note, which is not in the schema. This extra context helps agents understand fallback behavior.

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 a French food-establishment type, conforming to GBPH and EU regulation 852/2004. It specifies the output includes cleaning stations, frequency, product, method, and verification criteria, and lists covered establishment types. This distinguishes it from sibling tools which focus on HACCP, temperatures, recalls, 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 usage when a cleaning plan template for a specific food establishment type is needed, but it does not explicitly state when to use this tool versus alternatives or provide exclusions. No when-not guidance is given.

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 bears full burden. It discloses filtering behavior, internal tool usage, and automation design. No contradictions.

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 bilingual sections, but slightly verbose. It front-loads the core purpose and efficiently adds use-case context.

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 single-parameter tool with no output schema, the description covers purpose, filtering logic, and automation use case. It could mention output format or pagination, but overall it's 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?

Schema coverage is 100%, and the parameter description is detailed, listing values and behavior for 'restaurant' and 'traiteur'. The description adds marginal bilingual context but no deeper semantics beyond what the schema 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 active recalls filtered by establishment type, distinguishing it from sibling tools like get_rappels_produits_actifs. It uses specific verbs and resources.

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 tool is for automated morning checks and uses an internal sibling tool. It provides context but lacks explicit when-not-to-use instructions.

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 description carries full burden. It indicates real-time data from an official source and mentions sorting (most recent first for limit). However, it does not disclose response structure, pagination behavior, authorization requirements, or any side effects. Adequate but could be more 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 a single paragraph with two sentences, fairly concise and direct. It includes essential information without excessive verbosity. Could be broken into bullet points for better scanability, but it's 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 3 optional parameters, no output schema, and no annotations, the description explains the tool's purpose and data source but omits response format details and any limitations (e.g., France-only scope). It covers basic usage but lacks completeness for an agent to fully understand the return data.

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 covers 100% of parameters with descriptions. The description adds value by clarifying 'les plus récents en premier' for limit, listing possible category values, and specifying date format. This enhances understanding beyond the bare 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 food product recalls from RappelConso, specifying the official source (data.economie.gouv.fr) and context (check food safety before service). It effectively distinguishes from siblings like get_alimconfiance_etablissement which are about establishment hygiene scores.

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 says when to use: to verify food safety before service, check if a reference is recalled, or consult latest health alerts. It implies context but doesn't explicitly state when not to use or list alternative sibling tools. Still, it provides clear 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?

No annotations provided, but description discloses output includes DLC in days, temperature, and regulatory source, plus covers many categories. Does not mention limitations but is sufficiently transparent for a lookup 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?

Single paragraph front-loaded with purpose, but slightly long due to listing many categories. Could be more concise, but each 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?

Despite no output schema, description compensates by explaining output format (days, temperature, source) and lists all covered categories. Tool is simple with one optional param, so completeness is high.

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?

Only one parameter with 100% schema coverage. Description adds no extra meaning beyond the schema's own description. 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?

Description clearly states the tool returns DLC rules for homemade preparations in French restaurants, listing specific categories. Verb 'Renvoie' and resource are specific. Distinguishes from siblings which cover HACCP solutions and 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 implicitly indicates when to use (need DLC rules for French restaurant preparations), but lacks explicit when-not or alternative tools. However, siblings are different enough to avoid confusion.

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 discloses data sources, output composition (risk score, months, frequency, recommendations), and the optional parameter's effect. Could mention limitations like data freshness but is reasonably transparent.

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?

Bilingual and well-structured with purpose first, then details. Some redundancy between languages but overall efficient and front-loaded.

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?

No output schema, but description clearly defines return fields (risk score, months, frequency, recommendations) and usage context. Sufficient for an agent to understand 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?

Schema coverage is 100%, so baseline is 3. The description repeats parameter details without adding significant new meaning beyond the schema, e.g., merely restating that dernier_controle_ddpp refines the 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 it returns an estimated DDPP inspection risk level for a given establishment type and department, specifying data sources and output components. It is unique among siblings, which focus on specific aspects like scores or sanctions.

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 suggests quarterly automation use but does not explicitly contrast with siblings like get_score_alimconfiance or get_alimconfiance_etablissement, nor states 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?

No annotations provided, and the description fails to disclose behavioral traits such as read-only nature, authentication needs, rate limits, or data freshness. It only describes the content returned.

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 sentence that conveys much information efficiently, but could be better structured (e.g., bullet points) for clarity. It is not excessively long.

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 provides a good overview of what the tool returns (levels, fines, legal bases). However, it lacks specifics on output structure or data handling, and no mention of limitations.

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 only parameter, which already describes it. The description adds minimal extra meaning (e.g., mentions 4 levels but the parameter values are different). 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 sanctions and inspection risks for DDPP controls in catering, listing specific levels, fines, and legal bases. It is distinct from sibling tools which cover HACCP, temperatures, allergens, 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?

No guidance on when to use this tool versus alternatives. It does not explain scenarios where this tool is appropriate or mention any exclusions or prerequisites.

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 discloses that the tool returns detailed information about the score system (levels, criteria, frequency, actions). It does not mention any side effects or authentication needs, but since it is a read-only informational tool, the description is sufficiently transparent.

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 and informative, but somewhat verbose with historical and contextual details. It front-loads the main purpose and then provides specifics. While each sentence adds value, 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 has no parameters and no output schema, the description thoroughly covers what the tool returns: the four levels, six criteria, inspection frequency, and improvement actions. It also references the sibling tool for specific use cases, making the context 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 input schema has no parameters, so schema coverage is 100%. The description does not need to add parameter information. It provides context about what the tool returns, which adds value beyond the empty 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 the complete functioning of the Alim'confiance score system. It specifies the resource (score fonctionnement) and verb (retourne). It also distinguishes from the sibling tool get_alimconfiance_etablissement by explicitly stating to use that tool for 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?

The description gives explicit usage guidance: it tells when to use this tool (to get general info about the scoring system) and when to use the sibling get_alimconfiance_etablissement (for a specific establishment's score). This clearly differentiates from 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?

With no annotations, the description carries the burden. It explains that the tool covers security and hygiene criteria, sampling plans, and action on exceedance. It also notes behavior for absent/unknown 'categorie' parameter. However, it does not mention rate limits or authentication needs.

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 fairly concise but includes bilingual text, which adds length. It is well-structured with key information front-loaded, but could be slightly more streamlined.

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 tool returns: criteria types, sampling plans, application stages, and actions. It also notes a future regulatory change, making it sufficiently complete 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?

The input schema has 100% coverage with a description of the 'categorie' parameter and its values. The description adds that the parameter is optional and explains behavior when absent or unrecognized, providing additional context 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 regulatory microbiological criteria for foodstuffs, including specific regulations and types of criteria. This distinguishes it from sibling tools like get_haccp_temperatures or get_regles_dlc, which cover different aspects.

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 microbiological criteria but does not explicitly state when to use this tool versus alternatives. No guidance on when not to use or mention of other tools for different criteria.

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 present, so the description carries full responsibility. It discloses the data returned: core temperatures, rapid cooling requirements, reheating temperatures, and recommendations for sensitive populations. However, it does not describe output structure, pagination, or authentication needs.

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 and each sentence adds useful information. It could be slightly more concise, but it remains efficient and front-loaded with key details.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the lack of an output schema, the description covers the main data points and distinctions. However, it omits details about the response format (e.g., array structure) and does not mention any potential error conditions.

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%, but the description adds significant value: it clarifies that the parameter is a keyword search on identifier or label, provides example values, and states the default behavior when omitted.

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 mandatory cooking core temperatures by food type for French restaurants, listing specific examples (volaille 74 °C, etc.). It explicitly distinguishes itself 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 parameter type_aliment, including how to use it for keyword searching and the behavior when absent (returns all). It also mentions that this tool is distinct from get_haccp_temperatures, but does not provide explicit when-not-to-use guidance or list the sibling.

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