Herramientas Mastra vs MCP: ¿Cuál Debería Usar tu Agente?

Si construyes agentes con Mastra, te topas pronto con esta decisión: escribir una herramienta nativa con createTool, o conectar un servidor MCP y repartir sus herramientas al agente.

Para el modelo se ven igual: “llama a la herramienta X con estos argumentos”. Las operaciones y el coste, no. Lo aprendí por las malas cuando una integración MCP de WordPress se sentó junto a mi proceso de Mastra y consumió silenciosamente unos 200 MB de RAM siempre activa, solo para que el agente pudiera gestionar entradas.

Este artículo es la división práctica: qué es cada camino, cómo funcionan, cuándo merece la pena MCP y cuándo gana una herramienta Mastra ligera.

¿Nuevo en alguno de los dos lados? Empieza con Crea un agente de IA con Mastra y MCP para principiantes.

Lo que realmente estás eligiendo

Misma experiencia de agente. Factura de ejecución distinta.

Cómo funcionan las herramientas de Mastra

Una herramienta nativa es una función tipada con una descripción que el modelo puede leer. Mastra usa Zod para las entradas (y salidas opcionales). La ejecución permanece dentro de tu servidor.

import { createTool } from "@mastra/core/tools";
import { z } from "zod";

export const discordNotify = createTool({
  id: "discord-notify",
  description: "Post a short status message to a Discord webhook channel.",
  inputSchema: z.object({
    title: z.string(),
    body: z.string(),
    level: z.enum(["info", "success", "error"]).default("info"),
  }),
  execute: async ({ context }) => {
    // fetch webhook, return { ok: true } / error
    return { ok: true, title: context.title };
  },
});

Regístrala en el agente:

export const assistant = new Agent({
  id: "assistant",
  name: "Assistant",
  // ...
  tools: {
    discordNotify,
    // tinyfishSearch, postTweet, queryDatabase, ...
  },
});

Por qué es la opción por defecto para agentes en producción

En una app Mastra real terminas con una carpeta de herramientas: búsqueda web, metadatos de YouTube, GitHub, Discord, X/Bluesky, helpers de consulta a la BD, generación de imágenes, etc. Esa es la superficie central. Mantenla nativa.

Cómo funcionan las herramientas MCP en Mastra

MCP (Model Context Protocol) es un estándar para que un host (Mastra) pueda hablar con servidores que exponen herramientas, recursos y prompts. El cliente @mastra/mcp de Mastra puede lanzar un servidor stdio y cargar sus herramientas:

import { MCPClient } from "@mastra/mcp";

const mcpClient = new MCPClient({
  id: "mcp-client",
  servers: {
    sureDash: {
      command: "npx",
      args: ["-y", "@automattic/mcp-wordpress-remote@latest"],
      env: {
        WP_API_URL: process.env.WP_API_URL!,
        WP_API_USERNAME: process.env.WP_API_USERNAME!,
        WP_API_PASSWORD: process.env.WP_API_PASSWORD!,
      },
    },
  },
});

const mcpTools = await mcpClient.listTools();

// Same agent shape as native tools:
// tools: { ...nativeTools, ...mcpTools }

Qué se ejecuta realmente

Para un servidor MCP stdio lanzado con npx, el árbol de procesos suele verse así:

mastra node (your app + MCP client)
  └── npm exec / npx          ← often stays alive (~100+ MB)
        └── mcp server node   ← second V8 runtime (~80–100+ MB)
              └── remote API (WordPress, GitHub, …)

El modelo nunca ve eso. Solo ve nombres de herramientas y esquemas. Tú pagas los procesos extra mientras el host de Mastra esté arriba, especialmente si haces listTools() en la importación del módulo y mantienes la conexión abierta.

Por qué MCP sigue existiendo (y es útil)

• Los proveedores entregan paquetes completos de herramientas (entradas, páginas, medios, taxonomías) sin que escribas cada endpoint
• Un protocolo, muchos hosts: el mismo servidor puede funcionar con Claude Desktop, Cursor, Mastra y otros
• Integraciones opcionales: genial cuando necesitas WordPress la semana que viene, no en cada despliegue

MCP no son herramientas peores. Es capacidad alquilada con un impuesto de proceso y protocolo.

Cifras reales de memoria (por qué me importa)

En un servicio Mastra de producción de larga duración medí aproximadamente:

Solo ese camino de WordPress eran unos 200 MB siempre activos, antes de cualquier llamada del agente. El pico de memoria del servicio rondaba 1 GB. Tras desactivar MCP con un feature flag, el mismo servicio se estabilizó más cerca de ~450 MB solo con el proceso Node principal.

Eso no es una fuga de WordPress. Es:

1. Un segundo servidor Node para MCP stdio
2. Un padre npx que no desaparece
3. Un paquete proxy pesado (SDK de MCP, stack tipo Express, agentes de proxy, a veces QuickJS para PAC)
4. Carga anticipada al arrancar para que las herramientas existan en cada sesión de chat

El disco para la caché de npx de ese paquete era del orden de decenas de MB. La RAM es la parte cara en un VPS pequeño.

Comparación de arquitectura

Native Mastra tool
─────────────────
User → Agent → createTool.execute() → your API/SDK → result
                 (same process)

MCP tool
────────
User → Agent → MCP client → stdio/HTTP → MCP server process → remote API → result
                 (your process)          (another process)

La latencia suele ir bien en ambos casos para el chat humano. El coste en reposo y los modos de fallo no son iguales. MCP añade fallos de arranque (npx, variables de entorno ausentes, 401 remotos) y un proceso que debes monitorizar.

MCP detrás de un feature flag (recomendado)

No dejes servidores MCP opcionales cableados a “credenciales presentes = siempre activo”. Guarda las credenciales en .env y ponles puerta con un flag explícito:

function envFlag(name: string, defaultEnabled = false): boolean {
  const raw = process.env[name]?.trim().toLowerCase();
  if (raw === undefined || raw === "") return defaultEnabled;
  return raw !== "false" && raw !== "0" && raw !== "off" && raw !== "no";
}

const enableWordpressMcp = envFlag("ENABLE_WORDPRESS_MCP", false);
const hasWpCreds = Boolean(
  process.env.WP_API_URL &&
    process.env.WP_API_USERNAME &&
    process.env.WP_API_PASSWORD,
);

if (enableWordpressMcp && hasWpCreds) {
  // MCPClient + listTools()
} else {
  // log and skip; credentials can stay for later
}

# .env
ENABLE_WORDPRESS_MCP=false
WP_API_URL=https://example.com/wp-json/...
WP_API_USERNAME=...
WP_API_PASSWORD=...

Actívalo solo cuando necesites las herramientas, recompila si usas un bundle de producción y reinicia el servicio. El mismo patrón funciona para cualquier servidor MCP pesado.

Cuándo usar herramientas Mastra vs MCP

Prefiere herramientas Mastra cuando

• La capacidad es central para el producto (búsqueda, notificaciones, publicación, BD, TTS, imágenes)
• Necesitas aprobación, dry-run o logging estricto
• La herramienta corre en un schedule o workflow sin UI de chat
• Corres en un VPS pequeño y te importa la RAM en reposo
• Solo necesitas 2–3 endpoints de una API de proveedor enorme

Prefiere MCP cuando

• Un proveedor ya entrega un servidor sólido y necesitas muchas herramientas raramente
• Quieres el mismo servidor en Cursor y en tu app Mastra
• La integración es opcional y puede quedarse detrás de un flag
• Aceptas el impuesto de proceso a cambio de llegar antes a las herramientas

Un enfoque híbrido que funciona bien

Ejemplo: si solo creas y actualizas entradas, una herramienta Mastra de 40 líneas contra la REST API de WP le ganará a un proceso MCP de WordPress permanente todos los días de la semana.

Un MCP más ligero si decides mantenerlo

Si MCP se queda en el stack:

1. Evita npx de larga duración. Instala el paquete y apunta command al binario real o a node path/to/proxy.js
2. Fija versiones. No uses @latest en cada arranque
3. No cargues en la importación a menos que cada petición necesite esas herramientas (un cliente perezoso es más difícil si los agentes necesitan un mapa de herramientas estático, pero merece la pena diseñarlo así)
4. Limita la memoria del servicio en systemd (MemoryHigh / MemoryMax) para que un servidor desbocado no se lleve la máquina
5. Monitoriza los procesos hijos con systemctl status / ps --forest para ver los nodos de npx + MCP

Hoja de trucos para decidir

Preguntas frecuentes

Conclusión

Las herramientas Mastra son tu contrato en proceso: rápidas, baratas, amigables con aprobaciones y listas para workflows. Las herramientas MCP son una forma estándar de alquilar la superficie de herramientas de otro. Potentes, pero los servidores stdio (especialmente vía npx) cuestan RAM real y atención operativa.

La regla que uso ahora:

• Capacidades centrales del agente → herramientas Mastra nativas
• Paquetes opcionales de proveedores → MCP detrás de un feature flag
• Si un servidor MCP se vuelve crítico a diario → promueve el camino caliente a herramientas nativas

Esa división mantuvo la superficie del agente rica sin pagar ~200 MB para siempre por herramientas de WordPress que no estaba usando activamente.