--- title: "He dejado de usar MCP en la mayor parte de mi trabajo" description: "MCP es ideal para tareas puntuales. Para procesos volumétricos es lento, consume demasiados tokens y obliga al agente a repetir datos que ya posee. Esto es lo que uso en su lugar: llamadas directas a la API en scripts, una habilidad que las documente y un proxy para que nadie guarde claves en su portátil." date: 2026-09-16 language: es canonical: https://gduv.club/es/articles/mcp-vs-direct-apis source: gduv.club --- 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. [¿MCPs a escala? ¡Deja de desperdiciar todos tus tokens!](https://www.youtube.com/watch?v=LGaqFVPUpfA) ## 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._ **Doscientas descripciones de herramientas como doscientas etiquetas pequeñas, de las cuales solo se usan dos.**
{Array.from({ length: 60 }, (_, index) => ( {index === 17 ? 'create_contact' : index === 41 ? 'update_item' : 'tool'} ))} y 140 más
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. | Step | What happens | Cost | | :--- | :--- | ---: | | Leer el CSV | El archivo ya está en el disco | barato | | Escribir una llamada por fila | El modelo escribe cada campo de cada payload | ×200 | | Esperar a que cada llamada responda | Una tras otra | ×200 | | **Datos que el modelo tuvo que escribir** | | **todos** | _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. | Step | What happens | Cost | | :--- | :--- | ---: | | Buscar el artículo | Búsqueda en la colección | unos pocos tokens | | Leer el elemento del CMS | Se devuelve todo el campo de texto enriquecido | ~2.000 palabras | | Reescribir todo el campo | Cada carácter, para cambiar solo dos de ellos | ~2.000 palabras | | Enviar la actualización | Editar elemento es la única herramienta disponible | 1 llamada | | **Lo que costó** | | **~7 min, 20% de mi límite** | _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. **Las mismas dos mil palabras pasan por el modelo tres veces para cambiar dos caracteres; mediante un script pasan una vez y el modelo solo escribe el reemplazo.**
A través de la llamada a herramienta MCP
Leer el elemento Entran 2.000 palabras
El modelo lo reescribe todo
2.000 palabras
Enviar el elemento de vuelta Salen 2.000 palabras
A través de un script en la API
Descargar a un archivo local Una vez, y el modelo nunca lo lee
Buscar y reemplazar
2 caracteres
Subir el archivo de vuelta Sin reescritura
## 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. **Lo que pedí** (Un campo, veinte filas) - Veinte fechas de publicación **Lo que entró en el contexto** (La respuesta completa) - Veinte cuerpos de artículos - Todos los demás campos de la colección - Todo ello en cada turno posterior _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. **Interfaces** - Un servidor MCP - Una CLI - Un script en tu portátil **La API REST de la plataforma** - Documentada desde hace años - Normalmente con especificación OpenAPI - Lo que ya usan los conectores low-code **Las mismas operaciones** - Listar contactos - Crear un contacto - Actualizar un elemento del CMS _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. ```markdown # 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. **Hay configuraciones mejores que la mía** Hay personas que pasan esto por 1Password para que la clave no toque ningún archivo, y su agente se autentica correctamente. Yo no lo he configurado, así que no puedo decirte cómo funciona en la práctica. Yo utilizo un `.env` en gitignore leído por un script. ## 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. 1. **Buscar candidatos**. Ordenar el CMS por última edición, tomar tres 2. **Obtener contenido**. Solo esos tres 3. **Obtener rendimiento**. Search Console para esas URLs 4. **Entregar un informe**. Lo único que lee el modelo _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. **El equipo** - Una clave personal cada uno - Sin claves de servicio locales - Sin configuración por entorno **El proxy** - Identifica al compañero por su clave - Guarda las claves de servicio en un solo lugar - Permite solo operaciones en lista blanca - Permisos diferentes por persona **Los servicios** - El CRM - Analítica - El CMS del sitio web _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. **Usa MCP** (Puntual) - Buscar una cosa y cambiarla - Explorar una herramienta que rara vez usas - Cualquier cosa donde el coste sea el tiempo de configuración **Usa un script en la API** (Repetitivo o gran volumen) - Cientos de registros a la vez - Una tarea que ejecutas cada semana - Cualquier cosa que implique reescribir un payload _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 - [Model Context Protocol: tools specification](https://modelcontextprotocol.io/specification/2025-06-18/server/tools) - [Webflow: CMS items API](https://developers.webflow.com/data/reference/cms/collection-items/staged-items/create-item) - [HubSpot: contacts API](https://developers.hubspot.com/docs/api/crm/contacts) - [Anthropic: Claude Code settings and MCP configuration](https://docs.claude.com/en/docs/claude-code/mcp)