OutilsIA — Conseiller IA locale

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

Annotations already carry readOnlyHint=true and destructiveHint=false; the description adds genuinely useful context on top: 'Accepte uniquement une URL exacte' discloses the tool's narrow contract and 'ne donne aucun accès à la machine' clarifies it dereferences a public URL rather than inspecting local state — a boundary the readOnly annotation alone does not imply. No contradiction with 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?

Two sentences with zero waste: the first states the action and object, the second bundles the input constraint and the safety boundary. The main verb is front-loaded, and every clause carries information an agent needs before invoking.

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 an output schema exists and annotations cover the safety profile, the description is sufficient to invoke the tool correctly on the report_url side. The real gaps are the unexplained `usage` parameter (its enum values and how they shape the analysis) and the absence of routing guidance among the three report-related siblings. These are moderate rather than severe gaps, so this lands at an adequate-but-incomplete 3.

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 0%, so the description must compensate. It does meaningfully for report_url, adding a strict pattern constraint ('https://outilsia.fr/r/...') beyond the schema's generic uri format. However, the optional `usage` parameter (an enum of 7 French usage profiles) is never mentioned, leaving its effect on the analysis completely undocumented — partial compensation, not full.

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 has a specific verb ('Lit' / reads) and a clear resource: a public OutilsIA Local Cockpit report already created by the user. It distinguishes itself implicitly from siblings — 'déjà créé par l'utilisateur' separates it from report-creation tools and 'ne donne aucun accès à la machine' separates it from local-machine tools like check_pc_for_local_ai — but it never names the sibling it is not, which keeps it just below a 5.

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 conveys the core precondition — the agent should use this tool when the user already has an exact public report URL of the form https://outilsia.fr/r/... It does not explicitly state when to prefer this tool over the report-list siblings (list_benchmark_proofs_from_report, list_installed_models_from_report), nor does it give exclusion conditions such as 'do not use if the report is not public.'

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?

Annotations already indicate readOnlyHint and non-destructive behavior. The description adds useful context beyond that: the tool does not scan the system and relies entirely on explicitly supplied characteristics. This clarifies the tool's boundary without contradicting the 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 two succinct sentences with no wasted words. The core function is front-loaded, followed by a clear non-scan caveat and invocation prerequisite.

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 that an output schema exists and annotations cover the safety profile, the description provides enough context for a basic invocation: purpose, required inputs, and a clear exclusion. It could be more complete by explaining how optional parameters like usage affect the estimation, but this is not critical for core usage.

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 0%, so the description carries the burden of explaining parameters. It names the four required hardware characteristics (CPU, RAM, GPU, VRAM) but does not add meaning for the six optional parameters such as usage, os_name, unified_memory, or storage_free_gb. This leaves the agent with limited semantic guidance beyond raw schema names.

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 estimates which local AI models are suitable based on user-provided hardware characteristics. It uses a specific verb ('Estime quels modèles IA locaux conviennent') and explicitly distinguishes itself from a scan, which helps separate it from sibling tools like lookup_local_model or list_models_for_budget.

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 clear when-not-to-use guidance: it is not a scan and must not be called when CPU, RAM, GPU, or VRAM are missing. It does not explicitly name alternative tools, but the exclusion and prerequisite are strong enough to guide invocation.

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?

Beyond the readOnlyHint and destructiveHint annotations, the description adds behavioral context: it produces a probable diagnosis, it is not a scan, and it works from declared RAM/VRAM values rather than live hardware discovery. This helps set expectations about reliability and input handling.

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 short and front-loaded, with the core purpose in the first sentence and the disclaimers in the following sentences. It is efficient with no filler, though the cryptic '/r/...' fragment slightly reduces clarity.

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 output schema and annotations reduce the burden of describing return values and safety. However, with 8 optional parameters and 0% schema coverage, the description leaves several inputs unexplained, including storage_free_gb despite the title mentioning storage bottlenecks. The main invocation modes are stated, but not the full input space.

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 0%, so the description must compensate, but it only explains report_url and the ram_gb/vram_gb pair. The other six parameters (cpu_name, gpu_name, cpu_cores, unified_memory, storage_free_gb) receive no semantic guidance, and the title's storage focus is not mapped to storage_free_gb in the description.

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

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

