Model Context Protocol (MCP) explicado para founders SaaS

16 de Mayo del 20268 minIA, MCP, Anthropic, Arquitectura, SaaS

Respuesta corta (60 segundos): Model Context Protocol (MCP) es un estándar abierto introducido por Anthropic en noviembre 2024 para conectar asistentes de IA a herramientas externas. En 2026 ya lo soportan Claude Desktop, OpenAI, Google, y decenas de SaaS B2B. Para un founder SaaS, MCP importa por una razón: si tu cliente puede conectar tu producto a su asistente de IA con un click, tu SaaS gana un canal nuevo de uso. Pero solo si tu API ya es estable y tenés demanda concreta. Adoptar MCP por hype sin caso de uso es Q4.

MCP es uno de esos términos que en 2026 está apareciendo en cada conferencia y newsletter técnica, sin que la mayoría de founders sepan exactamente qué implica para su SaaS. Este post intenta resolverlo sin hype y sin tecnicismos que no agregan claridad.

Lo escribo desde la posición práctica: en proyectos de consultoría veo founders preguntando "¿debería implementar MCP?" sin saber bien qué están considerando. La respuesta correcta casi nunca es "sí" o "no" — es "depende de qué problema querés resolver".

Qué es MCP, en términos concretos

Imaginá que tu cliente usa Claude Desktop o un agente propio para automatizar tareas. Hoy, para que ese cliente conecte tu SaaS a su asistente, tenés que:

• Construir una integración custom para cada asistente que quiera consumir tu API.
• Que tu cliente programe o configure cada conexión manualmente.
• Mantener N integraciones para N asistentes diferentes.

Con MCP: vos implementás un MCP server que expone tu funcionalidad. Cualquier asistente de IA que soporte MCP (Claude Desktop, ChatGPT, Cursor, agentes custom) puede conectarse al servidor con configuración mínima del usuario final. Una integración, muchos consumidores.

Es básicamente lo que USB fue para los periféricos: un estándar que reemplaza N conectores propietarios por uno solo.

Por qué importa específicamente para SaaS

Tres razones que veo en proyectos LATAM:

1 · Canal de uso emergente: el asistente de tu cliente

Cada vez más usuarios técnicos usan Claude Desktop, ChatGPT Plus, o Cursor como interfaz principal para trabajar. Si tu SaaS solo es accesible vía tu UI propia, perdés mindshare en ese canal.

Ejemplo concreto: un SaaS de gestión de proyectos. Sin MCP, el usuario sale de Claude, va al SaaS, busca el dato, vuelve a Claude. Con MCP, el usuario le dice a Claude "buscá las tareas asignadas a Juan que vencen esta semana", Claude llama al MCP server del SaaS, y devuelve la info dentro de la misma conversación.

2 · Diferenciación competitiva temporal

En 2026, exponer un MCP server todavía no es estándar en SaaS B2B. Los que llegan primero ganan: aparecen primero en "integraciones para Claude Desktop", se mencionan en posts de la comunidad, atraen developer usuarios.

Esta ventana se cierra. Para 2027-2028, MCP probablemente sea expectativa básica como hoy lo es tener una API REST.

3 · Reduce costo de mantenimiento de integraciones

Si tu producto ya integra con LLMs vía API custom (function calling, plugins, copilots), MCP te permite consolidar esas integraciones detrás del mismo servidor.

Caso típico: un SaaS construye un copilot interno con OpenAI. Después un cliente enterprise pide integración con su Claude on AWS Bedrock. Después aparece la oportunidad de un plugin para ChatGPT. Tres integraciones, tres mantenimientos. Con MCP, una sola superficie.

Cómo funciona técnicamente (versión corta)

Un MCP server es un proceso que expone:

1. Resources — lecturas (ej: "el contenido del documento X", "la lista de proyectos del usuario Y").
2. Tools — escrituras / acciones (ej: "crear una tarea", "enviar un email", "ejecutar una query").
3. Prompts — templates de prompts reusables para casos comunes.

La comunicación es JSON-RPC sobre stdio, SSE o HTTP. El asistente de IA (cliente MCP) descubre qué resources/tools/prompts ofrece el server, autentica si es necesario, e invoca cuando el LLM lo decide.

Ejemplo simplificado de un MCP server en Python:

~
from mcp.server import Server
from mcp.types import Tool, TextContent

server = Server("my-saas-mcp")

@server.list_tools()
async def list_tools() -> list[Tool]:
  return [
      Tool(
          name="search_projects",
          description="Search projects by query string",
          inputSchema={
              "type": "object",
              "properties": {
                  "query": {"type": "string"},
                  "limit": {"type": "number", "default": 10},
              },
              "required": ["query"],
          },
      ),
  ]

