Guillaume Duvernay

He dejado de usar MCP en la mayor parte de mi trabajo

14 min de lectura

AI efficiencyagentsMCP

Desde hace unos meses he evitado usar MCP siempre que he tenido la oportunidad, optando por otras alternativas. No tengo un problema con el protocolo. Mi problema es lo que me cuesta en el trabajo diario: un gran volumen de operaciones repetitivas en un CRM, un CMS y varias herramientas de análisis.

Esta es la versión escrita de un vídeo que publiqué, con los mismos ejemplos.

Video: ¿MCPs a escala? ¡Deja de desperdiciar todos tus tokens!Play

La configuración nunca era coherente entre entornos

Alterno entre Claude Code, Codex y Antigravity según lo que esté haciendo. Cada uno conecta los servidores MCP a su manera. A veces es un archivo de configuración JSON. Otras veces hay que buscar un plugin oficial y, cuando no lo hay, añades un servidor personalizado a mano.

Así que, cada vez que abría una sesión en un entorno diferente, no estaba seguro de tener todo conectado. Algunos servidores se habían caído y necesitaban re-autenticarse. Empezaba a trabajar y me daba cuenta a mitad del proceso.

En un plan de equipo es peor. En Claude Code, solo el administrador puede añadir conectores personalizados antes de que estén disponibles para todos, por lo que un compañero que necesite uno tiene que esperar.

Esa es una fricción que puedo tolerar. Lo que realmente me sale caro está más adelante.

Las descripciones de las herramientas cuestan antes de preguntar nada

Cuando un servidor MCP se conecta, expone sus herramientas al cliente. Para un CRM, serían cosas como listar contactos, obtener un contacto, crear un contacto o editar un contacto. Cada herramienta lleva una descripción que indica cuándo usarla, además de la estructura del payload que espera.

Todo eso reside en la sesión. Conecta diez servidores con veinte herramientas cada uno y estarás cargando doscientas descripciones de herramientas y sus esquemas en cada conversación, incluso en aquellas donde solo usas dos.

Diez servidores con veinte herramientas es un recuento ilustrativo, no una medida de una configuración particular. Lo que muestra es la estructura: un presupuesto fijo, la mayor parte gastado antes de que empiece la conversación.
Cada una de estas se carga independientemente de que la sesión la utilice o no. Las dos marcadas son las que llama una sesión típica.

Los clientes están mejorando en esto. Claude Code puede revelar herramientas progresivamente en lugar de cargar cada descripción al principio, y hay otros enfoques donde el agente busca la herramienta que necesita. Por eso espero que esto desaparezca por sí solo, y no es mi queja principal.

El agente vuelve a escribir lo que ya tienes

Imagina que le pides a tu agente que suba doscientos contactos de un CSV a tu CRM. El archivo está ahí mismo, en tu portátil, correctamente formateado.

Aun así, el agente tiene que escribir cada llamada a la herramienta por sí mismo, carácter por carácter: el nombre de la herramienta, luego el payload con el nombre del contacto, el email y lo demás. Doscientas veces. Normalmente sin paralelismo.

Los costes aquí son representaciones, no medidas exactas. La fila central escala con tu archivo y las otras no.

Lo que yo querría es que el agente mirara el CSV, determinara cómo se mapean los encabezados con los campos del CRM y luego moviera los datos sin leerlos internamente. Eso es una transformación, y la mayoría de los clientes no pueden hacerlo, así que optan por reescribir.

Además, es poco fiable. Al pasar de unos pocos cientos de registros, el agente se vuelve perezoso y hace la mitad, o comete un pequeño error a mitad del proceso que descubres más tarde.

Siete minutos para cambiar un número

Esto fue lo que me hizo dejar de usar MCP para el trabajo repetitivo.

Gestiono un sitio web en Webflow. Los artículos viven en una colección de CMS, una fila por artículo, y el cuerpo es texto enriquecido, que Webflow almacena como HTML inline. Un artículo típico tiene dos mil palabras.

Le pedí al agente que buscara un artículo y cambiara un número: de 70 a 80.

Encontrarlo fue instantáneo. Luego, el MCP de Webflow tiene una sola herramienta para esto: editar un elemento del CMS, donde pasas los campos que quieres cambiar junto con sus nuevos valores. No hay una función de buscar y reemplazar dentro de un campo. Así que, para cambiar dos caracteres, el agente leyó todo el cuerpo, volvió a escribir las dos mil palabras con el nuevo número en medio y envió todo el bloque.

Los siete minutos y el 20% son lo que medí en mi propia sesión ese día, para un solo artículo.

Una solución sería tener herramientas más inteligentes: un endpoint de buscar y reemplazar en un campo del CMS. Eso ayudaría, pero no es algo que yo pueda implementar en el servidor de otra persona.

La otra solución no requiere permiso de nadie. Descargar el artículo una vez, escribirlo en un archivo local, editarlo allí con las herramientas en las que el entorno ya es eficiente y volver a subirlo.

La columna central es toda la diferencia. Editar un archivo es en lo que mejor se desempeñan estos entornos, y nada de esa edición pasa por el modelo.

No puedes limitar lo que el servidor devuelve

Una llamada MCP siempre devuelve algo, y cualquier cosa que devuelva pasa a formar parte de tu ventana de contexto.

Pide tus veinte artículos más recientes porque quieres sus fechas de publicación y, a menos que el servidor exponga un parámetro de campos, recibirás los veinte artículos completos. Cuerpos incluidos. Dos mil palabras cada uno, más todos los demás campos de la colección.

A menos que el servidor exponga un parámetro para ello, el payload llega completo y permanece en la ventana durante el resto de la sesión.

La API ya estaba ahí

Muchos servidores MCP son simplemente un envoltorio de una API que la empresa ya tenía.