The description clearly states the tool identifies a probable bottleneck from either a report URL or a declared RAM/VRAM profile. It distinguishes itself from a scan, but it does not explicitly contrast it with sibling tools like recommend_runtime or simulate_hardware_upgrade, and the shorthand '/r/...' is somewhat opaque.

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 input guidance: provide report_url OR ram_gb and vram_gb, and clarifies this is not a scan. It does not mention alternatives to prefer over this tool or explain when to choose report_url versus direct values, but the primary invocation pattern 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?

Annotations declare readOnlyHint=true and destructiveHint=false, but the description adds specific behavioral details: 'Aucun fetch, aucune citation observée' (no fetch, no observed citation). This goes beyond the generic read-only hint by clarifying the tool does not make network calls or rely on external data. It reinforces but also extends the annotation 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?

Two short sentences. First states the purpose, second states behavioral constraints. No fluff.

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

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

Given it's a simple reference tool with no parameters and an output schema exists, the description is adequate. It explains what it does and what it does not do. Could maybe mention that it's for clarifying scope, but overall 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 tool has no parameters, so per the baseline for 0 params, a score of 4 is appropriate. The description doesn't need to compensate for missing parameter info.

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

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

The description clearly states the tool's function: it explains what the ScoreBot audit measures and does not measure. The verb 'Rappelle' (reminds/explains) and the specific resource 'ce que l'audit ScoreBot mesure' make the purpose precise. It distinguishes from sibling tools like geo_audit (which likely performs the audit) by focusing on explaining the method.

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 recalling the scope of the ScoreBot audit. The statement 'Aucun fetch, aucune citation observée, lecture seule' gives clear context that it is safe and non-side-effectful. However, it doesn't explicitly say 'use this when' or contrast with alternatives, so it stops short of full guidance.

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

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

Annotations already provide readOnlyHint: true and destructiveHint: false, making the read-only nature clear. The description adds valuable behavioral context beyond annotations: it confirms this tool never accesses the machine and performs no action, and states the return is the complete response in read-only mode. It also warns against adding any follow-up actions, which is not in 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 two sentences: the first defines the trigger conditions precisely, the second sets strict post-call behavior rules. No wasted words; every sentence is necessary and front-loaded with critical usage conditions.

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 2 optional parameters, a full output schema (not provided but exists per context), and comprehensive annotations, the description is fully self-contained. It explains purpose, triggers, safety profile (read-only, no machine access), and post-call constraints. No gaps remain for the agent to infer incorrectly.

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 0%, so the description must compensate. While the description does not explicitly list parameter names or formats, it implies 'target' refers to what to install/scan/delete (e.g., Ollama, model, driver) and 'requested_action' maps to the listed actions (install, download, etc.). The description's trigger list directly corresponds to the action enum, providing meaningful context beyond the schema. The 'target' maxLength and default are schema-only, but the description clarifies its semantic scope.

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 specifies the verb 'expliquer' (explain) and the resource 'la limite des actions locales' (local action boundary). It lists exact trigger conditions (install, download, update, run, delete, scan, benchmark) that distinguish it from sibling tools like 'check_pc_for_local_ai' and 'recommend_runtime'.

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

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

The description explicitly states when to call the tool: for any request to install, download, update, run, or delete Ollama, a model, or driver, as well as scanning or benchmarking. It also provides strong negative guidance: after the call, do not add commands, procedures, web searches, external sources, or manual alternatives. This covers both triggers and post-call constraints.

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?

Annotations already declare readOnlyHint=true, but the description adds more: it explicitly says it doesn't modify the target site and doesn't promise to be cited by ChatGPT. This provides extra safety and expectation-setting beyond the annotation.

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 concise sentences with the primary action stated first. It includes all essential info without redundancy.

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

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

With an output schema present, the description need not detail return values. It covers purpose, read-only nature, and a key parameter requirement, making it sufficiently complete for a simple one-parameter tool.

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

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

The schema only defines a 'url' parameter with length constraints. The description adds the crucial 'public URL' requirement, which is not in the schema, clarifying that the URL must be publicly accessible.

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 performs a deterministic SEO audit and AI preparation on a public URL via ScoreBot. The verb 'Audit' and the resource 'URL' are specific, and it distinguishes from sibling tools that focus on local AI models and report analysis.

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 auditing a URL for SEO purposes, but it does not explicitly contrast with alternatives or specify when not to use it. However, given the distinct nature of sibling tools, the context is clear enough.

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

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

