Beyond Function Calling: How the Model Context Protocol (MCP) Turns AI Agents into Self-Evolving Systems

Anthropic's Model Context Protocol (MCP) transforms AI agents from isolated language models into self-evolving systems by replacing brittle hardcoded tool calling with a standardized, bidirectional integration bus. The Hermes Agent architecture implements MCP as a "universal workshop interface" that cleanly separates cognitive capability from operational capability, allowing agents to dynamically discover and use tools without retraining. This approach solves the scalability and security problems of traditional function calling by using JSON Schema contracts that serve as both machine-readable specifications and neural network-friendly instructions.

Imagine building a highly skilled master craftsman. This craftsman possesses immense cognitive power—the ability to reason, plan, and decompose incredibly complex problems. But there’s a catch: they are locked in an empty, windowless room. They have no raw materials, no specialized tools, and no way to interact with the outside world. Their brilliant cognitive power remains entirely theoretical. This is the state of most modern Large Language Models LLMs . They are intellectual giants trapped in digital sensory deprivation chambers. To break them out, we historically relied on hardcoded "tool calling" or custom API integrations. But anyone who has built production-grade AI agents knows the painful truth: hardcoded tool execution is brittle, monolithic, and incredibly difficult to scale. Every time you add a new tool, you risk confusing the model, breaking your prompts, or introducing critical security vulnerabilities. A quiet revolution is underway to solve this once and for all. It is called the Model Context Protocol MCP . In this deep dive, we will explore how the Hermes Agent architecture implements MCP not just as a way to call tools, but as a universal, bidirectional, and standardized integration bus . We will look at the production-grade Python patterns that turn an isolated LLM into a modular, self-improving "system of systems." The concepts and code demonstrated here are drawn from my ebook Hermes Agent, The Self-Evolving AI Workforce https://tiny.cc/HermesAgent To understand the Model Context Protocol, we must first discard the mental model of a simple function call. MCP is not an API endpoint; it is a standardized workshop interface . It defines the exact specifications for every tool, every drawer, every power outlet, and every raw material bin in our craftsman's workshop. It doesn't matter if a tool is a simple local file writer or a complex browser automation suite hosted on a remote server. As long as it adheres to the MCP standard, the agent can pick it up and use it without any retraining. This architectural shift achieves a clean separation of cognitive capability the agent from operational capability the tools . In the Hermes codebase, this separation is stark: AIAgent class is the craftsman. It doesn't know how to search the web, execute code, or read databases. It only knows how to reason and issue intent. model tools.py acts as the "nervous system," translating the agent's intent into standardized protocol calls and routing them to the appropriate tool hosts.This architecture stands on three core pillars: Standardized Schema Definition , Secure Client-Server Communication , and Closed-Loop Observability . Let's break down how each of these is implemented in production code. In traditional software engineering, we rely on rigid API contracts. In an agentic architecture, the contract must be understood by both machines and probabilistic neural networks. Under MCP, this contract is a JSON Schema that serves three distinct purposes simultaneously: But static schemas are a recipe for failure. If you present a model with 100 tools at once, its reasoning capability degrades due to context distraction. The solution? Dynamic, context-aware schema generation. Below is how Hermes dynamically computes tool definitions at runtime: model tools.py - Dynamic, context-aware schema computation def get tool definitions enabled toolsets: List str = None, disabled toolsets: List str = None, quiet mode: bool = False, - List Dict str, Any : """ Get tool definitions for model API calls with toolset-based filtering. All tools must be part of a toolset to be accessible. """ ... toolset resolution logic ... Ask the registry for schemas only returns tools whose check fn passes filtered tools = registry.get definitions tools to include, quiet=quiet mode Rebuild execute code schema to only list sandbox tools that are actually available if "execute code" in available tool names: sandbox enabled = SANDBOX ALLOWED TOOLS & available tool names dynamic schema = build execute code schema sandbox enabled, mode= get execution mode Replace static schema with the dynamically generated one for tool in filtered tools: if tool "name" == "execute code": tool "parameter schema" = dynamic schema break Rebuild discord schemas based on bot's privileged gateway intents if discord tool name in available tool names: dynamic schema = build discord schema based on intents Replace static schema with dynamic one for tool in filtered tools: if tool "name" == discord tool name: tool "parameter schema" = dynamic schema break return filtered tools The schema is not a static document; it is a living contract. If the agent's code execution sandbox loses access to a specific library, the execute code schema is instantly rebuilt to omit that capability. If a Discord bot lacks certain admin permissions, those tools vanish from the schema. By dynamically tailoring the schema to the environment, you prevent the LLM from attempting impossible actions, dramatically cutting down on execution errors and wasted API tokens. Even with perfect schemas, LLMs occasionally output malformed JSON e.g., trailing commas, unclosed brackets, or Python-style None instead of JSON null . To maintain system reliability, the orchestrator must perform self-healing on the incoming data before validation: python run agent.py - Defensive schema enforcement import re def repair tool call arguments raw args: str, tool name: str = "?" - str: """Attempt to repair common LLM-generated malformed JSON arguments.""" raw stripped = raw args.strip Fast-path: empty / whitespace-only - empty object if not raw stripped: return "{}" Python-literal None - normalize to {} if raw stripped == "None": return "{}" fixed = raw stripped 1. Strip trailing commas before closing braces or brackets fixed = re.sub r',\s }\ ', r'\1', fixed 2. Fix unescaped newlines inside string values 3. Ensure balanced structural characters ... additional robust repair logic ... return fixed By placing this validation and repair layer directly in the orchestrator, we prevent raw, malformed syntax from crashing the underlying tool servers. MCP decouples the agent from its tools by running them in separate processes, containers, or even different machines. This separation provides: However, this introduces a major technical hurdle: the async impedance mismatch . Modern LLM orchestrators often run in synchronous, multi-threaded environments like CLI loops or synchronous web workers , while MCP servers are inherently asynchronous relying on non-blocking network I/O, WebSockets, or subprocess pipes . If you try to block an active async event loop from a sync context, you will quickly run into the dreaded RuntimeError: This event loop is already running or Event loop is closed errors. To solve this, Hermes implements a robust asynchronous bridge that manages three distinct event loop strategies depending on the calling thread's state: python model tools.py - The Async Bridge import asyncio import threading import concurrent.futures def run async coro : """Run an async coroutine safely from any synchronous context.""" try: loop = asyncio.get running loop except RuntimeError: loop = None if loop and loop.is running : Scenario A: We are inside an active async context e.g., FastAPI gateway . We must offload the coroutine to a fresh background thread to avoid blocking. pool = concurrent.futures.ThreadPoolExecutor max workers=1 future = pool.submit run in worker, coro try: return future.result timeout=300 except concurrent.futures.TimeoutError: Gracefully cancel the coroutine inside its own worker loop cancel all worker tasks raise finally: pool.shutdown wait=False Scenario B: We are on a worker thread. Use a per-thread persistent event loop. if threading.current thread is not threading.main thread : worker loop = get worker loop return worker loop.run until complete coro Scenario C: We are on the main thread. Use a shared, persistent tool loop. tool loop = get tool loop return tool loop.run until complete coro The true magic of the Model Context Protocol is not just that it allows an agent to act, but that it enables the agent to learn from its actions . Every tool call is a telemetry event that feeds back into the agent's memory. When the agent calls a tool, the orchestrator doesn't just return the raw string output. It measures execution latency, captures system logs, tracks resource consumption, and triggers hooks that modify the agent's internal state. Here is how the central dispatch function handles this feedback loop: python model tools.py - Observability-Driven Tool Dispatch import time def handle function call function name: str, function args: Dict str, Any , task id: Optional str = None, tool call id: Optional str = None, session id: Optional str = None, ... context variables ... - str: 1. Enforce argument coercion and validation against schema coerced args = validate and coerce function name, function args 2. Measure precise tool dispatch latency dispatch start = time.monotonic try: Execute the tool via the registered MCP client result = registry.dispatch function name, coerced args is error = False except Exception as e: result = str e is error = True duration ms = int time.monotonic - dispatch start 1000 3. Fire post-execution hooks with performance and telemetry data invoke hook "post tool call", tool name=function name, args=coerced args, result=result, duration ms=duration ms, failed=is error 4. Allow registered plugins to sanitize or canonicalize the raw output hook results = invoke hook "transform tool result", tool name=function name, result=result for hook result in hook results: if isinstance hook result, str : result = hook result break return result This telemetry data doesn't just sit in a log file; it is consumed live by the agent to make strategic decisions: failed flag and automatically attempts a fallback strategy e.g., querying an alternate search index .The pinnacle of this closed-loop observability is what we call the Ouroboros Pattern —an agent recursively using its own tools to review and optimize its own behavior. In Hermes, when a main task is completed, the orchestrator spawns a background "Review Agent." This review agent is given access to a highly specialized subset of tools: memory and skills . It reads the transaction log of the conversation that just occurred, analyzes what went right and what went wrong, and writes new procedural knowledge directly back to the main agent's persistent memory. run agent.py - The Ouroboros Self-Improvement Loop def spawn background review self, messages snapshot, review memory, review skills : """Spawn a background thread to review the conversation and save new skills/memories.""" def run review : Instantiate a clean, lightweight agent inheriting the parent's API runtime review agent = AIAgent model=self.model, max iterations=16, quiet mode=True, provider=self.provider, api key=self.api key, enabled toolsets= "memory", "skills" , Restrict tools to memory writing review prompt = "Analyze the conversation history. Extract key user preferences, " "successful code patterns, or tool execution failures. Use the " "provided tools to save these as persistent memories or skills." Run the review conversation in the background review agent.run conversation user message=review prompt, conversation history=messages snapshot, Summarize actions taken during self-improvement actions = self. summarize background review actions review agent.history if actions: summary = " · ".join dict.fromkeys actions self. safe print f" 💾 Self-improvement complete: {summary}" Spawn off the main thread so the user never experiences latency threading.Thread target= run review, daemon=True .start This background review loop is completely non-blocking. While the user is reading the agent's response, a background thread is spinning up a separate context, evaluating the tool execution latency, and updating the agent's "Soul," "Memory," and "Skills" databases. On the very next prompt, the agent is already smarter, faster, and more aligned with the user's workflow. To visualize how these components interact, let's look at the flow of a single user interaction through this multi-layered architecture: This is the power of the MCP Revolution: action and learning are two sides of the same coin. For years, developers treated AI agents like traditional software programs—writing rigid, hardcoded wrappers around API calls. The Model Context Protocol changes the paradigm. By standardizing the communication layer, dynamically generating schemas, building robust async bridges, and hooking telemetry directly into self-improvement loops, we transition from building static tool users to deploying dynamic, self-evolving tool weavers . If you are still writing custom wrapper functions for every API you want your LLM to use, it is time to step into the workshop. The tools are ready. The craftsman is waiting. It's time to build. Leave a comment below with your thoughts and architectural approaches The concepts and code demonstrated here are drawn directly from the comprehensive roadmap laid out in the ebook Hermes Agent, The Self-Evolving AI Workforce : details link https://tiny.cc/HermesAgent , you can find also my programming ebooks with AI here: Programming & AI eBooks http://tiny.cc/ProgrammingBooks .