DEV Community: Khavel

An embedding model's price is a one-time cost. Its dimensions are a subscription.

Khavel — Tue, 18 Aug 2026 11:44:06 +0000

Embedding models are billed per 1M input tokens, so that's the number that ends up in the comparison. Here are the nine generally-available embedding models that publish a token price, every rate re-read off the provider's own page this morning (2026-08-17):

Model	Provider	$/1M input	Default dims	Max input tokens
`text-embedding-3-small`	OpenAI	$0.02	1536	8192
`amazon.titan-embed-text-v2`	Amazon	$0.02	1024	8192
`text-embedding-v4` (Qwen)	Alibaba	$0.07	1024	8192
`embed-v4.0`	Cohere	$0.12	1536	128,000
`text-embedding-3-large`	OpenAI	$0.13	3072	8192
`nova-2-multimodal-embeddings`	Amazon	$0.135	3072	8192
`gemini-embedding-001`	Google	$0.15	3072	2048
`codestral-embed`	Mistral	$0.15	1536	8192
`gemini-embedding-2`	Google	$0.20	3072	8192

(The Model column is the provider's own model string; the ids in our feed are normalised slightly differently — you'll see both at the end.)

Top to bottom, that's a 10x spread. It is also, for most retrieval workloads, the least consequential number on the row.

The ingestion bill is one-time, and it is small

Take a corpus of 1,000,000 documents averaging 800 tokens. That's 800M tokens to embed.

At $0.02/1M: $16.00
At $0.20/1M: $160.00

The entire 10x spread is $144, once. You will spend more than that deciding which model to use. The token price only becomes interesting again when you re-embed — a model migration, or a corpus that grows continuously — and even then it's a function of new tokens, not of the corpus you already indexed.

Meanwhile the thing you're actually buying is a pile of float vectors that you will store, index, and hold in RAM for as long as the product exists.

The vector is what recurs

One million vectors, float32:

Dimensions	Size
3072	12.29 GB
1536	6.14 GB
1024	4.10 GB
768	3.07 GB
256	1.02 GB

I'm deliberately not multiplying that by a vector-database rate — every managed vector store prices differently and I'm not going to invent a number. Use your own. The point is the shape: this one is monthly, it scales linearly with the dimension count, and picking the 3072-dim model over the 1024-dim one triples it forever.

…except the dimension is usually a knob, not a spec

This is the part that makes the comparison table misleading rather than merely incomplete. On most current models, the dimension count you see published is a default, and you can ask for a smaller vector:

OpenAI — a dimensions request parameter, which its API reference says is supported on text-embedding-3 and later models.
Cohere — embed-v4.0's docs table gives its dimensions as a choice of 256, 512, 1024 or 1536, with 1536 the default.
Google — an output_dimensionality parameter, via Matryoshka Representation Learning. Both Gemini embedding models default to 3072 and Google's docs say you can truncate below that without losing quality, recommending 768, 1536 or 3072.
Amazon — Titan Text Embeddings V2 is documented as having "configurable output dimensions", set via dimensions in the request body.

And Google publishes the trade-off as a table, which is the most useful thing I found all week. MTEB score by truncated dimension, for gemini-embedding-001:

MRL dimension	MTEB score
2048	68.16
1536	68.17
768	67.99
512	67.55
256	66.19
128	63.31

Read that carefully. 1536 scores fractionally higher than 2048. Going from 1536 down to 768 costs 0.18 MTEB points and halves your storage, your index size and your RAM. The cliff doesn't arrive until 256, and it doesn't get steep until 128.

So the honest version of "this model is 3072-dimensional" is "this model defaults to 3072 and its own vendor recommends 768 as a supported option". Those imply storage bills a factor of four apart.

The number that really is fixed: the input ceiling

The context window is the field on these rows that you cannot negotiate, and it varies more than the other two. Cohere's own current lineup spans the entire range:

embed-english-v3.0 — 512 tokens
embed-v4.0 — 128,000 tokens

That's 250x, same vendor, both generally available today. Google moved from 2048 on gemini-embedding-001 to 8192 on gemini-embedding-2. Most of the rest sit at 8192.

Why it compounds: the ceiling caps your chunk size, chunk size sets your vector count, and vector count multiplied by dimensions is your storage and your index. Chunking the same corpus against a 512-token ceiling instead of an 8192-token one yields 16x the vectors. Your token spend barely moves — it's the same text either way — while everything downstream of the embedding call multiplies.

To be fair to the small-context models: almost nobody chunks at the ceiling, because retrieval quality usually wants smaller chunks than the maximum anyway. The ceiling doesn't dictate your chunk size. It removes options, and it's the only one of the three fields where the provider makes the decision for you.

Rerank: there is no ladder to write

I wanted to end with the same table for rerankers. It doesn't exist, and the reason is worth more than the table would have been.

Of the 7 GA rerank models we track, 3 publish a rate, and the unit isn't tokens:

Model	Provider	Price
Amazon Rerank v1	Amazon	$1.00 per 1,000 searches
Rerank 4 Fast	Cohere	$2.00 per 1,000 searches
Rerank 4 Pro	Cohere	$2.50 per 1,000 searches

A "search" is not a standard unit, and it is not a token. AWS's price book bills its reranker in search units — $1 per 1,000 of them — where a unit is a query carrying some bounded number of document chunks, defined in the docs rather than on the price line. Cohere bills per 1,000 searches. Whether those two units mean the same thing for your query shape is your problem, not something either price implies.

That AWS model is also region-scoped in a way the price book makes plain: the SKU (Z7M6S4MRBXNXJRB4) is in us-west-2, and there is no rerank SKU in the us-east-1 price book at all.

The other four GA rerankers publish no first-party rate we could find. In our data those fields are null, which is a fact about the provider, not a gap we're papering over.

Get it as data

All of the above is in a free JSON feed — no key, no signup, CORS open. (If you would rather just look at the 13 rows, they are on one page too.)

curl -s https://aimodelwatch.dev/api/models.json \
  | jq -r '.models[]
      | select(.embedding_dimensions != null and .status == "ga")
      | [.price_input_per_mtok, .embedding_dimensions, .context_window, .id]
      | @tsv' \
  | sort -g

Output, run against the live endpoint today:

0.02    1024    8192    amazon-titan-embed-text-v2
0.02    1536    8192    text-embedding-3-small
0.07    1024    8192    qwen-text-embedding-v4
0.12    1536    128000  embed-v4-0
0.13    3072    8192    text-embedding-3-large
0.135   3072    8192    amazon-nova-2-multimodal-embeddings
0.15    1536    8192    codestral-embed
0.15    3072    2048    gemini-embedding-001
0.2     3072    8192    gemini-embedding-2
        384     512     embed-english-light-v3-0
        384     512     embed-multilingual-light-v3-0
        1024    512     embed-english-v3-0
        1024    512     embed-multilingual-v3-0

The four rows with a blank price are Cohere's v3 embedding family. They're still GA and still documented; Cohere's pricing page currently lists only Embed 4 among its embedding models, so there is no first-party rate to carry. A blank there means "the provider doesn't publish this", not "we didn't look" — every row carries the source_url it was read from.

One honest note while you're looking at that output. The two OpenAI rows read 8191 when this was drafted, and I'd written 8192 in the table at the top. Both numbers are first-party: 8191 is the figure OpenAI's 2024 new-embedding-models announcement carried, and the current API reference states "the max input tokens for the model (8192 tokens for all embedding models)". The disagreement was reconciled to 8192 on 2026-08-18 — the reference states the limit as a constraint on the input parameter, i.e. it carries the field as data, while the model spec pages state no limit at all. It's one token out of eight thousand and it changes nothing in this article. I'm leaving the paragraph in because a catalog that quietly rounds its own disagreements away isn't worth querying — and because you can see the audit trail: the row's notes field records the old value, the new one, and which surface won.

Data from AI Model Watch — 231 models, prices and lifecycle dates read from official provider documentation, refreshed daily, with null where the provider publishes nothing. Free JSON: /api/models.json and /api/deprecations.json.

OpenAI Responses API: function calling fiable, estado y trabajos en segundo plano

Khavel — Mon, 17 Aug 2026 09:25:11 +0000

Responses API no convierte una función en fiable por sí sola. Esta guía muestra el bucle correcto de tool calls, validación, estado y trabajos largos para que un agente no confunda una respuesta convincente con una acción segura.

OpenAI Responses API es la interfaz unificada para generar respuestas, usar herramientas y conservar estado entre turnos. Un tool call no es una orden que el servidor deba obedecer: es una propuesta del modelo que tu backend debe autorizar, validar, ejecutar de forma idempotente y devolver al modelo como function_call_output.

TL;DR

La keyword principal es OpenAI Responses API. La intención es técnica: un developer que ya puede hacer una llamada básica necesita montar un flujo fiable con function calling, JSON estructurado, streaming, estado conversacional y trabajos que no caben en una petición HTTP corta.

Mi postura: empieza con Responses API antes de introducir una capa de agentes. Es un contrato explícito que te obliga a entender input, output, tools y estado. Un SDK de agentes puede ahorrar orquestación después; no debería ocultar permisos, validación ni efectos externos.

Qué es Responses API y qué no resuelve

Responses API crea un objeto response a partir de un modelo, una entrada y, opcionalmente, herramientas. La salida no tiene por qué ser texto: puede contener mensajes, llamadas de función, resultados de herramientas alojadas, elementos de razonamiento y eventos de streaming. Leer solo output_text es correcto para un chat simple, pero insuficiente para un flujo que actúa sobre sistemas reales.

La API puede encadenar contexto con previous_response_id o con Conversations. Eso evita reenviar un historial manual enorme, pero no sustituye tu modelo de negocio: tú decides qué conversación pertenece a qué usuario, cuánto vive, qué datos se permiten y cuándo hay que resumir o borrar estado.

Tampoco decide si una llamada es segura. El modelo puede proponer create_invoice, send_email o deploy. Tu aplicación sigue siendo el control de autoridad: autentica al usuario, limita el recurso, valida argumentos, exige aprobación cuando corresponde y registra el efecto final.

El modelo propone pasos; el backend conserva la autoridad. Estado, validación, colas y auditoría son piezas distintas del texto generado.

El bucle correcto de function calling

Function calling tiene cuatro etapas: declaras una tool con un schema; el modelo emite uno o más elementos function_call; tu servidor valida y ejecuta solo los que autoriza; devuelves un function_call_output con el call_id original y pides la siguiente respuesta. Si falta el último paso, el modelo no ve el resultado real de la acción y tenderá a completar la conversación con una suposición.

No ejecutes argumentos directamente con json.loads y una llamada a tu SDK interno. El schema reduce salidas mal formadas, pero no prueba que el usuario tenga acceso a project_id, que una fecha exista ni que la acción sea razonable. Valida tipos, rangos, pertenencia al tenant y política de negocio fuera del modelo.

Para una operación con efecto, asocia una clave idempotente a la intención de negocio, no al texto del modelo. Un retry HTTP, una reconexión de streaming o una segunda respuesta no debe enviar dos emails o crear dos facturas. Guarda call_id, usuario, recurso, hash del payload y resultado de la ejecución.

Código: tool estrecha y resultado verificable en Python

Este ejemplo ilustra el bucle. La tool es deliberadamente de lectura y el resultado vuelve como datos, no como instrucciones. En producción, get_release debería imponer autorización y recuperar solo los campos permitidos para el usuario autenticado.

responses_tools.py

import json
from openai import OpenAI

client = OpenAI()
TOOLS = [{
    "type": "function",
    "name": "get_release",
    "description": "Returns approved release metadata for one repository.",
    "parameters": {
        "type": "object",
        "properties": {"repo": {"type": "string", "minLength": 1}},
        "required": ["repo"],
        "additionalProperties": False,
    },
    "strict": True,
}]

def get_release_for_user(user_id: str, repo: str) -> dict:
    assert repo in allowed_repos_for(user_id)  # authz, not a model prompt
    return read_release_metadata(repo)

response = client.responses.create(
    model="gpt-5",
    input="¿Cuál es el último release de api-gateway?",
    tools=TOOLS,
)

tool_outputs = []
for item in response.output:
    if item.type == "function_call" and item.name == "get_release":
        args = json.loads(item.arguments)
        result = get_release_for_user(current_user.id, args["repo"])
        tool_outputs.append({
            "type": "function_call_output",
            "call_id": item.call_id,
            "output": json.dumps(result),
        })

final = client.responses.create(
    model="gpt-5",
    previous_response_id=response.id,
    input=tool_outputs,
)
print(final.output_text)

El detalle importante no es el nombre de la función: es que allowed_repos_for vive en tu backend. Si el modelo propone otro repo, la autorización falla antes de tocar la fuente de datos. Devuelve un error de dominio breve y deja que el modelo explique el límite al usuario, en vez de darle una excepción cruda o inventar una respuesta.

Structured Outputs: contrato de interfaz, no control de seguridad

¿Te está sirviendo? Hay una dosis cada semana

Te resumo herramientas de IA para devs, agentes, MCP, seguridad y workflows en un email de 5 minutos. En español y sin ruido.

Suscribirme gratis

Cuando necesitas una salida que otro sistema consuma, usa Structured Outputs con JSON Schema estricto. En Responses API el formato se configura dentro de text.format; para tools, define strict: true y limita propiedades. Eso hace que el contrato sea más predecible que pedir «devuelve JSON válido» en un prompt.

Lo que conviene comprobar

Un schema debe representar una decisión pequeña y verificable. Para triage, por ejemplo: categoría de una allowlist, confianza acotada, evidencia citada y needs_human_review. Evita un objeto genérico tipo action: string que luego se convierte en una puerta trasera de comandos para cualquier integración.

Trata cualquier campo generado como entrada no confiable al cruzar una frontera. strict evita muchas formas inválidas; no sustituye escape HTML, validación de URLs, autorización, control de concurrencia, límites de tamaño ni saneamiento para SQL o shell. Un JSON impecable puede describir una acción equivocada.

Estado: previous_response_id frente a Conversations

previous_response_id es útil para enlazar el siguiente turno al anterior con una relación explícita. Es cómodo en una conversación corta o en un workflow donde tu base de datos guarda el último response ID por sesión. Las instrucciones de una llamada anterior no se arrastran automáticamente si pasas instrucciones nuevas: verifica ese comportamiento antes de asumir que una política quedó vigente.

Conversations es una entidad de estado reutilizable para añadir y recuperar ítems entre respuestas. Encaja cuando necesitas una conversación estable que pueda sobrevivir a distintos dispositivos o workers. Aun así, no conviertas la Conversation en tu única fuente de verdad: conserva en tu base la identidad del usuario, el tenant, el estado de aprobación y referencias de auditoría.

Mi regla: guarda solo IDs y contexto mínimo de producto; vuelve a resolver permisos, herramientas permitidas y policy en cada petición. El estado puede recordar la conversación, pero no debe heredar autoridad. Un usuario que pierde acceso a un proyecto no debería mantenerlo porque una conversación vieja lo mencionaba.

Streaming y background mode son flujos distintos

Streaming usa eventos server-sent para pintar progreso o texto parcial con baja latencia. Es una decisión de experiencia de usuario; no conviertas cada delta en un registro de negocio ni ejecutes una tool al primer fragmento. Espera al elemento de function call completo y conserva una ruta clara de cancelación del cliente.

Background mode sirve para respuestas largas que deben continuar aunque la petición web se corte. Creas la respuesta con background=true, persistes su ID y consultas su estado o recibes el evento webhook correspondiente. El frontend no debería mantener una conexión abierta durante minutos solo para fingir que un job asíncrono es streaming.

La consecuencia operativa importa: background mode conserva datos para poder hacer polling y no es compatible con Zero Data Retention. Revisa data controls, retención y la región de datos de tu organización antes de activarlo en flujos con información sensible. Para una tarea larga sin datos que deban salir, una cola propia y una llamada normal puede ser una alternativa más controlable.

Herramientas alojadas, MCP y límites de datos

Responses API puede combinar funciones de tu aplicación con herramientas alojadas, como web search, file search, code interpreter o image generation, según modelo y disponibilidad. Cada una introduce otra frontera: cuota, tiempo, datos enviados y resultados que pueden estar equivocados o contener instrucciones externas.

Los servidores MCP remotos son servicios de terceros. No les pases un token o documento solo porque una tool description sea atractiva. Delimita por servidor la URL, identidad, scopes, datos que puede recibir, rate limits y la aprobación para efectos externos. MCP conecta capacidades; no valida automáticamente su confianza.

Usa allowed_tools o un conjunto de tools por tarea cuando sea posible. Un agente de triage no necesita la misma superficie que uno de release. Reducir opciones también mejora la calidad: al modelo le cuesta menos elegir una tool cuando no le ofreces quince acciones parecidas con permisos distintos.

Arquitectura mínima que llevaría a producción

Entrada autenticada → policy de tenant → creación de response → parser de output → validador de schema y negocio → executor idempotente → auditoría → function_call_output → respuesta final. Si hay una acción sensible, añade una transición explícita de propuesta a aprobación: el modelo prepara payload y evidencia; una persona o regla independiente habilita la mutación.

Mantén los executors fuera del prompt. Una tool debería ser una función estrecha, con nombre que explique el efecto, parámetros mínimos y un resultado redactado. update_customer es demasiado grande; propose_customer_address_change y apply_approved_address_change dejan una frontera revisable.

Mide más que éxito HTTP: porcentaje de tool calls válidas, denegadas por policy, reintentos idempotentes, aprobaciones, errores por tipo, latencia p50/p95, coste por workflow y tareas resueltas sin escalado. Una respuesta fluida puede ocultar que el modelo llama tres veces a una API o que el 20% de acciones queda bloqueado al final.

Checklist antes de habilitar una tool con efecto

La tool expresa una única capacidad y no acepta campos libres que acaben en SQL, shell o URLs arbitrarias.

El backend autentica al usuario y comprueba autorización por tenant, recurso y operación; el modelo no decide permisos.

Los argumentos pasan JSON Schema y validación de negocio antes de llegar a un executor.

Las mutaciones tienen una clave idempotente y un registro de resultado por operación de negocio.

Las acciones externas o irreversibles muestran destino, payload, evidencia y riesgo antes de la aprobación.

Las tools disponibles se reducen por tarea y se revisan al cambiar de modelo, prompt o integración.

El estado conversacional no concede permisos persistentes y tiene una política de retención explícita.

Streaming, background jobs y webhooks tienen timeouts, cancelación, reintentos y observabilidad propios.

Hay evals con entradas ambiguas, argumentos inválidos, recursos de otro tenant y prompt injection indirecta.

Conclusión

Responses API es una buena base cuando quieres control fino: te enseña exactamente cuándo el modelo habló, cuándo pidió una tool y cuándo tu sistema produjo un resultado verificable. Esa claridad vale más que una demo de agente que parece autónoma hasta que intenta escribir en producción.