Webflow, HubSpot y el resto tienen APIs REST documentadas que son públicas desde hace años. Sobre eso construyeron sus conectores Zapier, Make, n8n y Softr. Cuando estas empresas lanzaron un servidor MCP, la mayoría mapearon sus endpoints existentes al protocolo. Por lo tanto, es una segunda interfaz para las mismas operaciones.

Cuando una plataforma mantiene paridad entre su MCP y su API, la interfaz que elijas no cambia lo que puedes hacer con ella.

Y tu agente puede llamar a una API perfectamente bien. En una sesión de Codex o Claude Code, escribe la solicitud y la ejecuta desde tu máquina. La diferencia es que una llamada a la API puede estar dentro de un script.

Esa única diferencia es lo que soluciona la reescritura. El agente mira tu CSV, determina el mapeo una sola vez, escribe un script que recorre las filas haciendo una llamada por cada una y luego lo ejecuta. A partir de ese momento, el modelo queda fuera del bucle. El script se ejecuta hasta terminar.

Escribe una habilidad, no una lista de herramientas

Una API no se explica sola, y eso es lo que MCP realmente te ofrece. Si le dices a un agente que “use la API de HubSpot”, adivinará basándose en lo que recuerde. Normalmente se acerca, pero no es exacto.

Pero las APIs están documentadas, generalmente con una especificación OpenAPI que puedes señalar o dejar que el agente encuentre. Y para cualquier cosa que hagas más de una vez, escríbelo.

# Habilidad: Contactos de CSV a CRM

Nunca usamos el MCP del CRM. Todo pasa por la API REST.

## Endpoints que usamos
- `POST /crm/v3/objects/contacts` para un contacto
- `POST /crm/v3/objects/contacts/batch/create` para hasta 100 por llamada
- Referencia completa: https://developers.hubspot.com/docs/api/crm/contacts

## Auth
La clave reside en `.env` en la raíz del repo como `CRM_KEY`. Léela con
`source .env` dentro del script. Nunca la imprimas, nunca la pegues en un
mensaje.

## Mapeo
Inspecciona los encabezados del CSV primero, luego mapea a los campos del CRM. Pregunta antes
de suponer cualquier cosa que no sea una coincidencia obvia.

Una vez que ese archivo existe, el agente sabe cómo te comunicas con tu CRM, qué endpoints usas y cómo autenticarte. Deja de adivinar y obtienes la misma fiabilidad que te daba MCP.

Las CLI funcionan de la misma manera y a menudo son mejores. Los agentes son buenos con los comandos de terminal, la mayoría de las CLI se documentan a sí mismas mediante la salida de ayuda y muchas gestionan OAuth por ti: inicias sesión una vez en el navegador y el token se queda en tu máquina. Internamente, suele ser la misma API otra vez.

La clave se queda en el archivo

Aquí es donde las APIs dan genuinamente más trabajo que MCP. La mayoría de los servidores MCP ahora usan OAuth, así que haces clic en una página de inicio de sesión y listo. Con una API, normalmente manejas una clave.

Mantengo un archivo .env en la raíz de la carpeta en la que trabaja el agente, y le indico al agente que la clave está ahí y cómo usarla: mediante un comando que la lea en el script, nunca imprimiéndola en la conversación. El agente sabe que la clave existe y dónde está. Nunca ve el valor.

Encadénalo como ya hace la terminal

Una vez que las llamadas están en scripts, puedes ponerlas una tras otra, y el modelo solo ve el resultado final.

Toma algo que hago regularmente: buscar los tres artículos que hace más tiempo que no toco, extraer su rendimiento y decidir qué reescribir.

A través de MCP, cada respuesta intermedia habría aterrizado en la ventana de contexto. Aquí, los tres primeros pasos nunca llegan al modelo.

El agente recibe un informe corto y estructurado y hace aquello para lo que es realmente bueno: leerlo y decirme qué corregir. Nunca vio los veinte artículos por los que filtró.

Nadie necesita una clave de API en su portátil

La objeción obvia: somos diez personas en un equipo de marketing, ¿ahora todos guardan claves de API en su máquina?

No. Lo que construimos en Softr es un proxy. Cada persona tiene su propia clave. Llaman al proxy con ella, el proxy sabe quiénes son y redirige la solicitud al servicio correcto usando la clave que posee para dicho servicio.

La capa de permisos es la parte que no teníamos forma de construir antes. Una clave pura lleva los mismos permisos para cualquiera que la posea.

Los permisos son la parte que más me importa. Una clave de API tiene un alcance definido al crearla, y después de eso, cualquiera que la tenga puede hacer lo mismo. A través del proxy, ponemos las operaciones en lista blanca, por lo que nuestra clave de Webflow puede ser de solo lectura para la mayoría del equipo y permitir que un gestor de contenidos cree y edite. Nadie puede borrar un artículo por accidente, y nadie tuvo que instalar nada.

Cuándo MCP sigue siendo la herramienta adecuada

No estoy argumentando en contra de MCP. Para trabajos puntuales es lo más rápido que existe, y yo sigo usándolo.

Nada de esto dice que debas elegir uno para todo. El coste de MCP aparece con el volumen y la repetición, así que ahí es donde vale la pena sustituirlo.

El momento de considerar esto es cuando una parte real de tu trabajo pasa por un agente que habla con tus herramientas. Antes de eso, configurar las cosas es la mayor parte del trabajo, y MCP gana en eso.

Después de eso, merece dedicarle una tarde. Pregunta a tu agente qué endpoints exponen tus herramientas, haz que escriba la habilidad contigo y ejecuta una de tus tareas recurrentes de las dos formas. La diferencia es inmediata en cualquier tarea con volumen.

Fuentes