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

Annotations only declare readOnlyHint and openWorldHint; the description adds substantive behavioral context beyond them, including the external OSV.dev query, the license categorization side effect, and the fact that onlyIssues filters dependencies while the summary still covers the full scanned set. It omits cost/latency characteristics of the network-heavy stages.

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 dense sentences, front-loaded with the orchestration summary before the optional flags. Every clause carries information, though the third sentence is long and stacks two flag behaviors into one breath.

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 and 100% schema coverage, the description need only cover orchestration and flag interactions, which it does. It stops short of noting network/auth implications or that stages can partially fail, but nothing essential for correct invocation 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 coverage is 100%, so baseline is 3, but the description goes further by defining the meaning of includeLicenses output (newLicenseCategories as categories unique in the scanned set) and clarifying onlyIssues semantics relative to the summary. That is real added meaning beyond the schema text.

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 names a specific verb and resource and enumerates the orchestrated steps: build-file scan, update check, optional OSV.dev vulnerability query. It is clearly a composite/full-audit tool, but it never contrasts itself with the close sibling scan_project_dependencies, so an agent must infer the difference.

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 by the framing as a 'full dependency audit' with optional stages, and the flag descriptions hint at cost tradeoffs. However, there is no explicit when-to-use-this-vs-alternative guidance and none of the many granular siblings (check_multiple_dependencies, get_dependency_vulnerabilities, scan_project_dependencies) are referenced.

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 readOnlyHint=true already declared, the description adds meaningful context: it enumerates the exact validation checks performed (reserved aliases, invalid first subgroups, undefined version.ref, accessor clashes, id(libs.plugins.*) misuse, libs in subprojects/buildscript) and clarifies that the output is 'a minimal diff suggestion, not a full file rewrite', which tells the agent nothing on disk is modified.

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 core purpose and efficiently structured across three sentences. The long enumeration of validate checks is dense but each item conveys a real behavioral fact; minor verbosity only.

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 9-parameter tool with a nested object and an output schema, the description adequately covers purpose, mode behavior, and the nature of the result. It correctly avoids over-explaining return values, leaving only edge-case usage guidance as a 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?

Schema description coverage is 100%, so every parameter is already documented in the schema. The description restates mode and coordinate semantics but adds no syntax/format detail beyond the schema, so the 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?

States specific verbs (generate/validate) and a specific resource (Gradle version-catalog libs.versions.toml entries). This is clearly distinct from all siblings, which query dependency/version/security data rather than author or check a catalog file.

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 two modes and what each does (generate a snippet vs validate catalog TOML + build text), which implies when each applies, but gives no explicit when-to-use guidance or alternatives relative to sibling tools. Usage is left to inference.

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 only declare readOnlyHint and openWorldHint, so the description carries the interesting behavior: it discloses the verdict taxonomy, that missing license metadata degrades to review rather than a false ok (a fail-safe default), and that the result is a heuristic policy signal rather than legal advice, pointing to notes[]. It omits any rate-limit or pagination context for the external deps.dev calls.

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-loads the operation and scope, then layers in verdicts, the fail-safe rule, and the legal disclaimer in short sentences. The opening sentence is dense but every clause carries information; nothing is filler.

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 spelled out, yet the description still surfaces the verdict semantics and notes[] pointer. Combined with annotations covering the read-only profile, an agent has enough to call it correctly; only cross-sibling routing 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%, so all three parameters (dependencies, projectLicense, disallow) are already documented, including that disallow replaces the default set entirely. The description reinforces the disallow/projectLicense relationship but adds no syntax, format, or default details beyond the schema; 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 (aggregate/flag) and resource (SPDX licenses across the transitive closure of Maven GAVs), and names the underlying deps.dev endpoints. It is distinguishable from the single-artifact sibling get_dependency_license by its transitive-closure scope, but no sibling is named explicitly to route the agent.

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 through the two policy modes (projectLicense posture vs explicit disallow list) and the ok/review/violation verdicts, but there is no explicit when-to-use-this-vs-alternative guidance against siblings like get_dependency_license or audit_project_dependencies, and no stated prerequisites.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety and network-reaching profile is covered. The description adds nothing about how the latest version is resolved (repository access, failure behavior for unknown coordinates), leaving behavioral gaps that annotations do not fill.

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 front-loaded sentence with zero filler; the verb+scope appear immediately and nothing is repeated from 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?

