WPFormation : WordPress en français

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds genuine context beyond that: it is a free lite version (implying limited depth/possible upsell) and states the output signals. It omits any auth, rate-limit, or coverage-limit specificity.

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?

Three short sentences, front-loaded with the action and scope, then the limitation, then the return. No wasted prose, though the return-value sentence partly duplicates the output schema.

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

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

With an output schema present, return values need not be explained, and annotations cover safety; the description still conveys scope, tier, and output shape. Only the absence of any routing guidance toward sibling audit tools keeps it from a 5.

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

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

Schema description coverage is 100% with a single required 'url' parameter whose format (full URL or bare domain) is documented in the schema. The description adds nothing about parameter format, so baseline 3 applies.

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

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

States a specific verb (audite) and resource (une page) with an explicit scope enumeration: llms.txt, données structurées, contenu citable, E-E-A-T, compatibilité assistants IA. This clearly separates it from siblings like verifier_securite_plugin or detecter_wordpress, which audit 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 phrase 'version allégée gratuite' implies this is the lightweight entry point of an audit family, hinting at when to pick it, but no explicit when/when-not or named alternative tool is given. Usage must be inferred from the audit scope.

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, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description goes further by enumerating what the comparison returns (score /100, security verdict, unpatched vulnerabilities, per-category detail, installs, last update, user rating) and by scoping the tool to reliability rather than features, which is genuinely additive given no 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?

Front-loaded with the verb and the comparison target, then a compact enumeration of the returned metrics. It is dense but every clause carries information; the only redundancy is the count range already present in the schema.

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

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

With no output schema, the description usefully enumerates the returned metrics, and the input contract is fully covered by the schema. What remains missing is routing guidance against the sibling security/audit tools, which is a modest gap rather than a blocking one.

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 a single parameter and 100% schema description coverage, the schema already documents the slug array, its example format and the 2-4 item bounds. The description restates the count range but adds no format or syntax detail beyond the schema, so the baseline 3 applies.

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

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

