Configurar MCP con Ollama 2026: conecta modelos locales a archivos, bases de datos y APIs

Datos rápidos

• Protocolo: JSON-RPC 2.0 sobre stdio (subproceso local) o Streamable HTTP (remoto). El antiguo transporte HTTP+SSE está obsoleto. Los agentes locales usan casi exclusivamente stdio. La revisión actual de la especificación es la 2026-07-28.
• Origen: creado por Anthropic como especificación abierta (modelcontextprotocol.io). En modelcontextprotocol/servers solo se mantienen unos pocos servidores de referencia (filesystem, git, fetch, memory y otros); SQLite, PostgreSQL, Puppeteer y GitHub pasaron a servers-archived. Ahora cada proveedor publica sus propios servidores.
• Clientes locales: Goose (código abierto, repositorio aaif-goose/goose), Cline (extensión de VS Code), Continue.dev (VS Code/JetBrains), LM Studio (aplicación de escritorio), más varias herramientas CLI.
• Modelos Ollama compatibles: cualquier modelo con entrenamiento nativo de tool calling, por ejemplo Gemma 4 31B, GLM-4.7 Flash, Qwen3.6 27B, Qwen3 32B, Qwen3-Coder 30B, Llama 3.3 70B.
• Transporte por defecto de los servidores: stdio para procesos locales; Streamable HTTP solo cuando necesitas compartir un servidor entre máquinas o agentes.
• La configuración vive en el cliente: Goose lee un bloque extensions en ~/.config/goose/config.yaml (o goose configure); Cline y Continue.dev tienen sus propios ajustes de MCP. Los campos son la misma idea en todos: nombre del servidor, comando, args, variables de entorno.
• No se necesita Claude Desktop. El protocolo es abierto e independiente de Claude Desktop; los servidores usados aquí son de código abierto (revisa cada licencia) y funcionan con cualquier cliente compatible.

Lo que MCP realmente desbloquea para un modelo local

• "Encuentra todos los TODO en este repositorio, agrúpalos por archivo y escribe un resumen en Markdown en notes/todos.md." — el servidor filesystem lee, el modelo agrupa, el mismo servidor escribe. Un único viaje de ida y vuelta de principio a fin.
• "Muéstrame los 10 mejores clientes por ingresos este trimestre y haz un gráfico." — el servidor postgres ejecuta el SQL (rol de solo lectura), el modelo resume y escribe un CSV mediante filesystem para tu herramienta de gráficos.
• "Abre la portada de Hacker News, encuentra las tres principales historias de IA, resúmelas y añádelas a mi lista de lectura." — el servidor playwright controla un navegador, el modelo extrae y resume, filesystem añade.
• "Abre un PR draft con el título chore: bump deps contra mi fork y enlaza la ejecución de CI fallida." — el servidor github crea el PR, obtiene la ejecución y escribe el enlace en la descripción.
• "Mira las últimas 100 filas de events.db y dime qué IDs de usuario son responsables del nuevo pico de errores." — un servidor de base de datos consulta una copia de los datos; el modelo razona; lees la respuesta en el panel de chat.
• Cada uno de estos es un flujo de trabajo de frase a acción que antes requería un modelo en la nube con herramientas alojadas o un script escrito a mano. MCP es la capa que te permite reutilizar los mismos servidores entre clientes y el mismo modelo entre servidores.

Comparativa de los cuatro servidores MCP más usados

Cómo encajan las piezas

• Ollama se ejecuta como servicio en segundo plano en 127.0.0.1:11434 y sirve el modelo a través de una API compatible con OpenAI. No sabe qué es MCP — simplemente responde a las completaciones de chat y emite tool calls cuando el modelo los solicita.
• El cliente MCP (Goose, Cline, Continue.dev, LM Studio) es el puente. Habla con Ollama para el modelo y con los servidores MCP para las herramientas. Cuando el modelo emite un tool call, el cliente lo enruta al servidor correcto, obtiene el resultado y lo devuelve a la conversación.
• Los servidores MCP son subprocesos independientes, uno por capacidad. Hablan JSON-RPC 2.0 sobre stdio. Cada servidor anuncia una lista de Tools, Resources y Prompts; el cliente los combina en la superficie de herramientas que se presenta al modelo.
• El transporte stdio mantiene todo en local. El servidor es iniciado por el cliente, se comunica a través de su stdin/stdout y termina cuando el cliente termina. Nada va por la red a menos que el servidor mismo abra una conexión (el servidor de navegador sí lo hace; los servidores de filesystem y base de datos no).
• El modelo ve una lista plana de herramientas. Desde la perspectiva del modelo no hay servidores — solo una lista de nombres de herramientas como filesystem.read_file, playwright.browser_navigate, github.create_pull_request. El cliente gestiona el enrutamiento.