@server.call_tool()
async def call_tool(name: str, arguments: dict) -> list[TextContent]:
  if name == "search_projects":
      results = await search_projects_in_db(arguments["query"], arguments.get("limit", 10))
      return [TextContent(type="text", text=str(results))]

El usuario configura Claude Desktop o el cliente MCP con la URL del server y credenciales. A partir de ahí, cuando el LLM detecta que "buscar proyectos" es relevante, invoca la tool.

Cuándo conviene adoptarlo

Decisión usando el framework de 4 cuadrantes:

Q1 — Alto impacto, bajo esfuerzo (hacelo ya):

• Tu SaaS ya tiene API pública estable, REST o GraphQL.
• Tenés clientes técnicos (developers, data analysts) que usan asistentes de IA.
• Identificás 3-5 endpoints que serían útiles desde Claude/ChatGPT.
• Estimado: 4-7 días dev para exponerlos vía MCP. ROI esperado: nuevo canal de adopción + marketing diferenciador.

Q2 — Alto impacto, alto esfuerzo (planeá deliberadamente):

• Querés que múltiples agentes de cliente puedan conectarse a tu SaaS con multi-tenancy.
• Requiere auth, rate limiting, observabilidad de uso por cliente.
• Estimado: 2-4 semanas dev. Considerá una fase 1 de Q1 antes.

Q3 — Bajo impacto, bajo esfuerzo (oportunista):

• Exponer 1-2 endpoints triviales internamente para que el equipo experimente.
• No prioridad pero buena fase de aprendizaje del equipo.

Q4 — Bajo impacto, alto esfuerzo (no hacelo):

• Tu API pública aún no es estable y se rompe seguido.
• No tenés clientes pidiendo integración con asistentes.
• Implementás MCP "porque está de moda" sin caso de uso.

Stack y herramientas en 2026

Para implementar un MCP server, las opciones maduras:

• TypeScript SDK (@modelcontextprotocol/sdk) — el más maduro. Funciona en Node, Bun, Deno. Bueno para SaaS Next.js que ya tienen su backend en TS.
• Python SDK (mcp) — segundo más maduro. Mejor cuando ya tenés código Python (data pipelines, ML, FastAPI).
• Cloudflare Workers MCP — para SaaS en edge. Más nuevo, comunidad creciendo.

Hosting recomendado:

• Para SaaS B2B con multi-tenancy: servidor dedicado (Fly.io, Railway, Modal) — USD 10-50/mes.
• Para servers livianos: Cloudflare Workers o Vercel Edge — pricing por requests, suele ser USD 5-20/mes en startup.

Observabilidad: cualquier MCP server debería loggear quién llamó qué tool, latencia, errores. Misma disciplina que el resto de tu API.

Tres errores comunes en early adoption

1. Exponer endpoints internos sin pensar en seguridad. Los MCP servers se conectan típicamente con API keys o OAuth. Si exponés endpoints que no deberían ser públicos (admin, debug), el LLM va a usarlos cuando le convenga.

2. No documentar bien los tools. El LLM elige qué tool llamar basándose en su descripción. Una descripción ambigua hace que el LLM use la tool equivocada o nunca. Tratá las descriptions como UI: claras, específicas, con ejemplos.

3. Implementar resources/tools que copian la API existente sin pensar en cómo se usan desde un LLM. Tu API REST está diseñada para devs; los tools MCP están diseñados para que un LLM las elija. Re-pensá los endpoints en términos de "qué quiere lograr el usuario", no "qué expone mi base de datos".

Mi recomendación práctica

Si tu SaaS B2B tiene una API pública estable y al menos 10% de tus usuarios son developers/data folks usando asistentes de IA: implementá un MCP server liviano en 1 semana que exponga los 3-5 endpoints más útiles. Eso te pone en la conversación temprana y te permite aprender en vivo.

Si tu SaaS aún no tiene API pública, o tus usuarios no usan asistentes externos, MCP no es tu prioridad. Hay otros 5-10 procesos de IA que pagarían mejor el esfuerzo.

Hablemos de tu caso

Si estás evaluando si MCP tiene sentido para tu SaaS o querés un sanity check sobre el ROI de implementarlo, reservá una llamada de 30 minutos sin costo. En 20 minutos suele ser suficiente para identificar si tu caso es Q1, Q2 o Q4 — y darte una recomendación específica antes de que dediques semanas a la decisión.

Leer también:

• Tutorial LangGraph: agente multi-paso — agentes que pueden consumir MCP servers como tools.
• Qué procesos automatizar primero (4 cuadrantes) — framework para decidir si MCP es Q1 o Q4 en tu caso.
• Cuánto cuesta implementar IA en una startup SaaS — referencias de costos.
• Más artículos sobre IA — guías y comparativas.
• Volver al blog — todos los artículos.