DEV Community

Cover image for I wired an MCP server to a watsonx Orchestrate agent — and it changed how I think about agentic AI
Jabulani Ndlovu
Jabulani Ndlovu

Posted on

I wired an MCP server to a watsonx Orchestrate agent — and it changed how I think about agentic AI

#ai #beginners #agentaichallenge #mcp

IBM watsonx Orchestrate · MCP · Beginner · 4 min read

What if your agent didn't need to know how any of its tools work? That's the idea behind MCP — and it's simpler than it sounds.

I'm just getting started with the IBM watsonx Orchestrate ADK (Agent Development Kit). This week I built a beginner-friendly weather agent that uses an MCP server to serve its tools. Here's what I learned.

The concept: M + N, not M × N

The traditional way to build agents is to wire each tool directly into each agent. That gets messy fast.

The old way:

Agent → Tool 1
Agent → Tool 2
Enter fullscreen mode Exit fullscreen mode

With MCP:

Agent → MCP Server → Tool 1
                   → Tool 2
Enter fullscreen mode Exit fullscreen mode

The agent just talks to one MCP server. The server handles everything behind it. Add more tools to the server — the agent automatically gets them. That's the shift.

What I built

A simple weather agent with two capabilities:

  • Get the current weather for a city
  • Get a multi-day forecast for a city

The MCP server exposes these as tools. The watsonx Orchestrate agent calls them through the toolkit — it never touches the weather API directly.

Here's the full flow:

User prompt
    ↓
watsonx Orchestrate Agent
    ↓
MCP Toolkit: weather_mcp
    ↓
MCP Server
    ↓
Open-Meteo Weather API (free, no key needed)
Enter fullscreen mode Exit fullscreen mode

How the agent is defined

The agent lives in a single YAML file. No code. Just intent:

name: Weather_Reporter_Agent
instructions: |
  You are a helpful weather reporting agent.
  Use get_current_weather for current conditions.
  Use get_weather_forecast for multi-day outlooks.
  Always ask for a city if the user doesn't provide one.
tools:
  - "weather_mcp:get_current_weather"
  - "weather_mcp:get_weather_forecast"
Enter fullscreen mode Exit fullscreen mode

That's it. The agent knows what tools exist, when to use them, and how to respond. The MCP server handles the rest.

Talking to the agent

Once imported into watsonx Orchestrate, the agent is available in the Agent Builder UI. No extra setup.

You can ask it things like:

"What's the weather in Johannesburg right now?"

"Give me a 3-day forecast for Cape Town."

"Will it rain in Durban tomorrow?"

The agent picks the right tool, calls the MCP server, and responds in plain language. The whole thing just works.

Why I think this matters — even at beginner level

The part that clicked for me: the agent and the tools are completely separate. I could swap the weather API tomorrow and the agent definition wouldn't change at all. I could add a new tool to the MCP server and any agent using that toolkit would pick it up automatically.

For a beginner project, that's a surprisingly powerful pattern to start with.

What's next

This was just the foundation. Next I want to:

  • Try connecting multiple agents to the same toolkit
  • Explore how this pattern scales in a real enterprise use case

If you're exploring watsonx Orchestrate or MCP-based agents, I'd love to hear what you're building.

#watsonx #MCP #FastAPI #AgenticAI #ibm #beginners #python

Top comments (0)