Configuración: Ollama + Goose en 15 minutos

• Paso 1 — instala Ollama. Descárgalo desde ollama.com/download (macOS/Windows/Linux). Confirma que el servicio está corriendo con curl http://127.0.0.1:11434/api/tags.
• Paso 2 — descarga un modelo con tool calling. Elige entre Gemma 4 31B (gemma4:31b), GLM-4.7 Flash (glm-4.7-flash), Qwen3.6 27B (qwen3.6:27b), Qwen3 32B (qwen3:32b) o Llama 3.3 70B (llama3.3:70b). 32 GB de memoria unificada o 24 GB de VRAM manejan cómodamente 26B–32B en Q4_K_M.
• Paso 3 — instala Goose. En macOS o Linux ejecuta curl -fsSL https://github.com/aaif-goose/goose/releases/download/stable/download_cli.sh | bash (o brew install block-goose-cli). En Windows usa el instalador de PowerShell de la documentación de Goose, o WSL. El CLI se instala como goose.
• Paso 4 — configura Ollama como proveedor. Ejecuta goose configure, elige ollama como proveedor, establece el modelo al que descargaste y el host en http://127.0.0.1:11434 (en blanco también equivale a localhost:11434). Goose escribe esto en ~/.config/goose/config.yaml. La ventana de contexto predeterminada de Ollama puede ser pequeña (la documentación de Goose menciona 4096 tokens), lo que puede hacer que Goose ignore sus extensiones — inicia Ollama con OLLAMA_CONTEXT_LENGTH=32768 (o más).
• Paso 5 — añade el servidor MCP de filesystem. Ejecuta goose configure, elige Add Extension y luego Command-line Extension, o añade un bloque extensions a ~/.config/goose/config.yaml (ejemplo a continuación). Para una prueba puntual, goose session --with-extension "npx -y @modelcontextprotocol/server-filesystem /path/to/workspace" lo activa solo para esa sesión. Inicia goose session y pídele que liste los archivos en tu directorio de prueba. El primer turno confirma que el servidor está conectado.
• Paso 6 — verifica con una tarea real. Prueba goose session y pide "Haz una lista de cada archivo Markdown en notes/, con título y número de palabras, y escribe el resultado en notes/index.md." Si el agente lee, resume y escribe de vuelta, el bucle funciona.

# 1. Pull a tool-calling model
ollama pull gemma4:31b

# 2. Install Goose (macOS / Linux)
curl -fsSL https://github.com/aaif-goose/goose/releases/download/stable/download_cli.sh | bash

# 3. Configure Ollama as the provider
goose configure
# Provider: ollama
# Model:    gemma4:31b
# Host:     http://127.0.0.1:11434

# 4. Give Ollama a context window big enough for tool use, then start a session
OLLAMA_CONTEXT_LENGTH=32768 ollama serve   # in a separate terminal
goose session

Servidor Filesystem: leer y escribir en un directorio aislado

• Instalación: el servidor de referencia es @modelcontextprotocol/server-filesystem, ejecutado mediante npx -y (sin instalación global; requiere Node.js). Es uno de los servidores de referencia que siguen mantenidos. Goose, Cline y Continue.dev lo inician desde su configuración.
• Rutas en la allow-list: el servidor acepta uno o más argumentos de directorio y rechaza operaciones fuera de ellos. Siempre pasa una ruta explícita y estrecha — nunca ~ ni /.
• Herramientas expuestas: read_file, read_multiple_files, write_file, edit_file (reemplazos por línea), list_directory, search_files, move_file, create_directory, directory_tree. El modelo las ve como filesystem.read_file y así sucesivamente.
• Comodidad de uso: directory_tree devuelve un árbol JSON; ideal para que el modelo se oriente antes de leer archivos específicos. search_files hace una búsqueda recursiva similar a grep.
• Superficie de riesgo: el servidor respeta la allow-list, pero dentro de ella tiene lectura/escritura completa. Trata la allow-list como la única barrera y elige un directorio workspace dedicado en lugar de tu carpeta home.

