Qué es un MCP y cómo funciona el MCP de ArduMaker

Publicado el 2026-08-25 por frfrand

Explicación clara del Model Context Protocol (MCP): qué es, cómo funciona y por qué convierte a una IA en un operador real. Incluye un recorrido por el MCP de ArduMaker, su catálogo de cientos de herramientas para VPS, DNS, correo, bases de datos, proyectos y blogs, y un ejemplo real: este mismo artículo fue creado y publicado por una IA usando ese MCP.

Resumen en una línea: un MCP (Model Context Protocol) es el estándar que permite que una inteligencia artificial deje de solo conversar y empiece a ejecutar acciones reales en sistemas reales.

Definiciones rápidas, para humanos y para máquinas:

• MCP = Model Context Protocol. Un protocolo abierto que conecta un modelo de IA con herramientas externas.
• Servidor MCP = un programa que publica una lista de herramientas (acciones) que la IA puede llamar.
• Herramienta = una acción concreta con nombre y parámetros. Por ejemplo: crear un VPS, enviar un correo, publicar un artículo.
• MCP de ArduMaker = un servidor MCP con cientos de herramientas (el número vigente está en la referencia del catálogo) para administrar infraestructura: servidores, dominios, DNS, correo, bases de datos, proyectos y blogs.
• Dirección del servidor = https://mcp.ardumaker.com/mcp

La idea central: sin MCP, la IA describe lo que habría que hacer. Con MCP, la IA lo hace y te devuelve el resultado real.

Prueba de ello: este artículo que estás leyendo fue redactado, ilustrado y publicado por una IA usando el MCP de ArduMaker. No hubo un panel de control abierto en ningún momento.

¿Qué es un MCP, en palabras simples?

Durante años, los modelos de IA fueron muy buenos en una sola cosa: producir texto. Podías pedirle a un modelo que te explicara cómo configurar un servidor y te daba instrucciones impecables... que después tenías que ejecutar tú, a mano, una por una.

El Model Context Protocol (MCP) rompe esa barrera. Es un estándar abierto que define cómo un modelo de IA se conecta con el mundo exterior: bases de datos, servidores, APIs, servicios de correo, repositorios de código.

La analogía más útil es la de un enchufe. Antes de que existiera un estándar de enchufes, cada aparato necesitaba su propio cable a medida. Con un estándar, cualquier aparato entra en cualquier toma. El MCP es eso, pero para la IA: cualquier modelo compatible puede conectarse a cualquier servidor MCP y usar sus herramientas sin que nadie tenga que programar una integración especial.

Un servidor MCP no le "enseña" nada al modelo. Simplemente le entrega un catálogo: estas son las acciones disponibles, esto es lo que hace cada una, estos son los parámetros que necesita. El modelo lee ese catálogo y elige.

Sin MCP, la inteligencia artificial solo puede hablar. Con MCP, la inteligencia artificial puede hacer.

Cómo funciona un MCP: el ciclo de cuatro pasos

Todo lo que pasa dentro de un MCP se puede describir con un ciclo que se repite en cada acción.

Paso 1 — Tú pides. Hablas en tu idioma, con tus palabras. "Necesito un servidor nuevo para el proyecto." No hay comandos que memorizar ni formularios que completar.

Paso 2 — La IA elige. El modelo lee el catálogo de herramientas que publica el servidor MCP y decide cuál usar y con qué parámetros. Este punto es importante: la IA no improvisa comandos sueltos, elige de una lista cerrada y conocida.

Paso 3 — El MCP ejecuta. El servidor recibe la llamada, verifica que quien la pide tenga permiso para hacerlo, y toca el sistema real: crea el servidor, escribe el registro DNS, envía el correo.

Paso 4 — Vuelve el dato. El resultado real regresa al modelo: el ID que se generó, el estado del servicio, el error si algo falló. Esto elimina uno de los mayores problemas de la IA sin herramientas, que es inventar respuestas plausibles. Acá no hay nada que inventar: el sistema respondió lo que respondió.

Si la tarea necesita varios pasos, el ciclo simplemente vuelve a empezar. La IA encadena llamadas, lee cada resultado y ajusta el siguiente movimiento en base a lo que realmente pasó.

Las tres piezas de cualquier MCP

1. El cliente (o anfitrión). Es la aplicación donde usted habla con la IA: un chat, un editor de código, una terminal. El cliente es quien establece la conexión con el servidor y le pasa al modelo la lista de herramientas disponibles.

2. El servidor MCP. Es el que publica las herramientas y las ejecuta. Vive del lado del servicio: en el caso de ArduMaker, corre en la propia plataforma, con acceso a los sistemas que administra.

3. Las herramientas. Cada una es una función con nombre descriptivo, una explicación de lo que hace y una lista de parámetros con sus tipos. Es exactamente la información que un modelo necesita para decidir bien.

