frigolog-haccp-mcp

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 is published by Frigolog with a conflict of interest, that data is verified from public sources, and each claim links a public source. This provides important transparency about biases and verification, going beyond a simple 'get comparison'.

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 and front-loads the main purpose. It includes necessary details about compared fields and data sources. While slightly long, every sentence adds value, and the structure is 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 lists the fields compared (price, hardware, AI features, etc.), making the return values clear. It also notes the data verification and conflict of interest, covering most contextual needs for an agent to use this tool effectively.

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 fully describes the single parameter, but the description adds value by listing allowed values, explaining that absence returns full comparison, and presence returns details for one solution. This contextualizes the parameter 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 factual comparison of HACCP software solutions on the French market, listing specific solutions and details. It is distinct from sibling tools, which focus on regulations and inspections, not software comparison.

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 indicates when to use the tool (for comparing HACCP software) and explains the optional filter by solution. It does not explicitly state when not to use it, but no sibling tools serve the same purpose, so usage context is 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 are provided, so the description carries the full burden. It discloses the return structure (immediate action, PMS documentation, deadlines, alerts, example) but does not address side effects, authentication, or rate limits. For a read-only retrieval tool, this 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 verbose with French and English versions, containing redundant information. While all key aspects are present, it could be more concise. Front-loads purpose but lacks tight 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 the single optional parameter and no output schema, the description covers the return values adequately by listing the types of information for each non-conformity. It provides sufficient context for an agent to understand the tool's output.

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 is fully documented there. The tool description adds minimal extra meaning beyond restating the optional filter. Baseline 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 corrective actions for the 6 most common catering non-conformities, with specific verb 'Retourne' and resource 'actions correctives'. It distinguishes from sibling tools which focus on other regulatory aspects like temperatures, allergies, or inspections.

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

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

The description implicitly indicates when to use (when corrective actions for common non-conformities are needed) and mentions the optional filter. However, it does not explicitly exclude scenarios or reference siblings as 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?

Discloses dataset source, record count, refresh frequency, coverage period, and search behavior (full-text, case-insensitive, SIRET ignoring other params). No annotations, so description carries full burden; lacks mention of rate limits or error behavior but is otherwise 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 description is clear and front-loaded, but the English translation adds redundancy. Could be more concise by omitting the repetition.

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, description lists return fields and explains search modes, data source, and limitations. Missing details on error responses or pagination but sufficient for most use cases.

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 detailed parameter descriptions. The tool description adds value by explaining recommended combinations and behavior (e.g., SIRET overrides other params).

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 Alim'confiance inspection scores for a specific establishment and lists the returned fields. It does not explicitly differentiate from the sibling tool 'get_score_alimconfiance', though the name suggests a difference in scope.

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?

Provides good guidance on recommended search by SIRET and disambiguation via code_postal/commune, but does not compare to sibling tools or state when not to use this 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, the description must stand alone. It explains the regulation, return content (common names, hidden sources, penalties), and optional filtering. It does not disclose authentication or rate limits, but for a read-only data retrieval tool, this is sufficient.

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

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

The description is somewhat long due to listing all allergens and including both French and English, but it is front-loaded with the main purpose in the first sentence. Each part adds value, though it could be slightly more concise.

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

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

