Build One AI Tool Server, Call It From Three Different Agents

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:

1. 🖥️ Claude Code (Anthropic’s AI coding assistant)
2. 🐍 A Google ADK agent written in Python
3. 🦀 A Rust command-line app

None of them share a single line of code. Let’s see how.

🤔 First: what is MCP?

Think of MCP as an API on steroids.

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:

• An MCP server is a small program that offers tools. Each tool has a name, a description, and typed parameters — like a function signature the AI can read.
• An MCP client lives inside an AI app. It asks the server “what tools do you have?”, shows them to the AI model, and forwards the model’s tool calls back to the server.

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 stdout is the communication channel, an MCP server must never print() to it. Our server logs to stderr instead. One stray print statement would garble the protocol!

🤖 And what is an “agent”?

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.

🗺️ The project at a glance

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: 4 tools in ~300 lines

The server is built with FastMCP, which ships with the official mcp Python package. Writing a tool is as easy as decorating a function:

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 is the documentation the AI sees.

The server exposes four 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.

🔁 The cool part: edits that remember

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:

In practice, a conversation looks like this:

1. You: “Generate a cyberpunk ramen kitchen, 16:9”
2. Agent calls generate_image(...) → gets back "Saved to gen_...png Interaction ID: int_abc"*
3. You: “Nice — add a neon sign that says RAMEN”
4. Agent calls edit_image(previous_interaction_id="int_abc", edit_prompt="add a neon RAMEN sign")
5. The model edits that exact image, keeping the style and details consistent 🎉

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.

📦 Why the tools return file paths, not images

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:

• Token economy. A base64-encoded PNG is huge. Stuffing it into the AI’s context would waste thousands of tokens for nothing — the AI can’t do much with raw pixels, but it can absolutely tell you a file path.
• Friendly errors. Every tool catches exceptions and returns a readable 🔴 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).

🔌 Consumer 1: Claude Code (zero code!)

Plugging the server into Claude Code takes only a config file, .mcp.json:

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.

🐍 Consumer 2: a Google ADK agent

The Agent Development Kit (ADK) 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:

Two things worth noticing:

• We never define generate_image in this file. The toolset imports the tools over the protocol at startup.
• The instruction explicitly tells the LLM to track interaction IDs. The protocol carries the ID; the LLM's memory keeps it.

Run it with adk run nb2lite_adk_agent for a chat in your terminal, or adk web for a browser UI.

🦀 Consumer 3: a Rust CLI

To prove the “any language” claim, the repo includes a Rust client using , the official Rust MCP SDK. It spawns the same Python server as a child process:

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.

🧠 The takeaway

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.

🚀 Try it yourself

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):

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!)

Originally published at https://dev.to on July 15, 2026.