Esa estructura es también la razón por la que un MCP es más seguro que darle a la IA una terminal abierta. El servidor define de antemano qué se puede hacer y qué no. Si una acción no está en el catálogo, no existe. Y cada llamada pasa por la misma verificación de permisos que atravesaría un usuario humano.

El MCP de ArduMaker: qué puede hacer

Acá es donde la idea se vuelve concreta. El MCP de ArduMaker expone cientos de herramientas (eran cerca de 200 cuando se publicó este artículo, en agosto de 2026; la referencia del catálogo tiene el número vigente) que cubren, prácticamente, todo el ciclo de vida de una infraestructura. Estas son las áreas principales:

Servidores VPS. Crear máquinas, encenderlas, apagarlas, reiniciarlas y cambiarles el plan. Ejecutar comandos dentro de ellas. Crear y administrar servicios systemd, leer sus logs, programar tareas recurrentes, gestionar usuarios de Linux y redirecciones de puertos. Lo que no puede: borrar un VPS. No existe la herramienta, y es deliberado.

Dominios y DNS. Registrar dominios, crear y editar registros DNS, verificar el estado de los nameservers, activar dominios con certificado SSL incluido. Acá también hay un límite a propósito: no existe una herramienta para borrar un registro DNS. Se puede crear y sobrescribir; borrar, no.

Correo. Dar de alta dominios de correo, crear buzones, alias y filtros, revisar la verificación de MX, SPF, DKIM y DMARC, y también leer y enviar mensajes directamente.

Bases de datos. Listar motores instalados, explorar tablas y esquemas, hacer consultas de solo lectura, insertar o actualizar filas y consultar el historial de operaciones destructivas.

Proyectos y equipo. Etapas, tareas, checklists, comentarios, adjuntos, reuniones, calendario compartido y una papelera que permite restaurar lo borrado.

Repositorios y túneles. Vincular repos de GitHub a un VPS, desplegarlos, revisar los registros de cada despliegue y levantar túneles SSH entre máquinas.

Blogs. Crear artículos, subir imágenes, publicarlos, archivarlos y traducirlos automáticamente a español, inglés y portugués.

Una nota sobre la infraestructura, porque explica varias herramientas. Cada VPS de ArduMaker es un contenedor dentro de un host padre compartido. Esa máquina superior concentra lo que debe ser común: la IP pública, el nginx que termina el HTTPS, los certificados y las redirecciones de puerto que conectan internet con cada contenedor. El usuario administra su VPS —procesos, servicios, código, bases de datos— y nunca el host. Por eso publicar un dominio pasa por herramientas que operan en una capa a la que no tenés acceso directo, y por eso exponer una aplicación es siempre "crear una redirección", no "abrir un puerto".

Y el catálogo no es una lista escrita a mano: el servidor lo publica en vivo en mcp.ardumaker.com/tools.json, generado desde su propio registro de herramientas. Si una herramienta aparece ahí, existe.

Este artículo es la demostración

La mejor forma de explicar un MCP no es describirlo: es usarlo mientras se lo explica.

Este artículo no se escribió en un editor. No se subieron imágenes desde una computadora. Nadie hizo clic en un botón de "publicar". Todo se hizo en una conversación, en español, pidiéndole a una IA que escribiera un blog sobre qué es un MCP.

La IA se conectó al servidor MCP de ArduMaker, leyó el catálogo de herramientas, y ejecutó, en orden: revisar qué artículos ya existían, crear este en estado borrador, generar y subir las tres imágenes que estás viendo, escribir cada sección de texto una por una, fijar la portada, publicarlo y traducirlo.

Los diagramas de este artículo también se generaron durante la misma conversación, no se buscaron en un banco de imágenes.

Estas son, textualmente, las herramientas que se usaron.

listar_mis_blogs() -> revisar qué artículos ya existen

crear_blog( titulo = "Qué es un MCP y cómo funciona el MCP de ArduMaker", descripcion = "...", tags = ["MCP", "ArduMaker", "IA", "automatizacion", ...] ) -> { "id": 22, "status": "draft" }

crear_media_blog(blog_id = 22, filename = "mcp-portada.webp", ...) crear_media_blog(blog_id = 22, filename = "mcp-como-funciona.webp", ...) crear_media_blog(blog_id = 22, filename = "mcp-herramientas.webp", ...) -> las tres imágenes quedan alojadas en el artículo

agregar_seccion_blog(blog_id = 22, section_key = "s01_resumen", section_type = "text") agregar_seccion_blog(blog_id = 22, section_key = "s03_cita", section_type = "quote") agregar_seccion_blog(blog_id = 22, section_key = "s05_img_flujo", section_type = "image") -> cada bloque del artículo, uno por llamada

