mcp-maven-deps

catalog_entry

Read-only

Generate rule-correct Gradle version-catalog entries or validate TOML for alias, version, and accessor errors, returning minimal diff suggestions.

Instructions

Generate or validate Gradle version-catalog (libs.versions.toml) entries. mode=generate builds a rule-correct [versions]/[libraries]/[plugins] snippet with kebab alias + libs/alias(libs.plugins.) accessor; mode=validate flags reserved aliases, invalid first subgroups, undefined version.ref, accessor clashes, id(libs.plugins.) misuse, and libs usage inside subprojects/buildscript. Returns a minimal diff suggestion, not a full file rewrite.

Input Schema

TableJSON Schema

Name	Required	Description
`kind`	No	Entry kind for generate. Default: library.
`mode`	Yes	generate a catalog entry from a coordinate, or validate catalog TOML (+ optional build script text).
`alias`	No	Optional preferred alias for generate; sanitized if it violates catalog rules.
`coordinate`	No	Required for generate. Maven GAV or plugin marker coordinate.
`catalogName`	No	Catalog accessor prefix for generate (default libs).
`catalogPath`	No	Optional path of the catalog file for validate path-convention checks (default gradle/libs.versions.toml).
`catalogToml`	No	Existing libs.versions.toml content. Used by validate; for generate, avoids alias clashes and enables version-only bump suggestions.
`projectPath`	No	Optional project root. In validate mode, reads gradle/libs.versions.toml when catalogToml is omitted.
`buildContent`	No	Optional build script text for validate — detects id(libs.plugins.*) misuse and libs accessors inside subprojects/buildscript.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`alias`	No
`entry`	No
`notes`	No
`accessor`	No
`violations`	Yes
`catalogPath`	No
`suggestedDiff`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.1.0Oct 6, 2026

TDQS

A3.9/5.0

Behavior4/5

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.

Conciseness4/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines3/5

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.