# ~/.config/goose/config.yaml
extensions:
  filesystem:
    type: stdio
    name: filesystem
    enabled: true
    cmd: npx
    args: ["-y", "@modelcontextprotocol/server-filesystem", "/Users/you/agent-workspace"]
    envs: {}
    timeout: 300

Servidores de base de datos: consultar Postgres (y SQLite) con seguridad

• Postgres: postgres-mcp (Crystal DBA, licencia MIT) es la opción con modo de solo lectura (la última versión en PyPI es de mayo de 2025, así que comprueba la actividad del repositorio antes de depender de él). Ejecútalo con uvx postgres-mcp --access-mode=restricted (o pipx install postgres-mcp, o su imagen Docker) y pasa la URI de conexión en la variable de entorno DATABASE_URI. El modo restringido permite transacciones de solo lectura y un límite de tiempo por consulta; el modo sin restricciones es solo para desarrollo.
• Usa además un rol de solo lectura dedicado. El modo restringido es una barrera, el rol de la base de datos es otra. Crea un rol agent_ro con permisos solo de SELECT y usa la cadena de conexión de ese rol.
• SQLite: el servidor de referencia está archivado. Es el paquete de Python mcp-server-sqlite (no un paquete npm; última versión en abril de 2025); puede que aún funcione, pero no recibe correcciones. Apúntalo solo a una copia del archivo, nunca a tu única copia, o carga los datos en Postgres. Lee el código de cualquier servidor SQLite de la comunidad antes de darle un archivo.
• Conciencia del esquema: pide al agente que "liste las tablas y describa las cinco más usadas" antes de hacer preguntas analíticas — el modelo es mucho más preciso cuando ha inspeccionado el esquema que cuando adivina los nombres de columnas.
• Costo: las consultas van directamente a tu base de datos. Un SELECT * mal formado de una tabla de 100M de filas es el mismo accidente aquí que lo sería de un humano — mantén el rol en un pool de conexiones separado con un statement timeout.

# ~/.config/goose/config.yaml
extensions:
  postgres:
    type: stdio
    name: postgres
    enabled: true
    cmd: uvx
    args: ["postgres-mcp", "--access-mode=restricted"]
    envs:
      DATABASE_URI: "postgresql://agent_ro:${PG_AGENT_PASSWORD}@127.0.0.1:5432/analytics"
    timeout: 300

Servidor de navegador: controlar un navegador con Playwright MCP

• Qué servidor usar: el @playwright/mcp de Microsoft (npx @playwright/mcp@latest). El antiguo @modelcontextprotocol/server-puppeteer figura como "no longer supported", y en npm no existe ningún paquete @modelcontextprotocol/server-playwright.
• Herramientas expuestas: browser_navigate, browser_snapshot, browser_click, browser_type, browser_fill_form, browser_evaluate (ejecutar JavaScript), browser_take_screenshot, browser_tabs, browser_wait_for. El modelo lee la página con browser_snapshot (un snapshot de accesibilidad, que Playwright MCP recomienda frente a las capturas para ejecutar acciones) y usa las capturas de pantalla solo para mirar.
• Latencia: las sesiones de navegador reales tardan entre 1 y 5 segundos por acción. Una navegación de varios pasos puede consumir fácilmente entre 30 y 60 segundos y decenas de miles de tokens porque el contenido de las páginas es grande. Usa una ventana de contexto de 32K+.
• Referencias de elementos: el modelo hace clic en los elementos mediante las referencias del snapshot. Los modelos más pequeños se equivocan con frecuencia; un modelo de 27B+ con tool calling maneja los patrones comunes de forma fiable. Mantén las tareas acotadas — "extrae el título y el primer párrafo de esta URL" es mucho más fiable que "navega por el sitio y encuentra la página de contacto".
• Los casos de uso correctos: investigación (abrir la página, resumirla, añadir a notas), pruebas de regresión (navegar, hacer clic, captura de pantalla) y relleno de formularios en páginas que tú controlas. Los casos incorrectos: cualquier cosa donde un clic erróneo en la web en vivo tenga consecuencias.