Empieza por una tool de lectura, un schema pequeño y una traza completa. Añade estado cuando haya una razón de producto, y background mode cuando el trabajo de verdad sea largo. La autonomía útil no consiste en dar más funciones al modelo: consiste en hacer que cada capacidad tenga una frontera, una evidencia y una forma segura de fallar.

Preguntas frecuentes

¿Qué es OpenAI Responses API?

Es la API unificada de OpenAI para crear respuestas con input multimodal, herramientas, streaming y estado conversacional. La salida puede incluir texto y elementos de tool calling, no solo una cadena.

¿Responses API sustituye a OpenAI Agents SDK?

No necesariamente. Responses API ofrece el contrato de bajo nivel; Agents SDK puede ayudar a orquestar agentes. Si necesitas permisos y efectos controlados, debes implementar validación y autorización en cualquiera de las dos capas.

¿Function calling ejecuta mi función automáticamente?

No. El modelo devuelve una propuesta de llamada; tu aplicación interpreta el output, valida argumentos y permisos, ejecuta si procede y devuelve un function_call_output.

¿Para qué sirve previous_response_id?

Enlaza una respuesta nueva con el contexto de la respuesta anterior. Es útil para turnos cortos, pero no sustituye una política de identidad, autorización o retención de datos.

¿Cuándo uso background mode?

Cuando una respuesta puede durar más que la petición HTTP normal y quieres consultar su estado o recibir un webhook. Revisa antes su efecto en retención de datos y compatibilidad con Zero Data Retention.

¿Structured Outputs hace segura una acción?

No. Hace más predecible el formato. Todavía debes validar negocio, scopes, tenant, recursos, límites, idempotencia y aprobación humana cuando exista efecto externo.

Cómo llevar una tool de Responses API de demo a producción

Elegir una capacidad de lectura. Empieza por una consulta reversible con un recurso claro, como recuperar metadata de un release aprobado.
Diseñar el schema. Declara campos mínimos, tipos, allowlists y additionalProperties: false; activa modo estricto cuando sea compatible.
Separar autorización. Resuelve usuario, tenant, scopes y recurso en el backend antes de llamar a la fuente de datos.
Crear el primer response. Envía el input y solo las tools necesarias para esa tarea; registra el response ID y la versión de policy.
Interpretar function calls. Procesa únicamente elementos completos de tipo function call; no ejecutes texto libre ni deltas de streaming.
Validar y ejecutar. Comprueba schema y reglas de negocio, aplica rate limits e idempotencia y captura un resultado redactado.
Devolver function_call_output. Usa el call ID original y datos estructurados para que el siguiente response pueda explicar el resultado real.
Añadir aprobación. Separa propuesta y mutación cuando la acción escriba, envíe, despliegue o transfiera información.
Preparar fallos. Define errores de autorización, validación, proveedor y timeout; cada uno debe tener una recuperación distinta.
Medir y evaluar. Prueba tenants cruzados, argumentos hostiles y retries; mide tools inválidas, bloqueos, coste, latencia y resolución.

Fuentes y referencias

También te puede interesar

Recibe una lectura semanal de herramientas IA para devs

Cada semana te resumo herramientas de IA para devs, agentes, MCP, seguridad y workflows en un email de 5 minutos. En español y sin ruido.

Suscribirme gratis

MCP Registry: cómo publicar y descubrir servidores MCP sin confiar a ciegas

Khavel — Thu, 13 Aug 2026 10:48:35 +0000

El MCP Registry mejora el descubrimiento de servidores, no certifica que sean seguros. Aprende a publicar metadata reproducible y a construir una allowlist interna que trate cada servidor como una dependencia con privilegios.

Un MCP Registry es un catálogo con una API estándar para describir y descubrir servidores MCP. El registro oficial publica metadata —nombre, versión, repositorio, paquete o endpoint remoto—; no hospeda tu binario ni convierte un servidor listado en seguro o adecuado para tu empresa.

TL;DR

La keyword principal es MCP Registry. La intención es técnica y práctica: un maintainer quiere publicar un servidor reproducible, y un equipo quiere descubrirlo sin transformar una búsqueda de herramientas en una puerta de entrada a paquetes y credenciales no revisados.

Mi postura: usa el registro público como inventario y canal de distribución de metadata, no como una lista de confianza. La unidad de confianza sigue siendo una versión concreta de un artefacto, su código, sus tools, su identidad de ejecución y los permisos que le concedes.

Qué es MCP Registry y qué problema resuelve

MCP Registry es la especificación y el ecosistema de registros para servidores Model Context Protocol. El Official MCP Registry, en registry.modelcontextprotocol.io, es un catálogo público de metadata y una API REST sobre la que pueden construirse marketplaces o sub-registros. Su valor es que un cliente no tenga que adivinar cómo encontrar, instalar o actualizar cada integración.

La frase importante es metadata. Un server.json puede apuntar a un paquete npm, PyPI, una imagen OCI o un endpoint remoto, junto a los transportes y la configuración de arranque. El registro no ejecuta ese servidor por ti ni inspecciona exhaustivamente lo que hará cuando tenga acceso a tu filesystem, red, OAuth o secretos.

Eso separa tres cosas que se confunden con facilidad: descubrimiento (encontrar una ficha), procedencia (saber quién puede publicar un namespace) y confianza operativa (decidir si esta versión recibe permisos en tu entorno). El registro ayuda mucho con las dos primeras; la tercera es una política tuya.

Un registro público resuelve discovery; la allowlist y los controles de ejecución resuelven el riesgo de introducir una nueva dependencia con capacidades de agente.

El modelo mental correcto: catálogo, no sello de seguridad

Que un servidor aparezca en un registro oficial no significa que sus dependencias sean benignas, que el maintainer siga controlando el paquete, que sus tool descriptions no hayan cambiado o que encaje con tus datos. La propia documentación lo presenta como un repositorio de información autodeclarada y, mientras siga en preview, avisa de posibles cambios incompatibles o resets de datos.

Trátalo como tratarías npm: una ficha reduce fricción de discovery y aporta campos comparables; no sustituye revisión de código, lockfile, análisis de dependencias, firma, sandbox o permisos mínimos. En MCP el impacto puede ser mayor que en una librería de UI porque el proceso puede recibir secretos y ejecutar operaciones en nombre de un usuario.

Una política sana empieza con esta pregunta: ¿qué puede leer, escribir, ejecutar o enviar este servidor después de instalarse? Si no puedes responderla para una versión fijada, no está listo para la allowlist, aunque tenga un nombre bonito, muchos installs o una referencia en un marketplace.

server.json: el contrato que publicas

server.json es la ficha versionada del servidor. Como mínimo declara un nombre único, descripción, versión, repositorio y una o más formas de distribución: packages para artefactos instalables o remotes para endpoints. Para un paquete también declara su registryType, identificador, versión y transporte; para un remoto, URL y transporte compatible.

No copies un ejemplo antiguo sin comprobar el schema que genera tu versión de mcp-publisher. El formato evoluciona durante preview. La forma menos frágil de empezar es mcp-publisher init, revisar el JSON resultante y validarlo en CI contra el schema actual antes de publicar. El contrato de registry no es el archivo de configuración con secretos que ejecuta el host.

Un ejemplo deliberadamente mínimo para un paquete npm por STDIO sería este. Sustituye los nombres, controla la versión desde tu release y no incluyas valores de secretos: la ficha solo puede describir variables requeridas, no contenerlas.

server.json

{
  "$schema": "https://static.modelcontextprotocol.io/schemas/2025-12-11/server.schema.json",
  "name": "io.github.acme/release-notes",
  "description": "MCP server for approved release-note data.",
  "version": "1.4.0",
  "repository": {"url": "https://github.com/acme/release-notes-mcp", "source": "github"},
  "packages": [{
    "registryType": "npm",
    "identifier": "@acme/release-notes-mcp",
    "version": "1.4.0",
    "transport": {"type": "stdio"}
  }]
}

Mantén la descripción factual y breve. También es entrada para hosts y modelos: una descripción ambigua, promocional o con instrucciones operativas largas aumenta el riesgo de que un agente elija una capability que no debería tener.

Namespace y procedencia: quién puede afirmar ese nombre

El registro oficial asocia la publicación a un namespace. Para io.github.* usa identidad de GitHub; para dominios propios puede verificar DNS o HTTP. Esa verificación evita que cualquiera publique bajo com.tuempresa.*, pero no demuestra que todo el código de un repositorio o paquete sea seguro.

Lo que conviene comprobar

Elige un namespace que sobreviva a cambios de equipo. Si tu servidor es producto de una organización, un namespace de dominio verificado suele expresar mejor la propiedad que una cuenta personal. Documenta qué repositorio, pipeline y equipo pueden publicar y elimina permisos cuando alguien deja el proyecto.

En CI, separa el token que publica el artefacto del mecanismo que publica la metadata. El quickstart del registro ofrece autenticación GitHub/OIDC; úsala para que el pipeline pueda probar origen sin guardar una sesión humana de larga duración. Protege la rama y exige revisión del cambio de server.json, igual que harías con un workflow de release.

¿Te está sirviendo? Hay una dosis cada semana

Te resumo herramientas de IA para devs, agentes, MCP, seguridad y workflows en un email de 5 minutos. En español y sin ruido.

Suscribirme gratis

Versionado inmutable: publica un release, no una corrección silenciosa

Cada publicación de un servidor necesita una versión única. Una vez publicada, la metadata de esa versión es inmutable; si debes corregir descripción, repositorio, paquete o endpoint, publica otra versión. El registro intenta ordenar SemVer y marca la versión apropiada como latest, por lo que usar 1.4.0 de forma consistente simplifica a clientes y humanos.

No uses latest como versión de paquete en una allowlist. Fija la versión del artefacto y conserva su integridad en un lockfile, digest OCI o checksum cuando aplique. latest del registry es una conveniencia de discovery, no una orden para actualizar procesos de desarrollo sin revisar qué cambió.

Cuando solo ajustes metadata, una prerelease de registry puede ser preferible a fingir que el binario cambió. Pero no ocultes una modificación real de tools o permisos detrás de un parche menor: para el consumidor, añadir delete_repository es un cambio de riesgo aunque tu API siga siendo compatible.

Publicar paso a paso desde CI

El orden seguro es: compilar, probar y publicar el artefacto; verificar que es recuperable por su identificador y versión; generar o actualizar server.json; validar schema y coherencia; autenticar el publisher con identidad de CI; publicar la metadata; y consultar la API para confirmar que la versión concreta aparece. Si publicas la ficha antes que el paquete, invitas a instalaciones rotas.

Para npm, el registro pide que el paquete se vincule a su nombre MCP mediante mcpName. Esa comprobación reduce la distancia entre metadata y paquete. Añade además tests que arranquen el paquete exactamente como lo describe el server.json: comando, transporte, variables declaradas y un initialize de prueba sin tocar datos reales.

Un esqueleto de workflow puede ser tan simple como el siguiente. No es una receta para copiar secretos: el token OIDC y los permisos exactos dependen de tu proveedor y del namespace. La parte importante es que publicación sea una consecuencia de artefacto probado, no un comando manual desde un portátil.

release.sh (esquema)

npm ci
npm run build && npm test
npm publish --access public

node scripts/assert-server-json.mjs server.json
mcp-publisher login github-oidc
mcp-publisher publish server.json

curl --fail --silent   "https://registry.modelcontextprotocol.io/v0.1/servers?search=io.github.acme/release-notes"

Haz que assert-server-json compare name, versión, repositorio y paquete contra package.json y la etiqueta Git. Es una comprobación pequeña que evita el fallo más tonto del ecosistema: publicar metadata de 1.4.0 que instala sin querer 1.3.2.

Consumir la API sin mezclar discovery y ejecución

La API v0.1 expone una lista de servidores y el detalle de una versión. Permite filtrar por search, pedir solo latest o sincronizar incrementalmente con updated_since. Esto es suficiente para construir una vista de catálogo o un job que detecte cambios; no lo conviertas en un instalador automático para cada resultado nuevo.

El patrón adecuado es ingestión → normalización → evaluación de política → aprobación → distribución. Tu job puede traer nuevas fichas a una base interna y marcar qué cambió, pero un servidor no pasa a ser ejecutable por un developer hasta que una persona o una regla verificable aprueba su versión, identidad, permisos y distribución.

Guarda la versión y la respuesta original que revisaste. Si el upstream se actualiza, compara el nombre del paquete, transporte, comando, URL, variables, tools observadas y permisos. Un cambio en cualquiera de ellos requiere reevaluación; no basta con que version=latest avance.

Sub-registro privado: la capa que una empresa realmente necesita

El registro oficial es para servidores públicamente accesibles; para un servicio interno o una dependencia aprobada solo para tu organización, crea un sub-registro privado o un catálogo compatible. GitHub documenta que una implementación v0.1 necesita endpoints de listado y detalle, además de CORS si un cliente lo consume desde navegador o IDE.

El sub-registro no tiene que duplicar toda la funcionalidad del público. Empieza con una allowlist inmutable y explícita: ID interno, server name upstream, versión exacta, fuente, owner, clasificación de datos, scopes permitidos, transporte, fecha de revisión y fecha de caducidad. Si falta owner o fecha, el ítem caduca en vez de quedarse como excepción eterna.

Puedes sincronizar fichas públicas como candidatos, pero no copies automáticamente todas. La ganancia real es cambiar la experiencia por defecto: el developer descubre únicamente servidores aprobados, y el host impide conexiones fuera de política cuando la plataforma lo permita.

Supply chain MCP: controles antes de dar una tool al modelo

Antes de instalar un paquete local, verifica el publisher, repositorio y artefacto; fija versión y lockfile; analiza dependencias; ejecuta el proceso con filesystem, red y variables mínimas; y revisa el comando que el host va a lanzar completo. La recomendación de OWASP es clara: un servidor MCP local puede convertirse en una vía de sandbox escape, exfiltración o ejecución arbitraria si recibe acceso total por comodidad.

Después de instalar, inspecciona también las tools: nombre, descripción, argumentos, outputs y destino. Las descripciones y schemas son superficie de prompt injection. Conserva un hash de la definición de tools que aprobaste y alerta si cambia; un servidor que hoy solo lee puede sufrir un rug pull mañana sin que cambie el nombre del paquete.

Para servidores remotos, añade otra capa: validación TLS, URL exacta, OAuth con audiencia y scopes estrechos, egress controlado y rate limits. Una ficha de registry puede hacer visible un endpoint; no concede a ese endpoint derecho a recibir tokens de tu usuario. Para el flujo OAuth completo, consulta nuestra guía de OAuth 2.1 para MCP.

De la ficha al host: consentimiento y aislamiento

El host debe enseñar qué se instala o conecta, qué comando se ejecutará en local, qué variables necesita y qué acciones expone. La aprobación del usuario no puede ser una tarjeta truncada con un botón «Conectar». Si el host no revela el comando completo, los permisos o la procedencia, el equipo pierde la evidencia necesaria para aprobarlo.

Aísla servidores como dominios de seguridad independientes. Un servidor de documentación no necesita el token de un servidor de deploy ni acceso a todos los archivos del repositorio. Da una credencial por servidor y entorno, monta solo los directorios imprescindibles y bloquea red saliente salvo destinos que puedas justificar.

Las mutaciones de impacto —escribir código, emitir una orden, cambiar un permiso, enviar datos fuera— deben seguir requiriendo aprobación con parámetros completos. Un registro resuelve cómo encontrar una tool; no decide cuándo un agente puede ejecutar una acción con consecuencias.

Observabilidad y renovación de confianza

Registra server name, versión, digest o lockfile, host, usuario o service account, tool, argumentos redactados, resultado, latencia y decisión de aprobación. Sin esa relación no podrás responder qué servidor consultó un dato o cambió un recurso cuando una alerta llegue semanas después.

Lo que conviene comprobar

Configura dos bucles de revisión. El primero es de cambios: nueva versión, nuevo paquete, endpoint, comando, tool o scope reabre la evaluación. El segundo es temporal: cada entrada aprobada expira en 90 o 180 días y necesita un owner que confirme que sigue mantenida y con el mismo riesgo aceptable.

Mide también fricción útil: solicitudes de alta, tiempo hasta revisión, instalaciones rechazadas, permisos denegados, tools poco usadas y cambios detectados. Si tu catálogo tarda semanas para un servidor de lectura de bajo riesgo, acabará apareciendo un bypass; si aprueba todo en cinco minutos, solo has creado una lista decorativa.

Checklist de publicación y consumo

El nombre MCP pertenece a un namespace que controlas y la identidad de CI puede probarlo.
Paquete o endpoint existen antes que la ficha y su versión coincide exactamente con server.json.
El schema se valida en CI y el proceso se arranca en una prueba de integración sin secretos reales.
Cada publicación usa una versión única; una corrección se publica como release nuevo, no se reescribe.
La ficha no incluye secretos ni se confunde con el archivo de configuración runtime del host.
El registro público entra en el flujo como fuente de discovery, nunca como allowlist automática.
La allowlist interna fija versión, fuente, owner, datos, scopes, transporte, fecha de revisión y expiración.
Los paquetes locales se fijan, escanean y ejecutan con sandbox, red, filesystem y credenciales mínimos.
Las definiciones de tools se inspeccionan y se vuelven a aprobar si cambian.
Las acciones sensibles muestran parámetros completos y requieren consentimiento o aprobación humana.

Conclusión

MCP Registry es una pieza necesaria para que el ecosistema deje de repartir fragmentos de configuración por README y capturas. Estandariza discovery y metadata, y permite que clientes y empresas hablen el mismo idioma de catálogo. Eso es valioso, pero no es una auditoría de seguridad.

Publica como maintainer con releases reproducibles, versiones inmutables y CI; consume como equipo con una allowlist, artefactos fijados, sandbox y reevaluación por cambios. Si conviertes un registry en «instalar lo que aparezca», acabas de automatizar la parte peligrosa de tu supply chain. Si lo usas para hacer explícitas procedencia y políticas, reduces fricción sin regalar privilegios.

Preguntas frecuentes

¿Qué es MCP Registry?

Es un estándar y catálogo de metadata para descubrir servidores Model Context Protocol. El Official MCP Registry ofrece una API pública para que clientes y sub-registros consulten fichas de servidores.

¿El MCP Registry oficial certifica que un servidor sea seguro?

No. Ayuda a descubrir metadata y comprobar propiedad de namespaces, pero no sustituye revisión de código, integridad del artefacto, permisos mínimos, sandbox ni controles de ejecución.

¿Qué contiene server.json?

Describe el nombre, versión, repositorio y cómo obtener o conectar el servidor, por ejemplo un paquete con transporte STDIO o un endpoint remoto. No debe almacenar secretos runtime.