Beyond the readOnlyHint and destructiveHint annotations, the description explicitly states that it writes nothing to the target site and calls no model. These are meaningful behavioral guarantees that help an agent assess side effects and cost even though annotations already cover safety.

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?

Two short sentences front-load the main purpose and then add the critical behavioral caveats. Every word earns its place, with no repetition of schema 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?

For a one-parameter tool with an output schema, the description adequately covers what the tool generates, the input requirement, and the read-only/no-model behavior. No critical information appears missing.

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

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

The schema only declares a string named 'url' with length constraints, and has 0% description coverage. The description adds the crucial semantic that the URL must be public and is the input source for the kit, which is enough for a single, self-explanatory parameter.

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 ('Génère') and names the resource ('un kit GEO') plus concrete outputs (llms.txt, verdict robots IA, schemas JSON-LD). It clearly distinguishes this tool from audit/explanation siblings by framing it as kit generation.

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

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

The description implies the tool should be used for generating a read-only GEO kit from a public URL, but it does not explicitly state when to prefer it over related tools like geo_audit. The public-URL constraint gives some guidance, but exclusions and alternatives are absent.

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?

Annotations already declare readOnlyHint true. The description adds valuable behavioral context: it will not invent speeds if the report lacks proof, and it only operates on public reports. This goes beyond what annotations provide, giving the agent a clear honesty guarantee and scope constraint.

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 concise sentences, front-loaded with the core purpose. Every word adds value: the verb, resource, scope, honesty guarantee. No redundancy or fluff.

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

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

For a read-only tool with a single parameter, the description covers the essential: what is returned, the source constraint (public report), and behavior when no proofs exist. The presence of an output schema reduces the burden to explain return values. It could mention error states beyond 'no proof', but overall it is complete enough 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?

Despite 0% schema description coverage, the description compensates by specifying the expected URL format ('https://outilsia.fr/r/...') and that the report must be public. This adds meaningful semantic context beyond the schema's type/format constraints, helping the agent provide proper input.

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 tokens/s already measured in a public report, specifying the URL format. It distinguishes from siblings like list_installed_models_from_report by focusing on benchmark proofs. However, it lacks explicit differentiation language, keeping it one step below perfect.

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

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

The description implies the tool should be used for reading existing measurements from public reports. It does not provide explicit guidance on when to use alternatives among the sibling tools, nor does it state when not to use this tool. The context is clear but leaves the agent to infer usage boundaries.

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?

Annotations already declare readOnlyHint=true and destructiveHint=false, establishing safe read behavior. The description adds significant context: the tool returns only first-party, dated, non-extrapolated measurements from an unfinished multi-machine campaign. This goes beyond annotations to inform the agent about data scope and limitations.

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 sentences, each adding distinct information: return content, non-extrapolation, campaign state. It is front-loaded with the main purpose. Minor deduction for the cryptic third sentence ('Campagne multi-machines non terminée') which could be clearer.

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 is simple with one optional parameter and an output schema exists (so return values need not be elaborated). The description adequately covers what is returned and key behavioral constraints. However, the missing explanation of the 'query' parameter creates a gap in completeness, as the agent has no guidance on how to use the sole input.

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 one optional parameter 'query' with 0% description coverage, and the tool description does not explain its purpose or expected format. Given the low schema coverage, the description should compensate but fails to add any meaning to the parameter, leaving the agent to guess whether it filters results or something else.

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 dated public benchmarks (machine, runtime, tok/s, reference) from the OutilsIA first-party source. It adds specificity about non-extrapolation and campaign state, distinguishing it from sibling analysis tools. However, it does not explicitly differentiate from siblings in a comparative way.

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 is provided on when to use this tool versus alternatives. The constraints (not extrapolated, campaign not finished) imply boundary conditions but are not framed as usage instructions or compared to sibling tools like analyze_shared_report or check_pc_for_local_ai.

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 annotations already declare readOnlyHint=true, openWorldHint=false, destructiveHint=false, so the tool is clearly a safe read operation. The description adds meaningful context beyond annotations: it specifies the source is a public report at https://outilsia.fr/r/..., and reiterates it does not access the machine or install anything. This extra behavioral context is valuable, but a 5 would require even richer details like error behavior or access constraints.

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 concise sentences, both front-loaded with purpose and constraints. Every word earns its place, no redundancy. However, a 5 would require perfectly optimizing for reading order by leading with the most critical operational constraint first; here both sentences are equally important.

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 a single parameter, excellent annotations (readOnlyHint, safety hints), and a presumably defined output schema (has output schema: true), the description is complete. It explains the tool's action, the source format (public report), and what it does not do (no machine access, no installation). There is no gap given the complexity.

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 0%, so the description carries the full burden for the single parameter 'report_url'. The description mentions 'un rapport public https://outilsia.fr/r/...' which gives the parameter meaning – it's a URL to a specific report format. This adds value beyond the schema's format constraint. A 5 would require explicit param documentation (e.g., 'report_url: the full URL of the OutilsIA report'), but the description compensates adequately.

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 reads (lit) installed models from a public report URL, contrasting with sibling tools that analyze, check, explain, or recommend. The verb 'Lit uniquement' (reads only) and the specific resource 'modèles installés déjà présents dans un rapport' precisely distinguish it from similar list tools like 'list_benchmark_proofs_from_report' or 'list_first_party_measurements'.

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

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

