MCP, API o CLI: cuál usar para que Claude Code trabaje por ti
Las tres formas de que Claude Code toque tus herramientas, la regla de tres preguntas para elegir y cómo decirle qué modelo usar en cada tarea que delega.
Descargar el PDF207 KBEn esta página · 6 partes
Cuando empiezas a programar con IA, todo el mundo te recomienda conectar algo nuevo. Al mes tienes muchos servidores conectados y ya no sabes cuál hace qué. El problema es que MCP, API y CLI no son tres nombres para lo mismo: son tres caminos distintos para que Claude llegue a tus herramientas, y cada uno tiene su lugar.
Las tres, en una tabla
| Qué es | Cuándo brilla | Lo que cuesta | |
|---|---|---|---|
| API | El contrato entre dos programas: si me mandas esto, te devuelvo aquello. | Cuando construyes un producto que tiene que funcionar solo, sin ti ni la IA en medio. | Alguien tiene que escribir y mantener el código que la llama. |
| CLI | Un programa que manejas con comandos en la terminal, como gh (GitHub), vercel o railway. | Cuando existe una CLI buena para ese servicio. Claude Code vive en la terminal: es su idioma nativo. | Casi nada. Necesitas tenerla instalada y con sesión iniciada. |
| MCP | Un estándar abierto para conectar herramientas a una IA. Un servidor le cuenta a Claude qué puede hacer y cómo. | Cuando no hay CLI, cuando el servicio necesita tu cuenta (correo, calendario) o cuando quieres manejar un sistema tuyo con palabras. | Cada servidor es una puerta más abierta, con tus accesos. |
Por debajo, casi todo termina llamando a una API. La CLI y el MCP son dos formas distintas de que Claude llegue a ella.
Por qué la CLI suele ganar en Claude Code
Claude Code trabaja en tu terminal, así que una CLI no necesita nada extra: ya conoce los comandos, los puede encadenar uno detrás de otro y lee solo la respuesta que necesita. Por ejemplo, para saber por qué falló un pull request:
gh pr checks # qué revisiones fallaron
gh run view --log-failed # el log de la que falló
Le basta con pedirle: «revisa por qué falló el PR y muéstrame el error». Él elige los comandos.
Cuándo sí conviene un MCP
- El servicio no tiene una CLI buena, o iniciar sesión desde la terminal es un dolor. Gmail, Google Calendar y Drive son el caso típico: conectas una vez con tu cuenta y listo.
- Quieres manejar un sistema tuyo con reglas claras. Si envuelves tu propia API en un servidor MCP, desde ahí le pides las cosas con palabras («reparte los pedidos de hoy») y Claude usa las herramientas que tú definiste.
Para revisar y limpiar lo conectado:
claude mcp list # los servidores configurados
claude mcp remove <nombre> # quitar uno
La regla de tres preguntas
- ¿Existe una CLI buena para ese servicio? Úsala.
- ¿No existe, o necesita tu cuenta? Conecta un MCP.
- ¿Estás construyendo un producto que funciona sin ti? Eso va por API. Y si después quieres manejarlo con IA, le pones un MCP encima.
Delegar: un modelo para cada tarea
Conectar herramientas es la mitad. La otra mitad es a quién le das cada trabajo. Claude Code puede repartir tareas entre subagentes, y cada uno puede usar un modelo distinto:
| Tarea | Modelo que suele bastar |
|---|---|
| Buscar archivos, leer, renombrar, ordenar | haiku (rápido y barato) |
| Implementar lógica, escribir tests | sonnet |
| Decidir arquitectura, revisar seguridad | opus (el más fuerte) |
Si no le indicas un modelo, el subagente hereda el de tu conversación. Si estás usando el más caro, todas las búsquedas de archivos también van al más caro.
Hay tres formas de fijarlo, de más específica a más general:
- En el pedido. Dile a Claude qué modelo usar al delegar: «lanza un agente con
haikupara buscar dónde se valida el correo». - En la definición del subagente. Un archivo en
.claude/agents/(del proyecto) o~/.claude/agents/(tuyo) con el campomodel:
---
name: buscador
description: Busca y lee archivos del proyecto. Úsalo para encontrar dónde vive algo.
model: haiku
---
Busca en el código lo que te pidan y devuelve solo las rutas y un resumen corto.
- Por defecto para todos. La variable de entorno
CLAUDE_CODE_SUBAGENT_MODEL(por ejemplosonnet) fija el modelo de los subagentes que no traen uno propio.
Si prefieres que Claude te lo arme, copia este prompt:
Revisa qué servidores MCP tengo conectados (claude mcp list) y qué CLI tengo instaladas. Para cada servicio, dime si conviene usar la CLI o el MCP y por qué. Después créame tres subagentes en .claude/agents/: uno con model: haiku para buscar archivos, uno con model: sonnet para implementar y uno con model: opus para revisar decisiones de arquitectura.
En tres líneas
- La API es el contrato entre programas, la CLI es la herramienta que Claude Code ya sabe usar y el MCP es el enchufe para lo que no tiene CLI.
- Regla práctica: CLI si existe una buena, MCP si no hay o necesita tu cuenta, API si es tu producto.
- Cada tarea, al modelo que le corresponde: si no lo indicas, el subagente usa el mismo que tú.