¿Puedo cambiar un servidor ya publicado?

No se reescribe esa versión. Publica una versión nueva de server.json; las versiones publicadas son inmutables y deben ser únicas.

¿Necesito un registro privado para mi empresa?

Si quieres publicar servicios internos o aplicar una allowlist de servidores aprobados, sí. Puedes usar una implementación compatible v0.1 o un catálogo interno que fije versiones, owners, permisos y caducidad.

¿Debo instalar automáticamente los resultados del registry?

No. Úsalo para discovery y somete cada versión a política: publisher, paquete o endpoint, dependencias, tools, scopes, sandbox y aprobación antes de habilitarla.

Cómo publicar y gobernar un servidor con MCP Registry

Definir el límite. Enumera tools, datos, efectos y permisos; elimina capacidades que no pertenecen al primer release.
Publicar el artefacto. Compila, prueba y publica el paquete o endpoint antes de crear la ficha de registry.
Vincular la procedencia. Elige namespace, configura verificación GitHub, DNS o HTTP y limita quién puede publicar desde CI.
Generar server.json. Usa mcp-publisher init, declara versión exacta, repositorio y transporte sin incluir secretos runtime.
Validar en CI. Comprueba schema, coherencia con package metadata y un arranque real que complete initialize en sandbox.
Publicar una versión. Autentica el publisher con identidad de CI y registra la versión única; no reescribas releases publicados.
Verificar discovery. Consulta el detalle de esa versión en la API y guarda la respuesta revisada como evidencia de release.
Crear allowlist. Fija versión, fuente, owner, clasificación de datos, scopes, transporte, revisión y fecha de expiración.
Aislar ejecución. Usa credenciales por servidor, filesystem y red mínimos, y aprobación humana para acciones sensibles.
Reevaluar cambios. Altera paquete, endpoint, tool, schema o scope y obliga una revisión antes de avanzar a la nueva versión.

Fuentes y referencias

También te puede interesar

Recibe una lectura semanal de herramientas IA para devs

Cada semana te resumo herramientas de IA para devs, agentes, MCP, seguridad y workflows en un email de 5 minutos. En español y sin ruido.

Suscribirme gratis

n8n y agentes de IA: cómo crear workflows fiables con aprobación humana

Khavel — Wed, 12 Aug 2026 09:08:57 +0000

n8n puede convertir un agente en un workflow operativo, pero el canvas no sustituye permisos, contratos ni evaluación. Diseña una tarea estrecha, separa decisiones de efectos y deja al humano la última palabra cuando haya riesgo.

Un agente de IA en n8n es un workflow en el que un modelo elige una o varias tools para alcanzar una meta. Es útil cuando el trabajo tiene pasos, integraciones y decisiones que cambian; no es una excusa para dar acceso indiscriminado a correo, bases de datos o producción.

TL;DR

La keyword principal es n8n agentes IA. La intención es práctica: cómo diseñar y operar un primer workflow agentic que use datos y herramientas reales sin convertir una demo visual en una automatización opaca.

Mi postura: usa n8n para orquestar decisiones acotadas y efectos revisables. Si el agente envía un email, abre un ticket, cambia un registro o llama a una API con coste, el workflow debe tener validación, una aprobación cuando el impacto lo justifique y evidencia de qué ocurrió.

Qué es un agente de IA en n8n — y qué no es

Una cadena ejecuta pasos que tú defines de antemano: recibir un formulario, normalizar campos, llamar una API y guardar una respuesta. Un agente añade una decisión del modelo sobre qué tool usar, con qué argumentos y en qué orden. Esa flexibilidad tiene valor cuando la entrada es ambigua; también introduce rutas de fallo que un workflow determinista no tenía.

No confundas un AI Agent con cualquier nodo que llame a un LLM. Para clasificación, extracción con schema, resumen o transformación de texto, una cadena con salida estructurada suele ser más barata, fácil de probar y más segura. El agente entra cuando necesita seleccionar capacidades y la selección no cabe razonablemente en un if explícito.

La prueba de realidad es sencilla: describe la tarea sin mencionar el modelo. Si no puedes enumerar input permitido, resultado esperado, herramientas necesarias, dueño de la decisión y efecto externo, todavía no tienes un caso de uso; tienes una intención vaga.

El modelo puede proponer una acción y elegir una tool; el workflow conserva la autoridad sobre validación, aprobación, reintentos y auditoría.

La arquitectura mínima: separar pensar, validar y actuar

Un flujo que desplegaría tiene seis límites. Un trigger recibe el evento; una capa de normalización reduce el input a campos permitidos; el agente razona solo con contexto necesario; las tools tienen contratos pequeños; una puerta de aprobación detiene efectos sensibles; y una capa de auditoría deja evidencia de cada decisión. La cola y el error handler sostienen el proceso si hay trabajo largo o fallos transitorios.

El error común es conectar Gmail, Slack, CRM, GitHub y una base de datos como tools desde el primer día. El modelo ya no ve cinco integraciones: ve cinco superficies de acción con credenciales y consecuencias distintas. Empieza con una única tool de lectura y añade otra solo cuando tengas un caso, una autorización y una métrica que la justifiquen.

El prompt no es esa frontera. El prompt explica la tarea; el nodo, credencial, schema y política de aprobación imponen lo que puede suceder. Si un prompt dice «no borres nada» pero una tool permite borrar y no exige aprobación, tu sistema depende de que el modelo obedezca siempre. Eso no es un control.

Caso de inicio que sí merece un agente

Un buen primer caso es el triage de incidencias internas. Un webhook recibe título, descripción, servicio y enlace; el agente consulta una base de conocimiento de solo lectura y propone categoría, prioridad, evidencia y siguiente acción. El workflow valida el objeto de salida. Solo después, una persona aprueba crear o actualizar el ticket en el sistema correspondiente.

Ese diseño ofrece un baseline claro. Puedes medir si la categoría es correcta, si la evidencia existe, si eligió una tool adecuada y cuánto tarda. También puedes comparar una cadena simple contra el agente: si la cadena resuelve el 90% de los casos sin tools, probablemente no necesitas más autonomía para ese 90%.

Evita empezar por «responde tickets automáticamente». Es una mezcla de clasificación, conocimiento, identidad, tono, SLA y acción externa. Descompón esa frase en etapas; automatiza primero la que sea reversible y tenga un criterio de aceptación objetivo.

¿Te está sirviendo? Hay una dosis cada semana

Te resumo herramientas de IA para devs, agentes, MCP, seguridad y workflows en un email de 5 minutos. En español y sin ruido.

Suscribirme gratis

Contratos: el agente propone JSON; el workflow decide

Haz que el agente devuelva una decisión pequeña y validable, no párrafos que otro nodo tenga que interpretar. Un contrato útil incluye category, priority, evidence, next_action y requires_approval. Mantén los enums limitados y exige que la evidencia proceda del input o de una tool consultada; no conviertas una confianza inventada en una orden operativa.

Lo que conviene comprobar

Ejemplo de contrato para un triage. En n8n puedes implementarlo con Structured Output Parser o con un nodo de validación posterior; lo importante es que la rama de escritura solo reciba objetos que pasen el schema.

decision.schema.json

{
  "type": "object",
  "additionalProperties": false,
  "required": ["category", "priority", "evidence", "next_action", "requires_approval"],
  "properties": {
    "category": {"enum": ["bug", "access", "question", "incident"]},
    "priority": {"enum": ["low", "normal", "high"]},
    "evidence": {"type": "array", "items": {"type": "string"}, "maxItems": 3},
    "next_action": {"enum": ["request_context", "draft_ticket", "escalate"]},
    "requires_approval": {"type": "boolean"}
  }
}

Un schema no hace verdadera la respuesta; solo evita que un formato ambiguo avance. La regla es: validation failure significa detener, pedir más contexto o enviar a humano. Nunca significa adivinar campos que faltan y continuar con la escritura.

Tools estrechas y credenciales con alcance mínimo

Una tool debe corresponder a una operación que puedas describir como una API segura. buscar_runbook(servicio, consulta) es mejor que «acceso a toda la wiki». crear_borrador_ticket(titulo, cuerpo, prioridad) es mejor que «administrar el proyecto». Menos parámetros, resultados limitados, límites de tamaño y un owner claro hacen que la tool sea más fácil de evaluar y revocar.

Usa credenciales separadas por entorno y workflow. Compartir un workflow puede permitir a sus editores usar las credenciales que contiene; por eso, antes de compartir, revisa quién necesita editarlo y qué identidad ejecuta cada nodo. Un canvas compartido no es una razón para usar una cuenta de administrador global.

Trata cualquier documento, email, issue o resultado de búsqueda que entre al contexto como datos no confiables. Puede contener instrucciones para el modelo. Filtra qué campos se exponen a la tool, separa los datos de las instrucciones de sistema y nunca dejes que texto recuperado cambie scopes, URLs sensibles o identificadores de tenant.

Aprobación humana: dónde debe detenerse el flujo

La revisión humana es útil antes de una mutación, no después de descubrir una mutación. En n8n, una operación puede pausar y pedir aprobación; para procesos más complejos, usa una espera y una interfaz o canal de decisión que conserve el execution_id, actor, payload propuesto y fecha de expiración.

La aprobación debería mostrar lo que una persona necesita para responsabilizarse: acción propuesta, campos concretos, evidencia usada, destino, coste potencial y enlace a la ejecución. «El agente recomienda continuar» no es una solicitud de aprobación; es una transferencia opaca de responsabilidad.

Define políticas por impacto. Lectura de documentación pública puede seguir sin gate. Crear un borrador puede requerir revisión por muestreo. Enviar un correo, borrar, desplegar, cambiar permisos o tocar datos de cliente debe requerir aprobación explícita y registrar quién la otorgó. Si no puedes esperar, probablemente la acción no debería depender de un agente libre.

MCP en n8n: útil, pero no un catálogo sin freno

MCP puede servir para exponer herramientas externas al agente o para publicar workflows seleccionados como capacidades. El patrón conserva las mismas reglas: tools descubiertas no son tools aprobadas. Define un allowlist por workflow, usa identidades y scopes mínimos y registra qué servidor MCP y método ejecutó la operación.

No conectes un servidor MCP remoto solo porque ofrece muchas herramientas. Revisa su autorización, transporte, procedencia, datos que recibe y acciones posibles. Si el servidor toca recursos internos, aplica OAuth, audiencia y scopes en el servidor, como explicamos en la guía de OAuth para MCP; n8n no convierte una credencial amplia en una política segura.

Mi criterio: introduce MCP después de validar una tool nativa o HTTP estrecha. Si no sabes qué tool del catálogo necesita el caso, no es momento de dar al agente decenas de opciones. La selección de capabilities también necesita un diseño de producto y de seguridad.

Escalado: una ejecución no es una arquitectura

Un workflow corto puede vivir en una instancia. Si tienes trabajos asíncronos, picos, reintentos o aprobaciones que duran horas, separa la recepción del evento del trabajo. n8n documenta queue mode con procesos main, workers y un broker; úsalo cuando la carga lo justifique, no como decoración de un prototipo.

Pon idempotencia en el borde: conserva un ID de evento y evita que un retry cree dos tickets o envíe dos mensajes. El modelo puede reintentarse; una acción mutante no debería duplicarse sin una clave de negocio o un check de estado. En la rama de error, clasifica fallo de proveedor, timeout, validación, permiso y aprobación vencida; cada uno necesita una recuperación distinta.

Mide cola, duración p50/p95, tasa de reintento, acciones propuestas, aprobadas y rechazadas, tools llamadas y coste por workflow. Un gráfico de ejecuciones exitosas sin conocer cuántas decisiones fueron correctas solo mide que el sistema hizo algo.

Evaluación antes de activar el workflow

n8n ofrece evaluaciones ligeras y métricas, pero tu dataset importa más que el botón. Crea al menos 30 casos con entradas normales, incompletas, ambiguas y hostiles. Para cada uno, guarda decisión esperada, tools permitidas, tool calls prohibidas, evidencia mínima y si el caso debe pedir aprobación.

Define gates antes de modificar prompt, modelo o herramientas: porcentaje de categoría correcta, tasa de JSON válido, evidencia verificable, llamadas indebidas, falsos positivos de escritura, tiempo y coste. No cambies modelo y prompt a la vez si quieres saber por qué apareció una regresión.

La evaluación de trayectorias es especialmente valiosa en agentes: la respuesta final puede parecer buena aunque haya consultado una fuente errónea, usado la herramienta equivocada o intentado escribir sin aprobación. Registra ruta y argumentos redactados, no solo el texto final.

Seguridad y operaciones que no dejaría para después

Ejecuta el security audit de n8n al incorporar un workflow sensible. Revisa credenciales sin uso, webhooks sin protección, nodos con acceso a filesystem o ejecución de comandos, community nodes y configuración de instancia. Es una señal de higiene, no la garantía de que un agente entiende tus permisos.

Lo que conviene comprobar

Separa desarrollo, staging y producción. Prueba con identidades sandbox, datos sintéticos y destinos que no generen efectos reales. Mantén secretos en el gestor apropiado, redáctalos de logs y limita acceso al historial de ejecuciones: un prompt o respuesta puede incluir datos de cliente aunque la tool haya sido de solo lectura.

Cuando el workflow evolucione, versiona export, prompt, schema, modelo, lista de tools y credenciales lógicas. Cualquier cambio en una de estas piezas es una versión candidata que debe pasar el dataset y un canary, no un ajuste inocente en el canvas.

Checklist para un primer agente n8n

La tarea tiene un input, una salida y un owner definidos; no es «automatizar soporte».
Una cadena determinista no resuelve el caso igual de bien y más barata.
El agente recibe solo contexto necesario y devuelve un objeto que pasa schema.
Cada tool tiene propósito, allowlist, límite de datos, identidad y scope mínimos.
Las mutaciones se separan de la decisión y pasan por aprobación cuando el impacto lo exige.
Los retries son idempotentes y la rama de error distingue causas recuperables de denegaciones.
Existe un dataset con casos normales, ambiguos y hostiles, más gates de calidad, trayectoria, latencia y coste.
Hay trazas y auditoría con IDs, decisiones, tool calls y aprobaciones, sin almacenar secretos por defecto.
Staging y producción usan credenciales distintas; el workflow no necesita una cuenta admin global.

Conclusión

n8n es una buena capa de orquestación cuando quieres que una decisión de IA toque integraciones reales de forma visible. Su virtud no es dibujar nodos: es darte lugares claros donde validar, pausar, reintentar y auditar. Úsalos.

Empieza con un triage de lectura, una tool y una salida estructurada. Añade aprobación antes de la primera escritura. Mide la trayectoria antes de celebrar la respuesta. Cuando esas tres cosas sean aburridas y repetibles, entonces tendrás base para automatizar más; antes, solo tendrás una demo con acceso a sistemas reales.

Preguntas frecuentes

¿Qué es un agente de IA en n8n?

Es un workflow donde un modelo puede decidir qué herramientas usar para una meta. A diferencia de una cadena fija, la ruta puede variar según la entrada, por lo que necesita más control y evaluación.

¿Cuándo conviene usar n8n Agent y cuándo una cadena?

Usa una cadena para extracción, clasificación, resumen y pasos definidos. Usa un agente cuando la selección de una tool o el orden de pasos dependa de la situación y puedas limitar y auditar esa decisión.

¿Puede un agente n8n enviar emails o modificar un CRM?

Técnicamente sí, pero no debería hacerlo sin una identidad mínima, una tool estrecha, validación de argumentos e idealmente aprobación humana para efectos externos o irreversibles.

¿Cómo pruebo un agente antes de producción?

Crea un dataset de casos normales, ambiguos y hostiles; mide decisión, formato, evidencia, tools llamadas, acciones indebidas, latencia y coste. Ejecuta un canary con credenciales y destinos sandbox.

¿MCP hace seguro un workflow de n8n?

No. MCP conecta capacidades; aún debes revisar servidor, autenticación, scopes, tools expuestas, datos y aprobaciones. Una tool remota con permisos amplios sigue siendo un riesgo amplio.

¿Necesito queue mode para un agente?

No para un piloto pequeño. Sí puede ser necesario cuando hay carga, trabajos asíncronos, aprobaciones largas o necesidad de separar la recepción de eventos del procesamiento por workers.

Cómo desplegar un primer agente de IA en n8n

Acotar la misión. Elige una tarea reversible y de lectura, como clasificar y proponer el triage de una incidencia.
Definir el contrato. Especifica campos de entrada, schema de decisión, evidencia requerida, herramientas permitidas y acciones prohibidas.
Crear una tool mínima. Conecta una única fuente de conocimiento de solo lectura y limita datos, credencial y parámetros.
Añadir validación. Rechaza salida que no pase schema o que no contenga evidencia suficiente; no inventes defaults para continuar.
Separar escritura. Encierra crear ticket, enviar mensaje o cambiar registro en una rama posterior con clave idempotente.
Configurar aprobación. Muestra acción, payload, destino, evidencia y ejecución a una persona antes de la primera mutación.
Crear dataset. Incluye casos normales, ambiguos, incompletos y hostiles con decisión y trayectoria esperadas.
Medir y canary. Compara calidad, tools, latencia, coste y aprobaciones en staging antes de abrir una parte pequeña de tráfico.
Auditar y versionar. Guarda versión de workflow, prompt, schema, modelo y allowlist; redacta secretos de ejecuciones y trazas.

Fuentes y referencias

También te puede interesar

Recibe una lectura semanal de herramientas IA para devs

Cada semana te resumo herramientas de IA para devs, agentes, MCP, seguridad y workflows en un email de 5 minutos. En español y sin ruido.

Suscribirme gratis

Imagen 4 shuts down Monday, and Google's own docs disagree about where to go

Khavel — Tue, 11 Aug 2026 11:50:37 +0000

Model-lifecycle noise is almost always about chat models. Meanwhile Google's generative media line — image, video, music — has been quietly running the same deprecation machinery for a year, and one of its deadlines lands on Monday, August 17, 2026.

Every number and quote below was read this morning off Google's own pages, not off a tracker:

ai.google.dev/gemini-api/docs/pricing
ai.google.dev/gemini-api/docs/deprecations (page footer: Last updated 2026-08-03 UTC)

The deadline

Three model ids go dark on August 17:

imagen-4.0-generate-001
imagen-4.0-ultra-generate-001
imagen-4.0-fast-generate-001

They were released June 24, 2025. That's it — a fourteen-month production life for what the pricing page still describes as "Our latest image generation model, with significantly better text rendering and better overall image quality."

Where to go next has two official answers

The pricing page carries this warning, verbatim:

Warning: Imagen 4 models (imagen-4.0-generate-001, imagen-4.0-ultra-generate-001, imagen-4.0-fast-generate-001) are deprecated and will be shut down on August 17, 2026; migrate to Gemini 2.5 Flash Image to avoid service disruption.

