This article re-visits and updates an existing deployment originally built with Gemini CLI and re-tools the setup to leverage the new Antigravity CLI to build Model Context Protocol (MCP) AI applications in Python with a local development environment.
Is this Deja Vu?
There is no spoon.
This article updates an earlier deployment built out with Gemini CLI and re-tools the entire setup for Antigravity CLI.
The original article is here:
Local MCP Development with Python and Gemini CLI
Aren’t There a Quadrillion Python MCP Demos?
Yes there are.
Python has traditionally been the main coding language for ML and AI tools. The goal of this article is to provide a minimal viable basic working MCP stdio server that can be run locally without any unneeded extra code or extensions.
Antigravity CLI
Antigravity CLI is the follow-on successor to Gemini CLI- the terminal driven, agent assisted coding tool.
Full details on installing Antigravity CLI are here:
Getting Started with Antigravity CLI
Testing the Antigravity CLI Environment
Once you have all the tools in place- you can test the startup of Antigravity CLI.
You will need to authenticate with a Google Cloud Project or your Google Account:
agy
This will start the interface:
Python MCP Documentation
The official GitHub Repo provides samples and documentation for getting started:
The most common MCP Python deployment path uses the FASTMCP library:
Where do I start?
The strategy for starting MCP development is a incremental step by step approach.
First, the basic development environment is setup with the required system variables, and a working Antigravity CLI configuration.
Then, a minimal Hello World Style Python MCP Server is built with stdio transport. This server is validated with Antigravity CLI in the local environment.
This setup validates the connection from Antigravity CLI to the local process via MCP. The MCP client (Antigravity CLI) and the Python MCP server both run in the same local environment.
Next- the basic MCP server is extended with Antigravity CLI to add several new tools in standard Python code.
Setup the Basic Environment
At this point you should have a working Python interpreter and a working Antigravity CLI installation. The next step is to clone the GitHub samples repository with support scripts:
cd ~
git clone https://github.com/xbill9/gemini-cli-codeassist
Then run init.sh from the cloned directory.
The script will attempt to determine your shell environment and set the correct variables:
cd gemini-cli-codeassist
source init.sh
If your session times out or you need to re-authenticate- you can run the set_env.sh script to reset your environment variables:
cd gemini-cli-codeassist
source set_env.sh
Variables like PROJECT_ID need to be setup for use in the various build scripts- so the set_env script can be used to reset the environment if you time-out.
Hello World with STDIO Transport
One of the key features that the standard MCP libraries provide is abstracting various transport methods.
The high level MCP tool implementation is the same no matter what low level transport channel/method that the MCP Client uses to connect to a MCP Server.
The simplest transport that the SDK supports is the stdio (stdio/stdout) transport — which connects a locally running process. Both the MCP client and MCP Server must be running in the same environment.
The connection over stdio will look similar to this:
if __name__ == " __main__":
# Explicitly use stdio transport
mcp.run(transport="stdio")
Running the Python Code
First- switch the directory with the Python MCP sample code:
cd ~/gemini-cli-codeassist/mcp-stdio-python-agy
Run the release version on the local system:
cd ~/gemini-cli-codeassist/mcp-stdio-python-agy
make release
You can validate the final result by checking the messages:
Requirement already satisfied: cryptography>=3.4.0 in /home/xbill/.local/lib/python3.13/site-packages (from pyjwt[crypto]>=2.10.1->mcp->-r requirements.txt (line 1)) (48.0.0)
Requirement already satisfied: cffi>=2.0.0 in /home/xbill/.local/lib/python3.13/site-packages (from cryptography>=3.4.0->pyjwt[crypto]>=2.10.1->mcp->-r requirements.txt (line 1)) (2.0.0)
Requirement already satisfied: pycparser in /home/xbill/.local/lib/python3.13/site-packages (from cffi>=2.0.0->cryptography>=3.4.0->pyjwt[crypto]>=2.10.1->mcp->-r requirements.txt (line 1)) (3.0)
Requirement already satisfied: click>=7.0 in /home/xbill/.pyenv/versions/3.13.13/lib/python3.13/site-packages (from uvicorn>=0.31.1->mcp->-r requirements.txt (line 1)) (8.1.8)
xbill@penguin:~/gemini-cli-codeassist/mcp-stdio-python-agy$
Antigravity CLI settings.json
Settings.json is where MCP servers are setup in Gemini CLI. Antigravity CLI moves the MCP configuration to a seperate file: mcp_config.json.
xbill@penguin:~/gemini-cli-codeassist/mcp-stdio-python-agy$ cd .agents
xbill@penguin:~/gemini-cli-codeassist/mcp-stdio-python-agy/.agents$ d
total 4
-rw-r--r-- 1 xbill xbill 184 May 21 10:03 mcp_config.json
drwxr-xr-x 1 xbill xbill 30 May 21 10:03 .
drwxr-xr-x 1 xbill xbill 242 May 21 10:03 ..
This file contains the configuration for connecting to external tools and services:
{
"mcpServers": {
"hello-stdio-python": {
"command": "python",
"args": [
"/home/xbill/gemini-cli-codeassist/mcp-stdio-python-agy/main.py"
]
}
}
}
Validation with Antigravity CLI
Finally- agy CLI is restarted and the MCP connection over stdio to the Python Code is validated, The full session will start:
> /mcp list
────────────────────────────────────────────────────────────────────────────────────────────────────
MCP Servers
Plugins (~/.gemini/antigravity-cli/plugins)
> ✓ hello-stdio-python Tools: greet
And you can then connect to the MCP Server over stdio:
> greet Two Snakes!
● ListDir(/home/xbill/.gemini/antigravity-cli/mcp/hello-stdio-python)
● Read(/home/xbill/.gemini/antigrav...ello-stdio-python/greet.json)
● hello-stdio-python/greet(Calling greet tool via MCP) (ctrl+o to expand)
Hello! I've invoked the greet tool from the hello-stdio-python server with the parameter
"Two Snakes!" , and it responded with:
│ Two Snakes!
Extending the Python MCP Server with Antigravity CLI
Now that the basic MCP functionality has been tested and verified with Antigravity CLI- the Python server code can be extended with new MCP tools:
> with @main.py add 2 new MCP tools - one that returns the current system time and the other
returns the current system info like OS,
memory, etc
● ListDir(/home/xbill/gemini-cli-codeassist/mcp-stdio-python-agy)
● Read(/home/xbill/gemini-cli-codea...mcp-stdio-python-agy/main.py)
● Read(/home/xbill/gemini-cli-codea...-python-agy/requirements.txt) (ctrl+o to expand)
▸ Thought for 2s, 977 tokens
Clarifying Instructions
● Read(/home/xbill/gemini-cli-codea...cp-stdio-python-agy/Makefile)
● Read(/home/xbill/gemini-cli-codea...dio-python-agy/test_greet.py)
● Read(/home/xbill/gemini-cli-codea...o-python-agy/test_logging.py) (ctrl+o to expand)
▸ Thought for 2s, 1.4k tokens
Considering Time Return Formats
● ListPermissions(You have read and write access to the following workspace(s)...) (ctrl+o to
expand)
▸ Thought for 1s, 1.5k tokens
Proposing the Execution
● Edit(/home/xbill/gemini-cli-codea...mcp-stdio-python-agy/main.py) (ctrl+o to expand)
▸ Thought for 2s, 589 tokens
Initiating Unit Tests
● Edit(/home/xbill/gemini-cli-codea...dio-python-agy/test_greet.py)
● Bash(make test) (ctrl+o to expand)
Restart Antigravity CLI and check for the new MCP tools:
MCP Servers
Plugins (~/.gemini/antigravity-cli/plugins)
> ✓ hello-stdio-python Tools: greet, get_system_time, get_system_info
Get the current time:
> get_system_time
● hello-stdio-python/get_system_time(Executing get_system_time via MCP) (ctrl+o to expand)
I have successfully invoked the get_system_time tool from the local MCP server, and it
returned the following current system times:
Local Time: 2026-05-21T10:15:38.715899 (2026-05-21 10:15:38)
UTC Time: 2026-05-21T15:15:38.715912+00:00
And system Info:
> get_system_info
● hello-stdio-python/get_system_info(Executing get_system_info via MCP) (ctrl+o to expand)
I have successfully invoked the get_system_info tool from the local MCP server. Here is the
current system information retrieved:
Operating System: Linux
Release/Kernel: 6.6.99-09128-g14e87a8a9b71
Version: #1 SMP PREEMPT_DYNAMIC Fri, 6 Feb 2026 20:45:19 -0800
Architecture: x86_64
CPU Cores: 12
Memory Info: Total: 6530980 kB, Free: 332012 kB, Available: 1558252 kB
Python Version: 3.13.13
The information from the MCP tool execution comes back into the current context. You can use the information returned from the tools along with the underlying Gemini Models:
> can i play Cyberpunk 2077 on this machine
● WebSearch(Cyberpunk 2077 minimum system requirements) (ctrl+o to expand)
▸ Thought for 2s, 494 tokens
Assessing Game Requirements
Based on the system information retrieved, no, you cannot play Cyberpunk 2077 on this machine
in its current state.
Here is a detailed breakdown of why, comparing your system specs to the game's official minimum
requirements (after Update 2.0):
### 1. RAM (Critical Bottleneck) ❌
• Minimum Requirement: 12 GB RAM
• Your Machine: ~6.2 GB RAM ( Total: 6530980 kB )
• Verdict: This is a severe bottleneck. With only 6.2 GB of RAM, the game will either fail to
launch, crash constantly, or suffer from unplayable stuttering as your system runs out of
memory.
### 2. Operating System ⚠️
• Minimum Requirement: 64-bit Windows 10/11
• Your Machine: Linux (Kernel 6.6)
• Verdict: While Cyberpunk 2077 does not have a native Linux version, this is actually not a
dealbreaker. The game has a "Platinum" rating on ProtonDB, meaning it runs beautifully on Linux
via Steam Proton (compatibility layer). However, the hardware limits below still apply.
### 3. CPU Cores
• Minimum Requirement: Intel Core i7-6700 (4 cores) or AMD Ryzen 5 1600 (6 cores)
• Your Machine: 12 Cores
• Verdict: Excellent. Your CPU core count is more than capable of handling the game.
### 4. Graphics Card & Storage (Unknown) ❓
• Minimum Requirement: Dedicated GPU with at least 6 GB of VRAM (e.g., GeForce GTX 1060 6GB /
Radeon RX 580) and 70 GB SSD (an SSD is strictly required).
• Our system info tools do not expose your GPU model or storage type, but you would need to
meet these specifications as well.
──────
### Conclusion
Even though your CPU is powerful and Linux compatibility is excellent via Proton, the 6.2 GB
RAM limit will prevent you from playing the game. You would need to upgrade the system's RAM to
at least 12 GB (ideally 16 GB) and ensure you have a gaming-grade dedicated graphics card.
But you can still play Doom!
> can I play Classic Doom on this machine?
● WebSearch(classic doom 1993 system requirements) (ctrl+o to expand)
Absolutely, 100% yes! In fact, your machine could easily run thousands of instances of Classic
Doom (1993) at the exact same time.
Here is how your current system compares to the original 1993 requirements:
Component │ Classic Doom (│ Your Machine │ How Much Better Is It?
───────────────┼───────────────┼────────────────────┼──────────────────────────────────────────
Operating Syst│ MS-DOS 5.0 │ Linux (Kernel 6.6) │ Native Linux source ports (like Chocolate
Processor (CPU│ Intel 386DX (3│ 12 CPU Cores (Multi│ Thousands of times faster with massive mu
Memory (RAM) │ 4 MB (Megabyte│ 6,530 MB (6.2 GB) │ Over 1,600 times more RAM than required!
Storage │ 12 MB │ Gigabytes available│ Plenty of space to store every mod ever c
### How to play it on your Linux machine right now:
Because Doom's engine code was open-sourced in 1997, Linux has excellent native support through
modern "source ports" which run the game flawlessly with widescreen and high-resolution support.
You can install a lightweight classic source port like Chocolate Doom directly via your package
manager:
# On Debian/Ubuntu-based systems
sudo apt install chocolate-doom
Then, you just need a game file (like the free shareware DOOM1.WAD or a retail DOOM.WAD
from Steam/GOG) to start slaying demons!
One Last Code Review
Lets see how good of a Python coder I am -
> code review this Python MCP project
● Read(/home/xbill/gemini-cli-codea...p-stdio-python-agy/README.md)
● Bash(git status)
● Bash(find . -maxdepth 2) (ctrl+o to expand)
▸ Thought for 4s, 732 tokens
Investigating File Absence
Here is a comprehensive code review of the Python MCP (Model Context Protocol) project.
Overall, the project is exceptionally well-structured, lightweight, and employs industry best
practices for MCP stdio-based servers.
──────
📊 Project-Wide Code Review
## 1. Architectural Highlights & Best Practices
### A. Protocol Stream Safety (Logging to Stderr)
• The Design: MCP servers communicating via the stdio transport use stdout exclusively for
JSON-RPC protocol messages. Any standard print statements or unstructured logs written to
stdout will corrupt the protocol stream and cause client-side connection failures.
• The Implementation: In main.py, the root logger is configured to send all logs to sys.
stderr using the structured JsonFormatter from pythonjsonlogger .
• Verdict: Excellent. This guarantees that all logs are safe, structured (JSON format), and
completely isolated from the MCP communication channel.
### B. Developer Experience (DX)
• The Makefile provides full life-cycle automation for installation, manual execution,
testing, linting ( flake8 ), formatting ( black ), and type checking ( mypy ).
• The codebase maintains 100% strict compliance with PEP8/flake8 (79-character line limits) and
passes static type checks under mypy without any warning or exception suppression.
──────
## 2. File-by-File Detailed Review
### 📁 main.py
• Initialization: FastMCP simplifies server setup beautifully:
mcp = FastMCP("hello-world-server")
• Exposing Tools: The @mcp.tool() decorator is perfectly utilized. Docstrings are parsed
automatically by FastMCP and transmitted to MCP clients as the official description of the
tool:
@mcp.tool()
def get_system_time() -> str:
"""
Get the current system time in ISO-8601 format and human-readable format.
"""
• Modern Python Features: The get_system_time tool avoids the deprecated utcnow() method,
utilizing standard timezone-aware UTC retrieval:
now_utc = datetime.now(timezone.utc)
• Platform Portability: get_system_info gracefully detects whether it's running on Linux
(reading /proc/meminfo directly) and falls back to POSIX sysconf APIs if running on
macOS/BSD/other UNIX variants, ensuring maximum reliability.
──────
### 📁 test_logging.py and test_greet.py
• Logging Verification: test_logging.py employs a custom caplog_stream Pytest fixture that
intercepts root logging handlers to assert that debug, info, and error outputs generate valid
JSON strings with correct levels. This is highly robust!
• Input Robustness: test_greet.py thoroughly verifies greet behavior on empty strings and
special characters ( !@#$%^&*() ).
• New Tools Coverage: The new system tools are fully covered, verifying output structures and
ensuring the expected system/time labels are present.
──────
## 3. Areas for Improvement & Recommendations
While the project is in a production-ready state, addressing the following points will make the
project even more robust:
### Recommendation 1: Update README Virtual Environment Instructions
• File: README.md
• Issue: The README still suggests setting up a local .venv under # Installation . However,
as documented in your GEMINI.md, direct virtual environment setups can conflict with the
way MCP client launchers handle stdio Python subprocesses.
• Fix: Add a note in README.md warning developers that if the server is executed via an MCP
client (such as Claude Desktop), they must ensure their client configuration points explicitly
to the python executable inside that virtual environment (e.g., /path/to/project/.
venv/bin/python ), rather than just a global python command.
### Recommendation 2: Avoid Swallowing Key Failures in get_system_info
• File: main.py
• Issue: In get_system_info , the else block (POSIX fallback) catches all exceptions using a
bare except Exception: pass . If os.sysconf fails or is missing, mem_details remains
"Memory information not available." without any traceback or warning captured in the logs.
• Fix: Log the exception details at DEBUG or WARNING level so that issues on unsupported
systems can be diagnosed:
except Exception as e:
logger.debug(f"Failed to query POSIX sysconf memory: {str(e)}")
### Recommendation 3: Explicitly Set Pytest Rootdir
• File: Makefile
• Issue: Running pytest without a dedicated pytest.ini config file means it defaults to
scanning the current working directory recursively, which might include .venv files or parent
folders if executed from outside.
• Fix: Create a minimal pytest.ini file in the root of the project to lock down test
detection parameters:
[pytest]
testpaths = .
python_files = test_*.py
──────
### Final Verdict
Score: 9.8 / 10
The project is extremely clean, PEP8 compliant, well-tested, and demonstrates an outstanding
understanding of the Model Context Protocol's stdio transport constraints.
Summary
The strategy for using Python for MCP development with Antigravity CLI was validated with an incremental step by step approach.
A minimal stdio transport MCP Server was started from Python source code and validated with Antigravity CLI running as a MCP client in the same local environment.
Antigravity CLI was then used to extend the sample Python code with several MCP tools and use these tools inside the context for the underlying LLM.
This approach can be extended to more complex deployments using other MCP transports and Cloud based options.
Top comments (0)