Por qué un modelo no puede simplemente "saberlo"

Un modelo de lenguaje se entrena una vez, sobre un corpus de texto con una fecha de corte, y luego queda congelado: no aprende nada nuevo entre esa fecha y el momento en que tú le escribes. Eso significa que no puede saber el precio del bitcoin ahora mismo, ni si va a llover esta tarde en tu ciudad, ni el resultado de un partido que se jugó ayer, por la razón simple de que esa información no existía todavía cuando se generaron sus parámetros.

Lo inquietante no es esa limitación en sí —es lógica y esperable—, sino que un modelo mal instruido puede rellenar ese hueco con una respuesta que suena perfectamente segura de sí misma, sin ninguna señal visible de que se lo ha inventado. Nuestra guía sobre alucinaciones de la IA cubre ese problema en detalle; esta guía cubre la solución técnica: dejar de pedirle al modelo que "sepa" cosas y, en su lugar, darle una forma de consultarlas en el momento.

Hay un matiz que conviene aclarar porque genera confusión: algunos modelos comerciales sí tienen acceso a una herramienta de búsqueda web integrada de fábrica, y eso les permite responder preguntas sobre hechos recientes sin que tú programes nada. Pero esa búsqueda integrada es exactamente el mismo mecanismo que esta guía te enseña a montar por tu cuenta — una herramienta más, con su propio nombre y su propia función detrás —, solo que ya viene configurada por el proveedor. En el momento en que necesitas un dato de tu sistema (tu inventario, tu base de clientes, tu API interna), esa búsqueda web genérica ya no sirve, y ahí es donde entra construir tu propia herramienta.

Cómo funciona el mecanismo, paso a paso

El proceso tiene siempre la misma forma, sea Claude, ChatGPT o Gemini el modelo que uses: tú le describes una "herramienta" disponible (un nombre, qué hace, qué datos necesita para funcionar) en la misma llamada donde envías tu pregunta. El modelo no ejecuta nada por sí mismo — decide si necesita esa herramienta y, si es así, te devuelve una petición estructurada pidiéndote que la ejecutes tú. Tu código la ejecuta de verdad, y le devuelve el resultado real en un segundo mensaje. Solo entonces el modelo redacta la respuesta final, ya con el dato correcto en la mano.

1. Tú: "¿Qué tiempo hace en Valencia?"
2. Modelo: "Necesito usar la herramienta obtener_tiempo(ciudad='Valencia')"
3. Tu código: ejecuta la llamada real a la API del tiempo
4. Tu código: devuelve el resultado al modelo: "22°C, viento 12 km/h"
5. Modelo: "Ahora mismo en Valencia hace 22°C con viento suave."

Fíjate en el detalle clave: el modelo nunca toca internet directamente. No tiene ni puede tener acceso a la red por su cuenta — todo pasa por tu código, en el paso 3. Eso es una ventaja de seguridad, no una limitación: tú decides exactamente qué puede consultar el modelo y qué no, revisando cada petición antes de ejecutarla si hace falta.

Pruébalo tú mismo, ahora mismo

Esta caja hace de verdad los cuatro pasos de arriba, en vivo, con datos reales del servicio gratuito Open-Meteo — sin clave, sin registro, sin coste. Escribe una ciudad y pulsa el botón: verás primero la "decisión" simulada del modelo, después la respuesta cruda de la API real, y por último cómo quedaría la respuesta ya redactada para un humano.

El código real que hace esto con Claude

Lo que acabas de ver simula el proceso en JavaScript directamente en el navegador para que puedas probarlo sin instalar nada. En una aplicación real, el modelo de IA es quien decide si hace falta llamar a la herramienta, no una regla fija en el código. Así se ve con la API de Claude en Python:

import anthropic, requests

client = anthropic.Anthropic()  # lee ANTHROPIC_API_KEY del entorno

herramientas = [{
    "name": "obtener_tiempo",
    "description": "Da la temperatura y condición actual de una ciudad",
    "input_schema": {
        "type": "object",
        "properties": {"ciudad": {"type": "string"}},
        "required": ["ciudad"]
    }
}]

def obtener_tiempo(ciudad):
    geo = requests.get("https://geocoding-api.open-meteo.com/v1/search",
                        params={"name": ciudad, "count": 1}).json()
    lat, lon = geo["results"][0]["latitude"], geo["results"][0]["longitude"]
    clima = requests.get("https://api.open-meteo.com/v1/forecast",
                          params={"latitude": lat, "longitude": lon,
                                  "current": "temperature_2m,weather_code"}).json()
    return clima["current"]

