DEV Community: Arvind Menon

Guided Delegation: Adding Context7 Documentation to My Maven Tools MCP Server

Arvind Menon — Wed, 06 Aug 2025 17:50:44 +0000

How guided delegation bridges dependency analysis with up-to-date docs.

A while back I wrote about building a Maven Central MCP server so Claude / Copilot can answer the boring dependency questions straight from Maven Central.

It worked well for “what version should I be on?”

On major upgrades, updating the POM was only part of the work. Breaking changes could still leave me searching through documentation and fixing the resulting build failures. I wanted the assistant to have that documentation available while working through the upgrade.

The Gap: From “What to Upgrade” to “How to Upgrade”

My Maven tools can tell you things like:

What the latest stable version is
Whether an update is major/minor/patch
Which dependencies are aging or stale

That gets you to a decision. It doesn’t get you through the upgrade.

For anything non-trivial you still end up hunting for the right migration guide or “breaking changes” doc. And if the assistant falls back to generic web search, you quickly get stale or out-of-context advice.

That's where Context7 fits in. It retrieves indexed library documentation, including version-specific documentation where it's available. The assistant still needs to check that the result covers the version being targeted. If it doesn't, it can look for the project's migration guide or release notes using its own web-search tools, if available.

So the real problem became: how do I combine “Maven intelligence” with “current docs” without jamming everything into one big server?

The Approach: Guided Delegation

I didn’t want to re-implement Context7 inside my project. I just wanted a clean workflow:

Maven Tools does the analysis (versions, stability, update type)
If it looks like a potentially painful upgrade, it returns an extra field with explicit orchestration instructions
The assistant uses those instructions to call Context7 tools (or fall back to normal web search)

The Maven analysis returns hints for the next documentation lookup. The assistant decides whether to follow them. With Context7 enabled, Maven Tools also exposes its documentation tools through the same server, forwarding those calls to Context7. The analysis doesn't automatically run the documentation lookup. That's what I mean by guided delegation.

Implementation: Dual MCP Architecture with Spring AI

This ended up being mostly configuration.

1) Wire Context7 as an MCP client

In src/main/resources/application.yaml I enable the MCP client and tool callback, and point it at Context7:

spring:
  ai:
    mcp:
      client:
        enabled: true
        type: ASYNC
        request-timeout: 15s
        toolcallback:
          enabled: true
        streamable-http:
          connections:
            context7:
              url: https://mcp.context7.com/

context7:
  enabled: true

With that, Spring AI connects to Context7 and exposes its tools alongside my Maven tools.

2) Add “guidance hints” to the response models

On the Maven side, I don’t call Context7 directly. I just include a context7_guidance field when Context7 is enabled.

Here’s the rough shape of the tool method (trimmed down, but with the real parameters):

@Tool(description = "Bulk upgrade check (versions REQUIRED in input).")
public ToolResponse compare_dependency_versions(
    String currentDependencies,
    @Nullable StabilityFilter stabilityFilter,
    @Nullable Boolean includeSecurityScan) {
  return executeToolOperation(() -> {
    // ... compare versions, optionally scan with OSV
    return new VersionComparison(Instant.now(), results, summary, securitySummary);
  });
}

And the per-dependency comparison result can include a guidance block like this:

{
  "comparison_date": "2026-01-06T12:00:00Z",
  "dependencies": [
    {
      "dependency": "org.springframework.boot:spring-boot-starter",
      "current_version": "2.7.0",
      "latest_version": "3.2.0",
      "update_type": "major",
      "update_available": true,
      "context7_guidance": {
        "orchestration_instructions": "Use resolve-library-id tool with query='spring-boot-starter migration guide breaking changes' and libraryName='spring-boot-starter' to find the library ID. Then use query-docs tool with the returned libraryId and query='spring-boot-starter migration guide breaking changes' to get upgrade instructions. If Context7 doesn't provide sufficient information, perform a web search for 'spring-boot-starter major version upgrade guide'."
      }
    }
  ],
  "update_summary": { "major_updates": 1, "minor_updates": 0, "patch_updates": 0, "no_updates": 0 }
}

That string looks a bit verbose on purpose: it’s meant to be copy-pasteable instructions for the model, not a nice message for humans.

Setup Notes

If you’re running the Docker image, you don’t need a separate Context7 server. The container will call out to https://mcp.context7.com/.

If your network blocks it, the README documents a Context7-free image: arvindand/maven-tools-mcp:latest-noc7
There’s also a profile that disables the MCP client entirely (see src/main/resources/application-no-context7.yaml)

What Changed for Me

The practical difference is that a major upgrade conversation doesn’t stall out after “this is a major update”. The assistant can immediately pull the right docs and keep going.

