Local MCP Development with Python and Antigravity CLI

--- title: Local MCP Development with Python and Antigravity CLI published: true series: agy date: 2026-05-21 15:35:20 UTC tags: mcpserver,python,antigravitycli,antigravity canonical_url: https://xbill999.medium.com/local-mcp-development-with-python-and-antigravity-cli-1be148c0728a --- 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](https://xbill999.medium.com/local-mcp-development-with-python-and-gemini-cli-bfa9cea8bd1b) #### 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](https://medium.com/google-cloud/getting-started-with-antigravity-cli-26c5da90951f) #### 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: ```plaintext agy ``` This will start the interface:  #### Python MCP Documentation The official GitHub Repo provides samples and documentation for getting started: [GitHub - modelcontextprotocol/python-sdk: The official Python SDK for Model Context Protocol servers and clients](https://github.com/modelcontextprotocol/python-sdk) The most common MCP Python deployment path uses the FASTMCP library: [Welcome to FastMCP - FastMCP](https://gofastmcp.com/getting-started/welcome) #### 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: ```shell 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: ```shell 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: ```shell 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: ```python 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: ```shell cd ~/gemini-cli-codeassist/mcp-stdio-python-agy ``` Run the release version on the local system: ```shell cd ~/gemini-cli-codeassist/mcp-stdio-python-agy make release ``` You can validate the final result by checking the messages: ```plaintext 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. ```plaintext 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: ```json { "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: ```console > /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: ```console > 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: ```console > 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: ```plaintext MCP Servers Plugins (~/.gemini/antigravity-cli/plugins) > ✓ hello-stdio-python Tools: greet, get_system_time, get_system_info ``` Get the current time: ```console > 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: ```console > 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: ```plaintext > 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! ```console > 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 - ```plaintext > 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.