The description explicitly states when to use this tool: to read installed models already present in a public report. It also tells when not to use it by clarifying 'N'accède pas à la machine et n'installe rien' – it does not access the machine or install anything. This directly distinguishes it from sibling tools like 'check_pc_for_local_ai' or 'simulate_hardware_upgrade'.

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?

Beyond the readOnlyHint annotation, the description discloses that results are catalog estimates rather than measured or scanned data. 'Pas un scan, pas un benchmark, pas de tokens/s inventés' clearly sets expectations about output provenance and prevents overclaiming.

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?

Two short sentences with no filler. The core filter action is front-loaded, and the limitation statement is compact and informative.

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

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

The tool is simple and has an output schema, so return-value documentation is not necessary. However, with 5 parameters and no schema descriptions, omitting two of them makes the definition not fully self-sufficient. A sentence on unified_memory and storage_free_gb would close the gap.

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 description maps vram_gb, ram_gb, and usage into understandable language, but the schema itself has 0% parameter descriptions. It leaves unified_memory and storage_free_gb completely unexplained, so an agent gets no help understanding the boolean unified_memory flag or how storage_free_gb factors into filtering.

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?

States a concrete action ('Filtre le catalogue public') with explicit filtering criteria (VRAM, optional RAM, usage). It also disambiguates from measurement/report tools by saying it is not a scan or benchmark, which distinguishes it from siblings like list_benchmark_proofs_from_report.

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 this is catalog-only estimation and not a scan, benchmark, or source of invented tokens/s, giving clear when-not guidance. It does not name sibling alternatives, so routing is less direct than it could be.

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 annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, establishing a safe, bounded read operation. The description adds one detail: it does not invent tokens/s (meaning no hallucination), which is a useful behavioral note beyond annotations. However, it omits other relevant behaviors such as whether it accesses a live API or local cache, rate limits, or result format. With annotations covering safety, a 3 is appropriate.

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

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

The description is two sentences with zero wasted words. Every sentence adds necessary context: the first covers the core purpose and searchable dimensions, the second clarifies it's not a scan and doesn't generate fabricated data. This is exemplary 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 simple string parameter, high-coverage annotations, an output schema, and is part of a sibling group focused on hardware/report tools. The description adequately explains the search action and the public catalog scope. However, it doesn't describe what the output contains (though an output schema exists, reducing the burden), and it doesn't address data freshness or query constraints beyond maxLength. For a single-param lookup, this is minimally adequate but not thorough.

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 a single parameter (query) with 0% schema description coverage, meaning the JSON schema provides no semantic hints beyond type and length constraints. The description partially compensates by listing search dimensions (name, size, or Ollama tag), which gives the agent guidance on what 'query' can contain. However, this is minimal—it doesn't explain formatting, case sensitivity, or how multiple dimensions combine. Baseline 3 is reasonable given the low coverage but some added value.

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 'Cherche' (search) and the resource 'dans le catalogue public OutilsIA' with specific search dimensions (name, size, or Ollama tag). It also explicitly distinguishes itself from siblings by stating 'Ce n'est pas un scan', which is unique among the sibling tool names that revolve around reports, benchmarks, and hardware analysis.

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 states what the tool does and that it searches a specific public catalog, providing basic context. However, it does not specify when to prefer this over a sibling tool (e.g., when checking for model availability vs. analyzing a runtime report), nor does it mention any conditions for non-use or alternatives. The 'no invention of tokens/s' is a negative clarification but not a usage directive.

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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the description's main behavioral contribution is the negative clarification (not a scan/benchmark). The description does not disclose any additional behavioral traits such as expected output format, error handling, or whether the tool requires internet access. With annotations covering the safety profile, the description adds only marginal value.

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, no filler, front-loaded with the purpose. Every sentence adds value. It is appropriately sized for the tool's complexity.

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

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

