MCP para herramientas locales
MCP es útil cuando el agente necesita contexto y herramientas reales, pero cada tool local es una puerta. Empieza por lectura, allowlists y trazas antes de exponer comandos o escritura.
Objetivos de aprendizaje
- Diseñar tools pequeñas, auditables y con permisos mínimos.
- Separar lectura, búsqueda, escritura y ejecución.
- Crear un contrato claro para aprobar acciones peligrosas.
En cristiano: tool MCP. Es una función que un servidor MCP ofrece al agente: buscar archivos, consultar una base de datos, leer documentación o ejecutar una acción acotada.
Terminal
tools:
search_notes:
mode: read
allowed_paths: ["./docs", "./notes"]
max_results: 10
read_file:
mode: read
allowed_extensions: [".md", ".txt", ".json"]
max_bytes: 20000
run_check:
mode: execute
allowed_commands:
- "npm run lint"
- "npm test"
requires_human_approval: false
delete_file:
enabled: false Idea clave. La primera versión de un MCP interno debería leer y verificar, no modificar. La escritura llega después de tener logs y revisión humana.
Diseño por riesgo
- Riesgo bajo: buscar, leer, listar, resumir.
- Riesgo medio: crear borradores, escribir en carpeta temporal.
- Riesgo alto: borrar, publicar, enviar, cobrar, tocar producción.
Cuidado. No expongas una shell genérica como tool “porque es cómodo”. Si el agente puede ejecutar cualquier comando, el control ya no está en el prompt.
Terminal
trace:
task_id: "agent-2026-07-05-001"
tool: "read_file"
args:
path: "docs/precios.md"
decision: "allowed"
reason: "extension .md, path inside ./docs"
bytes_returned: 4821 Comprueba que funciona. Intenta acceder a `../.env`, borrar un archivo y ejecutar `curl`. Un MCP local bien diseñado debe rechazar esas acciones por diseño, no por buena voluntad del modelo.
Guardar y reabrir el proyecto.
MCP bien usado no da más poder al agente: le da poder más estrecho, observable y reversible.