An output schema exists, so return values need not be explained, and both parameters are fully documented. The only shortfall is the absence of routing guidance against the many sibling version-lookup tools, which is minor given the low complexity of the operation.

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

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

Schema description coverage is 100%, so the schema already explains projectPath, groupId/artifactId, and the no-version-needed contract. The description adds no format or syntax detail beyond what the structured fields provide, making the baseline 3 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?

States a specific verb ('Batch lookup of latest versions') and resource ('Maven dependencies'), and the word 'multiple'/'Batch' implicitly separates it from the sibling get_latest_version. It stops short of naming that sibling explicitly, so an agent must infer the single-vs-batch split.

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 through 'Batch' and 'multiple' — an agent can infer this tool is for several coordinates at once, but the description never states when to prefer it over get_latest_version or compare_dependency_versions. No exclusions or prerequisites are 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?

Annotations only declare readOnlyHint and openWorldHint, so the description must carry the rest, and it does: it discloses that v1 coverage is intentionally bounded, that matrices are not scraped at runtime and require manual refresh via compat-matrices.json, and that limitations surface in notes[]. That is meaningful behavioral context beyond the annotations, though it does not discuss auth or rate limits.

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

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

The purpose is front-loaded in the first sentence, followed by the numbered validation list and the scope caveat. Dense but every sentence carries information; the numbered clauses are slightly long but earn their place.

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 multi-check validation tool with an output schema already present, the description covers what is validated, the conditional triggering of each check, the static-matrix limitation, and where limitations are reported (notes[]). Nothing needed to call 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 coverage is 100%, so the baseline is 3, but the description adds real semantic linkage beyond the schema: it explains that springBoot expands the BOM and enables javax→jakarta checks at ≥3.0.0, and that android versions are validated against shipped matrices. It clarifies cross-parameter effects the schema only hints at.

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 ('Check whether a set of versions is mutually compatible') and then enumerates the three distinct validations it performs (Spring Boot BOM, AGP↔Gradle↔JDK/KGP matrix, javax→jakarta). This clearly separates it from siblings like check_multiple_dependencies or check_version_exists, which only test existence.

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 conditional activation ('when springBoot is set', 'when Spring Boot ≥ 3'), which implies usage context, but it never explicitly says when to prefer this tool over siblings such as detect_dependency_conflicts or check_multiple_dependencies, nor does it name any alternative. Usage is inferred rather than directed.

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 and openWorldHint, so the safety profile is covered. The description adds real value by disclosing the resolution order (declared repositories first, then Maven Central / Google Maven / Gradle Plugin Portal fallback), which an agent could not infer from the annotations or 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?

A single front-loaded sentence that states the core purpose first, followed by the resolution detail. The trailing parenthetical is somewhat dense but every clause carries information; nothing is wasted.

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 existence check with an output schema, full parameter coverage, and annotations, the description covers the essential non-obvious behavior (repository resolution order and public fallback). Nothing critical to calling it correctly appears to be 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%, so the schema already documents all four parameters. The description reinforces the role of projectPath in resolving repositories and clarifies the fallback behavior, but adds little meaning beyond the existing parameter descriptions.

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

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

