Conecta Ollama a bases de datos y APIs con MCP: configuración de agentes locales 2026

Datos rápidos

• Protocolo: JSON-RPC 2.0 sobre stdio (subproceso local) o HTTP/SSE (remoto). Los agentes locales usan casi exclusivamente stdio.
• Mantenido por: Anthropic (especificación de código abierto); servidores de referencia mantenidos en modelcontextprotocol/servers en GitHub más un ecosistema de terceros en crecimiento.
• Clientes locales en 2026: Goose (Block), 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. En mayo de 2026: Gemma 4 27B, GLM-5.1 32B, Qwen3 32B, Qwen3-Coder 30B, Llama 3.3 70B.
• Transporte por defecto: stdio para procesos locales; HTTP/SSE solo cuando necesitas compartir un servidor entre máquinas o agentes.
• La configuración vive en un único archivo: ~/.config/goose/config.yaml (Goose), el bloque MCP de ~/.continue/config.json (Continue.dev) o mcpServers en la interfaz de configuración de Cline. La misma estructura en todos: nombre del servidor, comando, args, variables de entorno.
• No se necesita Claude Desktop. El protocolo es anterior a las historias de exclusividad de Claude Desktop; todos los servidores de referencia tienen licencia MIT/Apache 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 puppeteer controla un navegador sin cabeza, 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."** — el servidor sqlite consulta; 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, sqlite.query, puppeteer.navigate. 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 27B (gemma4:27b), GLM-5.1 32B (glm5:32b), Qwen3 32B (qwen3:32b) o Llama 3.3 70B (llama3.3:70b). 16 GB de memoria unificada o 12 GB de VRAM manejan cómodamente 27B–32B en Q4_K_M.
• Paso 3 — instala Goose. pipx install goose-ai (macOS, Linux) o descarga el instalador desde la página de releases de Goose. 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. Goose escribe esto en ~/.config/goose/config.yaml.
• Paso 5 — añade el servidor MCP de filesystem. Edita ~/.config/goose/config.yaml para agregar un bloque mcpServers (ejemplo de configuración a continuación). Reinicia 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:27b

# 2. Install Goose
pipx install goose-ai

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

# 4. Start a session — Goose reads ~/.config/goose/config.yaml
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 necesaria). Goose, Cline y Continue.dev lo inician automáticamente desde el bloque de 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
mcpServers:
  filesystem:
    command: npx
    args:
      - "-y"
      - "@modelcontextprotocol/server-filesystem"
      - "/Users/you/agent-workspace"
    env: {}

Servidores SQLite y Postgres: consultar datos reales

• **Servidor SQLite (@modelcontextprotocol/server-sqlite)** toma una ruta a un archivo .db. Útil para análisis de logs, prototipado de esquemas y exploración de exports sin necesidad de levantar una base de datos.
• **Servidor Postgres (@modelcontextprotocol/server-postgres)** toma una cadena de conexión. El patrón recomendado es crear un rol de solo lectura dedicado para el agente y usar la cadena de conexión de ese rol.
• Herramientas expuestas: query (solo SELECT cuando está configurado como solo lectura), list_tables, describe_table. El servidor Postgres añade list_schemas. Algunos forks añaden write_query — mantenlo deshabilitado a menos que confíes en el modelo con esta base de datos.
• 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 llamado a describe_table 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
mcpServers:
  sqlite:
    command: npx
    args:
      - "-y"
      - "@modelcontextprotocol/server-sqlite"
      - "--db-path"
      - "/Users/you/data/events.db"
    env: {}

  postgres:
    command: npx
    args:
      - "-y"
      - "@modelcontextprotocol/server-postgres"
      - "postgresql://agent_ro@127.0.0.1:5432/analytics"
    env:
      PGPASSWORD: "${PG_AGENT_PASSWORD}"

Servidor de navegador: controlar Chromium con Puppeteer o Playwright

• Servidores de referencia: @modelcontextprotocol/server-puppeteer (más ligero, sin cabeza por defecto) y @modelcontextprotocol/server-playwright (más pesado, soporta múltiples navegadores). Para agentes locales, Puppeteer es suficiente.
• Herramientas expuestas: navigate, screenshot, click, fill, select, evaluate (ejecutar JavaScript), get_page_content. El modelo usa get_page_content para leer texto estructurado y screenshot para confirmar visualmente.
• 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+.
• Selectores: el modelo tiene que elegir los selectores CSS. 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
mcpServers:
  puppeteer:
    command: npx
    args:
      - "-y"
      - "@modelcontextprotocol/server-puppeteer"
    env:
      PUPPETEER_HEADLESS: "true"
      # 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: @modelcontextprotocol/server-github, ejecutado con un PAT en la variable de entorno GITHUB_PERSONAL_ACCESS_TOKEN. El token es la única autenticación — el servidor en sí no tiene configuración separada.
• 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 docenas adicionales. 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
mcpServers:
  github:
    command: npx
    args:
      - "-y"
      - "@modelcontextprotocol/server-github"
    env:
      GITHUB_PERSONAL_ACCESS_TOKEN: "${GH_AGENT_PAT}"
      # 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 27B (gemma4:27b)** — 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-5.1 32B (glm5:32b)** — 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 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.

Fuentes

• Especificación de Model Context Protocol — Especificación oficial, esquema JSON-RPC, definiciones de transporte y ciclo de vida.
• Repositorio GitHub modelcontextprotocol/servers — Servidores de referencia (filesystem, sqlite, postgres, github, puppeteer, etc.) y su documentación de configuración.
• Documentación del proyecto Goose — Instalación del CLI, configuración del proveedor Ollama, sintaxis de configuración de 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.

FAQ

Lecturas relacionadas

• Mejores modelos locales para tool calling en 2026 — benchmarks comparativos para los modelos recomendados arriba (Gemma 4, GLM-5.1, 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.