Build One AI Tool Server, Call It From Three Different Agents (MCP Explained)

A developer built a single MCP server that exposes image-generation tools via the Model Context Protocol, allowing three different AI agents—a Google ADK agent, a Rust CLI client, and Claude Code—to call the same server over stdio. The server uses FastMCP to wrap Google's Gemini image model and supports stateful editing through the Interactions API.

Have you ever wanted to give an AI assistant a new ability — like generating images — and have that ability work in any AI tool you use, not just one? That's exactly what this project does, and the magic ingredient is the Model Context Protocol MCP . In this article we'll walk through a real, working repo where one small Python server gives image-generation superpowers to three completely different programs : None of them share a single line of code. Let's see how. Think of MCP as USB-C for AI tools . Before USB-C, every device needed its own special cable. Before MCP, every AI app needed its own special plugin format — a ChatGPT plugin didn't work in Claude, a Claude tool didn't work in your Python agent, and so on. MCP fixes this with a simple split: The two sides talk JSON messages. The simplest way they connect is called stdio : the client just launches the server as a child process and they chat over standard input/output — the same pipes you use when you run echo hi | grep h . 💡 Fun consequence:because stdoutisthe communication channel, an MCP server must never print to it. Our server logs tostderrinstead. One stray print statement would garble the protocol An agent is an AI model in a loop with tools: the model reads your request, decides a tool would help, calls it, reads the result, and keeps going until the job is done. The AI is the brain; MCP tools are the hands. Here's the repo layout: nb2lite-agent-claude/ ├── MCP/ ← the star: an MCP server wrapping Gemini's image model │ └── server.py ├── python/ ← consumer 1: a Google ADK agent ├── rust/ ← consumer 2: a Rust CLI client └── .mcp.json ← consumer 3: config that plugs the server into Claude Code And here's how the pieces connect: Claude Code ──┐ ADK agent ──┼── MCP over stdio ──► MCP/server.py ──► Gemini image API Rust CLI ──┘ │ ▼ images/ folder your generated PNGs Three arrows in, one server, one API out. The Gemini-specific code exists in exactly one file . The server is built with FastMCP , which ships with the official mcp Python package. Writing a tool is as easy as decorating a function: python from mcp.server.fastmcp import FastMCP mcp = FastMCP "NB2Lite Agent" @mcp.tool def generate image prompt: str, aspect ratio: str = "1:1", thinking level: str = "low" - str: """Generates a new image from a text prompt.""" ... That's it. FastMCP reads the function signature and docstring and automatically tells every connected AI: "there's a tool called generate image, here's what it does, here are its parameters." Your code The server exposes four tools: | Tool | What it does | |---|---| generate image | Text prompt → brand-new image | edit image | "Change X in the image we just made" | edit local image | Edit an image file from your disk | get help | The server describes its own config and tools | Under the hood, they all call Google's gemini-3.1-flash-lite-image model — a fast image model — through something called the Interactions API . Most image APIs are goldfish: every request starts from zero. The Interactions API is different — it's stateful . Every generation returns an interaction id , and you can pass that ID back to continue the session: interaction = ai client.interactions.create model=MODEL NAME, previous interaction id=previous interaction id, 👈 "continue from here" input=edit prompt, response format={"type": "image"}, store=True, 👈 remember this interaction on Google's side In practice, a conversation looks like this: generate image ... → gets back int abc " edit image previous interaction id="int abc", edit prompt="add a neon RAMEN sign" Notice who remembers what: Google's servers store the image session, and the agent's conversation memory holds the ID. The MCP server itself stays stateless — you can restart it anytime. A tool could send the image bytes back to the AI. This server deliberately doesn't — it saves the file to disk and returns a short message: 🟢 Image successfully saved • Saved to: /home/you/images/gen 1780123456 a3b2c1d0.png • Interaction ID: int abc Two beginner-friendly lessons hide in here: 🔴 Image generation failed: ... string instead of crashing. The AI reads the error and can fix its own mistake wrong aspect ratio? it'll retry with a valid one .Plugging the server into Claude Code takes only a config file, .mcp.json : { "mcpServers": { "nb2lite-agent": { "type": "stdio", "command": "python3", "args": "/path/to/MCP/server.py" , "env": { "GEMINI API KEY": "${GEMINI API KEY}" } } } } Claude Code launches the server, discovers the four tools, and from then on you can just type "generate a 16:9 image of a mountain sunrise" in your coding session. The Agent Development Kit ADK https://google.github.io/adk-docs/ is Google's framework for building your own agents. Its MCPToolset does all the MCP plumbing — spawn the server, do the handshake, convert every discovered tool into something the LLM can call: root agent = LlmAgent name="nb2lite adk agent", model="gemini-2.5-flash", instruction="...remember the most recent Interaction ID and pass it " "as previous interaction id for follow-up edits...", tools= MCPToolset connection params=StdioConnectionParams server params=StdioServerParameters command="python3", args= str MCP SERVER , , , , Two things worth noticing: generate image in this file. The toolset instruction explicitly tells the LLM to track interaction IDs. The protocol carries the ID; the LLM's memory Run it with adk run nb2lite adk agent for a chat in your terminal, or adk web for a browser UI. To prove the "any language" claim, the repo includes a Rust client using rmcp https://crates.io/crates/rmcp , the official Rust MCP SDK. It spawns the js let service = .serve TokioChildProcess::new Command::new "python3" .configure |cmd| { cmd.arg &server ; }, ? .await?; let result = service .call tool CallToolRequestParam { name: "generate image".into , arguments: json { "prompt": prompt, "aspect ratio": "16:9" } .as object .cloned , } .await?; There's no AI model in this binary at all — it's a plain program calling the tools directly: cargo run -- tools list the tools cargo run -- generate "a cyberpunk ramen kitchen" 16:9 high make an image cargo run -- edit int abc123 "add a neon RAMEN sign" refine it That's a nice mental model to end on: an MCP tool call is just a function call over a pipe. An LLM can make it, and so can your shell script. Without MCP, supporting these three consumers means three integrations : a Claude-specific setup, an ADK wrapper, and a Rust port of the Gemini client. Three places to update every time the API changes. With MCP, the capability lives in one file , and each consumer is ~30 lines of config or boilerplate. Adding a fourth consumer tomorrow — LangChain, an editor plugin, whatever — costs about the same. Write the tool once. Let every agent call it. The server is published as a ready-to-run Docker image — you don't need the repo at all. Point any MCP client at it this is a .mcp.json for Claude Code : { "mcpServers": { "nb2lite-agent": { "type": "stdio", "command": "docker", "args": "run", "-i", "--rm", "-e", "GEMINI API KEY", "-v", "/absolute/path/to/images:/images", "xbill9/nb2lite-mcp:latest" } } } Set GEMINI API KEY in your environment, ask your agent to generate an image, and check your mounted images/ folder. Remember: -i but never -t — a TTY corrupts the protocol stream Questions about MCP, ADK, or the Rust side? Drop them in the comments 👇