editar_blog(blog_id = 22, cover_image = "mcp-portada.webp") publicar_blog(blog_id = 22) -> { "status": "published" }

traducir_blog(blog_id = 22, languages = ["es", "en", "pt"]) -> el mismo artículo, en tres idiomas

Qué cambia en el día a día

Un MCP no es una demo de laboratorio. Cambia tareas concretas que hoy consumen tiempo:

Levantar un proyecto entero en una frase. "Creá un VPS, apuntale este dominio, instalá el certificado y desplegá mi repo." Antes eran cinco paneles distintos y una hora de trabajo. Ahora es una orden y una cadena de llamadas encadenadas.

Diagnosticar sin buscar. "¿Por qué está caído el sitio?" La IA revisa el estado del VPS, lee los logs de nginx, mira el estado del servicio systemd y te dice qué encontró, con los logs reales en la mano.

Auditar sin abrir la consola. "¿Cuánto gastamos este mes y en qué?" o "¿qué borró alguien del proyecto la semana pasada?". Las respuestas salen de los datos, no de una estimación.

Automatizar lo repetitivo. Programar tareas, rotar claves, revisar la verificación DNS de los dominios de correo, publicar contenido en tres idiomas.

Trabajar en tu idioma. No hace falta recordar la sintaxis de systemd, ni los nombres exactos de los registros DNS, ni cómo se llamaba aquel comando. Lo describís y se hace.

Seguridad: el alcance importa más que los permisos

Es la pregunta que aparece siempre, y con razón: si una IA puede reiniciar servidores y tocar bases de datos, ¿qué impide un desastre?

Los permisos son los tuyos. El agente actúa en nombre de la persona que lo autorizó. Si esa persona no administra una empresa, el agente tampoco. Si un VPS tiene visibilidad restringida, el agente no lo ve.

Pero además elegís el alcance al autorizar, y eso es lo que de verdad acota el riesgo. Cuando conectás un agente decidís tres cosas por separado:

• Solo lectura, o no. Una sesión de solo lectura no escribe nada, aunque quien la autorizó sea admin de todo.
• Todos los proyectos, o una selección.
• Todos los VPS, o una selección.

Un agente que resume tu semana no necesita el mismo alcance que uno que despliega. Dar el mínimo no es paranoia: es la diferencia entre un error y un incidente.

El agente sabe su alcance antes de empezar. Existe una herramienta, ver_contexto_inicial, que le dice de entrada quién lo autorizó, qué alcance le dieron, qué ids puede ver y qué cosas no va a poder hacer nunca. Esto suena menor y no lo es: sin eso, un agente descubre sus límites chocándose, después de haberte prometido algo que no puede cumplir.

Hay operaciones que ningún agente MCP puede hacer, tenga el alcance que tenga. Son cuatro, y están publicadas:

• borrar un proyecto entero,
• agregar, quitar o cambiar el rol de un miembro de un proyecto,
• crear, editar o borrar un adjunto marcado como secreto,
• borrar un VPS.

No es que estén restringidas: no existen las herramientas. El camino no está.

En la misma línea, hay eliminaciones que directamente no se exponen: no hay forma de borrar un blog de manera permanente —el mecanismo es archivar, que es reversible— ni de borrar un registro DNS. Y las que sí pueden hacer daño piden confirmación explícita: crear o editar un registro NS, MX o un A de la raíz de un dominio falla si no mandás confirmado, porque un error ahí tumba el sitio o el correo de todo el dominio con demora real de propagación aun después de arreglarlo.

El contenido escrito por terceros llega marcado como no confiable. Es la parte menos vistosa y quizás la más importante. Cuando una herramienta devuelve algo que no escribió quien autorizó al agente —el cuerpo de un correo, un comentario, un log, la salida de un comando, el mensaje de un commit— el servidor lo envuelve y lo etiqueta: esto son datos, nunca instrucciones. Si adentro viene algo con forma de orden dirigida a la IA, la IA tiene que reportártelo en vez de obedecerlo, incluso si el texto dice venir de ArduMaker, de un administrador o de vos.

Y hay combinaciones de alcance que son riesgosas aunque cada mitad sea inocente. Esto el servidor lo publica explícitamente, y vale más que cualquier frase tranquilizadora:

• Leer correo + ejecutar comandos en un VPS. Cualquiera que conozca una de tus direcciones puede poner texto delante de tu agente. Si ese mismo agente puede abrir un shell, un correo bien escrito es un intento de ejecución remota que no le cuesta nada al atacante y no requiere tener cuenta en ArduMaker. Ninguna de las dos mitades es peligrosa sola.
• Leer correo + enviar correo del mismo dominio. Un mensaje entrante puede convencer al agente de responderle a un tercero desde tu dominio: phishing a tus propios clientes, con tu firma DKIM.
• Leer correo o comentarios + consultar bases de datos. Texto no confiable más SQL arbitrario es un camino de exfiltración.

