SpringAI MCP Server in Practice: Tool Declaration and SSE Service Startup

Understanding MCP Server Development from Scratch

MCP (Model Context Protocol) is rapidly becoming an important standard for AI Agents to integrate with external tools. In this hands-on tutorial based on SpringAI, the instructor walks through a concrete stock analysis scenario to demonstrate how to declare tools, organize services, and expose capabilities to the outside world.

The core of the demo consists of three interconnected services: the first uses decorators to declare tools, exposing ordinary functions as MCP-callable tools; the second calculates the actual market performance of a given stock over the past three days; the third builds on both to generate an investment recommendation report. These three services chain together to form a compact Agent workflow of "data retrieval → data analysis → conclusion output" — a great example for understanding the division of responsibilities in an MCP Server.

Tool Declaration: Decorators Are the Key Step

In an MCP Server, a Tool is the smallest unit of capability exposed to upper-level Agents. The tutorial demonstrates tool declaration using decorators — meaning developers simply annotate an ordinary function and the framework automatically identifies its inputs and outputs, registering it as a callable tool at the protocol level.

This declarative approach lowers the barrier to entry: developers focus on business logic (such as fetching stock data, calculating trends, and assembling reports), while tool registration, parameter parsing, and call routing are handled by the framework. For beginners, grasping the mapping of "decorator = tool entry point" first, then expanding into specific business logic, is a natural and effective learning path.

MCP (Model Context Protocol) was proposed and open-sourced by Anthropic in late 2024, with the goal of establishing a unified standard for interactions between AI models and external tools or data sources. Prior to this, each AI application typically had to write custom integration logic for different tools, and the lack of a unified protocol led to massive duplication of effort. MCP's design mirrors the philosophy of a USB interface: the server side (MCP Server) is responsible for packaging and declaring its capabilities, while the client side (MCP Client — typically an Agent or LLM host program) calls them using the protocol format, with neither party needing to understand the other's internal implementation. SpringAI is the official Spring ecosystem framework for integrating with large language models, with built-in support for the MCP protocol, allowing Java/Kotlin developers to quickly build MCP Servers using familiar annotation-style syntax — no need to parse protocol packets from scratch.

Exposing Services via SSE Protocol

Once the three tools are implemented, the tutorial chooses to launch all three services together using SSE (Server-Sent Events) as the transport protocol. SSE is one of the most common transport methods in MCP, well-suited for the server to continuously push events to the client, providing a smooth experience when an Agent calls a tool and receives a streaming response.

The instructor's approach is to start all three services at once, then verify each one individually to confirm it's running properly. This "start everything first, then check status" approach is very practical during local debugging — it quickly surfaces issues like whether all tools registered successfully or whether any ports are already in use.

SSE (Server-Sent Events) is a unidirectional real-time communication protocol built on HTTP — the server can continuously push a stream of text events to the client over a single long-lived connection, without the client needing to repeatedly poll. Unlike WebSocket's bidirectional communication, SSE only supports server-to-client push, but it's much lighter to implement and natively compatible with standard HTTP infrastructure (such as reverse proxies and load balancers). In the MCP context, after an Agent sends a tool call request, the tool's execution result — especially streaming text generated by an LLM — can be returned incrementally via SSE, producing the "typewriter" effect of text appearing character by character. The MCP specification supports both Stdio (standard input/output, suitable for local inter-process communication) and SSE as transport methods; SSE is the more common choice for network-facing service scenarios.

The Runtime Environment Debate: UV or Conda?

One noteworthy detail in the tutorial is the discussion around choosing a runtime environment for the MCP Server. The instructor mentions that the official MCP documentation actually doesn't recommend the direct service-startup approach demonstrated in the tutorial — instead, it recommends using UV.

The Official Recommendation: UV

UV is a modern Python package and environment management tool that has gained popularity in recent years for its speed and clean dependency resolution. With the UV approach, installing packages and creating virtual environments all go through UV, and the startup command becomes uv run (paired with nohup uv run to keep the service running in the background). It relies on the system's native virtual environment (on Linux or Windows) rather than Conda's activation workflow.

UV was written in Rust by the Astral team (the same developers behind the code formatter Ruff) and officially released in 2024. Its core advantages are: dependency resolution tens of times faster than pip, built-in virtual environment management (similar to venv), and support for locking dependency versions via pyproject.toml for reproducible environments. For MCP Server deployments — where you often need to spin up quickly across different machines — UV can install dependencies and execute a script with a single uv run script.py command, even on a bare environment with nothing pre-installed. This dramatically reduces the cognitive overhead of environment setup. The official docs lean toward recommending UV partly because many MCP Server examples are written in Python, and UV has gradually become one of the de facto standards in the modern Python toolchain.

The Practical Alternative: Conda Works Just Fine

That said, the instructor also acknowledges that whether to use UV "depends on the individual." He personally prefers managing dependencies with Conda — activating a virtual environment and running a single command to start the service works perfectly well too. In other words, the official recommendation for UV is more about consistency and convenience than a hard requirement. During the learning phase, stick with whatever toolchain you're comfortable with. There's also plenty of documentation online about running MCP with UV, which makes for good supplementary reading.

Summary: What This Tutorial Actually Teaches

Setting aside the toolchain details, the main thread of this tutorial is quite clear:

• Use decorators to declare tools, turning business functions into MCP-callable capabilities;
• Design three collaborative services around a stock analysis scenario to form a minimal Agent workflow;
• Expose all services externally via SSE protocol and verify each one locally;
• For environment management, UV is the official preference, but Conda and other existing environment solutions work equally well.

For readers looking to get started with AI Agent development, MCP Server is an unavoidable piece of the puzzle. Understanding the chain of "tool declaration → service orchestration → protocol exposure" matters far more than debating which virtual environment to use. The recommended approach: get all three services running locally, then refer to the official documentation to try the UV startup method — this will deepen your understanding of the differences between runtime environments.