# ~/.config/goose/config.yaml
extensions:
  playwright:
    type: stdio
    name: playwright
    enabled: true
    cmd: npx
    args: ["@playwright/mcp@latest"]
    envs: {}
    timeout: 300
# Block obviously dangerous endpoints at the OS firewall level
# rather than relying on the agent to refuse them.

Servidor GitHub: repositorios, issues y PRs desde un modelo local

• Instalación: usa el github/github-mcp-server oficial de GitHub, ejecutado desde su imagen Docker (ghcr.io/github/github-mcp-server) con un PAT en la variable de entorno GITHUB_PERSONAL_ACCESS_TOKEN. El antiguo paquete npm @modelcontextprotocol/server-github figura como "no longer supported"; no lo uses en instalaciones nuevas.
• Herramientas expuestas: search_repositories, get_file_contents, create_or_update_file, create_pull_request, list_issues, create_issue, add_issue_comment, merge_pull_request, más muchas otras. La superficie completa es grande; la mayoría de las tareas usan entre 5 y 10 herramientas.
• Limita el alcance del PAT. Usa un PAT de grano fino limitado a repositorios específicos con los permisos mínimos necesarios (Read para navegar, Write para crear PRs/issues). No uses un PAT clásico con repo para un agente experimental.
• Flujos de trabajo reales: triage ("lee los últimos 20 issues abiertos, agrúpalos, propón etiquetas"), borradores ("lee el README y abre un PR corrigiendo erratas"), reportes ("qué PRs están inactivos esta semana").
• Superficie de riesgo: el agente puede crear issues y PRs, comentarlos y (con permisos de escritura) hacer push de commits. Deshabilita las herramientas de merge a menos que confíes tanto en el modelo como en el flujo de trabajo — un merge accidental en un repositorio con PAT de grano fino es recuperable, pero solo si lo notas rápido.

# ~/.config/goose/config.yaml
extensions:
  github:
    type: stdio
    name: github
    enabled: true
    cmd: docker
    args: ["run", "-i", "--rm", "-e", "GITHUB_PERSONAL_ACCESS_TOKEN", "ghcr.io/github/github-mcp-server"]
    envs:
      GITHUB_PERSONAL_ACCESS_TOKEN: "${GH_AGENT_PAT}"
    timeout: 300
# Fine-grained PAT scoped to one or two test repos,
# not your personal account-wide classic token.

Un modelo de seguridad que no confía en el modelo

• Limita el servidor filesystem a un directorio. Nunca ~ ni /. Elige una carpeta agent-workspace/ y pon copias de los archivos que el agente necesita tocar. Si el agente falla, el peor caso es una carpeta.
• Ejecuta los servidores de base de datos en solo lectura por defecto. Un rol agent_ro dedicado con permisos solo de SELECT y un statement timeout de 30 segundos elimina toda una clase de incidentes.
• Coloca cada herramienta de escritura o shell detrás de una aprobación explícita. Goose, Cline y Continue.dev admiten reglas de aprobación por herramienta. Permite las herramientas de lectura por defecto; requiere aprobación para write_file, edit_file, execute_command, create_pull_request y cualquier acción del navegador que envíe formularios.
• Usa el registro de auditoría. Cada cliente MCP registra las tool calls y los resultados. Después de una sesión larga, revisa el registro: detectarás al modelo intentando cosas que no esperabas (a veces inofensivas, a veces justificando ajustar los permisos).
• Limita el acceso de terceros con tokens de alcance estrecho. PATs de GitHub limitados a dos repositorios de prueba. Roles de Postgres de solo lectura. Sesiones de navegador sin credenciales. El modelo eventualmente intentará cosas que no anticipaste; los límites de lo que puede hacer no deben depender de que el modelo lo haga bien.
• Aísla al agente para trabajo con datos sensibles. Deshabilita el acceso a la red en el host mientras se ejecuta el agente (o usa un namespace de red) cuando trabajes con datos privados. El stack local ya no envía nada fuera de la máquina, pero la defensa en profundidad detecta errores en servidores de terceros.
• Trata la selección de servidores MCP como cualquier elección de dependencia. Los servidores de referencia están bien mantenidos; muchos servidores de terceros no lo están. Lee el código del servidor antes de instalar uno que necesite credenciales.