The deprecations table, for the same three ids, puts something else in its Recommended replacement column:

Model	Release date	Shutdown date	Recommended replacement
`imagen-4.0-generate-001`	June 24, 2025	August 17, 2026	`gemini-3.1-flash-image`
`imagen-4.0-ultra-generate-001`	June 24, 2025	August 17, 2026	`gemini-3.1-flash-image`
`imagen-4.0-fast-generate-001`	June 24, 2025	August 17, 2026	`gemini-3.1-flash-image`

Two first-party surfaces, two different destinations. And it gets worse if you follow the banner, because Gemini 2.5 Flash Image is itself deprecated — it's in the same table with a shutdown of October 2, 2026, six weeks after the model it's being offered as an escape from.

Follow the table's pointer for that model and you get this chain:

gemini-2.5-flash-image            shutdown Oct 2, 2026
  └─ recommended: gemini-3.1-flash-image-preview
                                  shutdown Jun 25, 2026   ← already passed
       └─ recommended: gemini-3.1-flash-image
                                  no shutdown date announced

The middle hop is a model whose own shutdown date was 47 days ago. Nothing here is malicious — it's an ordinary docs-consistency problem across three tables that each move on their own schedule. But if you're writing the migration, you need to know that the pointer requires two hops and that one of the hops is dead.

Worth noting what the pricing page does not say: in the Gemini 2.5 Flash Image section there is no deprecation warning at all. It reads as a normal, buyable model. A reader who follows the banner lands on a page that looks clean.

It isn't just an id swap — the billing unit changes

Imagen 4 bills per image, flat, paid tier only (there is no free tier):

	Price per image
Imagen 4 Fast	$0.02
Imagen 4 Standard	$0.04
Imagen 4 Ultra	$0.06

The banner's target, Gemini 2.5 Flash Image, also quotes a flat per-image output price: $0.039 per image on the Standard tier.

The table's target, Gemini 3.1 Flash Image, bills per token — image output at $60.00 per 1M tokens — which Google converts on the page to a resolution-tiered rate:

Resolution	Price per image
0.5K	$0.045
1K	$0.067
2K	$0.101
4K	$0.151

So imagen-4.0-generate-001 at $0.04 costs the same whatever you render; its replacement costs $0.045 at 0.5K and $0.151 at 4K — a shade under 3.8x — and image size becomes a line item in your cost model where it previously wasn't one. That's the part that breaks a spreadsheet, not the model id.

A Google shutdown date is a floor, not a schedule

This is the bit worth internalizing, and Google states it plainly on the deprecations page:

Deprecation announcements are made on the Release notes page, and the announced earliest shutdown dates are tracked on this page. Already-shutdown models are indicated with gray backgrounds.

Now look at the Veo rows. veo-3.0-generate-001, veo-3.0-fast-generate-001 and veo-2.0-generate-001 all carry a shutdown date of June 30, 2026 — 42 days ago as I write this. They are not gray. The pricing page still sells them, with live per-second rates and a warning in the future tense: "will be shut down on June 30, 2026."

So the date is a lower bound on when the endpoint disappears, not a prediction of when it will. Both failure modes are real: build a migration that assumes the date holds and you may cut over needlessly; build one that assumes it slips and you find out the hard way. The only safe read is "not before this date."

The stable video model is the deprecated one

Also from the pricing page, about Veo 3 — the deprecated line:

Our stable video generation model, available to developers on the paid tier of the Gemini API.

And about Veo 3.1, the model the deprecations table names as its replacement:

Preview models may change before becoming stable and have more restrictive rate limits.

Every Veo model in the Gemini API is now either deprecated or preview. The table hedges accordingly — the replacement cell reads veo-3.1-generate-preview "or the GA models on the Gemini Enterprise Agent Platform", which is a different product with a different surface. If you need a generally-available video model inside the Gemini API specifically, as of today the pricing page does not offer you one.

Google's generative-media lifecycle, in one table

Every model in Google's Imagen, Veo, Lyria and image-generation sections that carries a shutdown date, oldest deadline first:

Model	Shutdown	Recommended replacement
`imagen-3.0-generate-002`	Nov 10, 2025	`imagen-4.0-generate-001`
`veo-3.0-generate-preview`	Nov 12, 2025	`veo-3.1-generate-preview`
`veo-3.0-fast-generate-preview`	Nov 12, 2025	`veo-3.1-fast-generate-preview`
`gemini-2.0-flash-preview-image-generation`	Nov 14, 2025	`gemini-2.5-flash-image`
`gemini-2.5-flash-image-preview`	Jan 15, 2026	`gemini-2.5-flash-image`
`imagen-4.0-generate-preview-06-06`	Feb 17, 2026	`imagen-4.0-generate-001`
`imagen-4.0-ultra-generate-preview-06-06`	Feb 17, 2026	`imagen-4.0-ultra-generate-001`
`gemini-3.1-flash-image-preview`	Jun 25, 2026	`gemini-3.1-flash-image`
`gemini-3-pro-image-preview`	Jun 25, 2026	`gemini-3-pro-image`
`veo-3.0-generate-001`	Jun 30, 2026	`veo-3.1-generate-preview`
`veo-3.0-fast-generate-001`	Jun 30, 2026	`veo-3.1-fast-generate-preview`
`veo-2.0-generate-001`	Jun 30, 2026	`veo-3.1-generate-preview`
`imagen-4.0-generate-001`	Aug 17, 2026	`gemini-3.1-flash-image`
`imagen-4.0-ultra-generate-001`	Aug 17, 2026	`gemini-3.1-flash-image`
`imagen-4.0-fast-generate-001`	Aug 17, 2026	`gemini-3.1-flash-image`
`gemini-2.5-flash-image`	Oct 2, 2026	`gemini-3.1-flash-image-preview`

The other models in those same sections read "No shutdown date announced": gemini-3.1-flash-image, gemini-3-pro-image, veo-3.1-generate-preview, veo-3.1-fast-generate-preview, veo-3.1-lite-generate-preview, lyria-3-clip-preview, lyria-3-pro-preview, lyria-realtime-exp.

Two patterns fall out of the column of dates. Preview lifetimes are short and getting shorter — gemini-3.1-flash-image-preview ran from Feb 26 to Jun 25, 2026, about four months, where the Imagen 4 previews got roughly eight. And a lineage gets re-pointed as it goes: Imagen 3 pointed at Imagen 4, which now points out of Imagen entirely and into the Gemini image line.

Why you probably haven't seen this tracked

Because these models don't fit the schema everyone uses. They have no context window and no per-token price — they bill per image or per second of video — so a per-token price tracker either drops them or shows a row of blanks.

That includes ours, partly. AI Model Watch carries all 25 of Google's generative-media models with their lifecycle fields, but our price fields are per-token, so on these rows they're null and the real rate ($0.04 per image, $0.40 per second) lives in the row's notes with the source URL it was read from. A null there means "this model isn't priced in tokens," not "we couldn't find it" — but it's a genuine limitation of the schema and worth saying out loud rather than papering over.

The lifecycle half is structured and free:

