DevBox in Practice: Building an MCP Server & Client from Scratch with One-Click Deployment

In AI application development, MCP (Model Context Protocol) is rapidly becoming the standard protocol for connecting large language models with external tools. Open-sourced by Anthropic in late 2024, MCP aims to solve the fragmentation problem of connecting LLMs with external data sources and tools. Before MCP, every AI application required custom integration code for different tools and APIs, resulting in massive duplication of effort. Drawing inspiration from the USB-C universal interface concept, MCP defines a common client-server architecture: the MCP Server exposes tools and resources, while the MCP Client communicates with the Server and passes tool capabilities to the LLM. This standardization means any MCP-compliant tool can be invoked by any MCP-supporting client, greatly promoting interoperability across the AI tool ecosystem.

However, the full workflow from development to deployment often feels daunting — environment configuration, Docker image building, SSL certificate provisioning, public network exposure... any of these steps can block your progress.

This article will walk you through using the DevBox cloud development platform to build a complete MCP server and client from scratch, achieving one-click deployment without any Docker knowledge.

DevBox Platform: An End-to-End Solution from Development to Deployment

DevBox is a cloud development platform designed for developers. Its core value lies in radically simplifying the entire workflow of application creation, development, debugging, deployment, and publishing. It offers several key features:

• Multi-language and multi-framework support: Covers mainstream languages like Python and Node.js, with native support for MCP service templates
• Seamless local IDE integration: Develop directly in local editors like VSCode or Cursor, with an experience identical to local development
• One-click deployment and publishing: No Docker knowledge required — just enter a version number to automatically build images and complete deployment. Traditional containerized deployment typically requires developers to write Dockerfiles, configure multi-stage builds, and handle dependency caching, but DevBox fully encapsulates these complex operations within the platform
• Automatic network configuration: After deployment, both internal and public access URLs are automatically provided, with SSL certificates configured automatically. This automated SSL certificate management means developers don't need to manually request and renew certificates through tools like Let's Encrypt — services natively support HTTPS secure access
• Flexible port management: When creating an application, you can manually modify exposed ports and toggle public network access

Additionally, DevBox integrates various database services, including relational databases and vector databases, which can be created with simple clicks. Vector databases are particularly important for AI applications — they can store and retrieve semantic vector representations of text, serving as the infrastructure for advanced AI features like RAG (Retrieval-Augmented Generation). This makes DevBox ideal for full-stack AI application development scenarios.

Building the MCP Server: Defining a Weather Query Tool

Creating the MCP Server Project

First, create a new project in DevBox with the following key configurations:

• Project name: MCP Server
• Service type: Select MCP
• Runtime version: Python 3.12
• Exposed port: Change to 8081

After creation, you can open the project directly in your local IDE. DevBox provides an MCP service template that we can modify as needed.

Writing MCP Tool Code

When building MCP tools, there's a crucial detail: you must provide detailed descriptions of the tool's functionality and required parameters through comments. The reason is straightforward — the LLM needs these descriptions to determine when to invoke the tool and how to pass parameters. This involves the LLM's Function Calling mechanism: developers pass a JSON Schema description of available tools (including function names, purpose descriptions, parameter types, and meanings) as context to the model. During inference, the model determines whether the current user request requires calling a tool. If so, the model outputs a structured tool call request (containing the function name and extracted parameters) rather than directly generating a natural language response. Therefore, the clearer your descriptions are, the higher the model's invocation accuracy.

In this demo, we define a "get weather" MCP tool that takes a city name as a parameter and returns a fixed weather result (for demonstration purposes only). After defining the tool, you need to modify the port number in the startup script to ensure it matches the 8081 port exposed when creating the application.

Publishing and Deploying the MCP Server

The publishing process is extremely simple — just three steps:

1. Enter a version number in DevBox, and the platform will automatically build the Python image
2. Click "Publish" for automatic deployment, keeping default configurations and confirming the exposed port is 8081
3. Click "Deploy Application" and wait for the status to change to "Accessible"

Once deployment is complete, both public and internal addresses are ready, and the MCP server can serve external requests.

Building the MCP Client: Gradio Interface with LLM Tool Calling

Creating the Client Project

Create another project in DevBox using the Python framework with the port set to 8082. After entering VSCode, we'll build the MCP client code from scratch.

Core Calling Logic Explained

The client's core is a query function that contains the complete workflow for MCP client creation and user input processing:

Step 1: Initialize the LLM Service

Build the API connection to the LLM (based on the OpenAI SDK) for subsequent intelligent decision-making. The OpenAI SDK has become the de facto standard for LLM API calls — numerous model providers both domestically and internationally (such as DeepSeek, Qwen, Moonshot, etc.) offer interfaces compatible with the OpenAI API format. This means you can seamlessly switch between different LLM services simply by changing the Base URL and API Key.

Step 2: Create the SSE Client Connection

MCP services support two connection methods: SSE and STDIO. STDIO (Standard Input/Output) is suitable for local scenarios where the MCP Client communicates with the MCP Server by launching a subprocess, with data passing through the process's stdin and stdout — extremely low latency but limited to the same machine. SSE (Server-Sent Events) is HTTP-based, where the Server continuously pushes event streams to the Client through long-lived connections, naturally supporting remote deployment and network communication. SSE is part of the HTML5 specification and is lighter than WebSocket, making it particularly suitable for server-to-client unidirectional data pushing scenarios. Since our server is deployed in the cloud using SSE, the client also needs to initialize a corresponding SSE client for interaction.