MCP local vs Claude Desktop: qué cambia, qué permanece

Elegir un modelo con tool calling para MCP local

• Gemma 4 31B (gemma4:31b) — el entrenamiento de tool calling de Google es el mejor en su clase para este tamaño. Cabe en 16 GB de memoria unificada o 24 GB de VRAM en Q4_K_M. Buen razonamiento general; algo conservador en tool calls encadenados.
• GLM-4.7 Flash (glm-4.7-flash) — el modelo de Zhipu tiene una fiabilidad de tool calling muy alta y una ventana de contexto de 128K de serie. Ligeramente más pesado que Gemma 4; cabe cómodamente en una GPU de 24 GB.
• Qwen3.6 27B (qwen3.6:27b) — la opción Qwen más reciente en Ollama (unos 18–19 GB, contexto de 256K, con soporte de tool calling). Qwen3 32B (qwen3:32b) — equilibrado; el 32B denso maneja MCP sin problemas y se desenvuelve bien en un bucle de agente largo. Qwen3-Coder 30B (qwen3-coder:30b) es la mejor opción si tu trabajo de agente está orientado al código.
• Llama 3.3 70B (llama3.3:70b) — el techo más alto pero el más pesado. 48 GB+ de memoria unificada o 2× 24 GB de GPUs en Q4_K_M. Úsalo solo si tu hardware lo admite; los modelos más pequeños suelen ser suficientes.
• Evita para trabajo con MCP: cualquier cosa por debajo de 7B y cualquier modelo de uso general sin entrenamiento explícito de tool calling. Emitirán llamadas malformadas, el bucle se bloqueará y culparás al harness — pero el harness está bien.
• Para técnicas de prompting estructurado que mejoran la calidad del tool calling en cualquier modelo, consulta Chain-of-thought prompting.
• Para los datos comparativos, consulta Mejores modelos locales para tool calling en 2026.

MCP vs Function Calling simple: cuál es la diferencia

• El function calling es la capacidad del lado del LLM: el modelo emite un objeto JSON estructurado que describe el nombre de la herramienta y los argumentos. Las herramientas de OpenAI, las de Anthropic y la API de tool call de Ollama usan la misma idea con formatos de wire ligeramente diferentes.
• MCP se sitúa por encima: estandariza cómo se describen, descubren, invocan y devuelven las herramientas entre procesos. Un modelo con function calling por sí solo no sabe nada de tu filesystem; un servidor MCP hace disponibles las operaciones de filesystem, el cliente las mapea a la API de function calling del modelo y el modelo puede llamarlas.
• El beneficio es la interoperabilidad. Escribe el servidor filesystem una vez; Claude Desktop, Goose, Cline, Continue.dev y LM Studio lo usan todos sin cambios. Cambia el modelo de Claude a Gemma 4; el servidor no cambia.
• Puedes hacer agentes con function calling puro. Reimplementarás manejadores de filesystem, base de datos y navegador por proyecto. Con MCP, esas son dependencias listas para usar.
• Para scripts puntuales, el function calling puro es más sencillo. Para cualquier cosa que quieras reutilizar entre proyectos o modelos, MCP es el camino de menor esfuerzo en pocos días.

Errores comunes al configurar MCP local

