MCPHero: El puente entre MCP y las librerías tradicionales de IA
3 min de lectura

MCPHero: El puente entre MCP y las librerías tradicionales de IA

590 palabras

Últimamente estoy siguiendo de cerca todo lo que rodea al protocolo MCP (Model Context Protocol), y hace poco me encontré con un proyecto que tiene bastante sentido: MCPHero.

La realidad es que aunque MCP está pegando fuerte, muchas librerías de IA “tradicionales” como openai o google-genai siguen sin soporte nativo para MCP. Solo soportan tool/function calls. MCPHero viene a solucionar precisamente esto: hacer de puente entre servidores MCP y estas librerías.

¿Qué es MCPHero?

MCPHero es una librería Python que permite usar servidores MCP como tools/functions en las librerías nativas de IA. Básicamente, te permite conectarte a cualquier servidor MCP y usar sus herramientas como si fueran tools nativas de OpenAI o Google Gemini.

El problema que resuelve

La situación actual es un poco… peculiar. Por un lado tenemos el ecosistema MCP creciendo, con servidores que exponen herramientas útiles. Por otro lado, tenemos clientes de IA muy establecidos (OpenAI, Google Gemini) que solo entienden de “tools” o “function calls” en su formato propietario.

MCPHero cierra esa brecha: se conecta al servidor MCP, obtiene las definiciones de herramientas, las convierte al formato que entiende la librería de IA, y cuando la IA quiere usar una herramienta, MCPHero ejecuta la llamada en el servidor MCP y devuelve el resultado.

Cómo funciona: dos flujos principales

1. list_tools - Obtener las definiciones

tools = await adapter.get_tool_definitions()

MCPHero llama al servidor MCP via HTTP, obtiene las definiciones de herramientas, y las mapea al formato de la librería de IA que estés usando.

2. process_tool_calls - Ejecutar las llamadas

tool_results = await adapter.process_tool_calls(tool_calls)

Cuando la IA decide usar una herramienta, MCPHero intercepta esas llamadas, las ejecuta en el servidor MCP, y devuelve los resultados en el formato que espera la librería.

Ejemplo rápido con OpenAI

import asyncio
from openai import OpenAI
from mcphero.adapters.openai import MCPToolAdapterOpenAI

async def main():
    # Conectar al servidor MCP
    adapter = MCPToolAdapterOpenAI("https://api.mcphero.app/mcp/your-server-id")
    client = OpenAI()

    # Obtener tool definitions
    tools = await adapter.get_tool_definitions()

    # Hacer la petición con tools
    messages = [{"role": "user", "content": "What's the weather in London?"}]
    response = client.chat.completions.create(
        model="gpt-4o",
        messages=messages,
        tools=tools,
    )

    # Procesar tool calls si las hay
    if response.choices[0].message.tool_calls:
        tool_results = await adapter.process_tool_calls(
            response.choices[0].message.tool_calls
        )

        # Continuar conversación con resultados
        messages.append(response.choices[0].message)
        messages.extend(tool_results)

        final_response = client.chat.completions.create(
            model="gpt-4o",
            messages=messages,
            tools=tools,
        )
        print(final_response.choices[0].message.content)

asyncio.run(main())

Soporte para Google Gemini

Lo interesante es que también soporta Google Gemini:

from mcphero.adapters.gemini import MCPToolAdapterGemini

adapter = MCPToolAdapterGemini("https://api.mcphero.app/mcp/your-server-id")

El concepto es el mismo: obtener las herramientas, pasarlas a Gemini, y procesar las function calls.

Manejo de errores

Algo que valoro es que tiene manejo de errores decente:

# Devuelve errores en los resultados (por defecto)
results = await adapter.process_tool_calls(tool_calls, return_errors=True)

# O salta las llamadas fallidas
results = await adapter.process_tool_calls(tool_calls, return_errors=False)

Por qué me interesa

Tengo varias razones para tener MCPHero en mi radar:

  1. Compatibilidad hacia atrás: No tienes que abandonar tu código actual con OpenAI o Gemini
  2. Ecosistema MCP: Puedes aprovechar los servidores MCP que ya existen
  3. Flexibilidad: Soporta tanto OpenAI como Google Gemini
  4. Python puro: Fácil de integrar en proyectos existentes

