MCP

Spring AI

  • enables folks who are already big users of Java and Spring to start building AI tools in a familiar way
  • 1.0.0 Release May 20, 2025
  • great overview at the site Spring AI

The Example

  • comprises of both an MCP Server and MCP Client inside an application
  • Use case is kubernetes cluster health
    • user uploads a kubeconfig file for a cluster
    • user can then ask for the health of that cluster
    • (future) LLM will recommend fixes
    • (future) LLM can directlly implement fixes to the live cluster

The Goal

  • build an example MCP Client and MCP Server in Spring
  • build a use case of invoke tools through an LLM interaction
  • start looking at “AI-based self-healing kubernetes”

What’s In It

  • 3 tools
    • list namespaces
    • list pods in a namespace that are in error
    • list all pods in a cluster that are in error
  • client
    • allows for uploading a kubeconfig file POST /api/kubeconfig
    • has a hard-coded endpoint for “status” GET /api/status/{kubeconfig_name}
    • has an additional endpoint for looking at what ‘tools’ the client can see GET /api/tools

Running

  • clone the repo Kubernetes MCP Server Spring AI
  • grab a Google Cloud credential file that has access to the VertexAI endpoints (json format preferably)
  • there are two apps in the repo;
    • /client
    • /server
  • build each in their respective directories (e.g. cd ./client and gradle clean build)
  • start the server first
  • then the client (e.g. GOOGLE_APPLICATION_CREDENTIALS=(path to service_account_key.json) java -jar build/libs/...jar)
  • see what tools are exposed curl localhost:8080/api/tools | jq
  • grab a kubeconfig file and post it to the client curl -XPOST localhost:8080/api/kubeconfig -F "file=@kubeconfig"
  • ask the LLM if there’s anything wrong with your cluster curl localhost:8080/api/status/kubeconfig

What’s Happening?

  • the client is getting the tools automatically exposed by the MCP server
  • the client automatically adds them, and their description, to the initial prompt to the LLM
  • the LLM will return which tool - if any - it wants to use and what the arguments should be (e.g. the kubeconfig file as that’s the required argument for the tool)
  • the client uses the LLM return to then invoke the tool via the MCP server
  • the response is then sent, along with all the context so far, to the LLM
  • the LLM then answers the question

Conclusion

  • it works
  • it’s synchronous –> next step is to implement the Reactor-version
  • it’s dumb –> for now
  • it will hopefully give an example that as of 6/1, I can’t find in the Spring AI examples

Good Luck!