curl -s https://aimodelwatch.dev/api/models.json \
  | jq -r '.models[]
      | select(.provider=="Google")
      | select(.modality | any(test("image-out|video-out|audio-out")))
      | [(.retires_on // "none"), .id, .status, (.replacement // "-")] | @tsv' \
  | sort

That returns all 25 rows, dated deadlines first. (There's also /api/deprecations.json, which is the lifecycle-only projection — it's narrower, and it has no modality field, so filter that one on .provider and .id instead.)

No key, no signup, CORS open, and every row carries the source_url it was read from so you can check it against Google yourself. Which you should — that's the whole point of the source_url being there.

If you're on Imagen 4 right now

You have until Monday, August 17. Test against the table's target, gemini-3.1-flash-image, not the banner's — the banner's target has an October date on it.
Re-price before you cut over. Flat per-image becomes resolution-tiered per-token, and 4K lands near 3.8x what Imagen 4 Standard cost you.
If you're on Veo instead, you have more time than the page implies, and less certainty. June 30 came and went; nothing is gray yet.

The general version, which is the reason I keep a catalog of this at all: a model shutdown is a date on someone else's calendar, and nothing in your build system is watching it.

OAuth 2.1 para MCP: cómo proteger servidores remotos sin romper los clientes

Khavel — Sat, 08 Aug 2026 09:20:19 +0000

Un servidor MCP remoto que lee documentos o ejecuta tools no puede confiar en que el cliente sea conocido. OAuth 2.1 no es un botón de login: es el contrato que descubre identidad, limita scopes y permite validar cada llamada sin convertir la autorización en un prompt.

OAuth 2.1 para MCP es el mecanismo para que un cliente obtenga un token con permiso limitado y un servidor MCP remoto compruebe ese token antes de exponer tools, recursos o acciones. En MCP, el servidor protegido es un resource server; el host del agente es el OAuth client; y tu proveedor de identidad emite los access tokens.

TL;DR

La keyword principal es OAuth 2.1 MCP. La intención es de implementación: publicar Protected Resource Metadata, descubrir el authorization server, usar Authorization Code + PKCE, definir scopes pequeños y validar issuer, audience, expiración y permisos en cada tool call.

Mi postura: si tu MCP remoto puede tocar correo, documentos, datos de cliente o sistemas internos, no intentes resolver identidad con una API key compartida en una variable de entorno. Una key solo identifica una integración; no expresa quién pidió una acción ni qué alcance tenía. OAuth te da un contrato, pero sigues necesitando autorización de negocio en tu backend.

Qué cambió y por qué importa ahora

La revisión MCP 2026-07-28 endurece la autorización y elimina parte de la complejidad de sesiones del protocolo. Para OAuth, el cambio relevante es práctico: la especificación prioriza Client ID Metadata Documents (CIMD) para clientes que no tienen una relación previa con el servidor, deja Dynamic Client Registration como compatibilidad y exige discovery interoperable de metadata OAuth u OpenID Connect.

No conviertas eso en una migración cosmética. Un servidor MCP público no puede suponer que conoce de antemano todos los hosts que se conectarán. El flujo debe permitir discovery sin aceptar redirect URIs arbitrarias, tokens para otra audiencia o scopes enormes porque son más cómodos de configurar.

La propiedad evergreen es que el patrón no depende de un host concreto. Cambiarán SDKs y pantallas de consentimiento; seguirán siendo necesarios un resource identifier estable, metadata verificable, PKCE, token validation y una política de autorización que no viva dentro del modelo.

El servidor MCP valida el token antes de ejecutar una tool; el proveedor de identidad autentica y emite credenciales, pero no sustituye la política por tenant o recurso de tu aplicación.

El mapa mental correcto: cuatro roles, dos decisiones

Hay cuatro piezas. El cliente MCP (un host de agente) inicia la conexión y representa al usuario. El servidor MCP es el resource server que protege su endpoint HTTP. El authorization server autentica y emite tokens. Por último, tu API, base de datos o SaaS aguas abajo contiene el recurso real. No confundas el servidor MCP con el identity provider: uno recibe la tool call; el otro decide cómo se obtiene la identidad.

OAuth resuelve la primera decisión: ¿este cliente presenta un token válido para este recurso y con estos scopes? Tu aplicación resuelve la segunda: ¿este usuario de este tenant puede leer este documento o ejecutar esta acción ahora? El scope abre una capacidad general; la autorización de negocio revisa IDs, ownership, rol, estado y consecuencias.

Por ejemplo, tickets:read no autoriza a leer cualquier ticket. Autoriza a intentar la tool de lectura. El handler debe cargar el usuario desde claims verificadas y aplicar el filtro de tenant antes de consultar. Si pasas el user_id que propone el modelo como autoridad, has vuelto a delegar seguridad al prompt.

Flujo OAuth 2.1 de un servidor MCP remoto

El cliente llama al endpoint MCP sin token o con token insuficiente. El servidor devuelve 401 Unauthorized y un WWW-Authenticate: Bearer que apunta a su Protected Resource Metadata (PRM).
El cliente descarga el documento PRM. Ahí descubre el resource que debe aparecer como audiencia, el authorization server permitido y los scopes que el recurso entiende. Si el resource del JSON no coincide exactamente con el recurso pedido, debe rechazarlo.
El cliente descubre los endpoints OAuth u OpenID Connect del issuer, registra su identidad por pre-registro o CIMD cuando esté disponible y abre Authorization Code con PKCE. PKCE evita que otro proceso intercepte y canjee el código de autorización.
Tras consentimiento, el authorization server emite un access token dirigido a tu resource identifier. El cliente repite la llamada MCP con Authorization: Bearer …. El servidor valida firma o introspección, iss, aud, exp, scopes y cualquier claim de tenant antes de despachar una tool.
Cada tool ejecuta autorización propia, registra actor, cliente, tool, recurso y resultado, y devuelve un error de autorización seguro cuando corresponda. No guardes el access token en trazas, mensajes de error ni contenido de tool.

¿Te está sirviendo? Hay una dosis cada semana

Te resumo herramientas de IA para devs, agentes, MCP, seguridad y workflows en un email de 5 minutos. En español y sin ruido.

Suscribirme gratis

Protected Resource Metadata: la pieza que suele faltar

Protected Resource Metadata es un JSON servido por el resource server, no por el proveedor de login. Según RFC 9728 y MCP, publica el identificador del recurso y los authorization servers autorizados. En una ruta MCP como https://mcp.acme.test/remote, el cliente puede buscar https://mcp.acme.test/.well-known/oauth-protected-resource/remote o seguir el resource_metadata del challenge, que debe tener prioridad.

Lo que conviene comprobar

Evita meter aquí una lista fantasiosa de permisos. scopes_supported documenta lo que el servidor puede pedir; el challenge de una request concreta puede exigir un conjunto más preciso y el cliente debe tratar ese challenge como autoridad para ese intento. Es una forma de pedir consentimiento incremental sin entregar admin:* al primer clic.

Un ejemplo mínimo y explícito podría ser el siguiente. Los nombres de scopes son tuyos: diseña verbos y dominios que alguien de seguridad pueda revisar, no copias de los nombres de tools.

/.well-known/oauth-protected-resource/mcp

{
  "resource": "https://mcp.example.com/mcp",
  "authorization_servers": ["https://login.example.com"],
  "scopes_supported": [
    "issues:read",
    "issues:write",
    "deployments:read"
  ],
  "resource_name": "Example engineering MCP"
}

Implementación Node: challenge, metadata y guard de token

El SDK MCP puede encargarse del transporte y del registro de tools, pero el borde HTTP debe seguir devolver metadata y rechazar tokens inválidos antes de llegar al modelo o a los sistemas internos. Este ejemplo usa Express y jose para mostrar el contrato; adapta los endpoints y claims a tu proveedor de identidad. En producción, cachea JWKS respetando sus cabeceras y mantén las URLs de issuer y audiencia en configuración revisada, no en input del usuario.

auth-boundary.mjs

import express from "express";
import { createRemoteJWKSet, jwtVerify } from "jose";

const app = express();
const resource = "https://mcp.example.com/mcp";
const issuer = "https://login.example.com";
const jwks = createRemoteJWKSet(new URL(`${issuer}/.well-known/jwks.json`));

app.get("/.well-known/oauth-protected-resource/mcp", (_req, res) => {
  res.type("application/json").send({
    resource,
    authorization_servers: [issuer],
    scopes_supported: ["issues:read", "issues:write"],
  });
});

async function requireScope(req, res, next) {
  const token = req.get("authorization")?.replace(/^Bearer\s+/i, "");
  if (!token) {
    res.set("WWW-Authenticate",
      `Bearer resource_metadata="${resource.replace("/mcp", "/.well-known/oauth-protected-resource/mcp")}", scope="issues:read"`);
    return res.sendStatus(401);
  }
  try {
    const { payload } = await jwtVerify(token, jwks, { issuer, audience: resource });
    const scopes = String(payload.scope || "").split(" ");
    if (!scopes.includes("issues:read")) return res.sendStatus(403);
    req.actor = { subject: payload.sub, tenant: payload.tenant_id };
    return next();
  } catch {
    return res.sendStatus(401);
  }
}

app.post("/mcp", requireScope, mcpHttpHandler);

No copies este fragmento sin decidir si tu access token es JWT, opaco o ambos. Un token opaco normalmente se valida por introspección contra el authorization server; un JWT se valida contra claves públicas confiables. En ambos casos, la audiencia debe ser el resource identifier de tu MCP, no el nombre genérico de tu producto.

Scopes, audiencia y acciones sensibles

Empieza con scopes legibles y estrechos: repo:read, issues:read, issues:write, deployments:read. No concedas tools:* si solo necesitas una consulta. Los scopes no deben depender de un prompt ni de los argumentos declarados por el LLM; se comprueban en el servidor antes de ejecutar la operación.

Separa lectura de escritura. Para issues:write, añade una aprobación explícita en el host o una confirmación en tu aplicación antes de mutar. Para acciones de alto impacto —borrar, desplegar, cambiar permisos, enviar comunicación externa— utiliza scopes específicos, un segundo control contextual y logs de auditoría. OAuth reduce blast radius; no vuelve segura una tool excesivamente poderosa.

La claim aud es tu defensa contra token replay entre APIs. Un token emitido para https://api.example.com no debe servir para https://mcp.example.com/mcp solo porque comparten issuer. Valida audiencia exacta, no startsWith, no el hostname a ojo, y nunca aceptes una audiencia enviada por el cliente.

CIMD, pre-registro y por qué DCR ya no es la primera opción

El registro de cliente responde a otra pregunta: ¿qué aplicación está pidiendo el token? Si controlas cliente y servidor, el pre-registro de client ID y redirect URIs es simple y robusto. Si esperas hosts desconocidos, MCP prioriza Client ID Metadata Documents: el client ID puede ser una URL HTTPS que publica metadata verificable del cliente.

Dynamic Client Registration puede seguir existiendo por compatibilidad, pero no debería ser el camino que abra registros ilimitados y redirect URIs sin validación. La especificación actual lo coloca como fallback. Trata cada mecanismo como una superficie de seguridad: limita métodos de autenticación, exige URIs exactas y registra el client ID que obtuvo consentimiento.

No prometas soporte universal antes de probar hosts reales. Algunos clientes aún llegarán con capacidades antiguas. Publica claramente qué versiones, mecanismo de registro y scopes admites; ofrece el fallback mínimo sin bajar la validación del token por «compatibilidad».

Errores que rompen autorización MCP

Proteger solo la pantalla de consentimiento y dejar /mcp sin validar Authorization en cada request.
Aceptar cualquier issuer que aparezca en un JWT o construir el JWKS URL con una claim no confiable.
Comprobar firma y expiración, pero omitir audiencia, scopes, tenant y autorización del recurso concreto.
Usar una API key global como identidad del usuario y registrar todas las acciones como si las hiciera el servidor.
Devolver access tokens, authorization codes, cabeceras Bearer o datos de consentimiento en logs de trazas.
Entregar write al conectar el servidor aunque el usuario solo quiera explorar datos de lectura.
Confiar en que el modelo no invocará una tool peligrosa si el system prompt dice que tenga cuidado.

Checklist de lanzamiento

El endpoint MCP remoto rechaza sin token y expone WWW-Authenticate con resource_metadata.

La Protected Resource Metadata devuelve resource exacto, authorization server permitido y scopes revisados.

El cliente usa Authorization Code con PKCE y redirecciones registradas de forma exacta.

El servidor valida issuer, firma o introspección, audiencia, expiración y scope por request.

Cada tool aplica control de tenant, rol, propiedad y estado además del scope OAuth.

Lectura y escritura tienen scopes distintos; las mutaciones de impacto tienen aprobación y auditoría.

Tokens, códigos y cabeceras de autorización están redaccionados de logs, errores y trazas.

Hay tests para token de otra audiencia, scope insuficiente, issuer falso, tenant cruzado y request repetida.

Conclusión

La autorización MCP bien hecha no se nota cuando todo va bien: el host descubre la identidad necesaria, obtiene permiso mínimo y la tool funciona. Se nota cuando alguien conecta un cliente nuevo, intenta reutilizar un token contra otro recurso o pide una acción que no le corresponde; ahí el servidor debe fallar de forma predecible y auditable.

Mi recomendación es empezar con un solo recurso remoto y dos scopes de lectura/escritura, no con un catálogo enorme de permisos. Publica PRM, valida aud e iss, aplica autorización de negocio en cada tool y escribe los tests hostiles antes de abrir el servidor a más clientes. Es menos vistoso que una demo de agente, pero es lo que evita convertir MCP en una llave maestra.

Preguntas frecuentes

¿Qué es OAuth 2.1 para MCP?

Es el patrón de autorización que permite a un cliente MCP obtener un access token limitado y a un servidor MCP remoto validarlo antes de exponer tools o recursos protegidos.

¿Necesita OAuth un servidor MCP local por STDIO?

Normalmente no. Un servidor local puede usar credenciales del entorno o de una librería local; OAuth está pensado sobre todo para transportes HTTP remotos donde cliente y servidor no comparten una frontera de confianza.

¿Qué es Protected Resource Metadata en MCP?

Es un documento JSON del servidor MCP que declara el resource identifier, los authorization servers y scopes. El cliente lo descubre desde WWW-Authenticate o una ruta /.well-known/ para iniciar OAuth correctamente.

¿Basta con validar la firma del JWT?

No. También debes validar issuer, audiencia, expiración y scopes, y luego aplicar autorización de negocio por usuario, tenant y recurso concreto en la tool.

¿Debo usar Dynamic Client Registration en MCP?

Puede ser un fallback de compatibilidad. La especificación actual prefiere pre-registro cuando existe relación previa y Client ID Metadata Documents cuando cliente y servidor no se conocen de antemano.

¿OAuth protege contra prompt injection?

No directamente. OAuth limita quién puede invocar capacidades; sigue siendo necesario tratar contenido externo como no confiable, validar argumentos y exigir aprobación para efectos sensibles.

Cómo proteger un servidor MCP remoto con OAuth 2.1

Delimitar recurso. Define una URL HTTPS estable para el endpoint MCP que será la audiencia esperada del token.
Diseñar scopes. Separa lectura, escritura y acciones de alto impacto; evita permisos globales basados en nombres de tools.
Publicar metadata. Sirve Protected Resource Metadata con resource exacto, issuer permitido y scopes soportados.
Emitir challenge. Devuelve 401 con WWW-Authenticate y resource_metadata cuando no haya token o falte scope.
Configurar OAuth. Usa Authorization Code con PKCE, discovery OAuth/OIDC y redirect URIs registrados con coincidencia exacta.
Validar access token. Comprueba firma o introspección, issuer, audiencia, expiración, scopes y claim de tenant en cada llamada.
Autorizar tool. Evalúa usuario, tenant, rol, ID de recurso y estado de negocio antes de llamar a sistemas aguas abajo.
Auditar sin secretos. Registra actor, client ID, tool, recurso y resultado; redacta token, código y cabeceras.
Probar denegaciones. Añade casos de token de otra audiencia, scope insuficiente, issuer falso, tenant cruzado y mutación sin aprobación.

Fuentes y referencias

También te puede interesar

Recibe una lectura semanal de herramientas IA para devs

Cada semana te resumo herramientas de IA para devs, agentes, MCP, seguridad y workflows en un email de 5 minutos. En español y sin ruido.

Suscribirme gratis

Ollama en producción: Docker, privacidad, API compatible y límites que sí importan

Khavel — Thu, 06 Aug 2026 09:18:43 +0000

Ollama hace fácil ejecutar un modelo local; llevarlo a producción consiste en decidir qué puede alcanzar la red, quién llama a la API, cómo se versionan modelos y cuándo dejar de fingir que local equivale a seguro.

Ollama en producción es un runtime para servir modelos abiertos localmente mediante una API HTTP. No es un producto de privacidad ni una plataforma de agentes completa: es la capa de inferencia que debes encerrar detrás de autenticación, límites, red y observabilidad propias.

TL;DR

La keyword principal es Ollama en producción. La intención es práctica: desplegar Ollama con Docker, usar su API (o la compatibilidad con OpenAI), decidir dónde guardar modelos y evitar exponer el puerto 11434 a una red que no controlas.

Mi postura: úsalo primero para un caso interno, acotado y medible —clasificar tickets, resumir documentación permitida o un copiloto de bajo riesgo—. Si empiezas exponiendo un endpoint sin identidad, presupuesto ni trazas porque «el modelo está en tu máquina», has trasladado el riesgo; no lo has reducido.

Qué es Ollama y qué no resuelve

Ollama descarga y ejecuta modelos en una máquina y expone una API local. Su valor para un equipo es reducir fricción entre una aplicación y modelos abiertos: puedes hacer pull, servir chat, embeddings o tools y conservar un contrato HTTP estable cerca de tus datos o de tu entorno de desarrollo.

No sustituye un gateway de identidad, una política de datos, un sistema de secretos, un evaluador, un vector store ni un control de acceso por tenant. Tampoco hace seguro un prompt hostil: un modelo local puede seguir filtrar datos que le des, obedecer instrucciones inadecuadas o generar una acción errónea si tu aplicación se lo permite.

Piensa en Ollama como piensas en Postgres: un componente importante, no la arquitectura completa. La pregunta sana no es «¿puedo correr un LLM en local?», sino «¿qué petición autenticada puede usar qué modelo, sobre qué datos, con qué límite y cómo demostraré qué pasó?».

Una arquitectura mínima separa al consumidor del runtime: el gateway aplica identidad y cuotas; Ollama sirve inferencia; el volumen conserva modelos; y la telemetría permite operar sin registrar prompts completos por defecto.

Arquitectura mínima que sí desplegaría

La versión pequeña tiene cuatro piezas. La aplicación llama a un backend o gateway propio; ese borde autentica al usuario o servicio, limita tasa y tamaño, decide el modelo permitido y crea una traza. Solo entonces llama a Ollama en una red privada. El volumen de modelos es persistente y el sistema de métricas recibe duración, tokens o campos de uso disponibles, modelo, estado y errores, no necesariamente el prompt literal.

El puerto de Ollama debe quedar en loopback o en una red de contenedores no enrutable desde Internet. Si necesitas acceso remoto, publica el gateway con TLS y autenticación; no conviertas 11434 en tu API pública. Esta separación también te deja cambiar de runtime, enrutar una parte del tráfico a un proveedor externo o apagar un modelo problemático sin editar cada cliente.

Para varios tenants, el aislamiento no sale gratis por ejecutar local. Mantén la identidad y la autorización fuera del prompt: filtra documentos antes de construir contexto, utiliza credenciales de servicio de mínimo privilegio y no aceptes que el cliente elija libremente modelo, URL de herramientas o parámetros que multiplican coste.

Despliegue Docker seguro por defecto

Este compose.yaml no intenta resolver alta disponibilidad. Sí evita el error más común: publicar Ollama en todas las interfaces. El binding explícito a 127.0.0.1 hace que el host local pueda inspeccionarlo, pero no lo anuncia a la LAN. Conserva los modelos en un volumen para que una recreación del contenedor no obligue a descargarlos de nuevo.

compose.yaml

services:
  ollama:
    image: ollama/ollama:latest
    restart: unless-stopped
    ports:
      - "127.0.0.1:11434:11434"
    volumes:
      - ollama-models:/root/.ollama
    healthcheck:
      test: ["CMD-SHELL", "ollama list >/dev/null 2>&1"]
      interval: 30s
      timeout: 10s
      retries: 5

volumes:
  ollama-models:

Arranca con docker compose up -d, descarga un modelo desde una sesión administrativa con docker exec -it <contenedor> ollama pull llama3.2 y prueba curl http://127.0.0.1:11434/api/tags. En hardware acelerado, sigue la sección de GPU de la documentación oficial y verifica en logs qué backend se cargó: asumir que hay GPU es una forma cara de descubrir que todo está sirviendo por CPU.

API: úsala directa o mantén compatibilidad OpenAI

La API nativa de Ollama es la mejor elección cuando controlas el cliente y quieres sus conceptos tal cual. La compatibilidad parcial con OpenAI es útil para migrar un SDK existente o para que tu gateway tenga una interfaz uniforme, pero no debe llevarte a asumir paridad total de endpoints, estado o campos. Lee la tabla de compatibilidad de la versión que despliegues y prueba los casos que consumes.

¿Te está sirviendo? Hay una dosis cada semana

Te resumo herramientas de IA para devs, agentes, MCP, seguridad y workflows en un email de 5 minutos. En español y sin ruido.

Suscribirme gratis

Lo que conviene comprobar

Un cliente Python mínimo puede hablar por la ruta compatible sin poner una clave secreta local. La cadena api_key existe porque el SDK la exige; no equivale a autenticar tu servidor. La autenticación real debe estar en el gateway delante de ese endpoint.

client.py

from openai import OpenAI

client = OpenAI(
    base_url="http://127.0.0.1:11434/v1/",
    api_key="ollama",  # requerido por el SDK; no autentica Ollama
)

reply = client.chat.completions.create(
    model="llama3.2",
    messages=[
        {"role": "system", "content": "Responde solo con JSON valido."},
        {"role": "user", "content": "{\"ticket\": \"T-42\"}"},
    ],
    response_format={"type": "json_object"},
)
print(reply.choices[0].message.content)

La validación continúa después del modelo. Parsea el JSON con un schema real, rechaza campos inesperados y no conviertas una respuesta del LLM directamente en SQL, shell, HTTP o una llamada mutante. Ese límite importa igual con modelo local, cloud o híbrido.

Modelos y Modelfile: versiona el contrato, no solo el nombre

Un nombre de modelo flotante no es una garantía de comportamiento. Para un workflow serio, fija versión de imagen, modelo y configuración que realmente evaluaste. Guarda también el hash de tu prompt, la plantilla, el tamaño de contexto, parámetros relevantes y el dataset de evaluación. Si cualquiera cambia, tienes una nueva variante de producción.

Un Modelfile permite partir de un modelo y declarar parámetros o instrucciones. Es útil para una política de salida estable o un contexto concreto, pero no es una frontera de seguridad: un usuario todavía puede intentar desviar la tarea y tu aplicación sigue teniendo que validar resultados y permisos.

Modelfile

FROM llama3.2
PARAMETER temperature 0.1
PARAMETER num_ctx 8192
SYSTEM """
Eres un clasificador de tickets internos.
Devuelve JSON con categoria, prioridad y evidencia breve.
No inventes datos que no aparezcan en la entrada.
"""

Crea una etiqueta evaluable con ollama create soporte-v1 -f Modelfile, ejecuta tu conjunto de casos y promociona esa etiqueta solo si pasa los gates de precisión, rechazo, latencia y coste de infraestructura. Una modificación de num_ctx puede cambiar memoria y latencia de forma material; no es un ajuste cosmético.

Privacidad: qué mejora y qué sigue siendo tu problema

Ejecutar inferencia dentro de tu red puede reducir la exposición a un proveedor externo, pero solo si el input, los logs, el almacenamiento de modelos, los backups, los proxies y la observabilidad respetan el mismo límite. Una traza con prompt completo en un SaaS externo invalida una parte importante de la decisión, aunque el token se haya calculado en local.

Define una clasificación de datos antes de permitirlos: público interno, confidencial, datos personales, secretos y datos prohibidos. Para cada clase, decide si puede entrar al prompt, cuánto tiempo se conserva, quién puede ver logs y qué hacer ante borrado o incidente. Si no puedes contestar esas preguntas, usa datos sintéticos hasta poder hacerlo.

Y no confundas ausencia de tráfico externo con seguridad. Prompt injection indirecta, documentos maliciosos, exfiltración mediante herramientas y una respuesta alucinada siguen siendo riesgos de la aplicación. Mantén tools con allowlist, separa lectura de escritura y exige aprobación humana para efectos externos.

Coste y capacidad: local no significa gratis

El coste se mueve de una factura por token a hardware, electricidad, VRAM o RAM, tiempo de operación, disco y capacidad ociosa. Por eso conviene medir por workload: tokens por segundo, latencia p50/p95, cola, memoria, modelo cargado, errores de carga y porcentaje de requests abandonadas. El número que importa no es solo «cuánto tarda una respuesta», sino cuánto tarda una petición útil bajo concurrencia real.

Empieza con una concurrencia pequeña y un modelo que quepa con margen en tu máquina. Aumentar contexto, paralelismo o modelos residentes puede deteriorar latencia o provocar presión de memoria. Pon timeout en el gateway, backpressure para la cola y un error claro cuando no hay capacidad, en lugar de dejar peticiones colgadas hasta que el caller reintente en cascada.

Si un caso requiere gran contexto, razonamiento fuerte o SLA estricto, un runtime local puede no ser la mejor capa principal. Diseña una ruta explícita: modelo local para clasificación y extracción barata; proveedor remoto aprobado para los casos que justifiquen coste y datos permitidos; y un fallback humano cuando el resultado no es seguro.

Observabilidad y evaluación antes de ampliar tráfico

Registra un ID de petición, usuario o servicio pseudonimizado, modelo, versión de prompt, latencia, cola, resultado de schema, tool calls y motivo de denegación. Evita convertir el tracing en un segundo repositorio de secretos: usa redacción, hashes o muestras aprobadas para el contenido sensible.

Antes de cambiar modelo, cuantización, contexto o Modelfile, ejecuta un dataset fijo con casos normales, ambiguos y hostiles. Mide tarea correcta, formato válido, evidencia, rechazo apropiado, coste de infraestructura y latencia. Haz un canary pequeño y compara contra la versión anterior; una demo manual no detecta regresiones silenciosas.

El enlace con la guía de evaluación RAG es deliberado: aunque no haya retrieval, necesitas una disciplina de dataset, baseline y gates. Sin ese contrato, cada actualización de modelo se convierte en una apuesta sobre usuarios reales.

Errores que veo al desplegar Ollama

Publicar 0.0.0.0:11434 y confiar en que la red corporativa ya es un control de acceso.

Permitir que el frontend elija cualquier modelo, tamaño de contexto o tool sin pasar por backend.

Descargar modelos sin inventario, licencia revisada, versión fijada ni prueba de comportamiento.

Guardar prompts completos, credenciales y documentos sensibles en logs por defecto.

Tratar el system prompt o el Modelfile como si fueran autorización de seguridad.

Medir una respuesta aislada en un portátil y declarar que hay capacidad de producción.

Cambiar modelo y prompt a la vez; cuando baja la calidad, nadie sabe qué regresó.

Checklist de salida a producción

Ollama queda en loopback o red privada; no hay puerto de inferencia abierto a Internet.
Un gateway autentica clientes, aplica cuotas, timeouts y un allowlist de modelos.
Los modelos, Modelfiles y parámetros usados están versionados y evaluados.
Los datos que entran al prompt tienen clasificación, retención y redacción definida.
Las respuestas pasan schema validation antes de llegar a sistemas internos.
Las tools tienen permisos mínimos; las acciones mutantes requieren confirmación y auditoría.
Hay métricas de latencia, capacidad, errores y resultado de evaluación sin registrar secretos por defecto.
Un canary y un rollback permiten volver a la variante anterior sin editar todos los clientes.

Conclusión

Ollama es muy útil cuando necesitas iterar con modelos abiertos cerca de tus sistemas y no quieres que cada equipo invente su propio launcher. Pero su ventaja se diluye si lo expones como una API anónima, no sabes qué modelo responde o registras indiscriminadamente todo el contexto.

Lo que conviene comprobar

Mi recomendación es aburrida y eficaz: un modelo, una tarea interna de lectura, un gateway, un dataset de evaluación, una red privada y telemetría mínima. Cuando puedas explicar latencia, datos, permisos y rollback con la misma claridad que explicas ollama run, entonces ya tienes una base para ampliar.

Preguntas frecuentes

¿Qué es Ollama en producción?

Es usar Ollama como runtime de inferencia para una aplicación real, con despliegue, red, identidad, límites, observabilidad, evaluación y rollback; no solo ejecutar un chat en local.

¿Ollama es privado por defecto?

Ejecutar un modelo en tu infraestructura puede reducir exposición externa, pero no garantiza privacidad. Siguen importando los prompts, logs, backups, proxies, permisos, modelos descargados y herramientas conectadas.

¿Puedo exponer Ollama directamente a Internet?

No es una buena arquitectura. Mantén el runtime en red privada y expón un gateway con TLS, autenticación, cuotas y validación de requests.

¿La compatibilidad OpenAI de Ollama es completa?

No. Facilita reutilizar parte de clientes y endpoints, pero debes comprobar las funciones y límites que necesita tu aplicación en la documentación y en tests de integración.

¿Cómo reduzco el coste de Ollama?

Mide tokens por segundo, latencia, cola, memoria y utilización; elige modelos que encajen en tu hardware, limita contexto y concurrencia, y enruta solo tareas justificadas al modelo más caro.

¿Un Modelfile protege contra prompt injection?

No. Sirve para configurar un modelo, pero la defensa requiere tratar contenido externo como datos, validar salidas, limitar tools y aplicar permisos en el servidor.

Cómo desplegar Ollama para un primer workflow interno

Acotar la tarea. Empieza con una operación de lectura y bajo riesgo, como clasificación o extracción de documentos permitidos.
Preparar red privada. Ejecuta el contenedor con puerto en loopback o una red interna; no publiques el puerto de inferencia.
Persistir y descargar. Monta volumen de modelos, descarga una versión elegida y anota imagen, modelo y parámetros.
Interponer gateway. Autentica al consumidor, limita tasa, fija modelos admitidos, define timeout y crea una traza por request.
Versionar contrato. Crea Modelfile si hace falta, guarda prompt y schema de salida, y etiqueta la variante evaluada.
Validar resultados. Parsea la salida con schema y separa cualquier tool o efecto externo de la respuesta del modelo.
Medir baseline. Ejecuta dataset de casos normales, ambiguos y hostiles; guarda calidad, latencia, capacidad y fallos.
Desplegar canary. Envía una fracción pequeña de tráfico, compara con baseline y conserva rollback a la variante previa.

Fuentes y referencias

También te puede interesar

Recibe una lectura semanal de herramientas IA para devs

Cada semana te resumo herramientas de IA para devs, agentes, MCP, seguridad y workflows en un email de 5 minutos. En español y sin ruido.

Suscribirme gratis

Make your CI fail before your model does

Khavel — Wed, 05 Aug 2026 11:45:11 +0000

Today, August 5 2026, claude-opus-4-1 retires. Anthropic said so on June 5, on their model-deprecations page, with the date in plain text. Two months of notice.

If that id is hard-coded in a repo somewhere, nothing in the build system found out. Tests passed all summer. The linter had no opinion. The dependency bot, which will open a PR because a transitive dev dependency moved from 4.2.1 to 4.2.2, has no idea the model your product is built on has an expiry date on someone else's calendar.

That is the actual shape of the problem: a model dying is a calendar event, not a code change. Nothing in CI watches a calendar.

Why your provider's email doesn't cover you

It does exist. Anthropic, OpenAI and Google all email deprecation notices — they are contractually motivated to. But they email the account owner: whoever's card is on the org. Not the repo. Not the pull request. Not the person who pinned the id eight months ago and left.

So the notice lands in a billing inbox, and the id sits in src/llm.ts until the call starts 404ing. Between those two events there are usually months where a build could have told you, and didn't.

The numbers, from today's catalog

I maintain AI Model Watch, a daily-verified catalog of model prices, context limits and lifecycle dates, every row carrying the provider URL it was read from. Pulled from the live feed while writing this (updated: 2026-08-05, 204 models):

74 of the 204 are already deprecated or retired.
12 carry a retirement date inside the next 90 days (13 if you count the one retiring today).

Do not add those together. 9 of the 12 are already inside the 74 — being deprecated and being near your retirement date is the normal case, not two separate populations. The distinct total is 77, not 86. Two counts in one paragraph is a set problem, and the word joining them is a claim like any other.

The interesting three are the ones that aren't in the 74. qwen3-max is ga today, priced today, sitting in the current docs looking entirely healthy — and Alibaba's own deprecation table retires it on September 8, pointing at qwen3.7-max. A status field would never have warned you. Only the date does.

Thirty seconds to a check

One file, no dependencies, no key, no signup, Node 18+:

curl -sLO https://aimodelwatch.dev/ci/check-models.mjs
node check-models.mjs --scan .

--scan walks your source and picks out anything that looks like a model id it knows, so there is nothing to configure on the first run. Here is a real run against a three-line fixture — output as it came out, only the Windows path separators normalized:

$ node check-models.mjs --scan .
check-models 1.1.0 — feed updated 2026-08-05, 204 models
scanned . — found 3 model ids in your source
  claude-opus-4-1  src/llm.ts:2
  gemini-2.5-flash  src/llm.ts:4
  qwen3-max  src/llm.ts:3
checked 3 models · retirement threshold 90 days

✖ claude-opus-4-1: Claude Opus 4.1 is DEPRECATED. Retires 2026-08-05 (in 0 days). Provider's stated replacement: claude-opus-4-8.
✖ qwen3-max: Qwen3-Max retires 2026-09-08 — 34 days away (threshold 90). Provider's stated replacement: qwen3.7-max.
✖ gemini-2-5-flash: Gemini 2.5 Flash is DEPRECATED. Retires 2026-10-16 (in 72 days). Provider's stated replacement: gemini-3.6-flash.

3 problems, 0 warnings. Details: https://aimodelwatch.dev/deprecations

$ echo $?
1

Three ids, three providers, three different failure modes: one that expires today, one still marked GA with a date five weeks out, one deprecated with a quarter left. Exit 1 on all of them.

(The id in my source is gemini-2.5-flash and the finding comes back as gemini-2-5-flash — providers write the same model both ways depending on the page, so ids are matched in a normalized form. Worth knowing if you grep the JSON report.)

In GitHub Actions

There is an action, so this is the entire setup — no install step, no setup-node, no inputs:

# .github/workflows/model-lifecycle.yml
name: model lifecycle
on:
  pull_request:
  schedule: [{ cron: '0 7 * * 1' }]
jobs:
  check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: Khavel/check-models-action@v1

With no inputs it walks the repo, finds every model id in the source, and checks all of them. Findings come back as inline ::error annotations on the offending line plus a job-summary table. The action vendors the script, so @v1 pins the code while the catalog stays live.

The cron line is the half that matters. A pull_request trigger only helps on days somebody opens a PR. Deprecations are announced on days nobody opens a PR — that is the entire nature of a calendar event. A weekly run is what turns "we found out in August" into "we found out in June".

The other half: prices move too

Nobody emails you when a model gets cheaper or dearer. There is no deprecation notice for a 40% output-price hike; the invoice just changes shape at the end of the month.

So pin the numbers you costed the product on, and commit the file:

node check-models.mjs --scan . --pin .amw-pin.json --update-pin   # once, then commit
node check-models.mjs --scan . --pin .amw-pin.json                # every build

The pin file is small and diffable — status, the three prices, retires_on, the stated replacement, per model. When a value moves away from what you pinned, it shows up as a build failure with both numbers in it:

✖ qwen3-max: Qwen3-Max input price ($/1M) changed since your pin: 0.8 → 1.2.

(That one I produced by editing the pin to an old value — I am not going to fake a price change to make a point. The mechanism is what's real: it compares your committed snapshot against today's catalog.)

One sharp edge, stated up front

GitHub does not evaluate a composite action's outputs when the action fails the job. So steps.*.outputs.* come back empty on exactly the path you care about — the failing one.

I could not fix that from inside a composite action, so instead the JSON report is written unconditionally: point report-path somewhere and read it with if: always(), or set warn-only: true and branch on the outputs yourself. Worth knowing before you build a Slack notification on top of the outputs and wonder why it posts empty messages.

What's underneath

The check reads a free JSON feed — no key, no signup, CORS open, and every row carries the provider page the values were read from:

curl -s https://aimodelwatch.dev/api/models.json | head -20
curl -s https://aimodelwatch.dev/api/deprecations.json | head -20

Everything in it is what the provider states, taken from its own documentation. Where a provider publishes nothing, the field is null and the check stays quiet rather than guessing — an invented retirement date that fails someone's build would be much worse than a missing one.

If you would rather not put a third-party action in your pipeline, the script is one file with no dependencies and works on any CI. curl it and run it.

Either way: the check costs about two lines, and the thing it catches is a model that stops existing while your tests are green.

Docs and options: https://aimodelwatch.dev/ci
Action source: https://github.com/Khavel/check-models-action
The feed: https://aimodelwatch.dev/api/models.json

MCP Apps: cómo añadir interfaces interactivas a tools MCP sin abrir un agujero de seguridad

Khavel — Thu, 30 Jul 2026 10:17:31 +0000

MCP Apps permite que una tool devuelva una interfaz interactiva dentro del chat. Es útil para aprobar, explorar y decidir; no para saltarse permisos ni convertir el agente en una web embebida sin controles.

MCP Apps es una extensión de Model Context Protocol para que un servidor devuelva una interfaz interactiva —un dashboard, formulario, tabla o flujo de aprobación— dentro de un host de chat compatible. La UI vive en un iframe sandboxed y habla con el host mediante mensajes controlados; no obtiene acceso directo al DOM, cookies o almacenamiento del host.

TL;DR

La keyword principal es MCP Apps. La intención es práctica: entender cuándo una tool necesita UI, cómo conectar la vista con un servidor MCP y qué límites de seguridad son imprescindibles antes de ponerla delante de usuarios o datos reales.

Mi postura: una UI MCP tiene sentido cuando reduce ambigüedad humana, no cuando maquilla una tool demasiado poderosa. Un formulario de aprobación, una tabla filtrable o un explorador de resultados puede evitar decenas de turnos. Una mini-aplicación con acceso libre a red y tools de escritura solo multiplica superficie de ataque.

Qué es una MCP App y qué no es

Un servidor MCP normal expone tools, resources y prompts. La respuesta de una tool suele ser texto y, opcionalmente, structuredContent. Una MCP App añade una resource de UI, normalmente identificada con ui://, que el host puede renderizar junto al resultado. La vista recibe datos del resultado y puede pedir acciones al host por un puente de mensajes.

No es una nueva forma de hacer una SPA pública. La conversación sigue siendo el contexto principal; la interfaz es una mejora progresiva para la parte que una lista de texto resuelve mal. Si el host no soporta MCP Apps, la tool debe seguir devolviendo una respuesta textual útil. Ese fallback no es un detalle: es el contrato de portabilidad.

Tampoco es una autorización implícita. Que la vista muestre un botón no significa que pueda ejecutar una operación. El servidor debe validar usuario, tenant, argumentos y política igual que lo haría si la llamada viniera de un cliente HTTP ordinario.

La UI no se conecta libremente al host: recibe contexto y solicita acciones a través de un bridge; el host sigue decidiendo qué capacidades permite.

La arquitectura: servidor, host y vista

Hay tres piezas. El servidor MCP registra una tool y una resource HTML. El host descubre ambas, ejecuta la tool y, si soporta la extensión, monta la resource en un iframe aislado. La vista es un cliente pequeño: se inicializa, recibe input y resultado de la tool, y puede solicitar tools/call, recursos o acciones del host según sus capacidades.

La separación entre content y structuredContent importa. content es la explicación que puede necesitar el modelo y sirve como fallback textual. structuredContent es un objeto pensado para renderizar: IDs, series de datos, estados y filas. No metas en el contexto del modelo 3.000 filas que solo necesita pintar una tabla; entrega una síntesis textual y datos estructurados a la UI.

El host es la frontera de confianza. Puede restringir llamadas, enlaces externos, modo de visualización y capacidades de la app. Diseña la vista asumiendo que no tiene permiso para todo y que una petición puede ser rechazada; es una propiedad sana, no una limitación incómoda.

¿Te está sirviendo? Hay una dosis cada semana

Te resumo herramientas de IA para devs, agentes, MCP, seguridad y workflows en un email de 5 minutos. En español y sin ruido.

Suscribirme gratis

Cuándo una tool necesita UI

Usaría MCP Apps para explorar datos con filtros, comparar opciones, revisar un diff, rellenar un formulario de aprobación, visualizar un pipeline o confirmar una acción con consecuencias. En todos esos casos hay estado visual, selección humana o demasiada información para que el modelo la resuma sin perder control.

No la usaría para una búsqueda de documentación, una consulta determinista, una acción de una línea o un workflow que nadie necesita inspeccionar. Una respuesta textual o structuredContent basta y es más simple de probar. La UI también introduce lifecycle, accesibilidad, CSP, degradación y una matriz de hosts; no la añadas solo porque es nueva.

La pregunta de producto es concreta: ¿qué decisión humana mejora al ver y manipular este resultado? Si no puedes responderla, conserva la tool como texto. Si la respuesta es revisar, seleccionar o aprobar, una UI embebida puede reducir errores y turnos innecesarios.

server.ts — tool con fallback textual y datos para la vista

import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";

const server = new McpServer({ name: "release-dashboard", version: "1.0.0" });

server.registerResource(
  "release-view",
  "ui://release-dashboard/view.html",
  {},
  async () => ({
    contents: [{
      uri: "ui://release-dashboard/view.html",
      mimeType: "text/html;profile=mcp-app",
      text: await loadBundledHtml()
    }]
  })
);

server.registerTool(
  "list_release_risks",
  {
    title: "Riesgos de despliegue",
    inputSchema: { service: "string" },
    _meta: { ui: { resourceUri: "ui://release-dashboard/view.html" } }
  },
  async ({ service }, extra) => {
    const user = await requireAuthorizedUser(extra);
    const risks = await readRisksForTenant(user.tenantId, service);
    return {
      content: [{ type: "text", text: `Hay ${risks.length} riesgos abiertos para ${service}.` }],
      structuredContent: { service, risks: risks.map(toSafeViewModel) }
    };
  }
);

El ejemplo deja dos decisiones visibles. La resource no se inventa una URL web: usa un URI ui:// registrado. Y la tool comprueba identidad y tenant antes de leer datos; structuredContent solo contiene el modelo de vista seguro. El paquete @modelcontextprotocol/ext-apps ofrece helpers para registrar tools/resources y construir la vista, pero no sustituye esas validaciones.

La vista: trata el iframe como un cliente no confiable

La vista debe inicializarse con el bridge, esperar los eventos del host y renderizar solo datos validados. Su trabajo es presentar y recoger intención del usuario, no decidir permisos. Cuando el usuario pulsa aprobar, la vista llama a una tool estrecha con un ID; el servidor vuelve a comprobar que la persona puede aprobar ese recurso y que el estado sigue siendo válido.

Evita pasar secretos, tokens de larga vida o documentos completos en el HTML de la resource. El iframe aislado reduce privilegios, pero no convierte datos sensibles en inocuos. Envía el mínimo necesario, aplica redacción por tenant y considera que cualquier dato mostrado puede ser copiado por el usuario autorizado.

Para acciones de escritura, modela una transición explícita: preview → confirm → execute. La UI puede enseñar el impacto y pedir confirmación; el servidor debe usar un idempotency key y rechazar operaciones repetidas o estados caducados. Es el mismo patrón que usarías en una API de pagos, solo que aquí el disparador nació dentro de un chat.

CSP, red y enlaces: el límite que suele olvidarse

Una MCP App declara sus necesidades de red y el host puede aplicar esa política. Empieza con una CSP restrictiva: sin conexiones externas si no son necesarias; dominios concretos para API o assets; nada de comodines por comodidad. Si la app necesita datos, es preferible que los pida mediante una tool auditada antes que abrir connect-src \*.

No dejes que HTML o markdown procedente de tickets, documentos o usuarios llegue a la vista como markup confiable. Sanitiza, usa textContent para texto, limita URLs y evita inyectar plantillas dinámicas. Prompt injection no desaparece por mover el resultado a una UI: el contenido externo puede seguir intentando influir en el humano o en llamadas posteriores.

Abrir un enlace externo debe ser una capacidad explícita del host, no un efecto lateral de renderizar una celda de tabla. Enseña dominio y destino cuando una acción saque al usuario de la conversación. La fricción pequeña es preferible a una redirección silenciosa desde un panel que parece interno.

Compatibilidad progresiva y testing

El soporte de MCP Apps varía entre hosts y puede cambiar. Por eso prueba dos salidas: una sesión con UI y otra con solo texto. El contenido textual debe explicar resultado, límites y siguiente acción sin depender de la interfaz. Si el host no renderiza la vista, la tool no puede convertirse en un callejón sin salida.

Automatiza tests de contrato en el servidor: schema de entrada, autorización, filtrado por tenant, modelo de structuredContent, errores y doble ejecución. En la vista, prueba que una respuesta parcial, vacía o denegada no bloquee el chat. Y ensaya manualmente la interacción con los hosts que de verdad vas a soportar; no declares compatibilidad por haber visto un ejemplo funcionar en local.

Mide utilidad, no solo clicks: cuántos turnos evita la UI, cuántas aprobaciones se revierten, qué operaciones se cancelan, cuánto tarda en aparecer el resultado y cuántas veces se usa el fallback textual. Si no reduce error o tiempo de decisión, una respuesta bien diseñada probablemente era mejor.

Checklist de producción

La tool devuelve una respuesta textual completa aunque el host no soporte UI.
La resource usa un URI ui:// registrado y MIME type específico para MCP Apps.
La vista recibe structuredContent mínimo y no secretos ni datos de otros tenants.
Cada tool de lectura o escritura revalida usuario, tenant, scopes y estado en servidor.
Las acciones mutantes tienen preview, confirmación, idempotencia y auditoría.
La CSP declara solo dominios imprescindibles; sin comodines ni scripts remotos no revisados.
La UI trata todo contenido externo como datos y lo sanitiza antes de mostrarlo.
Se prueba el fallback textual y la degradación en cada host objetivo.
Logs guardan IDs, acción, resultado y denegaciones; no el contenido sensible por defecto.

Conclusión

MCP Apps resuelve una carencia real: hay decisiones que una conversación textual explica mal. El valor no es poner un dashboard bonito dentro de un chat; es dar una superficie de revisión pequeña, contextual y reversible a una tool que ya tiene un contrato claro.

Empezaría con una sola tool de lectura y una vista que haga una cosa excelente: filtrar incidencias, revisar resultados o comparar un plan. Mantén fallback textual, CSP corta, datos mínimos y calls de escritura separadas. Cuando eso sea operable, amplía. En agentes, cada pixel interactivo también es una superficie de permiso.

Preguntas frecuentes

¿Qué es MCP Apps?

Es una extensión de Model Context Protocol que permite a un servidor MCP entregar una interfaz interactiva dentro de un host compatible, además del contenido textual y estructurado normal de una tool.

¿Una MCP App funciona en todos los clientes?

No. El soporte depende del host. Por eso una tool debe seguir ofreciendo un fallback textual útil cuando la interfaz no se pueda renderizar.

¿La UI de MCP Apps puede acceder al DOM o las cookies del host?

No debería. La arquitectura usa un iframe sandboxed y comunicación mediante un bridge de mensajes; el host conserva el control de capacidades.

¿Cuándo usar MCP Apps en lugar de una respuesta de texto?

Cuando el usuario necesita explorar datos, seleccionar opciones, revisar un artefacto o aprobar una acción. Para consultas simples, texto o structuredContent suele ser más robusto.

¿Cómo protejo una MCP App?

Valida autorización en el servidor para cada tool, limita structuredContent, aplica CSP restrictiva, sanitiza datos externos, exige confirmación para escrituras y registra acciones sin guardar secretos por defecto.

¿Puedo reutilizar una web existente como MCP App?

Sí, si adaptas la vista al lifecycle y al bridge del host, declaras recursos y CSP, y conservas una salida textual. No presupongas que una SPA existente funciona segura dentro de un iframe MCP sin cambios.

Cómo crear una primera MCP App segura para una tool existente

Elegir una decisión visual. Selecciona una tool de lectura donde filtrar, comparar o aprobar aporte más que texto.
Definir fallback. Escribe primero el content textual completo que recibirá un host sin soporte de UI.
Registrar resource. Publica una resource ui:// con HTML empaquetado y MIME type de MCP App.
Devolver datos mínimos. Añade structuredContent con un view model seguro, sin secretos ni campos de otros tenants.
Construir la vista. Inicializa el bridge, renderiza estados de carga y trata respuestas denegadas o parciales como normales.
Añadir llamada estrecha. Si hay interacción, llama a una tool con IDs y valida usuario, tenant, scopes y estado en servidor.
Cerrar CSP. Declara solo redes y capacidades imprescindibles; usa herramientas MCP antes que conexiones libres desde el iframe.
Probar degradación. Ejecuta los tests de contrato y comprueba la salida textual en hosts sin UI antes de anunciar soporte. > ### Criterio técnico > > Un buen chunk en tiempo real no es el más corto ni el más semántico: es el que conserva evidencia, tiempo y estado suficiente para responder sin inventar continuidad.

Fuentes y referencias

También te puede interesar

Recibe una lectura semanal de herramientas IA para devs

Cada semana te resumo herramientas de IA para devs, agentes, MCP, seguridad y workflows en un email de 5 minutos. En español y sin ruido.

Suscribirme gratis

Claude Opus 4.1 retires in a week — and its replacement is exactly 3x cheaper

Khavel — Wed, 29 Jul 2026 11:52:42 +0000

If you have claude-opus-4-1-20250805 hard-coded anywhere, you have until August 5, 2026. That is seven days from the day this went up.

Anthropic deprecated it on June 5, 2026 and published a tentative retirement date of August 5. It is the only Claude model on Anthropic's status table currently marked Deprecated rather than Active or Retired — and the only Claude model with a retirement date still in the future.

The interesting part isn't the deadline. It's what the migration does to your bill.

The replacement is 3× cheaper on every single price dimension

Anthropic's deprecation table names claude-opus-4-8 as the recommended replacement. Here is what changes, straight from Anthropic's published pricing:

Price dimension (per MTok)	Opus 4.1 (retiring)	Opus 4.8 (replacement)	Ratio
Input	$15	$5	3.0×
Output	$75	$25	3.0×
Cache write (5 min)	$18.75	$6.25	3.0×
Cache write (1 hour)	$30	$10	3.0×
Cache hits & refreshes	$1.50	$0.50	3.0×
Batch input	$7.50	$2.50	3.0×
Batch output	$37.50	$12.50	3.0×

Not "roughly a third". Exactly a third, on all seven, with no rounding.

On a modest 10M input / 2M output month, that is $300 → $100. On a coding-agent-shaped workload — call it 90M in and 25M out per month — it's $3,225 → $1,075, a difference of $2,150 every month, for a migration you are being forced into anyway.

And the price cut isn't a downgrade in disguise:

	Opus 4.1	Opus 4.8
Context window	200k tokens	1M tokens
Max output	32k tokens	128k tokens

Five times the context, four times the max output, one third the price. It is rare for a forced migration to be strictly better on every published axis, and this one is.

One wrinkle worth knowing: the two docs pages name different targets

Anthropic's model deprecations page lists the recommended replacement for claude-opus-4-1-20250805 as claude-opus-4-8, as a column in its migration table.

Anthropic's models overview says, in prose, to migrate to Claude Opus 5.

Both are first-party, and they are not really in conflict — Opus 5 is also $5 / $25 with a 1M context window, so the 3× arithmetic holds whichever you pick. But if you're automating a migration off a deprecation feed, this is the kind of thing that decides which string your script writes. Worth reading both pages rather than one.

The other thing: at Anthropic, "retired" is a per-cloud fact

Here's what I didn't expect to find while checking the above.

Anthropic's status table lists five retired Claude models. But its live pricing table still carries three of them, with full current rates and an inline qualifier naming the platforms where they're still served:

Claude Opus 4 — "retired, except on Google Cloud" — $15 in / $75 out
Claude Sonnet 4 — "retired, except on Bedrock and Google Cloud" — $3 / $15
Claude Haiku 3.5 — "retired, except on Bedrock and Google Cloud" — $0.80 / $4

The other two retired models (Claude 3.7 Sonnet, Claude 3 Haiku) are gone from the pricing table entirely.

So "retired" on Anthropic's own API does not necessarily mean unavailable to you. If you call Claude through Bedrock or Vertex, a model that is dead on the first-party API may still be serving your traffic, at the same published price it always had. That is genuinely useful if you're on a partner cloud — and genuinely misleading if you read "retired" as a single global fact and assume your Bedrock integration is about to break.

Note the exception is stated per model, not as a policy. Opus 4 is Google Cloud only; Sonnet 4 and Haiku 3.5 are Bedrock and Google Cloud. "Retired means it's still on Bedrock" is false as a general rule — you have to read the row.

Checking this from code instead of from a docs page

The reason I can put exact dates and per-cloud qualifiers in a table is that lifecycle status is a field I track, not prose I skimmed. It's a free JSON endpoint, no key, no signup, CORS open:

# every Anthropic model with a retirement date still ahead of us
curl -s https://aimodelwatch.dev/api/deprecations.json \
  | jq '.models[] | select(.provider=="Anthropic" and .retires_on > "2026-07-29")'

{
  "id": "claude-opus-4-1",
  "name": "Claude Opus 4.1",
  "provider": "Anthropic",
  "status": "deprecated",
  "deprecated_on": "2026-06-05",
  "retires_on": "2026-08-05",
  "replacement": "claude-opus-4-8",
  "api_string": "claude-opus-4-1-20250805",
  "source_url": "https://platform.claude.com/docs/en/about-claude/model-deprecations"
}

Every row carries the source_url it was read from, and fields the provider doesn't publish stay null rather than getting filled in with a guess. Seventy-seven models across all providers currently carry declared lifecycle data there.

The obvious use is a CI check: fail the build — or just warn — when a model ID in your config has a retires_on inside your next release window. Vendors do email you about deprecations, but they email the account owner, not the repo, and the email doesn't know which of your services still pins the old string.

Full deprecation table across providers: https://aimodelwatch.dev/deprecations
JSON feed: https://aimodelwatch.dev/api/deprecations.json

All prices and dates above were read on 2026-07-29 from Anthropic's own docs (platform.claude.com/docs/en/about-claude/pricing and /model-deprecations) and re-derived to the cent. Retirement dates are Anthropic's stated "tentative retirement date".

OpenAI Realtime API con WebRTC: cómo crear agentes de voz sin filtrar claves ni disparar costes

Khavel — Sat, 25 Jul 2026 10:09:43 +0000

Un agente de voz en tiempo real no es solo streaming de audio. Necesita una frontera clara entre navegador, backend, Realtime API, tools, permisos, VAD, logs y costes para no convertirse en una demo peligrosa.

OpenAI Realtime API con WebRTC permite crear agentes de voz de baja latencia donde el navegador envía y recibe audio por una conexión WebRTC, mientras un backend confiable inicializa la sesión, protege la API key real y define tools, permisos, logs y presupuesto.

TL;DR

La keyword principal es OpenAI Realtime API WebRTC. La intención de búsqueda en español es práctica: montar una arquitectura de voz en navegador sin exponer claves, entender cuándo usar tokens efímeros o interfaz unificada, y saber qué controles hacen falta antes de producción.

Mi postura: no empieces por una demo con micro abierto y tools conectadas. Empieza por el límite de confianza. Si no sabes quién crea la sesión, quién ejecuta tools, qué se registra, cuánto cuesta cada minuto y qué acciones requieren aprobación, todavía no tienes un agente de voz: tienes un socket caro con permisos ambiguos.

Qué es Realtime API con WebRTC

Realtime API mantiene una sesión abierta para enviar audio, recibir eventos, actualizar estado y dejar que el modelo responda mientras la conversación sigue viva. WebRTC es la vía recomendada para experiencias de voz en navegador porque mueve audio en tiempo real con menos fricción que intentar hacer streaming manual desde JavaScript.

La diferencia frente a un chatbot normal es importante. En chat puedes tolerar segundos de latencia, reintentos visibles y respuestas largas. En voz, 700 ms extra se sienten como interrupción, una tool lenta rompe el turno y una respuesta prolija parece mala UX aunque sea correcta.

Para developers, la arquitectura mental correcta es esta: el navegador captura audio y reproduce audio; el backend crea o negocia la sesión; Realtime API gestiona el modelo y eventos; tus sistemas internos ejecutan acciones con permisos mínimos; observabilidad y costes se miden por sesión, turno y tool call.

La frontera clave no es el audio: es separar cliente, backend confiable, sesión realtime, tools internas y controles de seguridad. El navegador nunca debería llevar la API key real.

Arquitectura recomendada para navegador

En una app web, el navegador no debe contener una API key estándar. Debe pedir a tu backend una sesión o un token de vida corta. Ese backend autentica al usuario, aplica rate limit, define configuración inicial, adjunta un identificador de seguridad si procede y llama a la API de OpenAI con la clave real.

OpenAI documenta dos formas de iniciar WebRTC desde cliente: una interfaz unificada donde el backend crea la llamada con /v1/realtime/calls, y el patrón de token efímero donde el backend emite una credencial temporal y el navegador completa la negociación SDP con Realtime API. La elección depende de cuánto quieras poner al backend en el camino crítico de arranque.

Yo usaría interfaz unificada si quieres control fuerte de sesión, auditoría centralizada y menos lógica sensible en cliente. Usaría token efímero cuando necesitas que el navegador conecte directamente, siempre con TTL corto, rate limit por usuario y configuración cerrada desde servidor.

Flujo paso a paso

1. El usuario abre la UI y concede permisos de micrófono. La app todavía no llama a tools ni abre una sesión privilegiada.
2. El cliente pide a tu backend crear una sesión realtime. El backend autentica al usuario, decide modelo, voz, VAD, herramientas permitidas y presupuesto máximo.
3. El navegador crea un RTCPeerConnection, añade el track de audio local y prepara un canal de datos para eventos.
4. La SDP offer viaja al backend o a Realtime API según el patrón elegido. La respuesta SDP queda como remote description y la sesión empieza.
5. El audio de entrada fluye por WebRTC. El modelo devuelve audio, transcripción, eventos de respuesta y posibles tool calls.
6. Las acciones sensibles pasan por tu servidor o por un MCP remoto con superficie limitada y aprobación. El resultado vuelve a la sesión como output de tool.
7. Al cerrar, guardas métricas: duración, tokens de audio/texto, tool calls, errores, VAD, interrupciones, coste estimado y si hubo aprobación humana.

Código mínimo: backend Node para iniciar sesión

server.js

import express from "express";

const app = express();
app.use(express.text({ type: ["application/sdp", "text/plain"] }));

app.post("/api/realtime/call", async (req, res) => {
  const user = await requireUser(req);
  await enforceRealtimeQuota(user.id);

  const form = new FormData();
  form.set("sdp", req.body);
  form.set("session", JSON.stringify({
    type: "realtime",
    model: "gpt-realtime-2.1",
    audio: {
      input: {
        turn_detection: {
          type: "semantic_vad",
          eagerness: "medium",
          interrupt_response: true
        }
      },
      output: { voice: "ash" }
    },
    instructions: [
      "Eres un asistente tecnico de soporte.",
      "Responde breve en voz.",
      "Confirma antes de ejecutar acciones con impacto externo.",
      "No repitas secretos, tokens ni datos personales."
    ].join("\n"),
    tools: [
      {
        type: "function",
        name: "lookup_ticket",
        description: "Busca un ticket permitido para el usuario autenticado",
        parameters: {
          type: "object",
          properties: { ticket_id: { type: "string" } },
          required: ["ticket_id"],
          additionalProperties: false
        }
      }
    ]
  }));

  const r = await fetch("https://api.openai.com/v1/realtime/calls", {
    method: "POST",
    headers: {
      Authorization: `Bearer ${process.env.OPENAI_API_KEY}`,
      "OpenAI-Safety-Identifier": hashUser(user.id)
    },
    body: form
  });

  if (!r.ok) {
    res.status(r.status).send(await r.text());
    return;
  }

  res.type("application/sdp").send(await r.text());
});

app.listen(3000);

¿Te está sirviendo? Hay una dosis cada semana

Te resumo herramientas de IA para devs, agentes, MCP, seguridad y workflows en un email de 5 minutos. En español y sin ruido.

Suscribirme gratis

Lo que conviene comprobar

Este ejemplo deja la API key en servidor, aplica autenticación antes de crear sesión y evita que el cliente decida tools o presupuesto. En producción añadiría CORS estricto, CSRF si aplica, logs por sesión, límites por minuto, cierre explícito de sesiones abandonadas y una lista de tools por rol.

Código mínimo: cliente WebRTC

client.js

const pc = new RTCPeerConnection();
const audio = document.querySelector("audio#assistant");
audio.autoplay = true;

pc.ontrack = (event) => {
  audio.srcObject = event.streams[0];
};

const stream = await navigator.mediaDevices.getUserMedia({ audio: true });
for (const track of stream.getTracks()) {
  pc.addTrack(track, stream);
}

const dc = pc.createDataChannel("oai-events");
dc.onmessage = (event) => {
  const msg = JSON.parse(event.data);
  if (msg.type === "response.done") recordTurn(msg);
  if (msg.type.includes("function_call")) queueToolReview(msg);
};

const offer = await pc.createOffer();
await pc.setLocalDescription(offer);

const sdp = await fetch("/api/realtime/call", {
  method: "POST",
  headers: { "Content-Type": "application/sdp" },
  body: offer.sdp
}).then((r) => r.text());

await pc.setRemoteDescription({ type: "answer", sdp });

El cliente debe ser aburrido: capturar audio, negociar WebRTC, reproducir audio y mostrar estado. No debería decidir scopes, modelo caro, credenciales ni tools disponibles. Si necesitas cambiar permisos durante la sesión, hazlo desde servidor con una política verificable.

Tools, MCP y acciones: dónde poner el límite

Realtime puede trabajar con function tools, MCP remoto y conectores. La tentación es conectar CRM, calendario, base de datos y ticketing desde el primer día. Mala idea. Voz reduce la fricción de pedir acciones, así que también reduce el tiempo que tiene el usuario para revisar qué está autorizando.

Para function tools, prefiero que tu aplicación ejecute la lógica y devuelva function\_call\_output. Eso te permite aplicar permisos reales, validar argumentos, registrar payloads y pedir aprobación humana antes de mutaciones. Para MCP remoto, limita allowed\_tools y asume que cualquier dato enviado en una tool call puede ser visto por ese servidor.

La regla operativa: lectura con datos no sensibles puede ser automática; escritura, compra, envío, borrado, cambio de permisos o acceso a datos personales debe tener confirmación visible. En voz, la confirmación debe ser corta pero concreta: acción, destino, identificador y consecuencia.

VAD, interrupciones y experiencia de conversación

Voice Activity Detection decide cuándo empieza y termina el turno del usuario. Si cortas pronto, el agente responde antes de entender. Si esperas demasiado, parece lento. OpenAI documenta server\_vad y semantic\_vad; este último intenta trocear cuando el modelo cree que el usuario terminó la idea, no solo por silencio.

Para soporte técnico, empezaría con semantic\_vad y interrupt\_response: true. Los usuarios interrumpen, corrigen IDs y cambian de objetivo. Si el agente no sabe parar, la experiencia parece una locución, no una conversación.

Mide interrupciones como métrica de producto. Muchas interrupciones pueden indicar que el agente habla demasiado, tarda en reconocer el objetivo o usa preambles molestos. No arregles eso solo subiendo modelo: muchas veces se corrige con prompts más claros y respuestas más cortas.

Prompting para voz: menos literatura, más política

Un prompt de voz necesita estructura. Define rol, idioma, tono, longitud, cuándo usar tools, cuándo pedir datos, cuándo confirmar y cuándo escalar. Sé útil y conciso no basta porque no dice qué hacer ante un número de pedido ambiguo, una tool lenta o una petición de borrar datos.

Con modelos realtime con razonamiento, empieza con reasoning.effort bajo y sube solo si hay tareas que realmente lo necesitan. La voz castiga la latencia. Prefiero un agente que resuelva el 80% de casos simples rápido y escale el resto, antes que uno que piense demasiado en cada saludo.

Los preambles son útiles si son breves: Lo reviso ahora antes de una tool lenta puede mejorar percepción. Pero si el agente rellena cada turno con frases de transición, estás pagando tokens para molestar. Define cuándo hablar mientras trabaja y cuándo quedarse callado.

Costes: lo que debes registrar desde el día uno

El coste de voz no se parece al coste de un prompt textual aislado. Hay audio de entrada, audio de salida, texto, posibles tokens cacheados, tools, reintentos y sesiones largas. Además, una mala UX puede duplicar coste si el usuario repite porque el agente lo interrumpió o contestó tarde.

Registra por sesión: modelo, duración, tokens por modalidad, respuestas canceladas, interrupciones, errores de tool, número de turns, coste estimado y usuario o tenant. No guardes audio completo por defecto salvo que tengas base legal y política clara; muchas veces bastan transcripciones redaccionadas y métricas agregadas.

Realtime soporta prompt caching de forma automática cuando hay coincidencia de tokens entre respuestas, pero no lo trates como garantía de presupuesto. Diseña prompts estables, no metas contexto variable enorme al inicio y resume estado largo si la sesión se alarga.

Seguridad y privacidad específicas de voz

La voz introduce riesgos distintos. Puede contener datos personales que el usuario dice sin pensar, ruido de fondo, nombres de terceros o instrucciones inyectadas por otra persona cerca del micrófono. El agente no debería aceptar una orden sensible solo porque la oyó.

Lo que conviene comprobar

Añade controles simples: autenticación antes de sesión, scopes por usuario, denylist de datos que no se leen en voz, confirmación para acciones externas, timeouts, cierre al cambiar de pestaña si procede, y logs que no creen otra fuga. Para equipos regulados, separa entorno de demo y producción desde el primer prototipo.

La prompt injection indirecta también aplica. Si el agente lee una web, ticket o documento y luego actúa, ese contenido debe tratarse como dato no confiable. Una frase dentro de un ticket no puede autorizar que el agente mande un email, borre un registro o exponga un secreto.

Cuándo usar Agents SDK y cuándo ir directo a Realtime

Si solo necesitas una UI web de voz con una o dos tools, ir directo a Realtime API con WebRTC puede ser más claro. Controlas la negociación, ves los eventos y entiendes bien la frontera cliente-servidor.

Si necesitas handoffs, guardrails, especialistas, sesiones server-side, aprobación o integraciones complejas, mira la capa realtime del Agents SDK. La documentación describe RealtimeAgent, RealtimeRunner, RealtimeSession, handoffs y guardrails específicos para respuestas y function-tool calls.

No lo conviertas en religión de SDK. La pregunta buena es quién orquesta. Si el navegador solo captura audio, tu backend gestiona permisos y el SDK te ayuda a coordinar especialistas, tiene sentido. Si solo añade abstracción antes de entender el flujo, espera.

Checklist de producción

API key estándar solo en servidor, nunca en navegador.
Sesiones creadas tras autenticar usuario y aplicar cuota.
Modelo, voz, VAD, tools y presupuesto definidos en backend.
Tools separadas por rol, tenant y tipo de acción.
Confirmación explícita para operaciones irreversibles o externas.
Logs con IDs, métricas y errores; audio bruto solo si hay necesidad real y política.
Evals de conversación con interrupciones, ruido, IDs, acentos y peticiones ambiguas.
Monitor de coste por sesión y alertas por duración o reintentos.
Fallback textual o humano si falla WebRTC, tool crítica o guardrail.

Conclusión

OpenAI Realtime API con WebRTC ya permite construir agentes de voz muy convincentes, pero la parte difícil no es abrir el micrófono. La parte difícil es hacer que esa conversación tenga permisos, límites, coste predecible y una experiencia que no se rompa cuando el usuario interrumpe.

Mi recomendación: construye primero el esqueleto de confianza. Backend que crea sesiones, cliente tonto, tools estrechas, VAD medido, confirmaciones visibles y coste por sesión. Después mejora voces, handoffs y prompts. Si lo haces al revés, tendrás una demo brillante y una deuda de seguridad desde el primer commit.

Preguntas frecuentes

¿Qué es OpenAI Realtime API con WebRTC?

Es una forma de conectar una app de navegador a modelos realtime mediante WebRTC para enviar audio, recibir audio y manejar eventos de conversación o tools con baja latencia.

¿Puedo usar mi API key de OpenAI en el navegador?

No deberías. La clave estándar debe quedarse en servidor. El navegador debe usar una sesión creada por backend o una credencial efímera de vida corta.

¿Qué diferencia hay entre WebRTC y WebSocket en Realtime API?

WebRTC encaja mejor para audio directo desde navegador. WebSocket suele tener más sentido en pipelines server-side, telephony o cuando tu servidor controla el flujo de audio.

¿Realtime API puede llamar tools o MCP?

Sí. Puede usar function tools, MCP remoto y conectores, pero las acciones sensibles necesitan permisos estrechos, validación y aprobación cuando haya impacto externo.

¿Cómo controlo el coste de un agente de voz?

Mide duración, tokens de audio y texto, turns, reintentos, tools, respuestas canceladas y coste estimado por sesión. Añade cuotas por usuario o tenant desde el backend.

¿Cuándo usar Agents SDK para agentes de voz?

Úsalo cuando necesites handoffs, guardrails, orquestación server-side o especialistas. Para una UI web simple, Realtime API directo puede ser más transparente al principio.

Cómo lanzar un agente de voz con OpenAI Realtime API y WebRTC sin abrir demasiado el sistema

Definir caso de uso. Elige una tarea de voz acotada, con datos permitidos y acciones claras.
Diseñar frontera de confianza. Decide qué vive en navegador, backend, Realtime API y sistemas internos.
Crear endpoint de sesión. Autentica usuario, aplica cuota y crea la sesión con API key solo en servidor.
Conectar WebRTC. Captura micrófono, negocia SDP, reproduce audio y escucha eventos por data channel.
Añadir tools mínimas. Empieza por lectura segura y valida argumentos antes de ejecutar negocio real.
Configurar VAD. Prueba server\_vad y semantic\_vad, mide interrupciones y latencia percibida.
Instrumentar coste. Registra duración, tokens, tools, errores, reintentos y coste estimado por sesión.
Meter guardrails. Bloquea datos sensibles, acciones no autorizadas y contenido externo que intente cambiar instrucciones.
Probar con conversaciones reales. Incluye ruido, acentos, IDs dictados, interrupciones y peticiones ambiguas antes de producción.

Fuentes y referencias

También te puede interesar

Recibe una lectura semanal de herramientas IA para devs

Cada semana te resumo herramientas de IA para devs, agentes, MCP, seguridad y workflows en un email de 5 minutos. En español y sin ruido.

Suscribirme gratis

Búsqueda híbrida RAG: BM25, vectores y reranking sin complicar tu stack

Khavel — Thu, 23 Jul 2026 09:42:42 +0000

La búsqueda vectorial pura falla justo en consultas con IDs, nombres propios y términos raros. La búsqueda híbrida RAG combina BM25, embeddings y reranking para recuperar mejor evidencia antes de llamar al modelo.

Búsqueda híbrida RAG significa ejecutar recuperación léxica, normalmente BM25 o full-text search, junto a recuperación semántica por embeddings, fusionar rankings y pasar al LLM un contexto ordenado con evidencias citables.

Arquitectura base

TL;DR

La keyword principal es búsqueda híbrida RAG. La intención de búsqueda en español es práctica: entender cuándo la búsqueda vectorial se queda corta, cómo combinar BM25 con vectores y cómo evaluar si el cambio mejora respuestas reales.

Mi postura: si tu RAG responde sobre documentación técnica, soporte, contratos, catálogos, logs o conocimiento interno con nombres propios, no deberías empezar por vector-only. Empieza híbrido o al menos deja el camino preparado para activarlo sin reindexar todo.

Briefing

Qué problema resuelve la búsqueda híbrida RAG

La búsqueda vectorial es buena capturando significado. Si alguien pregunta cómo revocar una clave, puede encontrar documentos que hablan de rotación, credenciales o secretos aunque no usen las mismas palabras. Ese es su valor.

Pero los embeddings tropiezan con lo exacto: ERR\_CONN\_RESET, invoice\_2026\_041, TenantIsolationPolicy, SKU-A17, una clase interna o un endpoint raro. Para un humano esos tokens son la pista principal. Para un vector pueden quedar diluidos como ruido.

BM25 y full-text search hacen lo contrario: premian coincidencias léxicas, frecuencia de términos y rareza de palabras. La búsqueda híbrida combina ambas señales para que el sistema no tenga que elegir entre significado y precisión.

Una arquitectura híbrida separa recall léxico, recall semántico, fusión de rankings, reranking y evaluación. No mete más chunks por intuición: decide qué evidencia merece llegar al prompt.

Lectura práctica

La arquitectura mínima: dos recuperadores y una fusión

El patrón base tiene cuatro pasos. Primero normalizas la consulta y aplicas permisos o filtros duros. Segundo ejecutas BM25 o full-text search contra el texto indexado. Tercero ejecutas búsqueda vectorial contra embeddings de chunks. Cuarto fusionas ambos rankings con una regla estable, normalmente Reciprocal Rank Fusion cuando no quieres calibrar scores heterogéneos.

La clave es no mezclar puntuaciones crudas sin pensar. Un score BM25 no significa lo mismo que una similitud coseno o producto interno. RRF evita parte del problema porque trabaja con posiciones de ranking, no con escalas absolutas. Si un documento aparece arriba en dos listas, sube. Si solo aparece en una, todavía puede entrar, pero con menos fuerza.

Después puedes añadir reranking. Un cross-encoder o late-interaction reranker mira pares consulta-documento con más detalle y reordena un conjunto pequeño de candidatos. Es más caro, así que suele aplicarse después de recuperar 40-100 candidatos, no sobre todo el corpus.

Checklist

Cuándo usar híbrida y cuándo no

Usa búsqueda híbrida si tus usuarios preguntan con nombres exactos, errores, siglas, IDs, versiones, rutas, clases, productos, tickets o fragmentos copiados de una interfaz. Es el caso normal en RAG para developers y soporte técnico.

También encaja cuando el corpus mezcla lenguaje natural con tablas, documentos largos, documentación API, changelogs, incidencias y preguntas con permisos. En esos entornos, el vector-only suele parecer convincente en demo y fallar en producción cuando aparece terminología específica.

No la añadas por moda si tu corpus es pequeño, homogéneo y semánticamente simple. Si tienes 200 documentos y las consultas son abiertas, una búsqueda vectorial bien evaluada puede bastar. La regla pragmática es medir: si pierdes consultas exactas o tienes respuestas sin citas fuertes, híbrida deja de ser complejidad extra y pasa a ser higiene.

Código: RRF simple para unir BM25 y vectores

rrf.py

from collections import defaultdict

def reciprocal_rank_fusion(result_lists, k=60):
    scores = defaultdict(float)
    docs = {}

    for results in result_lists:
        for rank, item in enumerate(results, start=1):
            doc_id = item["id"]
            docs[doc_id] = item
            scores[doc_id] += 1.0 / (k + rank)

    ranked_ids = sorted(scores, key=scores.get, reverse=True)
    return [{**docs[doc_id], "rrf_score": scores[doc_id]} for doc_id in ranked_ids]

query = "ERR_CONN_RESET al refrescar token OAuth"
bm25_hits = bm25_search(query, limit=50)
vector_hits = vector_search(embed(query), limit=50)

candidates = reciprocal_rank_fusion([bm25_hits, vector_hits])
context = rerank(query, candidates[:80])[:12]
answer = generate_with_citations(query, context)

Puntos a revisar

Lo que conviene comprobar

Este ejemplo no depende de un proveedor concreto. La idea es deliberadamente simple: recupera dos listas, fusiona por posición, rerankea pocos candidatos y genera solo con contexto citado. Después puedes sustituir bm25\_search, vector\_search y rerank por PostgreSQL, Azure AI Search, Qdrant, Weaviate, Pinecone, Elasticsearch o tu stack actual.

¿Te está sirviendo? Hay una dosis cada semana

Te resumo herramientas de IA para devs, agentes, MCP, seguridad y workflows en un email de 5 minutos. En español y sin ruido.

Suscribirme gratis

Implementación con PostgreSQL y pgvector

PostgreSQL es una opción muy razonable cuando tu corpus vive cerca de datos transaccionales, permisos por tenant o joins que no quieres duplicar en otro sistema. tsvector y tsquery cubren full-text search; pgvector añade almacenamiento y búsqueda de embeddings. Para muchos productos internos, esa combinación reduce sincronización y fugas entre sistemas.

El diseño típico guarda content, metadata, tenant\_id, tsv y embedding en la misma tabla. La query aplica primero filtros obligatorios, ejecuta full-text y vector search por separado, calcula posiciones y fusiona con RRF en SQL o en aplicación. Lo importante es que los permisos no sean un filtro posterior decorativo: deben aplicarse antes de recuperar candidatos.

Postgres no siempre será el buscador más rápido para corpus enormes o requisitos avanzados de relevancia. Pero como baseline operable es fuerte: transacciones, backups, permisos, SQL, joins y menos piezas móviles. Si el equipo no puede operar dos índices con disciplina, una arquitectura más simple puede ganar aunque no sea la más glamourosa.

Lectura práctica

Implementación con motores dedicados

Azure AI Search documenta híbrida como ejecución paralela de full-text y vector queries, con RRF para devolver un único ranking. Es una buena lectura porque separa claramente BM25, HNSW/eKNN y fusión.

Weaviate expone búsqueda híbrida con BM25F y vector search, configurable por peso y método de fusión. Qdrant permite consultas híbridas con vectores densos, sparse y reranking; su documentación reciente empuja un patrón de ingestión con embeddings densos, sparse y late-interaction. Pinecone soporta patrones sparse-dense y enfoques con índice híbrido o combinación de señales según el tipo de índice.

La decisión no debería ser qué vector database está de moda. Pregunta: dónde viven tus permisos, cómo vas a versionar embeddings, cómo filtrarás por tenant, cómo depurarás un resultado malo, cuánto cuesta rerankear y quién operará el índice cuando falle.

Briefing

Tuning: alpha, top_k y reranking

Si tu proveedor ofrece un peso tipo alpha, no lo trates como una constante universal. Queries con IDs suelen necesitar más señal léxica. Queries conceptuales suelen necesitar más señal semántica. Puedes empezar con un valor medio, pero guarda métricas por tipo de consulta.

top\_k antes de fusionar y después de rerankear importa más de lo que parece. Si recuperas pocos candidatos, el documento correcto ni llega al reranker. Si recuperas demasiados, suben coste, latencia y ruido. Una configuración común es recuperar 30-100 por canal, fusionar, rerankear 40-100 y pasar 5-15 chunks finales al LLM.

El reranking solo compensa si el candidato correcto está en el pool. Si context recall es bajo, no arregles con un reranker caro. Arregla chunking, filtros, normalización de query, sinónimos, indexación de campos o combinación sparse/dense.

Evaluación: no publiques híbrida sin comparar contra baseline

Antes de activar búsqueda híbrida, congela un dataset pequeño: preguntas reales, documentos esperados cuando existan, categoría de query y riesgo. Ejecuta vector-only, BM25-only e híbrida con el mismo corpus. Mide recall@k, MRR, nDCG si tienes qrels, groundedness de respuesta y coste por consulta.

La mejora que busco no es solo más score agregado. Quiero ver casos concretos: errores exactos que BM25 rescata, preguntas conceptuales que el vector mantiene, documentos irrelevantes que el reranker expulsa y respuestas que citan mejor evidencia.

No cambies embeddings, chunking, prompt, reranker y fusión en el mismo experimento. Si lo haces, no sabrás qué ayudó. La búsqueda híbrida es un cambio suficientemente grande como para merecer baseline propio.

Lectura práctica

Seguridad, permisos y privacidad

El fallo peligroso en RAG no es solo responder mal. Es recuperar un documento correcto para el usuario equivocado. En híbrida hay más caminos para que un documento entre al candidate pool, así que los filtros de tenant, permisos, clasificación y fecha deben aplicarse antes de ranking o en cada subconsulta.

Evita indexar secretos, claves, dumps, prompts internos sensibles o datos personales que no necesites para la tarea. Si el corpus incluye contenido no confiable, como tickets, emails, páginas externas o docs subidas por usuarios, trata esos chunks como datos, no como instrucciones. Esto conecta directamente con defensas contra prompt injection indirecta.

Para observabilidad, registra IDs de documentos, scores, rankings, filtros aplicados y versión de índice. No necesitas guardar todo el texto recuperado en logs permanentes. Muchas veces basta con referencias y muestras controladas para depurar sin crear otra base de datos sensible.

Errores comunes que veo en RAG híbrido

Fusionar scores BM25 y vectoriales como si estuvieran en la misma escala.
Aplicar filtros de permisos después de recuperar, cuando el ranking ya fue contaminado.
Usar top\_k pequeño y culpar al reranker de no encontrar documentos que nunca recibió.
Indexar chunks sin títulos, rutas, fechas, producto, versión o metadatos útiles para desempatar.
No separar consultas exactas, conceptuales, negativas y multi-hop en la evaluación.
Medir solo la respuesta final y no guardar los candidatos que llegaron al prompt.
Añadir híbrida para tapar un problema de chunking obvio.

Plan de adopción en una semana

Día 1: etiqueta 40-60 preguntas reales y separa consultas con IDs, errores, nombres propios, conceptos generales, permisos y preguntas sin respuesta.
Día 2: ejecuta tu pipeline vector-only y guarda candidatos, respuesta, citas, latencia y coste.
Día 3: añade recuperación BM25 o full-text con los mismos filtros de permisos.
Día 4: fusiona con RRF y compara candidate pools antes de tocar prompts.
Día 5: añade reranking solo sobre candidatos fusionados y mide si mejora precisión sin romper latencia.
Día 6: ajusta top_k por tipo de consulta y crea un gate mínimo de regression retrieval.
Día 7: despliega para un porcentaje pequeño de tráfico y revisa ejemplos, no solo promedios.

Conclusión

La búsqueda híbrida RAG no es una capa elegante para presumir de arquitectura. Es una corrección práctica a un defecto real de vector-only: confundir parecido semántico con evidencia suficiente.

Mi recomendación es empezar por el pipeline más aburrido que puedas operar: filtros duros, BM25, vectores, RRF, reranking opcional, citas y evaluación. Si eso mejora recall y groundedness en preguntas reales, ya tendrás permiso técnico para invertir en motores más sofisticados. Si no lo mide, es solo otro índice caro.

Preguntas frecuentes

¿Qué es búsqueda híbrida RAG?

Es un enfoque de recuperación para RAG que combina búsqueda léxica como BM25 o full-text search con búsqueda vectorial por embeddings, fusiona resultados y entrega al modelo un contexto más fiable.

¿Por qué BM25 sigue siendo útil con embeddings?

Porque BM25 captura coincidencias exactas, términos raros, IDs, errores, nombres propios y acrónimos que los embeddings pueden suavizar demasiado.

¿Qué es RRF en búsqueda híbrida?

Reciprocal Rank Fusion es una técnica para fusionar listas ordenadas usando la posición de cada documento en cada ranking, sin depender de que los scores tengan la misma escala.

¿Necesito reranking en un RAG híbrido?

No siempre. Añádelo cuando tengas suficientes candidatos, consultas ambiguas o requisitos altos de precisión. Primero mide si híbrida sin reranker ya resuelve el fallo.

¿PostgreSQL con pgvector basta para búsqueda híbrida?

Para muchos productos internos sí, especialmente si necesitas joins, permisos y transacciones cerca del corpus. Para escalas grandes o relevancia avanzada, puede convenir un motor dedicado.

¿Cómo evalúo una búsqueda híbrida RAG?

Compara BM25-only, vector-only e híbrida con preguntas reales. Mide recall@k, MRR o nDCG, groundedness, calidad de citas, latencia y coste por consulta.

Cómo implementar búsqueda híbrida RAG sin rehacer todo el sistema

Crear baseline. Guarda preguntas reales, documentos esperados, candidatos vector-only, respuesta, citas, latencia y coste.
Añadir índice léxico. Indexa texto y metadatos con BM25, full-text search o sparse vectors sin saltarte permisos.
Ejecutar dos recuperadores. Lanza búsqueda léxica y vectorial con la misma query normalizada y filtros obligatorios.
Fusionar rankings. Usa RRF o una combinación calibrada; evita sumar scores crudos sin normalización.
Rerankear candidatos. Aplica reranking solo sobre el pool fusionado, no sobre todo el corpus.
Construir contexto final. Deduplica chunks, conserva citas, limita ruido y ordena por utilidad para la respuesta.
Medir regresiones. Compara contra baseline con recall@k, MRR, groundedness, coste y ejemplos fallidos.
Desplegar gradualmente. Activa por cohortes o tipos de consulta y revisa trazas antes de subir tráfico.

Cierre editorial

Criterio técnico

Un buen chunk en tiempo real no es el más corto ni el más semántico: es el que conserva evidencia, tiempo y estado suficiente para responder sin inventar continuidad.

Fuentes y referencias

También te puede interesar

Real-time chunking para RAG y agentes Evaluación RAG en producción OpenTelemetry GenAI para agentes LiteLLM Proxy: gateway IA, costes y modelos Prompt injection en agentes de IA

Recibe una lectura semanal de herramientas IA para devs

Cada semana te resumo herramientas de IA para devs, agentes, MCP, seguridad y workflows en un email de 5 minutos. En español y sin ruido.

Suscribirme gratis