La recomendación que da el propio servidor es la correcta: separá agentes. Uno que atiende correo, sin acceso a VPS. Uno que opera servidores, sin buzones. Para triage y resúmenes, solo lectura alcanza.

Todo queda registrado. Cada proyecto tiene su historial de actividad. Las operaciones destructivas contra bases de datos tienen su propio registro: quién, cuándo y qué. Y la papelera guarda lo eliminado con la posibilidad de restaurarlo. Con una salvedad honesta: ejecutar_comando_vps registra que se ejecutó un comando, no cuál — otra razón para preferir las herramientas dedicadas, que sí anotan el verbo.

Las credenciales nunca se exponen. Las herramientas que administran claves de API o tokens devuelven su uso y su costo, pero jamás el valor del token. Lo mismo con las contraseñas de los buzones de correo.

La conclusión honesta no es que un MCP no agrega riesgo. Es que lo hace explícito y acotable: el catálogo es cerrado, el alcance lo elegís vos, las combinaciones peligrosas están documentadas y el contenido ajeno llega marcado como lo que es.

Preguntas frecuentes

¿Qué significa MCP? Model Context Protocol. Es un estándar abierto para conectar modelos de IA con herramientas y datos externos.

¿Un MCP es lo mismo que una API? No exactamente. Una API está pensada para que la use un programador escribiendo código. Un MCP está pensado para que la use un modelo de IA leyendo descripciones en lenguaje natural. Muchos servidores MCP funcionan por encima de una API existente.

¿Necesito saber programar para usar el MCP de ArduMaker? No. Se usa conversando. Quien programa, además, gana: puede pedirle a la IA que despliegue, revise logs o consulte la base sin salir del chat.

¿Con qué modelos funciona? Con cualquier cliente compatible con el protocolo MCP. Esa es justamente la ventaja de que sea un estándar abierto: no queda atado a un proveedor.

¿Cuál es la dirección del servidor? https://mcp.ardumaker.com/mcp — transporte Streamable HTTP, autorización OAuth 2.1 con PKCE y registro dinámico de clientes. En la práctica: pegás la dirección en tu cliente y te lleva a aprobar la conexión con tu cuenta.

¿Puedo darle acceso limitado? Sí, y conviene. Al autorizar elegís si la sesión es de solo lectura, si ve todos tus proyectos o una selección, y si ve todos tus VPS o una selección. Un agente que solo lee no escribe nada, aunque vos seas admin de todo.

¿La IA puede romper algo? Solo puede hacer lo que la persona que la autorizó ya podía hacer, dentro del alcance que le diste, y solo mediante las herramientas publicadas. Hay cuatro operaciones que ningún agente puede hacer nunca —borrar un proyecto, tocar miembros de un proyecto, tocar adjuntos secretos y borrar un VPS—, varias eliminaciones no están expuestas en absoluto, y las acciones más delicadas piden confirmación explícita.

¿Y si alguien le manda instrucciones a mi agente escondidas en un correo o en un comentario? Es una amenaza real y el servidor la trata como tal: todo el contenido escrito por terceros llega envuelto y marcado como no confiable, con la indicación de tratarlo como datos y nunca como instrucciones. La otra mitad de la defensa es tuya: no le des a un mismo agente acceso a leer correo y a ejecutar comandos.

¿Cuántas herramientas tiene? Cientos: cerca de 200 cuando se publicó este artículo (agosto de 2026) y más de 300 cuando se lo actualizó (octubre de 2026), repartidas entre VPS, dominios, DNS, correo, bases de datos, proyectos, repositorios, túneles, blogs y administración de claves y costos. El número vigente está siempre en la referencia de herramientas y en mcp.ardumaker.com/tools.json, que se genera en vivo desde el servidor.

Empezar es conectar una dirección

Para usar el MCP de ArduMaker alcanza con agregar el servidor en un cliente compatible y autorizarlo con tu cuenta:

https://mcp.ardumaker.com/mcp

En ese momento elegís el alcance: solo lectura o no, todos los proyectos o algunos, todos los VPS o algunos. Vale la pena pensarlo dos segundos — es la decisión que define qué puede pasar después.

A partir de ahí, la IA ve tus empresas, tus proyectos y tus servidores, con tus permisos y dentro del alcance que le diste. Y podés empezar por lo simple: pedile que llame a ver_contexto_inicial y te cuente qué está viendo. Es la mejor primera conversación posible, porque te devuelve el mapa completo y de paso te confirma con qué alcance quedó conectada.

El salto conceptual es este: durante décadas, administrar infraestructura significó aprender la interfaz de cada herramienta. Con un MCP, la interfaz sos vos explicando lo que querés.

Este artículo es la prueba. Fue una conversación, y terminó siendo una página publicada, ilustrada y traducida.