En mi lista de pruebas

Como con muchas de las cosas que últimamente me llaman la atención, esto está en mi lista de cosas para probar. Tengo curiosidad por:

  • Ver cómo se comporta en un proyecto real
  • Probar diferentes servidores MCP
  • Evaluar el rendimiento en producción
  • Comparar con usar MCP directamente

Referencias

MCPHero es una herramienta interesante para quienes quieren aprovechar el ecosistema MCP sin abandonar sus librerías de IA existentes, y merece ser evaluada para proyectos donde la compatibilidad hacia atrás sea un requisito importante.

Comentarios

Últimas Entradas

2 min

315 palabras

Lately I’ve been closely following everything around the MCP protocol (Model Context Protocol), and recently I found a project that makes a lot of sense: MCPHero.

The reality is that although MCP is taking off, many “traditional” AI libraries like openai or google-genai still don’t have native MCP support. They only support tool/function calls. MCPHero comes to solve exactly this: make a bridge between MCP servers and these libraries.

What is MCPHero?

MCPHero is a Python library that lets you use MCP servers as tools/functions in native AI libraries. Basically, it lets you connect to any MCP server and use its tools as if they were native OpenAI or Google Gemini tools.

6 min

1147 palabras

Dos protocolos, dos filosofías

En los últimos meses han aparecido dos protocolos que van a cambiar cómo construimos sistemas de IA: Agent2Agent Protocol (A2A) de Google y Model Context Protocol (MCP) de Anthropic. Pero aquí está el tema: no compiten entre sí.

Es más, tras analizar ambos durante semanas, me he dado cuenta de que entender la diferencia entre A2A y MCP es crucial para cualquiera que esté construyendo sistemas de IA más allá de simples chatbots.

8 min

1530 palabras

Otro protocolo más que promete cambiarlo todo

Cuando IBM Research anunció el Agent Communication Protocol (ACP) como parte del proyecto BeeAI, mi primera reacción fue la habitual: “Ah, otro protocolo universal más”. Con casi 30 años en esto, he visto demasiados “estándares definitivos” que acabaron en el olvido.

Pero hay algo diferente en ACP que me hizo prestar atención: no promete resolver todos los problemas del mundo. Simplemente se enfoca en uno muy específico: hacer que agentes de IA de diferentes frameworks puedan hablar entre sí. Y lo hace de una manera que realmente tiene sentido.

6 min

1145 palabras

Confesión de un escéptico convertido

Cuando Anthropic anunció el Model Context Protocol (MCP) en noviembre de 2024, mi primera reacción fue: “Ah, otro protocolo más que promete resolver todos los problemas de integración”. Como DevOps Manager que ha visto nacer y morir docenas de “estándares universales”, tengo razones para ser escéptico.

Pero después de varios meses viendo cómo MCP se ha adoptado masivamente - OpenAI lo integró en marzo 2025, Google DeepMind en abril - decidí investigar más allá del hype. Y tengo que admitir algo: estaba equivocado.

5 min

1020 palabras

I have been using Claude Code daily for months, and there is one configuration that has completely changed how it works with my code. It is not a new plugin, a more powerful model, or a magic prompt. It is something that has existed since 2016 and that most developers use without knowing it every time they open VS Code: the Language Server Protocol (LSP).

Karan Bansal published an excellent article explaining in detail how to enable LSP in Claude Code and why it matters. After trying it, I can confirm the difference is real and significant.

3 min

591 palabras

Greg Brockman, President and Co-Founder of OpenAI, recently published a thread that perfectly describes the moment we’re living in software development. According to him, we’re witnessing a genuine renaissance in software development, driven by AI tools that have improved exponentially since December.

The qualitative leap

The most striking part of Brockman’s thread is how they describe the internal change at OpenAI: engineers who previously used Codex for unit tests now see the tool writing practically all code and handling a large portion of operations and debugging. This isn’t an incremental improvement, it’s a paradigm shift.