States a specific verb (check existence) and resource (a specific version of a Maven artifact), with the scope of the search made explicit. This clearly distinguishes it from siblings like get_latest_version and check_version_compatibility.

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 repository resolution and fallback behavior, which implies when this check is appropriate, but it never explicitly routes the agent between this and sibling tools such as get_latest_version or check_version_compatibility. Usage is implied rather than stated.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, covering the safety profile. The description adds the behavioral detail that results are classified into upgrade types (major/minor/patch), which is useful, but discloses nothing about network/repository access, auth needs, or rate limits beyond the openWorld hint.

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 well-formed sentence that front-loads the action and its result with no filler. It is appropriately sized, though its brevity means the usage context is entirely omitted.

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 a full output schema and safety annotations, the description's coverage of purpose and output is adequate for a read-only comparison tool. It falls short on usage context and alternative routing, which matter given the dense set of version-related siblings.

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 both parameters and the nested dependency fields are fully documented in the schema. The description adds no syntax or format detail beyond it (e.g., how to handle the default projectPath or version formatting), 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?

The description names a specific verb (compare) and resource (dependency versions) and states the output (upgrade types major/minor/patch), so the agent knows exactly what the tool produces. It does not, however, distinguish itself from siblings like get_latest_version or check_multiple_dependencies, which also handle version 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?

There is no when-to-use guidance, no when-not-to-use, and no named alternative despite several closely related siblings (get_latest_version, get_dependency_changes, compare_upgrade_closure). The agent must infer the routing from the description alone.

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

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

Annotations declare readOnlyHint=true and openWorldHint=true, so safety profile is known. The description adds valuable non-obvious behavior: two sequential Gradle resolves with up to 20 substitutions, Gradle does not fall back to deps.dev, deps.dev is an isolated public graph not a project resolve, and advisory is not a safety verdict. These are strong additions beyond 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?

Front-loaded with the core action, then dense behavioral caveats. Every sentence conveys a distinct constraint (graphSource defaults, Gradle vs deps.dev, advisory caveat). No wasted words, though the advisory caveat could be slightly clearer in placement.

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. The description covers the key behavioral quirks an agent needs: graph source selection, fallback rules, upgrade limits, and advisory interpretation. Missing explicit when-to-use guidance against siblings, but otherwise sufficient for a moderately complex 7-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?

Schema description coverage is 100%, so the schema already documents all seven parameters including the graphSource auto behavior, substitution modes, and upgrades limits. The description reinforces but does not add new syntax or format details beyond what the schema provides. Baseline 3 is appropriate when the schema carries the load.

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?

Specific verb and resource: compares a direct upgrade's closure before/after a candidate version. Distinguishes itself from siblings like compare_dependency_versions or get_transitive_graph by focusing on before/after closure of a single upgrade. An agent can tell what it does without opening the schema.

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 graphSource selection logic and limits, which implicitly tells when each mode is used, but it never says when to use this tool versus siblings like compare_dependency_versions or get_transitive_graph. Usage context is implied by the compare-before-after framing, not explicitly stated.

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

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

Annotations cover safety (readOnlyHint=true, openWorldHint=true). The description adds valuable context beyond them: it discloses that results are an 'approximation of a full project resolve' and points to notes[] for limitations, and it explains the mediation logic (nearest-wins vs highest-wins) that shapes the reported pick. This goes meaningfully beyond the structured fields.

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 dense sentences, front-loaded with the core action and mechanism, with the approximation caveat last. Every sentence carries information; the only minor cost is jargon density (GAs, mediation), which is acceptable for a developer-facing tool.

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?

An output schema exists so return values needn't be explained, and the description covers mechanism, output semantics (which version wins), and limitations via notes[]. Given the tool's moderate complexity and full annotation/schema coverage, this is nearly complete; only explicit sibling routing 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%, so both parameters are already documented in the schema. The description's mention of Maven nearest-wins and Gradle highest-wins loosely reinforces the buildSystem parameter's purpose, but adds no syntax or format detail beyond what the schema provides. Baseline 3 is appropriate.

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

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

