MCP con modelos locales, herramientas sin nube

Un modelo de lenguaje por sí solo es un interlocutor sin manos. No puede consultar, no puede calcular, no puede recuperar nada, solo puede responder con lo que hay en la conversación. La cosa se pone interesante cuando recibe herramientas, y el protocolo para eso es MCP.

Lo que con Claude o ChatGPT se da por hecho también funciona del todo en local. Modelo en tu ordenador, herramientas en tu ordenador, datos en tu ordenador. Este playbook enseña el camino y dice en el punto justo dónde se atasca, porque en un punto se atasca de verdad.

1. Aclara qué tres piezas necesitas

El protocolo conoce tres papeles, y la confusión suele venir de meter al modelo entre ellos.

El host es la aplicación en la que estás, por ejemplo Claude Desktop o una interfaz web local. Arranca un cliente por conexión, y cada cliente habla con exactamente un servidor. El servidor proporciona las herramientas, por ejemplo acceso a archivos o a una base de datos.

El modelo no está en esa lista a propósito. No participa en el protocolo. El host recoge la lista de herramientas de los servidores, se la presenta al modelo, y cuando el modelo quiere llamar a una, el host ejecuta la llamada. Suena a sutileza, pero es la razón por la que el mismo servidor funciona detrás de cualquier modelo.

En Claude Desktop el host y el acceso al modelo van en una sola aplicación. En un montaje local los separas: Ollama pone el modelo, una interfaz o un script propio hace de host. Es el mismo software de servidor que con Claude, y ese es todo el sentido de un protocolo abierto. Qué servidores registras en cada entorno es independiente de eso y una cuestión de seguridad, ver paso 10.

Consejo: Si el protocolo en sí todavía te resulta ajeno, lee primero la lección Qué es MCP. Todo lo de aquí la da por sabida.

2. Comprueba si tu modelo sabe usar herramientas

No todo modelo local domina la llamada a herramientas. Algunos nunca fueron entrenados para ello, otros pueden hacerlo formalmente y luego lo usan mal. Esa es la primera barrera y descarta a buena parte de los candidatos.

En la biblioteca de Ollama, los modelos con soporte de herramientas están marcados como tales. Guíate por eso en vez de probar y luego pasar media hora buscando por qué no ocurre nada.

Consejo: Para llamar herramientas no cojas el modelo más pequeño que encuentres. Por debajo de unos siete mil millones de parámetros la capacidad falta en buena medida y salen llamadas mal formadas. Por encima decide no el tamaño sino si el modelo fue entrenado expresamente para ello: en comparativas, modelos de 8B y 14B con entrenamiento de herramientas quedan muy cerca, mientras que modelos bastante mayores sin ese entrenamiento rinden peor. Más grande no es aquí automáticamente mejor.

3. Usa una interfaz que ya hable MCP

El camino más rápido pasa por una interfaz que traiga el protocolo. Open WebUI soporta MCP de forma nativa desde la versión 0.6.31 y está pensada para modelos locales. Con eso te ahorras escribir el cliente.

El montaje queda así: Ollama corre en segundo plano, Open WebUI se conecta a él, y en sus ajustes registras tus servidores MCP.

Un detalle que pilla a casi todo el mundo en el primer intento: los servidores son los mismos, el registro no. Lo que en Claude Desktop se configura como un proceso arrancado en local (stdio, o sea un comando más argumentos) necesita en una interfaz web una dirección accesible. Algunos servidores admiten ambas cosas, otros solo una.

Si para un servidor stdio necesitas un puente, eso no es un mero cambio de formato sino una puerta nueva. Átalo a 127.0.0.1, dale un token de acceso y no lo pongas en la red. Un servidor de archivos expuesto por un puente sin autenticación es acceso a archivos para cualquiera que conozca la dirección.

Consejo: Antes de construir un cliente propio, prueba el que ya existe. La mayoría se da cuenta ahí de que no necesita uno propio.

4. Empieza con un servidor inofensivo

Coge primero un servidor que solo lea. Un acceso a archivos limitado a un único directorio de pruebas es ideal. Así ves si la cadena funciona sin que un fallo cause daño.

Luego hazle al modelo una pregunta que no pueda responder sin la herramienta. "Qué pone en el archivo notas.txt" es una buena prueba, porque la respuesta es inequívocamente correcta o falsa.

Consejo: Si el modelo responde sin haber usado la herramienta, se ha inventado la respuesta. Justo por eso una prueba con respuesta inequívoca es mejor que una abierta.

5. Cuenta con que el modelo pase por alto las herramientas

Aquí está el punto en el que los montajes locales se diferencian de Claude, y pesa más que todo lo técnico.

Un modelo grande decide de forma fiable cuándo hace falta una herramienta. Un modelo local pequeño no siempre. A veces responde de memoria aunque la herramienta adecuada esté ahí. A veces coge la equivocada. Y en una cadena de varios pasos pierde el hilo más a menudo.

Antes de culpar al modelo: también puede venir del montaje. Una plantilla de chat equivocada, un servidor que no describe bien sus herramientas, una cuantización demasiado basta, una interfaz que ni siquiera pasa las llamadas a herramientas. Comprueba eso primero. Si el comportamiento persiste, es un límite de capacidad del modelo, y ese no se configura para que desaparezca.