States a specific verb (compare) and resource (2-4 WordPress plugins from the wordpress.org directory) and even clarifies the evaluative lens with 'Mesure la fiabilité, pas les fonctionnalités'. It is distinguishable from most siblings, though it never names the closely related verifier_securite_plugin, which a single-plugin security check would plausibly overlap with.

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 '2 à 4 plugins' bound implies the comparison use case, but there is no explicit when-to-use statement or exclusion versus alternatives like verifier_securite_plugin or auditer_agent_readiness. Usage is inferable but not spelled out.

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 readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds real behavior beyond that: detection is limited to what is externally visible ('repère ce qui est visible depuis l'extérieur') and the plugin inventory is explicitly never exhaustive, which tells the agent not to treat a short list as proof of absence. It does not describe failure behavior on unreachable domains.

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?

A single tight passage: the capability claim comes first, the detection targets are listed compactly after the colon, and the exhaustiveness caveat is placed last where it belongs. Every clause carries information and nothing is repeated from the schema or annotations.

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?

There is no output schema, so the description correctly carries the burden of enumerating return contents, which it does thoroughly (version, theme, parent theme, plugins, builder, hosting, CDN, headless). It also flags the key reliability caveat about plugin coverage. Minor gaps remain around response shape, error handling for unreachable sites, and the absence of explicit routing to alternatives.

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 one parameter at 100% schema description coverage, the schema already documents that the URL may be a full address or bare domain, with an example. The description's only contribution is the 'site public' qualifier, which hints at a reachability requirement but adds no syntax or format detail. Baseline 3 applies since the schema does the heavy lifting.

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

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

The description states a specific verb (detect) and resource (a public site's WordPress footprint) and then enumerates the exact artifacts it surfaces: version, theme and parent theme, page-code plugins, page builder, hosting, CDN, headless mode. That is far more concrete than a tautology, and it is clearly distinct from siblings like verifier_securite_plugin or comparer_plugins. It stops short of naming any sibling explicitly, so it does not fully earn 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?

Usage is only implied by the detection scope; there is no statement of when to reach for this tool versus radar_domaine (broader domain recon) or comparer_plugins (plugin comparison). The one implicit constraint is the word 'public', which rules out non-reachable or authenticated sites, but that is left for the agent to infer. Minimum viable 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?

Beyond the readOnly/idempotent annotations, it discloses non-obvious behaviors: redirect resolution to the replacement article, fallback to nearby articles for unknown addresses, and section-scoped extraction. These are exactly the runtime traits an agent cannot infer from 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?

Four dense sentences, front-loaded with what is read and followed by parameter/edge-case behavior. Efficient, though the final sentence packs multiple distinct cases together.

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 exists, and the description compensates by naming the returned fields plus edge-case outcomes (redirects, unknown addresses, non-article pages). An agent has enough to call it correctly and anticipate the response shape.

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 still adds value by explaining that section accepts an anchor, a sommaire number, or intertitre words, and that slug accepts either a bare slug or a full address including a #ancre form.

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 specific verb ('Lit') and resource ('un article WPFormation') and enumerates what is returned (titre, catégorie, dates, texte, sommaire des intertitres). A sibling like search_articles is implicitly distinguished by single-article-by-slug scope, though no sibling is named.

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?

Gives clear context for the section parameter (one part at a time, also via #ancre) and what the tool yields for categories, service pages, tools, redirected URLs and unknown addresses. It does not explicitly say when to prefer this over search_articles, so it falls short of the top score.

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, idempotentHint, openWorldHint and destructiveHint=false, so safety is covered. The description adds genuine behavioral context beyond that: findings are classified into green/orange/red with an associated action, which tells the agent what the output looks like and how to interpret severity.

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 dense, front-loaded sentences with zero filler: verb and resource first, then the covered areas, then the output classification. Every clause carries information.

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, read-only audit tool with no output schema, the description supplies the missing return-value context (classified findings with actions) that the annotations do not cover. It omits edge-case behavior (invalid/unreachable domains), which keeps it just short of 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 single 'domain' parameter is already documented with an example (exemple.fr) and note that a full address is accepted. The description adds no syntax or format detail beyond the schema, so the baseline 3 applies.

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

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

States a specific verb+resource ('Contrôle un nom de domaine') and enumerates the exact scope covered: registration details, DNS/hosting, email authentication (SPF, DKIM, DMARC) and HTTPS certificate. This clearly separates it from siblings like detecter_wordpress or verifier_securite_plugin, which operate on different 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 implies the use case (a domain-level health audit) through the enumerated checks, but never states when to prefer this over siblings such as detecter_wordpress or verifier_securite_plugin, nor any prerequisites. Usage is inferable but not explicit.

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 cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower; the description adds real behavioral context by disclosing the linguistic handling of queries (French preferred, English terms translated) and the breadth of indexed content. It does not describe result ordering or formatting.

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

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

Two dense sentences that front-load the scope; the parenthetical topic list is long but serves as useful keyword coverage. No filler sentences.

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 two-parameter search tool with no output schema, the description adequately conveys what is searched and the expected query language. Return format and ranking behavior are unspecified, but the annotations and schema carry most of the remaining burden.

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 only two parameters exist, both documented in the schema. The description reinforces the French-query convention already present in the schema but adds no new semantics for limit or query syntax, so baseline 3 applies.

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

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

States a specific verb ('Recherche') and resource ('contenus de WPFormation') and enumerates the content types covered (articles, plugin/theme sheets, pages, tools), which lets an agent distinguish it from get_article. It does not, however, explicitly name the sibling it is not (e.g., get_article for fetching a known article).

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?

Gives one piece of usage guidance — query in French, common English terms are translated — but offers no when-to-use framing relative to get_article or comparer_plugins. Usage is only implied by the tool's search semantics.

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, idempotentHint and openWorldHint, so safety profile is covered. The description adds genuine context beyond that: the data sources (WordPress.org, WPVulnerability), the scoring methodology (13 criteria across sécurité, maintenance, communauté, support) and the A-F grading scale, which tells the agent what kind of analysis backs the result.

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 dense sentences, front-loaded with the core action and input forms before the return detail. Every clause carries information (inputs, scoring scale, data sources), though the enumeration of return fields runs long and partly duplicates the output schema.

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

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

For a single-parameter, read-only lookup tool with an output schema, annotations and 100% schema coverage, the description supplies everything needed: input forms, scoring basis, data provenance and output shape. Nothing required to invoke it correctly is missing.

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

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

Schema description coverage is 100% and the single parameter already documents that it accepts a wordpress.org slug or a plugin name with examples. The description repeats that dual-input fact with parallel examples, adding confirmation but no new semantics. Baseline 3 is appropriate when the schema does the heavy lifting.

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

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

States a specific verb and resource ('Évalue la fiabilité d'un plugin WordPress') and narrows scope to single-plugin scoring by slug or name, which cleanly separates it from the sibling 'comparer_plugins'. The enumerated output (score /100, note A-F, 13 criteria, vulnerabilities, verdict) makes the deliverable unambiguous.

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

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

Implies usage by explaining the accepted inputs (wordpress.org slug or plugin name) and noting the same barème as the wpformation.com checker, but never states when to prefer this over siblings like comparer_plugins or what happens on an unknown plugin. Usage context is inferable rather than explicit.

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