Copied to Clipboard
Once you have validated the server can run locally — exit with control-c.
Then run a deployment to Azure Kubernates Service:
> make deploy
✦ I'll check if the AKS cluster exists before proceeding with the deployment.
✦ The make deploy command was successful. The Python-based MCP server is now running on Azure Kubernetes Service
(AKS).
Deployment Details:
- ACR Image: mcpacrpenguinv2.azurecr.io/mcp-server-image:921e6f8
- AKS Cluster: mcp-aks-penguin
- AKS Service IP: 20.99.165.219
- Pod Status: Running (1/1 READY)
You can now access the MCP server at http://20.99.165.219.
Getting deployment status:
✦ The current status of your Azure resources is as follows:
- AKS Cluster (mcp-aks-penguin): Succeeded, version 1.34.
- Kubernetes Service (mcp-server-service): LoadBalancer type, with External IP 20.99.165.219.
- Kubernetes Pods: The mcp-server pod is Running and healthy (1/1 READY).
And the current endpoint:
│ │AKS Endpoint: │
│ 20.99.165.219
Gemini CLI settings.json
The default Gemini CLI settings.json has an entry for the Python source:
1{2"mcpServers":{3"azure-aks-python":{4"httpUrl":"http://20.99.165.219/mcp"5}6}7}
Validation with Gemini CLI
Leaver the MCP server window running. Start a new shell. Gemini CLI is restarted and the MCP connection over HTTP to the Python Code is validated, The full Gemini CLI Session will start:
▝▜▄ Gemini CLI v0.34.0
▝▜▄
▗▟▀ Signed in with Google: xbill@glitnir.com /auth
▝▀ Plan: Gemini Code Assist Standard /upgrade
> /mcp list
Configured MCP servers:
🟢 azure-aks-python - Ready (1 tool)
Tools:
- mcp_azure-aks-python_greet
🟢 DeveloperKnowledge (from DeveloperKnowledge) - Ready (2 tools)
Tools:
- mcp_DeveloperKnowledge_get_documents
- mcp_DeveloperKnowledge_search_documents
And you can then connect to the MCP Server over HTTP:
> greet AKS!
✦ I will now greet AKS! by calling the mcp_azure-aks-python_greet tool.
╭────────────────────────────────────────────────────────────────────────────────────────────────────────────╮
│ ✓ greet (azure-aks-python MCP Server) {"param":"AKS!"} │
│ │
│ AKS! │
╰────────────────────────────────────────────────────────────────────────────────────────────────────────────╯
✦ AKS!
Project Review
Finally — you can use Gemini CLI to review the project:
✦ I have conducted a comprehensive code review of the project. Overall, the implementation is clean, follows
cloud-native best practices, and is well-configured for AKS. Here are my specific findings and recommendations:
1. Architecture & Implementation (main.py)
- FastMCP: Excellent use of the FastMCP library, which simplifies server creation and tool definition.
- Health Check: The /health custom route is correctly implemented and integrated with Kubernetes liveness and
readiness probes.
- Logging: Using python-json-logger for JSON-formatted logs is a best practice for containerized environments,
facilitating better observability in Azure.
- Tooling: The greet tool is functional and correctly typed.
2. Containerization (Dockerfile)
- Optimization: The use of python:3.13-slim and proper layer ordering (copying requirements.txt before code)
ensures small image sizes and fast rebuilds.
- Environment: PYTHONUNBUFFERED=1 is correctly set to ensure logs are emitted immediately.
3. Orchestration (k8s.yaml)
- Probes: Well-defined liveness and readiness probes ensure high availability.
- Resources: CPU and memory limits/requests are specified, which prevents resource exhaustion in the cluster.
- Security: The securityContext dropping all capabilities is a strong security measure.
- Improvement: Consider adding runAsNonRoot: true and allowPrivilegeEscalation: false to further harden the
deployment.
4. Automation (Makefile)
- AKS Focus: The recent cleanup has effectively focused the automation on the AKS workflow.
- ACR Integration: The aks-create target correctly uses --attach-acr, simplifying permission management between
AKS and the registry.
- Cleanup: The new destroy target provides a simple way to tear down all resources.
- Note: The AZ_ACR_NAME uses a dynamic hostname-based suffix, which is a clever way to avoid global naming
collisions in Azure.
5. Dependencies (requirements.txt)
- Recommendation: Currently, dependencies are not version-pinned. For consistent deployments, it's recommended
to pin versions (e.g., fastmcp==0.4.1).
6. Project Documentation (GEMINI.md & README.md)
- Consistency: Both files are now aligned with the AKS-only deployment strategy.
---
Final Verdict: The project is in excellent shape for an AKS-based MCP server. The transition from ACA to AKS is
complete and well-documented.
Summary
The strategy for using Python for MCP development with Gemini CLI was validated with a incremental step by step approach.
A minimal HTTP transport MCP Server was started from Python source code and validated with Gemini CLI running as a MCP client in the same local environment. Then this solution was deployed remotely to the Azure Kubernates Service and validated with the local installation of Gemini CLI.
This approach can be extended to more complex deployments using other MCP transports and Cloud based options.