Consejo: Cuantas menos herramientas estén activas a la vez, más fiable es la elección. Tres bien descritas ganan a veinte, y con modelos pequeños por mucho.

6. Escribe las descripciones para un modelo más débil

Con un modelo potente la descripción de una herramienta puede ser escueta, deduce el contexto solo. Con un modelo local la descripción es tu palanca más importante.

Escribe en ella cuándo se usa la herramienta, no solo qué hace. Así que en vez de "busca en la base de datos", pon "úsala cuando se pregunte por un cliente, una factura o un expediente". La diferencia en la tasa de acierto es notable.

Consejo: Si construyes servidores propios, esa es de todos modos la mejor práctica. Las reglas del buen diseño de herramientas están en Diseño de herramientas, y con modelos locales rinden el doble.

7. Engancha tu memoria

El servidor más valioso en un montaje local es el que recuerda cosas. Un modelo pequeño sabe poco del mundo y menos aún de ti. Una memoria compensa en parte ambas cosas, porque entonces el conocimiento no tiene que estar dentro del modelo, se consulta.

Ese es también el punto en el que la cuestión del tamaño se desactiva. Un modelo de 8 mil millones con acceso a tus notas es mejor en preguntas sobre tu proyecto que un modelo grande sin ese acceso.

Consejo: De eso trata exactamente la tesis central de esta academia. Un modelo que conoce tu contexto gana a uno más potente que tiene que adivinar. El montaje está en Configurar la memoria.

8. Ata corto las herramientas que escriben

Las herramientas de escritura son el riesgo evidente. Un modelo que puede borrar archivos, enviar correos o modificar registros y que de vez en cuando coge la equivocada es una combinación incómoda. Esas necesitan confirmación, siempre.

Eso no vuelve inofensiva la lectura, y ese es el error que se lee constantemente en las guías. Una herramienta de lectura con acceso demasiado amplio trae claves SSH, credenciales, documentación fiscal o datos de clientes al contexto del modelo, y de ahí a registros e historiales. Si más adelante ejecutas esa misma interfaz una vez contra un modelo en la nube, ese es justo el camino hacia fuera que querías evitar. Además: lo que se llama "read" no tiene por qué carecer de efectos secundarios, el protocolo no lo impone.

Por eso la regla no es "lectura libre, escritura bloqueada" sino el menor acceso posible en ambos lados. Dale al servidor de archivos un único directorio en vez de tu carpeta de usuario, y haz que se confirmen las acciones de escritura.

Consejo: Empieza con un único directorio en acceso de lectura y amplía solo cuando sepas qué toca realmente el montaje. No al revés.

9. Revisa los servidores ajenos antes de conectarlos

Un servidor MCP es código ejecutable en tu ordenador. Que tu modelo corra en local no vuelve más seguro a un servidor ajeno. La ganancia de privacidad del modelo local se esfuma si el servidor conectado llama a casa.

Consejo: El procedimiento de revisión está en Revisar servidores MCP ajenos con seguridad. En un montaje que es local expresamente por privacidad, ese paso no es opcional.

10. Decide con honestidad si basta

Tras una semana de uso diario sabes si el montaje aguanta. Dos resultados son normales y ambos están bien.

O basta, y entonces tienes un asistente con herramientas del que nada sale de casa. O no basta, porque el modelo se equivoca demasiado a menudo. Entonces la respuesta no es "lo local no sirve" sino un montaje mixto: lo local para todo lo que lleve datos sensibles, el modelo grande para los casos duros.

Aquí vale, eso sí, justo lo que advierte el paso 8. Si dentro del mismo perfil cambias entre modelo local y modelo en la nube, se llevan consigo las herramientas y el historial existente, y con ellos todo lo que una herramienta de lectura trajo antes. Así que separa en el nivel que de verdad separa: dos instalaciones separadas, o directorios de configuración separados. Una segunda ventana no basta, y un segundo perfil de usuario en la misma interfaz tampoco: allí los servidores MCP y las credenciales de modelo suelen estar registrados de forma global, o sea alcanzables desde ambos perfiles. La instalación local lleva los servidores sensibles y ningún acceso a la nube; la otra lleva el acceso a la nube y sencillamente no incluye esos servidores.

Consejo: Que un servidor MCP PUEDA correr en ambos lados no significa que deba. La portabilidad te ahorra el aprendizaje al montar el segundo entorno, no la decisión sobre qué servidores se registran allí. Más sobre el principio en Portabilidad de herramientas.

Qué sigue

Si aún falta el modelo, empieza por Tu primer modelo de IA local en 30 minutos. La cuestión del tamaño la cubre Qué modelo local encaja con tu hardware. Y si algún día quieres construir un servidor propio en vez de conectar los de otros, el nivel 6 con Planificar un servidor MCP es la entrada.

Source

• Model Context Protocol, especificación oficial: https://modelcontextprotocol.io
• Ollama, modelos con soporte de herramientas: https://ollama.com/search?c=tools
• Open WebUI, documentación sobre la conexión MCP: https://docs.openwebui.com