Hey Devs!
Jesse here, solo-building Portal One – an AI Agent Command Center to help you build, manage, and actually rely on your AI agents.
One of the biggest challenges I've hit? Getting AI agents to reliably navigate multi-step tasks. You know the feeling: you design this brilliant workflow, and the agent wanders off, picks the wrong tool, or just plain freezes, overwhelmed by choices. It’s like giving a toddler the keys to a spaceship.
My "aha!" moment came when I realized: maybe I'm giving them too much freedom, too many tools, all at once.
So, I dove into making our Model Context Protocol (MCP) server smarter – making it dynamic. Instead of just serving up a static list of all possible tools, it now adapts what the agent can see and do based on the actual state of the task. Think of it as giving the agent blinders, so it can only focus on what's relevant right now.
Here are a few key realizations from that journey:
1. The "Kid in a Candy Store" Problem: Too Many Tools Spoil the Agent
Initially, my MCP server was like an eager waiter listing every single item on a 50-page menu. For an AI agent, this is overwhelming. When an agent sees a giant list of tools, especially if their names are similar or their purposes overlap, it increases the chance of it picking the wrong one or getting stuck in a loop trying to decide.
The Realization:
Agents perform way better with a curated, context-specific list of capabilities. If the task is "start the game," the agent shouldn't even see the "make a guess" tool yet.
How Dynamic MCP Helps:
The server now only exposes tools relevant to the agent's current state. This drastically reduces the "action space" the agent has to consider, making its decisions simpler and more accurate. It's a core idea in the Model Context Protocol – the server can control what list_tools returns based on context.
2. Let the Server Be the "Task Chaperone," Not Just a Vending Machine
My early agents felt like they were just blindly hitting an API. They'd call a tool, get a response, and then it was entirely up to their (sometimes flawed) logic to figure out what to do next. This often led to them trying things out of order or missing crucial steps.
The Realization:
The server can, and should, play an active role in guiding the agent through a task by managing the state and updating the agent's context.
Our Solution: The Number Guessing Game Demo
To really nail this down, I built a simple Number Guessing Game where the AI is the player.
- Lobby State: The agent only sees a
start_gametool. - Agent calls
start_game: The server's internal state changes to "Playing." - Playing State: Now, the
start_gametool is gone. Instead, it seesmake_guessandgive_up_game. - Dynamic Tool Schema: Even better, after a guess, the schema for
make_guesscan change! If the agent guessed too low, the tool's description might update to "Guess a number between 51 and 100."
This way, the server isn't just passively responding; it's actively shaping the agent's understanding of what's possible and sensible at each step. You can see the code for this demo server on GitHub. It really shows how the MCP TypeScript SDK can be used to build these stateful interactions.
3. "Show, Don't Just Tell" Still Wins for Complex Ideas
Explaining "dynamic, state-aware, context-adaptive capability provisioning for AI agents" is a mouthful and usually gets blank stares.
The Realization:
A simple, interactive demo makes abstract concepts click. The Number Guessing Game, as basic as it is, perfectly illustrates the power of a dynamic MCP. People get it when they see the tool list change or the tool's instructions adapt in real-time.
Want the Full Scoop?
This is just a peek at how we're thinking about making AI agents more dependable. The shift to a dynamic MCP server has been a game-changer for us.
I wrote up a more detailed explanation of the architecture, the "why" behind it, and how it all fits together on the Portal One blog.
And definitely check out the Number Guessing Game demo server on GitHub to see it in action!
Top comments (0)