Also: keeping this as “compose tools + add orchestration hints” felt a lot cleaner than turning Maven Tools into a documentation scraper.

If you try it, I’m curious about two things:

Are the context7_guidance instructions actually helpful in your upgrade scenarios?
Where do they fall short (too generic, too verbose, wrong query phrasing, etc.)?

Check out the repo if you haven't yet - github.com/arvindand/maven-tools-mcp.

About the Author: I'm a software architect at Rockwell Automation. I write about architecture, developer tooling, and the use of AI in software engineering. You can find me on GitHub or LinkedIn.

Updated September 2026 to clarify tool behaviour and limitations.

How I Connected Claude to Maven Central (And Why You Should Too)

Arvind Menon — Sat, 26 Jul 2025 22:53:22 +0000

A Spring developer's journey into the Model Context Protocol

I've spent almost a decade building and maintaining Spring/JVM systems in enterprise environments. As I've started learning more about AI—and integrating it into my daily workflows—I had a simple idea: use what I already know (Spring) to shave off the small, annoying bits of daily dev work.

Lately I've been trying to use AI for the parts of development that are mostly "mechanical". One of the first places I felt it: dependency lookups in bigger projects.

In a bigger codebase it's rarely one lookup. It's the same loop repeated across a long list of libraries: search the artifact, find the latest stable version, check whether it's still actively maintained, maybe skim for CVEs… and move on to the next one.

None of that is complicated. It's just time.

When I came across the Model Context Protocol (MCP)—a standard for giving AI assistants access to tools—I realized I could turn that loop into something Claude (or GitHub Copilot) could do directly. Same answers, fewer tabs, and I stay in the editor.

That's how Maven Tools MCP Server happened. It's not meant to replace Dependabot, Renovate, or the kind of CI/CD setup you need for compliance and automated updates. This is for the "I just need to know what's going on with my dependencies right now" moments—through the AI assistant you're already using.

What It Looks Like

Before the technical bits, here's what this looks like in real life. Instead of opening a pile of browser tabs, I paste my build file and ask:

"Check all these dependencies for updates, but only show me stable versions since this is going to production"

The assistant checks the dependencies, tells me what needs attention, and groups available updates as major, minor, or patch. Those categories help me decide what to investigate; they don't guarantee compatibility.

The Technical Challenge (And Why Spring Made It Easy)

Building an MCP server sounds like one of those "cool idea, lots of plumbing" projects. Spring Boot made it much less painful than I expected. The main job was building a bridge between AI assistants and Maven Central's API that can:

Work across JVM build tools because everything ultimately maps to Maven coordinates (Maven/Gradle/SBT/Mill)
Process bulk requests efficiently
Classify versions intelligently (stable/RC/beta/alpha/milestone)
Cache aggressively since dependency data doesn't change that often

Here's what the foundation looks like:

<dependencies>
    <!-- Spring AI's MCP support -->
    <dependency>
        <groupId>org.springframework.ai</groupId>
        <artifactId>spring-ai-starter-mcp-server</artifactId>
    </dependency>

    <!-- Optional MCP client integration (e.g., exposing Context7 tools) -->
    <dependency>
        <groupId>org.springframework.ai</groupId>
        <artifactId>spring-ai-starter-mcp-client-webflux</artifactId>
    </dependency>

    <!-- Spring cache abstraction -->
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-cache</artifactId>
    </dependency>

    <!-- Caffeine for caching -->
    <dependency>
        <groupId>com.github.ben-manes.caffeine</groupId>
        <artifactId>caffeine</artifactId>
    </dependency>

    <!-- Maven's own version comparison logic -->
    <dependency>
        <groupId>org.apache.maven</groupId>
        <artifactId>maven-artifact</artifactId>
    </dependency>
</dependencies>

With Spring AI's MCP support, you expose methods as tools and let the starter handle the protocol:

@Service
public class MavenDependencyTools {

    @Tool(description = "Single dependency. Returns newest versions by type (stable/rc/beta/alpha/milestone).")
    public ToolResponse get_latest_version(
        @ToolParam(description = "Maven coordinate like 'org.springframework:spring-core'")
        String dependency,
        @ToolParam(description = "Stability filter (ALL, STABLE_ONLY, PREFER_STABLE)", required = false)
        @Nullable StabilityFilter stabilityFilter) {

        return executeToolOperation(() -> {
            MavenCoordinate coordinate = MavenCoordinateParser.parse(dependency);
            List<String> allVersions = mavenCentralService.getAllVersions(coordinate);

            if (allVersions.isEmpty()) {
                return notFoundResponse(coordinate);
            }

            StabilityFilter filter = stabilityFilter != null ? stabilityFilter : StabilityFilter.PREFER_STABLE;
            return buildVersionsByType(coordinate, allVersions, filter);
        });
    }
}