States a specific verb+resource (detect version conflicts) and goes further by explaining the mechanism: unioning deps.dev transitive graphs for each direct dependency and flagging GAs at ≥2 versions. This clearly differentiates it from siblings like get_transitive_graph (which returns a graph) and scan_project_dependencies (which scans a project).

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 usage context (conflict detection with mediation strategy reporting) but never explicitly states when to choose this over alternatives such as check_multiple_dependencies, get_transitive_graph, or audit_project_dependencies. No when-not conditions or named alternatives are provided, so the agent must infer routing.

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 cover the safety profile (readOnlyHint=true) and openness (openWorldHint=true). The description adds meaningful behavioral detail beyond that: it discloses recursion into import-scope BOMs and conflict resolution via first-wins ordering, which an agent needs to interpret results.

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 tightly written sentences with zero filler. The core action is front-loaded, and the behavioral qualifier (recursion, ordering) follows immediately.

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 and full schema coverage, the description need not explain return values. It covers purpose and key resolution behavior adequately, though it omits any usage context or repository-resolution caveats for projectPath.

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 all four parameters (groupId, artifactId, version, projectPath) are already documented in the schema. The description adds no parameter-level detail, which is acceptable given 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 (expand) and resource (Maven BOM), and clarifies the outcome (managed dependency versions). The purpose is unambiguous and no sibling tool overlaps with BOM expansion, though it does not explicitly differentiate itself from the many other dependency tools.

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

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

The description explains what the tool does but gives no guidance on when to use it versus alternatives like get_transitive_graph or scan_project_dependencies. There is no when-to-use, when-not-to-use, or prerequisite information.

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 and openWorldHint, so safety and reach are covered. The description adds the source-resolution fallback order (AndroidX/AGP docs first, else GitHub releases), which is genuine behavioral context, but omits auth needs, rate limits, or failure behavior when neither source applies.

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, front-loaded sentence that states purpose first and qualifiers second. The parenthetical source clause is slightly dense but earns its place by explaining where the changelog comes from.

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?

An output schema exists, so return-value documentation is unnecessary, and the read-only/open-world annotations cover the safety profile. The description adequately covers the operation and its source resolution; only explicit usage guidance is absent.

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 all five parameters (including the exclusive fromVersion and inclusive toVersion semantics) are already documented in the schema. The description adds only the phrase 'between two versions,' which does not extend meaning beyond the schema. 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 and resource: retrieving changelog/release notes between two versions, with source detail (AndroidX/AGP docs vs GitHub releases). It is clear what the tool returns, though it does not explicitly contrast itself against siblings like get_latest_version or compare_dependency_versions.

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 when-to-use, when-not-to-use, or alternative-tool guidance is provided. The description merely describes output content and source resolution, leaving the agent to infer when this tool is preferable to its many siblings.

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

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

Annotations cover safety (readOnlyHint, openWorldHint), but the description adds real behavioral depth beyond them: the OpenSSF Scorecard is only surfaced when the GitHub repo is known, and it is omitted or flagged with capabilityUnavailable when deps.dev has no scorecard for the repo, is offline, or unreachable. This degradation behavior is valuable context an agent could not derive from the 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 core purpose in the first sentence, with supporting detail on the scorecard capability second. The em-dash clause is dense but information-bearing rather than 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?

An output schema exists, so return-value documentation is not required, yet the description still sketches the scorecard shape. For a read-only aggregation tool this is nearly complete; the only gap is guidance on how it relates to the many sibling inspection tools.

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 projectPath and the dependency coordinates/version are already documented in the schema. The description adds only marginal parameter meaning ('when the GitHub repository is known' implies repo resolution), so the 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?

States a specific verb and resource ('Get health signals for Maven dependencies') and enumerates the concrete signal categories returned: version info, GitHub activity, issue stats, license, maintenance signals. It is clear what the tool does, though it does not explicitly distinguish itself from overlapping siblings such as get_dependency_license or get_latest_version.

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 never states when to reach for this tool versus the many overlapping siblings (get_dependency_license, get_dependency_vulnerabilities, get_latest_version). It explains capability and failure modes but offers no usage conditions or exclusions, leaving the agent to infer selection.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds real behavioral context beyond that: data comes from POM <licenses> plus optional GitHub license metadata, and the category mapping is a static lookup with no external license API call. That last point is especially useful because it clarifies what the openWorldHint does and does not imply at runtime.

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, zero filler, front-loaded with the core purpose before the source/provenance caveat. Every clause carries information the agent can act on.

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?