The description thoroughly explains what the tool returns (common names, sources, penalties), covering the lack of an output schema. Sibling tools are all different compliance topics, so context is clear. The optional parameter is fully described.

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 for the parameter. The tool description adds meaning by explaining the default behavior ('tous' returns all allergens) and listing possible values, which goes beyond the schema's 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 the 14 mandatory allergens under EU Regulation 1169/2011, listing specific information (names, sources, penalties). It distinguishes itself from siblings (e.g., temperature, inspection tools) by being solely about allergens.

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 allergen information but does not explicitly state when to use it over alternatives. Context with sibling tools clarifies its distinct purpose, yet no direct 'when-to-use' or 'when-not-to-use' guidance 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 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, so the description carries the full burden. It discloses the tool returns a list of documents, which is a read-only operation. There are no side effects or additional constraints mentioned. The description is transparent about the tool's behavior for a simple listing function.

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 but includes both French and English versions, which adds length. It is front-loaded with the main action and includes key details. Could be slightly trimmed, but the bilingual nature may be necessary for the target audience.

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 value: a list of documents (common base + specific by trade) and the optional filter. For a simple list-returning tool with one optional parameter, the description is complete and leaves no major questions.

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, describing the single optional parameter and its values. The description adds contextual meaning by explaining that the return includes a 12-document common base plus business-specific documents, and that the parameter filters by establishment type. This adds value beyond the schema alone.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: returning a list of documents a DDPP inspector may request during a sanitary inspection, by establishment type. It specifies the verb 'Renvoie la liste des documents' and the resource (documents for DDPP inspection). This distinguishes it from sibling tools which cover actions like corrective measures, temperatures, or 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 implies usage context (preparing for a DDPP inspection) and provides the optional parameter filter. However, it does not explicitly state when to use this tool vs alternatives like 'get_checklist_ouverture_etablissement' or 'get_guide_bonnes_pratiques_secteur'. The context is clear but lacks explicit exclusions or alternative recommendations.

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

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

With no annotations provided, the description carries the full burden. It accurately describes the tool as returning information with no side effects, but does not mention authentication, rate limits, or any specific behavioral traits beyond the obvious read-only nature.

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

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

The description provides thorough details in both French and English, but is somewhat verbose. The structure is clear with distinct sections, but could be more concise, especially the French paragraph which is quite 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 the complexity of legal information and no output schema, the description fairly completely explains what the tool returns: obligations, exemptions, content, duration, cost, penalties. It covers the essential aspects for an agent to understand the tool's output.

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 description adds value by explicitly stating that the 'type_etablissement' parameter is optional and informational, reinforcing that the obligation is the same for all establishment types, which aids correct invocation.

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 HACCP training rules for French commercial catering, specifying who must train, exemptions, content, duration, cost, penalties. This verb+resource distinguishes it from sibling tools like 'get_sanctions_ddpp' 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 explains what the tool does, but does not explicitly state when to use it versus alternatives. It provides context that it covers legal obligations, but no guidance on exclusions or comparisons to 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?

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 carries full burden. It states the tool returns temperatures but does not disclose whether it is read-only, requires authentication, or has side effects. For a data retrieval tool, more behavioral context (e.g., data source freshness, response format) would be beneficial.

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 comprehensive, but slightly longer than necessary. The main purpose is front-loaded and each sentence adds value. It could be trimmed to a single language version without loss.

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 and no output schema, the description provides sufficient context: regulations, categories, and filter capability. It lacks details about output format but that is acceptable 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% (one parameter with full details). The description adds the optional filter mention but does not provide additional meaning beyond the schema. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool returns French regulatory food temperatures by product category, referencing specific regulations (arrêté of 21 Dec 2009, EC 852/2004, 853/2004). It lists covered categories, distinguishing it from sibling tools like get_temperatures_cuisson or get_seuils_microbiologiques.

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

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

The description mentions an optional filter (categorie) but does not explicitly state when to use this tool versus alternatives. It provides clear context (regulatory temperatures) but lacks when-not-to-use guidance or references to 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 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?

With no annotations, the description must fully disclose behavior. It states 'returns active recalls in real time' and the source, but does not mention rate limits, authentication, error handling, data freshness guarantees, or any side effects. The lack of detail limits transparency for a non-destructive read 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 mostly front-loaded with purpose and source, but the bilingual repetition (French and English) adds unnecessary length while still being informative. It earns its place but could be trimmed to single language.

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 structure. It does not describe the fields returned (e.g., product name, reason, date). For a retrieval tool, this is a significant gap. The description mentions filters but not what data each recall entry contains.

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 tool description repeats the three filter parameters (categorie, limit, date_depuis) but does not add semantic meaning beyond what the schema already provides. No enum values or deeper context are added.

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 verb 'Retourne' (returns) and the resource 'rappels et retraits de lots de produits alimentaires actifs en France'. It specifies the source (RappelConso/DGCCRF) and distinguishes from siblings like get_rappels_par_categorie_etablissement by being the only tool returning active recalls from the official source.

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

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

