MCP Servers in Java on Cloud Run: Why It Makes Sense

The MCP ecosystem has been accumulating tutorials and references in Python and TypeScript for months. Java, however, has been sidelined in most public guides, despite the fact that much of enterprise infrastructure still runs on the JVM. The article published this weekend on HackerNoon fills precisely that gap: how to build a custom MCP server in Java and deploy it to Google Cloud Run.

It's not a theoretical tutorial. The author walks through the complete cycle: defining MCP tools, starting the HTTP server, containerization with Docker, and deployment to Cloud Run with zero scaling. The result is an MCP server ready to be consumed from Claude Code or any protocol-compatible client.

What is an MCP server and why you'd want to build one

The Model Context Protocol (MCP) is the standard that Anthropic has established for Claude models to invoke external tools in a structured way. An MCP server exposes a set of tools—named functions with descriptions and parameter schemas—that the model can call during a conversation or task.

MCP servers are configured in `claude_desktop_config.json` or directly from Claude Code, and can run locally or remotely. The advantage of deploying to the cloud is obvious: continuous availability without relying on a local machine being powered on, and the ability to share the same server across multiple users or agents.

Cloud Run is a good fit here because it charges per request, not per unit of active server time. For an MCP server that receives sporadic calls, as is common in many agent workflows, the cost can be practically zero under low-load scenarios.

Why Java instead of Python or TypeScript

The legitimate question is: why complicate things with Java when there are more mature MCP SDKs in Python and TypeScript?

The answer is pragmatic. There are organizations with entire Java development teams, internal libraries on the JVM, and security policies that make it difficult to introduce new runtimes in production. For those teams, the most viable option to integrate Claude into their systems isn't to rewrite anything: it's to expose their existing services as MCP tools from the same stack they already operate.

Besides, the Java ecosystem has Spring Boot and Quarkus, two frameworks with robust HTTP support and mature containerization tools. Building an MCP server on Spring Boot doesn't require exotic dependencies: you just need to define the JSON-RPC endpoints that the protocol requires and register your tools with their corresponding schemas.

What the technical tutorial covers

Without reproducing code here, the HackerNoon article covers the following sections:

• Server structure: how to implement the `tools/list` and `tools/call` methods that the MCP protocol requires, returning responses in the JSON-RPC format that Claude expects.
• Tool definition: how to declare name, description, and parameter schema so the model can correctly select and use the tool.
• Containerization: a minimal Dockerfile to package the Spring Boot application in an image ready for Cloud Run.
• Deployment and configuration: `gcloud` commands to deploy the service and get the URL that you then add as a remote MCP server in your Claude configuration.

The complete flow is reproducible in an environment with Java 21, Maven, and access to a GCP project. Nothing that any backend Java team with some cloud experience doesn't already have.

Who this is useful for

This type of guide has concrete value for three profiles:

1. Java backend teams that want to expose internal business logic as MCP tools without switching stacks.
2. Platform engineers who manage infrastructure on GCP and want to integrate Claude Code into existing pipelines.
3. Agent developers who need MCP servers with high availability and controlled costs, and already have Cloud Run experience.

For personal projects or quick prototypes, Python or TypeScript remain the path of least friction. But in enterprise contexts with stack constraints, the Java+Cloud Run option is completely reasonable and, as of this tutorial, well documented.

---

We view positively that the MCP ecosystem is beginning to have solid technical references outside the Python/TypeScript pairing. Diversity of implementations is a sign of protocol maturity, not fragmentation.