An output schema exists, so return values need not be described, yet the description still usefully summarizes them. Safety is covered by annotations and data sources are explained. Minor gaps remain around error/unknown-license behavior and batch-scale expectations, but nothing essential to calling 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%, so the schema already documents projectPath, dependencies, groupId, artifactId, and the optional version. The description adds only indirect hints about resolution behavior (POM/GitHub sources) and does not explain the 100-item batch limit or how a missing version is resolved beyond what the schema states. 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 names a specific verb and resource ("Resolve license intelligence for Maven dependencies") and enumerates exactly what it returns: SPDX id, category taxonomy, plain-English notes, and provenance source. This output enumeration implicitly separates it from the compliance-oriented sibling check_license_compliance, so an agent can distinguish it without opening either schema.

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 by the purpose (use it when you need license info for Maven coordinates) but there is no explicit when-to-use, when-not-to-use, or named alternative such as check_license_compliance or get_dependency_health. The agent must infer the boundary itself.

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?

Goes well beyond the readOnlyHint/openWorldHint annotations: it explains that an empty list is not a safety guarantee (incomplete OSV coverage, reporting lag), that safeUpgrade is synthesized from fixed-version data and is advisory-only, and that fixesAllKnown=false signals an unfixed CVE. These are exactly the interpretive caveats an agent needs to avoid over-claiming 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?

Front-loads the purpose before the caveats, and every sentence carries substantive meaning (version pinning, empty-list semantics, safeUpgrade advisories). The safeUpgrade sentence is dense and clause-heavy, but it is load-bearing rather than filler.

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?

An output schema exists, so return values need not be re-specified, yet the description still supplies the interpretation rules (empty = no advisory, not safe; safeUpgrade = verify, not a guaranteed pin). For a vulnerability tool whose results are easy to misread, this is 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 description coverage is 100%, so both parameters are already documented. The description reinforces the pinned-version requirement and notes version-less coordinates are not queried, but adds no syntax or format detail beyond what the schema states — 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 (Check) and resource (dependencies for known vulnerabilities) and names the data source (OSV.dev), which meaningfully separates it from generic scanners. It never names a sibling such as get_vulnerability_paths or audit_project_dependencies, so an agent still has to infer which related tool applies, keeping it short of 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?

It supplies a real usage precondition (each dependency needs a pinned version, version-less coordinates are not queried), which is genuine when-to-use guidance. However there is no when-not or explicit alternative — nothing tells the agent to prefer scan_project_dependencies or get_vulnerability_paths in a given situation.

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 and openWorldHint, so safety is covered. The description adds real behavioral detail beyond that: per-item error surfacing instead of whole-call failure, cycle-granularity variance by product, and the fact that JDK is always vendor-specific. It stops short of describing rate limits or caching, but adds solid 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?

Front-loaded with purpose and the required-argument rule, then the vendor caveat, then matching/reporting behavior. Dense and every sentence carries information, though the final error-handling sentence and the cycle-granularity clause make it longer than strictly necessary.

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 fields need not be enumerated; the description still clarifies what is reported per cycle (isEol/eolDate/isMaintained/isLts/latestInCycle). Combined with the vendor and cycle-matching explanations, an agent has everything needed to call it correctly.

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

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

Schema coverage is 100%, so the baseline is 3. The description earns above that by explaining semantics the schema cannot: why jdk requires an explicit vendor (no generic 'java' product), and how each version maps to a release cycle with product-dependent granularity (major vs major.minor).

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?

Names a specific verb ('Check end-of-life / support status') and concrete resources (JDK, Kotlin, Gradle, Spring Boot) via endoflife.date. No sibling tool covers EOL/support status, so the scope is unambiguous against the list of version/dependency tools.

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

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