Step 3: Retrieve Available Tool List

Use the list_tools method to obtain information about all available tools in the connected MCP service, including tool names, purpose descriptions, and required parameters. This information is converted into JSON Schema format that the LLM can understand and passed to the model as part of the context, enabling the model to "know" what capabilities it has.

Step 4: LLM Decision-Making and Tool Calling Loop

This is the most critical part of the entire MCP client. The available tool information, user question, and system prompt are all fed to the LLM, which autonomously decides:

• Whether a tool needs to be called
• Which tool to call
• What parameters to extract from user input for the tool

Since streaming output is used, the processing logic is relatively complex. Streaming means the model doesn't wait until the complete response is generated before returning — instead, it pushes results token by token to the client, allowing users to see the response being generated in real-time, significantly improving the interaction experience. However, in tool calling scenarios, the client needs to identify tool call requests within the streamed data, assemble them completely, and then execute the actual call. The entire process is a loop: after the LLM calls a tool and gets the result, the result is added to the context, and the LLM determines whether it needs to call additional tools. If not, it exits the loop and provides the final response. This loop mechanism is also the foundational pattern for building AI Agents — ReAct (Reasoning + Acting), where the model alternates between reasoning and action until the task is complete.

Step 5: System Prompt Optimization

A special emphasis here: when building an MCP client, the system prompt directly determines the quality of the client's performance. The system prompt is an instruction text injected into the LLM before the conversation begins, defining the model's role, behavioral boundaries, and decision-making strategies. A well-designed system prompt needs to clearly tell the model: when it should call a tool rather than answer directly, how to extract structured parameters from ambiguous user expressions, how to choose the most appropriate tool when multiple tools are available, and how to organize raw data returned by tools into user-friendly natural language responses. Prompt Engineering has become one of the core skills in AI application development — an excellent system prompt enables the LLM to more accurately understand user intent and more appropriately select and invoke tools.

Building the Gradio Frontend Interface

Use Gradio to build the frontend interface with the following configurable options:

• LLM name, Base URL, API Key
• Temperature parameter
• MCP service address
• Tool call result display area
• LLM final response display area

Gradio is an open-source Python library maintained by Hugging Face, specifically designed for rapidly building web demo interfaces for machine learning and AI applications. Its core advantage is an extremely low frontend development barrier — developers can create complete web applications with text inputs, sliders, dropdown menus, and other interactive components using just a few lines of Python code. It comes with built-in WebSocket real-time communication, queue management, automatic API generation, and more, making it particularly suitable for AI prototype validation and internal tool building.

The Temperature parameter controls the randomness of LLM output, typically ranging from 0 to 2. Lower temperatures produce more deterministic and conservative outputs; higher temperatures produce more diverse and creative outputs. In tool calling scenarios, it's generally recommended to set the temperature at a lower level (e.g., 0.1-0.3) to ensure the model can stably and accurately generate tool call requests.

Note that Gradio's listening port should be set to 8082, matching the port exposed in DevBox.

Installing Dependencies and One-Click Deployment

Create a requirements.txt dependency file containing three core packages: gradio, mcp, openai. After activating the virtual environment and installing dependencies, modify the startup script to point to the client code file.

Once complete, use DevBox's one-click publish and deploy, and wait for the public URL to become accessible.

Verification: Full Pipeline Testing

Open the client's public URL, enter the Gradio interface, and follow these steps:

1. Configure the LLM service parameters (model name, API Key, etc.)
2. Enter the server's public URL in the MCP service address field (note: append the /sse suffix)
3. Enter a question, such as "What's the weather like in Beijing today?"

The test results show that the MCP client successfully completed the full tool calling pipeline: the LLM extracted "Beijing" as a parameter from the question, called the weather query tool, received the result "sunny" (our preset fixed value), and finally the LLM generated a complete natural language response based on the tool's returned result.

The entire process validates the complete MCP protocol pipeline from server tool definition, client SSE connection, LLM intelligent decision-making, to tool invocation — all components working correctly. This also demonstrates the core value of the MCP protocol: tool definers (Server developers) and tool users (Client developers) can be completely decoupled. As long as both sides follow the MCP protocol specification, seamless integration is achieved.

Summary and Reflections

Using the DevBox platform, we completed the full development and deployment workflow for both the MCP server and client. Throughout the process, developers only need to focus on the business logic itself — defining MCP tools, writing client calling logic, building the Gradio frontend — while environment configuration, image building, network configuration, SSL certificates, and other DevOps tasks are all handled automatically by the platform.

For developers looking to quickly validate MCP application ideas, this cloud development model can significantly lower the barrier to entry and reduce deployment costs. Of course, the weather query tool demonstrated in this article is relatively simple. If you're interested, you can try connecting more complex open-source MCP services, such as database queries, file operations, API aggregation, and more, to build more powerful AI Agent applications. The MCP ecosystem is currently growing rapidly, with the community producing numerous open-source MCP Server implementations covering common scenarios like GitHub operations, Slack messaging, database CRUD, web scraping, and more. Developers can directly reuse these ready-made tool services and combine multiple MCP Servers to build feature-rich AI Agents without developing every tool integration from scratch.