Forem: 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?”

But when I used it on real upgrades (especially major bumps), the agent would update the pom but then the build would most likely fail due to breaking changes in the libraries. Then I would have to go through documentation searches on the web and fix issues one by one. That's fine, but we can do better.

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’s another MCP server that can pull version-specific documentation into the assistant’s context.

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)

That’s what I mean by “guided delegation”: my server doesn’t fetch docs itself — it tells the model exactly how to fetch the docs using the right tools.

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 Arvind, a senior backend engineer based in Karlsruhe, Germany. I spend most of my time with Java and Spring Boot in enterprise environments, but lately I've been exploring AI integration and being more out in the open (source). You can find me on GitHub or LinkedIn.

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 scans everything, tells me what needs attention, and separates "safe" upgrades from "this might hurt" upgrades (major/minor/patch). The point isn't magic—it's speed and fewer tab hops.

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 Pattern Prediction: Based on historical data, when might the next Jackson release happen?

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

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?"

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 is genuinely useful. Extending assistants with tools changes what "AI help" feels like. Spring AI makes the on-ramp easy.

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.

Native images are worth it. GraalVM means the container starts instantly and uses minimal memory.

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.

AI + developer tooling still feels early, but MCP is one of the first things that's felt immediately practical. If you're curious about MCP, Spring AI, or just want to see what happens when an assistant can query real data, give it a try.