States the invocation constraint clearly ('at least one is required') and explains the vendor requirement for JDK. It doesn't name a sibling alternative or an explicit when-not-to-use, but the context for when this tool applies 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 already declare readOnlyHint=true and openWorldHint=true, so the agent knows this is a safe read against external repositories; the description's naming of the three remote sources is consistent and mildly reinforcing. However it adds nothing about network/latency behavior, resolution order when an artifact exists in multiple sources, or how the stability filter affects results.

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 well-formed sentence, front-loaded with the verb and outcome and with no wasted words. It is efficient, though its brevity is partly the result of omitting usage and behavioral detail rather than of tight editing.

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?

An output schema exists (so return values need not be explained) and annotations cover the safety profile, which lowers the burden. Still, for a resolver that queries three different repositories, the description omits how sources are prioritized and how projectPath interacts with repository resolution, leaving gaps an agent might need.

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 all four parameters (groupId, artifactId, projectPath, stabilityFilter) are already documented, including the enum values. The description adds no extra semantics such as coordinate format examples or what PREFER_STABLE actually does, so the baseline of 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?

Clear verb (get) and resource (latest version of a Maven artifact) with explicit scope (Maven Central, Google Maven, Gradle Plugin Portal). It distinguishes itself functionally from siblings like check_version_exists or compare_dependency_versions, but it never names an alternative, so the differentiation is implicit rather than stated.

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?

There is no guidance on when to use this tool versus the many version-related siblings (check_version_exists, compare_dependency_versions, check_version_compatibility). No prerequisites, no exclusions, and no mention of how repository sources interact are 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?

Annotations declare readOnlyHint and openWorldHint, so the safety profile is covered; the description goes further and discloses degraded-mode behavior — partial results flagged when deps.dev is unreachable, errors, or truncation by a node cap. This is exactly the kind of context annotations cannot carry. It stops short of describing pagination or how partials are surfaced in the payload.

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 tight sentences: capability first, output shape second, failure/degradation behavior last. Every sentence carries distinct information and there is no filler.

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?

An output schema exists, so return values need not be documented, yet the description usefully sketches nodes (g/a/v) and edges (from/to indices) plus the node-cap truncation caveat. Combined with the safety annotations this is nearly complete; the missing piece is guidance on when this graph tool beats the sibling comparison/expansion tools.

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 three required, self-explanatory parameters (groupId/artifactId/version), so the schema does the heavy lifting and baseline 3 applies. The description's 'GAV' shorthand confirms the parameter roles but adds no format or syntax detail 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?

States a specific verb and resource ('Fetch the resolved transitive dependency graph for a Maven GAV') and names the upstream source (deps.dev GetDependencies). It implies a distinction from siblings like expand_bom and compare_upgrade_closure by emphasizing the raw node/edge graph, though it never names a sibling to sharpen the boundary.

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 statement of when to choose this over expand_bom, compare_upgrade_closure, or check_multiple_dependencies, and no prerequisites (e.g., whether version must be resolved first). The agent must infer usage from the purpose alone.

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

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

Annotations only supply readOnlyHint and openWorldHint; the description adds substantial context beyond them: an empty vulnerabilityPaths list means no known vulnerability rather than a safety guarantee, partial results are flagged under three specific failure conditions (deps.dev/OSV unreachable, node-cap truncation, unique-dependency count truncated before OSV querying). That is exactly the kind of caveat an agent needs to interpret results correctly.

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 core behavior is front-loaded in the first sentence, with caveats trailing afterward. It is dense but each clause carries information (mechanism, output meaning, partial-result conditions); only minor trimming is possible.

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 explain the return shape, and it correctly focuses on interpretation semantics (empty list meaning, partial-result flags) and external dependency caveats. For a 3-param read-only tool with rich annotations, nothing material 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 all three required GAV parameters are documented in the schema, so the baseline of 3 applies. The description characterizes the input as a 'project root Maven GAV' but adds no per-parameter syntax, format, or constraint detail beyond what the schema already states.

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 precise verb and resource — 'Show the dependency path from a project root Maven GAV to each vulnerable transitive node' — and names the exact mechanism (deps.dev graph + OSV.dev advisories). It is clearly distinguishable from siblings like get_transitive_graph (raw graph) and get_dependency_vulnerabilities (flat list), since the output is a shortest root-to-node path per vulnerable dependency.

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 frames the use case crisply ('so a CVE deep in the tree can be traced back to which direct dependency pulls it in') and cross-references the sibling get_dependency_vulnerabilities for the shared OSV coverage caveat. It stops short of an explicit 'use this instead of X when Y' statement, so it is clear context without formal alternatives 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 declare readOnlyHint and openWorldHint, so safety is covered. The description adds genuine context beyond them: it explains that BOM/platform managed versions are applied and that this involves a network POM fetch, which tells the agent why the operation may be slow or require connectivity. It omits failure modes and offline behavior.

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 tight sentences with the core action front-loaded. The managed-version/network detail is dense but domain-relevant and earns its place.

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?