mensajes = [{"role": "user", "content": "¿Qué tiempo hace en Lima?"}]
respuesta = client.messages.create(
    model="claude-sonnet-5", max_tokens=1024,
    tools=herramientas, messages=mensajes
)

if respuesta.stop_reason == "tool_use":
    llamada = next(b for b in respuesta.content if b.type == "tool_use")
    resultado = obtener_tiempo(llamada.input["ciudad"])

    mensajes.append({"role": "assistant", "content": respuesta.content})
    mensajes.append({"role": "user", "content": [{
        "type": "tool_result",
        "tool_use_id": llamada.id,
        "content": str(resultado)
    }]})

    final = client.messages.create(
        model="claude-sonnet-5", max_tokens=1024,
        tools=herramientas, messages=mensajes
    )
    print(final.content[0].text)

Nota las dos llamadas al modelo: la primera para que decida si necesita la herramienta, la segunda para que redacte la respuesta ya con el dato real en la mano. Eso es exactamente lo que separaba las cajas "1" y "3" de la demo de arriba — aquí es el propio modelo, no una función de JavaScript escrita a mano, quien decide llamar a obtener_tiempo.

El mismo patrón funciona con ChatGPT (el campo se llama tools también, con function anidado) y con Gemini (function_declarations). Cambia el nombre exacto de un par de campos en el JSON; la idea de fondo —describir la herramienta, dejar que decida, ejecutar tú, devolver el resultado— es idéntica en los tres.

Un detalle que sorprende la primera vez: el input_schema de la herramienta no es solo documentación decorativa para el modelo, es una restricción real. Si defines ciudad como string obligatorio, el modelo no puede llamar a la función sin ese dato — como mucho, si el usuario no lo mencionó, el modelo te pedirá que lo aclares antes de intentar la llamada. Cuanto más preciso sea ese esquema (tipos correctos, campos obligatorios bien marcados, una descripción que deje claro qué formato espera cada parámetro), menos errores de "argumento inválido" tendrás que manejar en tu propio código más adelante.

Antes de dar por buena cualquier herramienta nueva, merece la pena probarla con al menos tres tipos de entrada distintos: una consulta directa y bien formada ("el tiempo en Bogotá"), una ambigua (una ciudad que existe en varios países, como "Córdoba" o "Guadalajara") y una que debería fallar limpiamente (una ciudad inventada). Ver cómo se comporta el modelo en los tres casos —sobre todo el tercero— dice mucho más sobre si tu agente está listo para usuarios reales que verlo funcionar una sola vez con el ejemplo perfecto que escribiste tú mismo para probarlo.

Más allá del tiempo: qué otras APIs puedes conectar

El clima es solo el ejemplo más fácil de probar sin fricción. El mismo patrón de código sirve para cualquier fuente de datos con una API HTTP normal — que hoy son literalmente miles, catalogadas en listas colaborativas como public-apis, con casi 500.000 estrellas en GitHub y categorías que van desde finanzas y criptomonedas hasta datos abiertos de gobiernos, transporte público o noticias.

El criterio para elegir una API con la que empezar no es "la más potente", sino la que resuelve un problema real que ya tienes. Si gestionas pedidos, empieza por una API de seguimiento de envíos; si sigues mercados, por una de precios; el patrón de código de la sección anterior es el mismo en todos los casos, solo cambia qué función ejecutas dentro de obtener_tiempo.

Errores y riesgos que no puedes ignorar

De aquí a un agente completo

Una sola herramienta ya es útil, pero el patrón se acumula: un agente real normalmente tiene entre tres y diez herramientas disponibles a la vez (consultar el tiempo, buscar un pedido, leer un archivo, enviar un correo), y decide por sí mismo cuál o cuáles necesita para cada petición concreta, encadenando varias si hace falta. Es el mismo bucle que viste arriba, repetido tantas veces como el modelo lo pida, hasta que ya no necesita ninguna herramienta más y da la respuesta final.

Cuando ese catálogo de herramientas crece, escribir y mantener cada definición a mano dentro de tu propio código deja de escalar bien — ahí es exactamente donde entra MCP, que empaqueta grupos de herramientas relacionadas en un "servidor" reutilizable entre proyectos distintos, en vez de redefinir obtener_tiempo desde cero cada vez que empiezas algo nuevo. Y si lo que quieres es que ese agente corra solo, en un horario, sin que tú lo dispares cada vez, ese es el terreno de n8n, que tiene un nodo de "AI Agent" con este mismo mecanismo de herramientas integrado visualmente.