Given the tool has 5 parameters, an output schema, and multiple siblings, the description is brief but covers the core purpose. However, it fails to explain the 'usage' and 'unified_memory' parameters, offers no examples, and does not clarify how the tool relates to siblings. It is adequate but has clear gaps.

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 0% for 5 parameters, so the description must compensate. It mentions three of the five parameters (OS, VRAM, RAM) but omits 'usage' and 'unified_memory', and does not explain the enum values for 'usage'. The description adds some meaning beyond the schema, but incomplete coverage leaves the agent guessing about the missing parameters.

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 action ('chooses a runtime path') and the key inputs (OS, VRAM, RAM), and it explicitly excludes other actions (installation, scan, benchmark). The title specifies the runtimes (Ollama, LM Studio, llama.cpp). However, it does not differentiate from sibling tools like check_pc_for_local_ai or list_models_for_budget, leaving some ambiguity about when to use this tool over those.

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 only provides negative guidance: what the tool is NOT (installation, scan, benchmark). It offers no positive guidance on when to use this tool vs. alternatives, no prerequisites, and no context about the recommended use case. This is insufficient for an agent to decide when to invoke 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safe read-only nature is covered. The description adds the useful behavioral detail that no recalculation happens and that the input must come from this app's OutilsIA tool, but it does not disclose anything about output format, validation, or error handling. Given the annotations, this is adequate but not rich.

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

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

The description is a single, tightly worded sentence that front-loads the core verb and behavior. Every word earns its place: it says what the tool does, what input it expects, and that it avoids recomputation.

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 a rich input schema, output schema, and annotations, so the description does not need to restate those details. It provides the missing context: the decision is a pre-existing OutilsIA output and no recalculation occurs. A small gap is the lack of any mention of what the rendered 'fiche' contains, but this is largely covered by the title and schemas.

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 only parameter, 'decision', has an extensive schema but zero schema-level descriptions. The description adds meaningful provenance ('produite par un outil OutilsIA de cette app') and tells the agent the object must already exist, not be computed. However, it does not explain the semantics of the many nested fields or the required schema_version, leaving the schema structure to carry most of the 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 states the specific verb 'Affiche' and the resource ('une décision produite par un outil OutilsIA'), and clarifies that it renders rather than recalculates. It does not explicitly name a sibling tool, but the 'sans recalculer' phrasing distinguishes it from the analysis and simulation tools in the sibling list.

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 clear context: use this tool when you already have a decision object produced by an OutilsIA tool and want to display it without recomputation. It does not explicitly list alternatives or exclusion cases, but 'sans recalculer' implicitly tells the agent not to use it for generating new decisions.

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?

Beyond the readOnlyHint annotation, the description explicitly states 'La simulation ne modifie rien' and adds a behavioral constraint: it must conclude no purchase is useful if the catalog shows no gain. This gives meaningful operational expectations, though it does not describe output structure, which is covered by an output schema.

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

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

Two sentences, each carrying distinct value: the first defines the comparison action, the second adds non-destructive behavior and decision logic. There is no filler or 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?

For a tool with nested profile object, an enum, and four parameters, the description conveys the core operation but omits context about when to use it and how the profile/usage parameters relate to the simulation. The presence of an output schema reduces the need to explain return values, but usage guidance is still missing.

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

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

With 0% schema description coverage, the description must compensate, and it partially does by linking 'hausse de RAM ou VRAM' to target_ram_gb/target_vram_gb and 'profil' to the profile object. It does not explain the 'usage' enum or the required profile subfields beyond what the schema itself encodes, leaving a notable gap.

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

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

The description states a specific action: compare the same hardware profile before and after a RAM/VRAM increase, which clearly identifies the tool's purpose. It is distinguishable from siblings like check_pc_for_local_ai through the 'simulation' framing, though it does not explicitly name any sibling to prevent confusion.

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

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

Usage is implied: an agent can infer this tool is for evaluating upgrade scenarios ('avant et après une hausse de RAM ou VRAM'). However, there is no explicit guidance on when to choose this tool over siblings such as explain_bottleneck or recommend_runtime, and no stated when-not-to-use conditions.

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