spring-ai-starter-mcp-server handles JSON serialization, parameter validation, stdio transport, and the MCP protocol bits. Without it, this would have been a much longer project.

What Makes This Different From Just Googling

Fair question. You can absolutely Google it or check Maven Central manually. The difference is what you get when you put it behind a tool designed for bulk + context:

Speed: 20+ dependencies in a single interaction, not 20 separate lookups.

Accuracy: Pulling directly from Maven Central, not from a blog post that happened to mention a version number.

Signal, not just numbers: Classifies versions (stable/RC/beta/etc.), compares properly, and uses historical data to infer release patterns.

Context: Ask follow-ups like "should I move from Spring Boot 2.7 to 3.x—what breaks?" and get an answer that uses both dependency data and ecosystem knowledge.

Example response from a bulk upgrade check:

{
  "comparison_date": "2026-01-06T12:00:00Z",
  "dependencies": [
    {
      "dependency": "org.springframework:spring-core",
      "current_version": "6.1.0",
      "latest_version": "6.2.7",
      "latest_type": "stable",
      "update_type": "minor",
      "update_available": true,
      "status": "success"
    }
  ],
  "update_summary": { "major_updates": 0, "minor_updates": 1, "patch_updates": 0, "no_updates": 0 }
}

Beyond Version Lookup

Once the basic "latest version" flow worked, it was obvious there was more useful stuff to return.

Dependency Age Analysis: Is a library "fresh" (≤30 days), "current" (≤6 months), "aging" (6 months–2 years), or "stale" (>2 years)?

Release patterns: How often has this library released, and how consistent has that timing been? The server also estimates the next release window from those intervals.

Project Health Scoring: Aggregate health score across dependencies. Which ones need attention?

I treat these as signals to investigate. A quiet release history doesn't by itself mean a library is abandoned, and a stable version label doesn't establish that an upgrade is compatible with my application.

This has already caught a few "we haven't looked at this in forever" dependencies—things that weren't on fire today, but were quietly becoming a maintenance risk.

Getting Started

It runs in Docker. For Claude Desktop, add this to your config:

{
  "mcpServers": {
    "maven-tools": {
      "command": "docker",
      "args": [
        "run", "-i", "--rm",
        "arvindand/maven-tools-mcp:latest"
      ]
    }
  }
}

For VS Code + GitHub Copilot, create .vscode/mcp.json:

{
  "servers": {
    "maven-tools": {
      "type": "stdio",
      "command": "docker",
      "args": ["run", "-i", "--rm", "arvindand/maven-tools-mcp:latest"]
    }
  }
}

Then ask things like:

"What's the latest stable Spring Boot version?"
"Check my build.gradle for outdated dependencies"
"Show me the health status of my project dependencies"
"Should I upgrade from Hibernate 5.6 to 6.x?"

For a Gradle build, the assistant needs to extract the dependency coordinates before calling the tools. The server's whole-file analysis supports Maven POMs.

Performance

I spent time on this because if it's slow, you'll stop using it:

Caching: Maven Central results cached with 24-hour TTL (vulnerability lookups cached separately)
Bulk Operations: One request handles 20+ dependencies
Native Images: GraalVM compilation for fast startup
Backpressure: Bounded concurrency so you don't melt your machine or Maven Central

Once cache is warm, most queries feel instant.

What I Learned

MCP let me make dependency checks available inside the assistant, and Spring AI handled much of the integration work.

Caching matters. Dependency data doesn't change often. Aggressive caching makes everything feel instant.

Bulk operations change the workflow. Checking a bunch of dependencies at once makes this kind of work much less tedious.

Spring Boot fits well. MCP server wiring, caching, HTTP client, configuration—Spring handles the boring parts.

I used GraalVM native compilation to keep startup time and memory use low. That matters for a tool launched alongside the assistant.

Source Code

Everything's MIT licensed:

GitHub: github.com/arvindand/maven-tools-mcp
Docker Hub: arvindand/maven-tools-mcp

If you try it, let me know what works and what doesn't. Issues and feedback welcome.

This started as a weekend experiment—Spring + curiosity about AI and MCP + impatience with dependency busywork. It turned into something I use daily and notice when it's missing.

About the Author: I'm a software architect at Rockwell Automation. I write about architecture, developer tooling, and the use of AI in software engineering. You can find me on GitHub or LinkedIn.

Updated September 2026 to clarify tool behaviour and limitations.