An output schema exists, so return shape need not be explained. For a single-parameter read-only scan, the description covers the source formats and the BOM resolution mechanism; only error/offline behavior is unaddressed.

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

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

Only one parameter and schema description coverage is 100%, so the schema already documents projectPath and its default. The description adds nothing about the parameter, so the baseline of 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: 'scan a local project directory to extract declared dependencies from build files (Gradle, Maven)'. It is meaningfully distinct from sibling get_transitive_graph or audit_project_dependencies. It does not explicitly differentiate itself from audit_project_dependencies, which sounds adjacent.

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 when-to-use guidance, no prerequisites, and no alternatives named among the many dependency-analysis siblings. Usage is only implied by the phrase 'local project directory'.

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/openWorldHint annotations, it discloses meaningful runtime behavior: default backend selection, closed/offline mode fallback routing, and the MAVEN_MCP_REPOSITORY_BASE / mirrors context. It does not mention auth requirements or rate limits, so it stops short of full behavioral coverage.

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, front-loaded with the core purpose before the routing detail. Reasonably tight, though the second sentence is dense with technical terms and could be split for readability.

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 described. The description covers the search action and backend selection well; minor gaps remain around what results contain and any auth/prerequisite context, but overall it is complete enough for an agent to call correctly.

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

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

Schema description coverage is 100%, so the schema already documents all four parameters including the repositoryType enum and the groupId:artifactId coordinate format. The description reinforces 'by keyword' and the closed-mode routing but adds little parameter detail beyond the schema, matching the baseline 3.

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

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

States a specific verb and resource: 'Search Maven artifacts by keyword,' which is concrete and clearly distinguishable from the version/vulnerability/license siblings. It lacks explicit naming of an alternative tool, but the purpose itself is 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?

The description explains backend routing ('Uses Maven Central Solr by default; in closed/offline mode ... routes to Nexus 3 REST or Artifactory'), which implies when each path applies, but it gives no explicit when-to-use guidance relative to sibling tools. Usage is only implied.

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?

Goes well past the readOnlyHint/openWorldHint annotations by disclosing the tri-state outcome space, the important caveat that existence is NOT a safety guarantee (a published typosquat still reports exists and is unflagged), and the non-authoritative nature of suggestions. This is exactly the behavioral context an agent needs to interpret results without over-trusting them.

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 tight sentences, front-loaded with the core action and tri-state result, followed by two caveats that each earn their place. No filler or restatement of the title.

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 explain return shapes; it instead covers the interpretive gaps (tri-state meaning, typosquat blind spot, suggestion semantics) that an agent could otherwise misread. Nothing needed for correct invocation 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%, so the baseline is 3; the description adds value by tying the suggestion output to the absent state and reinforcing that version is optional per item and only affects exact-version existence checks. It does not add syntax or format detail 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?

States a specific verb and resource (verify Maven coordinates for existence) and immediately pins down the return semantics as tri-state (exists / absent / unknown). It also carves out a distinct niche versus siblings like check_version_exists and check_multiple_dependencies by declaring its hallucination/slopsquat-detection intent and did-you-mean suggestions.

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 intended context is clear: catching names an LLM may have invented, and treating suggestions as candidates to verify rather than endorsements. However, it never names an alternative tool or states an explicit when-not-to-use condition, so the agent must infer routing from the sibling list.

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