• Error 1: usar un modelo pequeño de propósito general. Los modelos de menos de 7B (y la mayoría de los modelos generales de 7B–13B sin fine-tuning de tool calling) emiten tool calls malformados. Usa un modelo de 27B+ afinado para tool calling y deja de pelear con el harness.
• Error 2: poner tu directorio home en la allow-list. Las allow-lists de ~ "solo para pruebas" sobreviven hasta el uso rutinario. Crea un agent-workspace dedicado desde el principio.
• Error 3: dejar el servidor de base de datos en modo lectura/escritura. Una consulta DELETE redactada por un agente seguro de sí mismo sobre una tabla real es exactamente el incidente que esto evita. Haz de agent_ro tu rol por defecto; configura un rol escribible separado solo para las tareas que explícitamente lo necesiten y solo durante esas tareas.
• Error 4: aprobar automáticamente cada herramienta. El botón "aprobar todo" es cómodo y peligroso. Aprueba automáticamente las herramientas de lectura (read_file, list_directory, query); siempre requiere aprobación para las herramientas de escritura/shell/PR.
• Error 5: usar un modelo con contexto de 32K para trabajo de navegador de varios pasos. El contenido de la página es grande; un agente que navega tres páginas puede agotar los 32K tokens antes de razonar. Usa un modelo con contexto de 128K para tareas intensivas en el navegador.
• Error 6: asumir que el agente tiene criterio. No lo tiene. El modelo no tiene concepto de "esta es la base de datos de producción" o "este PR va a desplegarse". Los permisos son tu única barrera.
• Error 7: instalar todos los servidores de referencia desde el principio. Más herramientas = prompt de sistema más grande = selección de herramientas más lenta y menos fiable. Empieza con filesystem. Añade los demás solo cuando tengas un flujo de trabajo que los necesite.
• Error 8: instalar servidores de referencia archivados de tutoriales antiguos. Los paquetes npm @modelcontextprotocol/server-postgres, -puppeteer y -github figuran como "no longer supported" y el servidor de SQLite está archivado. Algunas guías antiguas también nombran paquetes npm que no existen (server-sqlite, server-playwright). Usa los servidores mantenidos indicados arriba.
• Error 9: poner la configuración de MCP en Ollama. Ollama no tiene ajustes de MCP. Los servidores se configuran en el cliente (extensions en Goose, los ajustes de MCP de Cline o Continue.dev).

Fuentes

• Especificación de Model Context Protocol — Especificación oficial, esquema JSON-RPC, definiciones de transporte y ciclo de vida, incluido el changelog de 2026-07-28.
• Repositorio GitHub modelcontextprotocol/servers — Los servidores de referencia mantenidos (filesystem, git, fetch, memory y otros) y la lista de servidores archivados.
• github/github-mcp-server — Servidor MCP oficial de GitHub, configuración con Docker y binario.
• microsoft/playwright-mcp — Servidor MCP de Playwright y sus herramientas de navegador.
• crystaldba/postgres-mcp — Servidor MCP de Postgres con modo de acceso restringido (solo lectura).
• Documentación de Goose — Instalación del CLI, configuración del proveedor Ollama, sintaxis de configuración de extensiones (servidores MCP).
• Biblioteca de modelos Ollama — Modelos locales disponibles, indicadores de soporte de tool calling y niveles de cuantización referenciados en esta guía.
• Repositorio GitHub de Cline — Implementación del cliente MCP para VS Code, panel de servidores MCP.
• Documentación de Continue.dev — Referencia del bloque de configuración mcpServers para el cliente Continue.dev.

Preguntas frecuentes

Lecturas relacionadas

• Mejores modelos locales para tool calling en 2026 — benchmarks comparativos para los modelos recomendados arriba (Gemma 4, GLM-4.7, Qwen3, Llama 3.3).
• Los agentes locales autónomos realmente funcionan — una verificación de la realidad sobre lo que un agente MCP local puede y no puede hacer de forma fiable en una tarea de larga duración.
• Continue.dev vs Cline vs Aider: el mejor agente de código local en 2026 — contexto de agente adyacente para trabajo orientado al código; Cline y Continue.dev también son clientes MCP.
• Mejores LLMs locales en 2026 — referencia de modelos para el panorama más amplio de pesos abiertos.
• Reemplaza Zapier con agentes de IA locales — marco de automatización de flujos de trabajo para el mismo stack MCP.
• Hub de Power Local LLM — biblioteca completa de guías.