The description provides explicit use cases: verifying food safety, knowing if a product is recalled, or consulting latest alerts. It does not mention when not to use or alternatives, but the context is 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 are provided, so the description carries full burden. It implies a read-only query by the verb 'Renvoie', but doesn't explicitly state idempotency or safety. 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 front-loaded with the French primary text, followed by an English summary. It lists many categories, which is informative but slightly verbose. Overall, it earns its 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 1 optional parameter, no output schema, the description thoroughly explains the output structure (DLC in days, temperature, source) and covers all use cases. No gaps identified.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema description coverage is 100%. The description adds significant value by explaining the filter mechanism (keyword search), providing concrete examples, and clarifying 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 uses a specific verb 'Renvoie' (returns) and resource 'règles de DLC', listing covered preparation types. It clearly distinguishes from sibling tools which focus on different topics like HACCP 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 the optional filter 'type_preparation' with keyword search examples, and states default behavior when absent. While it doesn't explicitly compare to alternatives, the tool's specific domain makes usage context 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, 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 are provided, so the description carries the full burden. It discloses the content returned (sanctions levels, deadlines, fines, legal basis), implying a read-only retrieval operation. However, it does not explicitly state that the tool is read-only or discuss side effects, but the level of detail is high.

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 verbose with two paragraphs (French and English), which adds redundancy. The main purpose is front-loaded, but the extra detail on legal basis and specifics could be condensed. Every sentence earns its place but the bilingual repetition reduces conciseness.

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

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

The tool has one optional parameter and no output schema. The description explains the sanction levels, triggers, fines, and legal basis comprehensively, but does not specify the return format or structure. Without an output schema, the agent lacks information on how to parse the result, leaving a gap in completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% for the single optional parameter 'gravite', with a description that enumerates valid values. The tool description merely restates that it is optional and lists the values, adding no new meaning beyond the schema. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool returns DDPP inspection sanctions and risks with specific levels, triggers, fines, and legal basis. It distinguishes itself from sibling tools by focusing on sanctions, but does not explicitly differentiate.

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. It does not mention prerequisites, exclusions, or comparison with sibling tools.

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

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

No annotations exist, so the description carries full burden. It fully discloses the informational nature of the tool and details what it explains. No hidden behaviors or side effects are relevant.

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?

Description is moderately long but well-structured with French and English versions, front-loads key purpose, each sentence adds value. 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 no input parameters and no output schema, the description completely covers the tool's educational purpose, detailing four levels, six criteria, inspection frequency, and improvement actions.

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 in schema, baseline 3. The description compensates by explaining the tool's content, adding 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 it returns the complete functioning of the Alim'confiance scoring system, including levels, criteria, frequency, and improvement actions. It distinguishes itself from the sibling tool get_alimconfiance_etablissement which is for a specific establishment's score.

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 says to use get_alimconfiance_etablissement for a single establishment's score, providing clear when-to-use and when-not-to-use guidance.

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

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

With no annotations, the description carries the 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 exist, so description carries full burden. It discloses not only temperatures but also cooling, reheating rules, and safety recommendations for sensitive populations. Implies read-only operation, though not explicitly stated.

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, which is redundant and slightly verbose. While informative, it could be more concise by keeping only one language or front-loading the key points more efficiently.

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 covers what is returned, including example temperatures, cooling/reheating rules, and safety recommendations. Provides a good complete picture of the tool's output.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, and the parameter description in the schema already provides detailed semantics. The main description does not add significant new meaning beyond what's 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?

Clearly states it returns mandatory core cooking temperatures by food type in French catering, including cooling and reheating rules. It explicitly distinguishes from the sibling tool 'get_haccp_temperatures' for 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?

Provides explicit guidance on when to use this tool versus alternatives by stating it is distinct from get_haccp_temperatures. Mentions optional parameter for filtering, but does not elaborate on 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.