\confidence{0}

#Prólogo

En noviembre de 2024, Anthropic liberó como código abierto un pequeño protocol con un enfoque modesto: una forma limpia basada en JSON-RPC para conectar AI assistants a los sistemas donde los datos y el trabajo realmente viven. En diecisiete meses, el Model Context Protocol cruzó el umbral de estándar emergente a predeterminado de la industria. Cada laboratorio de vanguardia ofrece soporte para clientes. El registro público superó los 9.400 servidores. Las descargas de SDK superaron los 97 millones por mes. Forrester predice que el 30 % de los proveedores de aplicaciones empresariales enviarán sus propios MCP servers en 2026.

Esta es la segunda vez en veinte años que un solo protocol ha reconfigurado por completo la forma en que se distribuye el software. La primera fue la REST API, después de que el iPhone convirtiera al JavaScript del lado del cliente en un runtime aceptable. La segunda es MCP, después de que los modelos de lenguaje grandes hicieran del uso estructurado de herramientas el patrón de consumo predeterminado para los servicios de software.

Para un fundador de SaaS en 2026, esta reconfiguración representa tanto la mayor oportunidad única de distribución disponible como el mayor riesgo individual en el modelo de precios. Cada decisión de producto que hayas tomado —precios por asiento, UX centrada en el dashboard, incorporación liderada por ventas, alianzas de integración— se optimizó para compradores humanos que leen pantallas. Los Agent buyers son diferentes. No leen pantallas. No aceptan fricción. Evalúan cada transacción. Prefieren elegir productos con la superficie de protocol más limpia, los precios más transparentes y el menor costo cognitivo por llamada.

Construir un MCP server no es el lanzamiento de una funcionalidad. Es una decisión de canal de distribución con la misma gravedad que el lanzamiento de una app móvil en 2009 o el lanzamiento de una API pública en 2012. Los equipos que lo tratan como tal —dotándolo de personal, gobernándolo, instrumentándolo y monetizándolo— dominarán sus categorías en la economía agent. Los equipos que lo tratan como un entregable de sprint lanzarán un servidor que nadie usa, culparán al protocol y verán cómo un competidor con una ejecución más precisa ocupa su lugar.

Este documento es la guía práctica para tratarlo correctamente. Cubre las ocho decisiones que más importan: arquitectura, diseño de herramientas, autenticación, seguridad, gobernanza, observabilidad, distribución y monetización. Se basa en los despliegues en producción en Block, Stripe, GitHub, Cloudflare, Atlassian, Microsoft y en las docenas de post-mortems y divulgaciones de seguridad que el ecosistema ha generado desde su lanzamiento. Es opinado donde los datos son claros, agnóstico donde no lo son y honesto en ambos casos.

— perea.ai Research

#Resumen Ejecutivo

La tesis. Lanzar un servidor MCP es una decisión de canal de distribución, no una decisión de características. Los equipos de SaaS que publican un servidor MCP de alta calidad en 2026 capturan la cuota de los primeros en moverse en una categoría que se está formando una sola vez y para la próxima década. Los equipos que lanzan un servidor MCP de baja calidad —herramientas generadas automáticamente, autenticación con fugas, sin observabilidad, sin monetización— dañan activamente su posición porque los agents degradan los servidores poco confiables y rara vez los reevalúan.

La evidencia.

• Velocidad de adopción. MCP creció de aproximadamente 100K descargas mensuales del SDK en noviembre de 2024 a 97M en marzo de 2026 —un aumento de 970× en 18 meses. Todos los principales proveedores de IA —Anthropic, OpenAI, Google, Microsoft, Amazon, Block— admiten MCP como cliente. (DigitalApplied; Optijara; Metosys.)
• Preparación empresarial. El 78% de los equipos de IA empresarial reportan al menos un agent respaldado por MCP en producción para el Q1 2026, frente al 31% de doce meses antes. 89% de adopción entre equipos con 250+ ingenieros de IA. (DigitalApplied.)
• Compromiso de los proveedores. Forrester predice que el 30% de los proveedores de aplicaciones empresariales lanzarán sus propios servidores MCP en 2026. Stripe, Block, GitHub, Cloudflare, Atlassian, Microsoft (Dynamics 365 Finance & Operations, Business Central, Fabric), Sentry, Linear, Asana, PayPal, Webflow, Intercom —todos en producción. (Forrester; Cloudflare MCP Demo Day.)
• Brecha de distribución. De aproximadamente 19,000 servidores MCP en el ecosistema público, menos del 5% están monetizados. La brecha entre “existe” y “genera ingresos” es la oportunidad. (Godberry Studios; MCP Hive.)
• Estandarización entre proveedores. Las definiciones de tools escritas para MCP funcionan en Claude, ChatGPT, Gemini, Cursor, Copilot y cualquier otro cliente compatible. El costo de integración que encarecía los despliegues de IA multi-proveedor desaparece en la capa MCP. (DigitalApplied.)

Las ocho decisiones que todo fundador de SaaS debe tomar, en orden.

1. Arquitectura. Stateful (Durable Objects, McpAgent) vs. stateless (createMcpHandler, mcp-handler). Local stdio vs. remote Streamable HTTP. La respuesta correcta depende de si tus tools requieren estado por sesión y de si eres una extensión de aplicación de escritorio o una extensión de SaaS.
2. Diseño de tools. La decisión de mayor apalancamiento. Las descripciones de tools son la UX orientada a agents. Las descripciones deficientes provocan tasas de fallo entre 3 y 4 veces superiores a las de las descripciones bien estructuradas. Las pruebas de Anthropic demuestran que incluir entre 1 y 5 ejemplos realistas por tool eleva la precisión del 72% al 90%.
3. Autenticación. OAuth 2.1 con PKCE obligatorio (S256), Protected Resource Metadata en /.well-known/oauth-protected-resource, Dynamic Client Registration y RFC 8707 resource indicators. Las API keys no son una opción viable para producción.
4. Seguridad. El OWASP MCP Top 10 —tool poisoning, prompt injection, rug-pulls, command injection, scope creep, supply chain— son reales, no teóricos. El CVE-2025-5277 de Stripe (command injection en aws-mcp-server) y la divulgación de Invariant Labs contra el servidor MCP oficial de GitHub son puntos de inflexión.
5. Gobernanza. Aislamiento multi-tenant (proceso por tenant o compartido con namespace), registro de auditoría completo, arquitectura pass-through con zero-data-retention para cumplir con SOC 2 / GDPR / HIPAA, y aplicación de policy-as-code.
6. Observabilidad. mcp-eval, MCPJam, mcpchecker para evaluación. Trazas de OpenTelemetry. Métricas por tool en TPR, FPR, precision, token usage, success rate. Puertas de CI. Sin estos elementos no puedes iterar el ciclo de diseño de tools que determina si los agents realmente eligen tu servidor.
7. Distribución. Primero el MCP Registry oficial, luego PulseMCP / Smithery / Glama / MCP.so / awesome-mcp-servers. Cada uno tiene una audiencia y un flujo de envío diferente. Publica automáticamente vía CI/CD porque el mantenimiento manual no escala.
8. Monetización. Por llamada (FluxA, AgentPay, ATXP, AgenticMarket), suscripción, freemium, basado en resultados. x402 stablecoin o Stripe Machine Payments Protocol para settlement nativo de agents. Los marketplaces suelen quedarse con entre el 10% y el 20% de los ingresos; la facturación self-hosted genera alrededor del 95%, pero requiere ingeniería real.

La matemática del operador. Una primera versión de un servidor MCP de SaaS de alta calidad, desarrollada por un solo ingeniero con el playbook que aparece a continuación, supone dos semanas de trabajo hasta la primera tool en producción, sesenta días hasta contar con autenticación y observabilidad de nivel comercial, y noventa días hasta la monetización. El costo de infraestructura es insignificante (Cloudflare Workers free tier, Vercel free tier). El activo que se compone es real: cada tool call genera datos estructurados de agent-intent que nadie más puede capturar.

#Parte I: Por qué MCP, y por qué ahora

#La velocidad de adopción es sin precedentes

La curva de adopción del Model Context Protocol es la más pronunciada que se ha visto para un protocolo de integración desde la API REST pública. El open-sourcing de Anthropic en noviembre de 2024 comenzó con aproximadamente 100.000 descargas mensuales del SDK. Para marzo de 2026, esa cifra había superado los 97 millones — una expansión de 970× en 16 meses. La curva comparable más cercana es la de npm en 2014-2016. (DigitalApplied; Metosys.)

El crecimiento no está impulsado por la actividad de aficionados. El registro público de servidores MCP alcanzó más de 9.400 entradas a mediados de abril de 2026, en comparación con 6.800 a fines de 2025 y 1.200 al final del Q1 de 2025 — una expansión interanual de 7,8× respecto a la línea base del Q1 de 2025, con un crecimiento mes a mes en el Q1 de 2026 manteniéndose estable en +18%. Entre los equipos de IA empresarial (50 o más profesionales de IA/ML), el 78% reporta al menos un agent respaldado por MCP en producción a partir del Q1 de 2026, frente al 31% un año antes. La cifra para equipos con 250 o más ingenieros de IA es del 89%. (DigitalApplied; Optijara.)

La estandarización entre proveedores es el factor clave. Todos los principales laboratorios — Anthropic, OpenAI, Google DeepMind, Microsoft, Amazon Web Services, Block — se han comprometido o han implementado soporte para MCP. Esto es históricamente raro. Cada generación anterior de protocolos de integración (OAuth 2.0 en la década de 2010, REST a principios de la década de 2010) tomó varios años para alcanzar el nivel de compromiso entre proveedores que MCP logró en doce meses. (DigitalApplied; ModelContextProtocol.io.)

Para un equipo de SaaS, esto significa una sola integración. El servidor MCP que envíes es invocable desde Claude Desktop, Claude Code, ChatGPT, Cursor, Windsurf, VS Code Copilot, GitHub Copilot, Gemini, custom agents construidos sobre el SDK de OpenAI Agents, custom agents construidos sobre el SDK de Anthropic, y cualquier nuevo client que se lance en los próximos 24 meses. El costo de integración que antes requería un adaptador separado para cada proveedor de IA —o, más comúnmente, ninguna integración en absoluto— se reduce a un único contrato JSON-RPC tools/list. (DigitalApplied A2A guide; OpenAI Agents JS docs.)

#El panorama de proveedores está completamente poblado

Las principales plataformas de SaaS ya han lanzado servidores MCP y los tratan como infraestructura de producción, no como experimentos:

• Stripe envía un Agent Toolkit y un Agentic Commerce Suite; el sistema interno de codificación Stripe Minions funciona a través de un servidor MCP de 400 herramientas llamado Toolshed y fusiona más de 1.000 pull requests por semana sin código escrito por humanos (Engineering.fyi Stripe; Medium Valdez Ladd; rywalker Stripe Minions).
• Block ejecuta Goose — el agente de codificación de código abierto bifurcado por Stripe — y construyó más de 100 servidores MCP internos; 12.000 empleados en 15 funciones laborales usan Goose, y el 75% de los ingenieros reportan ahorrar 8-10 horas por semana (All Things Open; engineering blog).
• GitHub lanza un servidor MCP oficial y es uno de los cuatro mantenedores nombrados del Registro MCP oficial (junto con Anthropic, PulseMCP y Microsoft) (modelcontextprotocol.io Registry).
• Cloudflare lanza una flota de más de 14 servidores MCP específicos por dominio — Documentation, Workers Bindings, Workers Builds, Observability, Radar, Browser Rendering, AI Gateway, Audit Logs, DNS Analytics, CASB, GraphQL — además del SDK McpAgent para construir servidores MCP en Workers (cloudflare/mcp-server-cloudflare; Cloudflare Agents docs).
• Microsoft lanza Dynamics 365 ERP MCP, Business Central MCP, Fabric Local MCP (GA), Fabric Remote MCP (preview), Microsoft Learn MCP y el Microsoft MCP Server for Enterprise (preview, Entra/Graph) (Microsoft Learn; Microsoft Fabric Blog).
• Atlassian lanza un Atlassian Remote MCP Server para Jira y Confluence Cloud, alojado en Cloudflare (Cloudflare MCP Demo Day).
• PayPal, Sentry, Linear, Asana, Intercom, Webflow todos lanzaron servidores MCP remotos como parte de la cohorte de mayo de 2025 del MCP Demo Day (Cloudflare MCP Demo Day).

Para un fundador de SaaS, la implicación no es que el campo esté cerrado —es que el estándar se ha cristalizado. Construir un servidor MCP en 2026 ya no es una apuesta sobre si el protocol importará. Es una elección táctica sobre la calidad de la implementación.

#La ventana para una primera versión de alta calidad

Forrester predice que el 30% de los proveedores de aplicaciones empresariales lanzarán sus propios servidores MCP en 2026. Hoy la cifra es aproximadamente del 5% según la mayoría de los conteos. La brecha de 25 puntos porcentuales entre hoy y fin de año es la ventana.

La ventana no es "ser el primero en lanzar algo". Muchos proveedores lanzarán servidores MCP de baja calidad (generados automáticamente desde Swagger, sin auth, descripciones de herramientas vagas, sin observabilidad) y descubrirán inmediatamente que los agents no los recomiendan preferentemente. La ventana es "ser el primero en lanzar un servidor MCP de alta calidad en tu categoría" — uno que maneje casos límite, tenga descripciones claras de herramientas, se lance con OAuth 2.1, exponga métricas de evaluación, se liste en registros e integre con uno de los rails de facturación nativos de agent.

Los equipos que cierran correctamente esta brecha capturan ventajas compuestas: el tráfico mediado por agent genera datos estructurados de agent-intent que nadie más tiene; las tasas de éxito de tool-call se acumulan en un ranking preferencial; la documentación que se indexa en los corpora de entrenamiento de IA se acumula en tasas de citación difíciles de desplazar.

#Parte II: Decisiones de arquitectura

La primera decisión técnica es la forma de implementación. La especificación de MCP (versión actual: 2025-11-25, con versiones estables anteriores 2025-06-18 y 2025-03-26) define dos transportes: stdio para la comunicación con subprocesos locales, y Streamable HTTP para servidores remotos. El transporte HTTP+SSE de la especificación de noviembre de 2024 está obsoleto. (modelcontextprotocol.io transports; Microsoft mcp-for-beginners.)

#stdio vs. Streamable HTTP

Para SaaS, la respuesta es casi siempre Streamable HTTP. stdio es apropiado cuando tu "server" es una herramienta CLI ya distribuida a los desarrolladores (Filesystem, Git, GitHub CLI), o cuando el contexto de ejecución controlado por el usuario lo requiere (modelo local-first de Claude Desktop). Cualquier cosa que envuelva tu API SaaS alojada debe ser Streamable HTTP, alojada en una URL pública. (modelcontextprotocol.io transports; OpenAI Agents JS docs.)

Un detalle pequeño pero importante: el servidor Streamable HTTP debe exponer un único endpoint que admita tanto POST (para mensajes de cliente a servidor) como GET (para flujos SSE) en la misma ruta. Los servidores DEBEN validar el encabezado Origin para prevenir ataques de DNS rebinding. Al ejecutarse localmente, los servidores DEBERÍAN enlazarse solo a 127.0.0.1, no a 0.0.0.0. (modelcontextprotocol.io transports; Toolradar deploy.)

#Con estado vs. sin estado

Para Streamable HTTP, la segunda decisión de arquitectura es si tu servidor mantiene estado por sesión.

Sin estado (punto de partida recomendado para la mayoría de las SaaS).

• Usa createMcpHandler (Cloudflare Agents SDK) o mcp-handler (Vercel) en Cloudflare Workers, Vercel Functions, AWS Lambda o cualquier runtime serverless estándar.
• Se crea una nueva instancia del servidor MCP por solicitud.
• Toda la autenticación y autorización proviene del bearer token; las herramientas llaman a tu API REST existente para el estado.
• Más simple de operar. Sin errores de gestión de sesiones. Escala horizontalmente sin coordinación.

Con estado (úsalo cuando las herramientas realmente requieran contexto por sesión).

• Usa McpAgent (Cloudflare, respaldado por Durable Objects) para estado integrado, SQL, elicitación e hibernación de WebSocket, o implementa tu propia gestión de sesiones con sesiones respaldadas por Redis.
• Cada sesión de usuario obtiene su propia instancia respaldada por SQL con estado persistente.
• Las herramientas pueden llamar a setState, reaccionar a onStateChanged, ejecutar SQL en una base de datos integrada y solicitar entrada elicitada del usuario a mitad de la llamada.
• Habilita herramientas conversacionales (formularios de varios turnos, estado de asistente en progreso, contexto que sobrevive a través de las llamadas).
• Operativamente más pesado: se aplica el precio de Durable Objects y el ciclo de vida de la sesión requiere lógica de limpieza explícita.

El SDK de Cloudflare Agents incluye ambos patrones uno al lado del otro y es la implementación de referencia más limpia para cualquiera de ellos. La clase McpAgent extiende Agent, expone state, setState, onStateChanged, sql, props (para la identidad OAuth) y elicitInput para human-in-the-loop, y viene con McpAgent.serve(path) para un despliegue de una línea con ambos transportes Streamable HTTP y SSE heredados. (Cloudflare McpAgent docs; Cloudflare skills mcp.md; PropelAuth Cloudflare guide.)

Para implementaciones en Vercel, el stack equivalente es mcp-handler (anteriormente @vercel/mcp-adapter) con Vercel Functions en Fluid Compute. Los clientes reportan ahorros de más del 90% en comparación con el serverless tradicional en Vercel para cargas de trabajo MCP porque Fluid maneja el patrón de largo inactivo-luego-ráfaga característico del tráfico MCP. (Vercel MCP server support; Vercel deploy MCP docs.)

#El esqueleto de 14 líneas

Las decisiones de arquitectura anteriores se reducen a una pequeña cantidad de código. Un servidor MCP Streamable HTTP sin estado completo en Cloudflare Workers, con una herramienta real, tiene aproximadamente 14 líneas:

import { createMcpHandler } from "agents/mcp";
import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { z } from "zod";

const server = new McpServer({ name: "my-server", version: "1.0.0" });
server.registerTool("get_status", {
  description: "Check the status of a service. Returns uptime, version, and last-incident timestamp.",
  inputSchema: { service: z.string() },
}, async ({ service }) => {
  const data = await fetch(`https://api.example.com/status/${service}`).then(r => r.json());
  return { content: [{ type: "text", text: JSON.stringify(data) }] };
});

export default { fetch: (req, env, ctx) => createMcpHandler(server)(req, env, ctx) };

El equivalente en Vercel como un archivo Next.js App Router es similar en longitud. El esqueleto no es la parte difícil; la parte difícil es lo que viene después.

#Parte III: El playbook de diseño de herramientas

La capa de diseño de herramientas es donde fallan la mayoría de los servidores MCP. La autenticación se resuelve principalmente con bibliotecas. La distribución se resuelve principalmente con registros. Pero el diseño de herramientas —las palabras que utilizas, los esquemas que envías, los modos de falla que manejas— es donde el modelo decide si invocar tu herramienta y si seguir invocándola.

La guía de Anthropic es la fuente canónica: la descripción de una sola herramienta tiene el mayor impacto en la precisión de las llamadas a herramientas de cualquier variable en el sistema. Sus pruebas internas muestran que entre 1 y 5 ejemplos realistas por herramienta elevan la precisión del 72 % al 90 %. (modelcontextprotocol.info Effective Tools; AgentPatterns Tool Schema Standards.)

#Las ocho reglas de diseño de herramientas

Regla 1: Una herramienta por acción distinta. Evita parámetros de modo. Una sola herramienta que acepta un parámetro mode ("read", "write", "list", "search") obliga al modelo a navegar por un árbol de decisiones complejo dentro de una sola herramienta. Es mejor utilizar herramientas separadas con nombres claros. Apigene, ChatForest, Axiom Studio, AgentPatterns y la propia guía de Anthropic coinciden en este punto. (Apigene; ChatForest; AgentPatterns server design; Axiom Studio.)

Regla 2: Nombres orientados a la acción, en snake_case. search_logs, book_consultation, submit_quote_request. No email, data, api ni helper. Elige un patrón verbo-sustantivo y aplícalo de forma consistente. (Leanmcp; Inovaflow; Workato.)

Regla 3: Trata la descripción como una UX orientada al agent. Tres partes:

1. Qué hace: una oración con un verbo específico.
2. Contexto y restricciones requeridos: qué necesita la herramienta y qué límites tiene.
3. Cuándo usarla frente a las alternativas: desambiguación explícita respecto de herramientas similares.

Ejemplo concreto (tomado del playbook de Axiom Studio, ligeramente adaptado):

Search file contents using regex patterns. Returns up to 100 matches. For larger result sets, use a more specific pattern or target a subdirectory with the path parameter. Searches are case-sensitive by default; use (?i) prefix for case-insensitive matching. For finding files by name rather than content, use find_files instead.

Esta descripción cumple cinco funciones: indica la acción, especifica el límite, ofrece una sugerencia de orientación, expone una restricción y redirige a una herramienta alternativa cuando corresponde. Las descripciones deficientes generan tasas de falla entre 3 y 4 veces superiores a las que ofrece este tipo de estructura. (Axiom Studio; Apigene.)

Regla 4: Cada parámetro necesita una descripción. El modelo lee las descripciones de los parámetros para completar los argumentos. Un parámetro user sin más es ambiguo; user_id con la descripción "Unique identifier for the user — must be a valid UUID v4" es inequívoco. Utiliza enums cuando corresponda. Indica los formatos de forma explícita (marcas de tiempo ISO 8601, correos electrónicos RFC 5322, códigos de producto GTIN-13). (AgentPatterns server design; Inovaflow; Anthropic.)

Regla 5: Mantén los esquemas planos. Evita $ref y oneOf. Los campos opcionales, las combinaciones con $ref y el manejo de enums complejos varían entre Claude Desktop, Cursor, ChatGPT, Gemini y otros clientes MCP. Las herramientas que pasan la validación en modo estricto del SDK de Anthropic pueden fallar de forma contundente en el de OpenAI. El patrón más seguro: objetos planos con tipos explícitos, sin $ref, sin oneOf y con un máximo de 3-4 parámetros. Prueba al menos en dos clientes antes de publicar. (Apigene; AgentPatterns Schema Standards.)

Regla 6: Expone las restricciones de forma explícita. Si tu herramienta devuelve hasta 100 coincidencias, indícalo en la descripción. Si un parámetro debe ser inferior a 1 MB, indícalo. Si una herramienta tiene un límite de tasa de 10 llamadas por minuto por usuario, indícalo. Un agent que desconoce un límite interpretará un resultado truncado como finalización y tomará decisiones incorrectas en pasos posteriores. (Axiom Studio.)

Regla 7: Los errores incluyen sugerencias de recuperación. Los errores a nivel de herramienta (isError: true) son información sobre la que el agent puede razonar y recuperarse. Los errores JSON-RPC deben reservarse para fallas del servidor (JSON no válido, herramienta desconocida, fallo interno). El mensaje de error en sí importa: "File not found" con "try search_files instead" genera un mejor comportamiento del agent que "ENOENT: no such file or directory". (Axiom Studio; AgentPatterns.)

Regla 8: Agrega variantes por lotes cuando los agents realizan bucles. Si observas que los agents invocan la misma herramienta N veces en secuencia, agrega una herramienta por lotes. read_files(paths: string[]) en lugar de N llamadas a read_file(path: string). Cada llamada sin procesamiento por lotes representa un ciclo completo de respuesta del LLM (generar la llamada, ejecutar, inyectar el resultado, generar la siguiente llamada); el procesamiento por lotes reduce la latencia y el costo de tokens de forma aproximadamente lineal. (Axiom Studio; Datadog/Block/Cloudflare layered query patterns analysis on Medium.)

#Esquemas de salida

La especificación del 18 de junio de 2025 introdujo outputSchema: ahora las herramientas pueden declarar un JSON Schema que describe su tipo de retorno, junto con el inputSchema existente. Las herramientas con esquemas de salida devuelven tanto structuredContent (con tipo y conforme al esquema) como el array content tradicional para mantener la compatibilidad con versiones anteriores. (ChatForest; AgentPatterns.)

Utiliza esquemas de salida cuando el código descendente u otras herramientas vayan a consumir los datos de forma programática. Omítelos en herramientas que devuelven principalmente contenido legible por humanos (resúmenes, texto generado, explicaciones) donde la estructura es el propio texto. El costo: cada esquema adicional incrementa la sobrecarga de tokens por herramienta en la ventana de contexto del agent.

#Tamaño de la lista de herramientas

La orientación empírica de los servidores MCP en producción (Stripe Toolshed, Block, Cloudflare, Datadog) coincide en la misma regla: mantén la lista de herramientas por debajo de 15 por servidor. Responsabilidad única por servidor; conjuntos de herramientas sin solapamiento. Stripe Toolshed cuenta con más de 400 herramientas, pero preselecciona 15 por ejecución del agent mediante precarga determinista contra el prompt. (Engineering.fyi Stripe; AgentPatterns server design.)

La razón es directa: la ventana de contexto del agent incluye todas las definiciones de herramientas. Los esquemas dominan el costo de tokens por herramienta. Un servidor que expone 50 herramientas a un modelo con contexto de 200 K deja mucho menos espacio para el razonamiento real, la recuperación y el diálogo.

La comparación de Datadog/Block/Cloudflare (Tanmay Deshpande, marzo de 2026) midió esto directamente en la API de HackerNews: un patrón “tradicional” de 10 herramientas consumió 6624 tokens y 3,6 segundos en cinco escenarios de referencia; una alternativa de “modo código” redujo los tokens en un 65 %; un patrón de “consulta en capas” redujo los tokens entre un 65 % y un 98 % y finalizó en 2,0 segundos. La implicación: publicar 10 herramientas estrechas es lo peor de los tres patrones cuando la API tiene cualquier superficie significativa.

#Qué exponer primero

La herramienta de mayor impacto que debes publicar primero es la que resuelve una tarea completa de extremo a extremo para el usuario. No un endpoint de lista. No un endpoint de obtener por identificador. Aquello que devuelve la respuesta que el usuario realmente necesita.

La guía Effective Tools de Anthropic lo concreta así: en lugar de list_users, list_events, create_event, publica schedule_event que encuentra disponibilidad y programa en una sola llamada a la herramienta. En lugar de read_logs, publica search_logs que devuelve las líneas relevantes con su contexto circundante. En lugar de get_customer_by_id + list_transactions + list_notes, publica get_customer_context que compila toda la información reciente y relevante de un cliente de una sola vez.

Para un fundador de SaaS, esto significa: identifica los 3-5 flujos de trabajo multi-paso más comunes que tus usuarios realizan manualmente y publica una herramienta por flujo de trabajo. Omite la larga cola hasta que los datos de producción muestren que los agents la solicitan.

#Parte IV: Autenticación y autorización

La especificación MCP (actualización del 25 de noviembre de 2025) exige OAuth 2.1 con PKCE para todos los transportes basados en HTTP. Las claves de API en variables de entorno todavía funcionan desde el primer día, pero el Registro oficial de MCP, Claude Desktop, Cursor, VS Code Copilot y Windsurf recomiendan preferentemente servidores respaldados por OAuth cuando los usuarios buscan integraciones. Si tu servidor todavía solicita un token bearer de larga duración en un archivo de configuración, estás dejando de lado participación en la distribución. (Botoi PKCE guide; WorkOS auth guide; Ekamoira OAuth 2.1.)

#El protocolo wire

La composición de autorización de MCP consta de cinco especificaciones pequeñas que se combinan:

• OAuth 2.1 (RFC 9700) — el marco de autorización en sí mismo
• PKCE (RFC 7636) — Proof Key for Code Exchange, con el método de desafío de código S256 obligatorio
• Dynamic Client Registration (RFC 7591) — los clientes se registran automáticamente sin aprovisionamiento por cliente
• Resource Indicators (RFC 8707) — vinculan tokens a recursos específicos para prevenir la reproducción entre recursos
• Protected Resource Metadata (RFC 9728) — detectable en /.well-known/oauth-protected-resource

La experiencia completa del cliente: un cliente MCP como Claude Desktop recibe un 401 en la primera conexión, lee WWW-Authenticate: Bearer realm="..." que apunta a /.well-known/oauth-protected-resource, analiza los metadatos, se registra dinámicamente (o usa un registro existente), ejecuta un flujo de código de autorización protegido por PKCE con el indicador de recurso que fija la audiencia del token a tu servidor MCP, intercambia el código por un token de acceso + token de refresco, y comienza a llamar a las herramientas con el bearer en el encabezado Authorization. (Prefect MCP OAuth; STOA OAuth+PKCE flow.)

#Lo que realmente tienes que implementar

Para un fundador de SaaS, el trabajo de implementación se descompone de la siguiente manera:

1. Endpoint de metadatos de recurso protegido en /.well-known/oauth-protected-resource. La ruta no es configurable: la RFC la fija. Devuelve JSON declarando tu servidor de autorización, los alcances admitidos y el URI del recurso. (Microsoft Azure AD MCP guide; Vercel deploy MCP.)

{
  "resource": "https://api.yourservice.com/mcp",
  "authorization_servers": ["https://auth.yourservice.com"],
  "jwks_uri": "https://auth.yourservice.com/.well-known/jwks.json",
  "scopes_supported": ["mcp:read", "mcp:invoke:safe", "mcp:invoke:destructive"],
  "response_types_supported": ["code"],
  "grant_types_supported": ["authorization_code", "refresh_token"]
}

2. Servidor de autorización. Constrúyelo tú mismo solo si es necesario. Para la mayoría de los equipos, delega. WorkOS, Auth0, Okta, AWS Cognito, Azure AD/Entra ID, Keycloak y Clerk admiten las RFC relevantes de forma nativa. WorkOS comercializa específicamente AuthKit listo para MCP; PropelAuth tiene una guía de Cloudflare Worker para MCP. La recomendación pragmática, repetida en todos los blogs de proveedores de autenticación: delega la autenticación a un proveedor de identidad establecido; enfoca tu esfuerzo de ingeniería en el control de acceso y la lógica de negocio. (Ekamoira; WorkOS; Prefect; STOA.)

3. Validación de JWT en tus manejadores de herramientas. Almacena en caché JWKS durante 1 hora (Microsoft Azure AD MCP recomienda exactamente este valor como equilibrio entre rendimiento y latencia de rotación de claves). Valida iss (emisor), aud (audiencia — debe coincidir con tu URI de recurso), exp (expiración), nbf (no antes de) y los alcances requeridos. La firma por sí sola no es suficiente: la reproducción entre recursos requiere la verificación de audiencia. (Prefect MCP OAuth; MCP Framework OAuth.)

4. Diseño de scopes. Separa los scopes destructivos y de solo lectura. El patrón que perdura:

• tools:read — acceso solo de lista, sin efectos secundarios
• tools:invoke:safe — acciones no destructivas (búsqueda, consulta, estado)
• tools:invoke:destructive — acciones que mutan el estado (compra, send_email, eliminar)

Un usuario que otorgó tools:read para ejecutar un informe semanal no debería poder ejecutar send_email con el mismo token. Claude Desktop y Cursor muestran los scopes solicitados en la pantalla de consentimiento, por lo que la separación hace que la UX sea honesta sobre lo que el cliente puede hacer. (Botoi; OWASP MCP Security; Ekamoira.)

5. RBAC a nivel de herramienta, no solo autenticación. La autenticación responde "¿quién está llamando?". La autorización responde "¿qué puede hacer?". Ambas son necesarias. La autenticación sin autorización es uno de los cinco errores principales que Ekamoira documenta en su análisis de fallos de seguridad comunes en MCP. Implementa control de acceso basado en roles — al menos separación de solo lectura/escritura/admin — en la capa de ejecución de herramientas. (Ekamoira.)

#Qué evitar

• Tokens en cadenas de consulta. Los logs y proxies capturan las URLs de forma rutinaria. El proveedor OAuth del MCP Framework los rechaza automáticamente. Nunca incrustes tokens bearer en la URL. (MCP Framework OAuth.)
• Tokens estáticos de larga duración. OAuth 2.1 exige tokens de acceso de corta duración (5-60 minutos) con rotación de tokens de refresco. Los tokens de larga duración son el mayor riesgo de credenciales en MCP: si se filtran en los logs, pueden abusarse durante toda la vida del token. (Botoi; OWASP MCP Top 10.)
• Firma simétrica de JWT (HS256). Usa claves de firma asimétricas (RS256 o ES256) obtenidas de un endpoint JWKS. Las claves simétricas deben compartirse con cada servidor validador, lo que amplía la superficie de compromiso. (MCP Framework OAuth.)
• Almacenamiento de tokens en localStorage. En el lado del cliente, los tokens pertenecen al almacenamiento seguro nativo del SO (Keychain en macOS, Credential Manager en Windows, libsecret en Linux). El almacenamiento en localStorage al estilo web es un antipatrón conocido. (MCP Framework; Prefect.)

#Parte V: Seguridad y Confianza

La Fundación OWASP ahora mantiene un OWASP MCP Top 10 dedicado (beta de 2025, con la revisión de 2026 que expande varias categorías). Es lectura obligatoria y la referencia canónica para el modelado de amenazas en los despliegues de MCP. Las categorías:

(OWASP MCP Top 10; OWASP MCP06; OWASP MCP Tool Poisoning page.)

#Las tres categorías que la mayoría de los equipos de SaaS subestiman

Tool Poisoning (MCP03). Demostrado en producción contra el servidor MCP oficial de GitHub (~14 000 estrellas de GitHub en el momento de la divulgación, uno de los servidores más ampliamente desplegados). Un issue malicioso en un repositorio público contenía instrucciones; un agent que triaba issues públicos leyó el issue, siguió las instrucciones ocultas, extrajo datos de repositorios privados y los escribió en un pull request público. Nombres de repositorios privados e información personal fueron exfiltrados. Esto no es teórico. La investigación «Poison Everywhere» de CyberArk extendió el modelo para demostrar que cada campo de texto en un schema de herramienta es una superficie de inyección: descripciones, descripciones de parámetros, valores predeterminados, opciones de enum, ejemplos, campos de título. (Pipelab tool poisoning; OWASP issue 806; Mindgard.)

Command Injection (MCP05). CVE-2025-5277 documentó una vulnerabilidad de command injection en el popular aws-mcp-server: la validación solo aseguraba que el comando comenzara con aws, pero aws -h;whoami evadió la verificación. CVE-2025-5276 (SSRF) y CVE-2025-5273 (lectura arbitraria de archivos) siguieron en el mismo ciclo de divulgación para markdownify-mcp. El patrón: herramientas que toman cadenas controlables por el usuario y las canalizan hacia la ejecución de subprocess, rutas de archivos o llamadas HTTP sin sanitización. (Snyk Labs; Tenable.)

Indirect Prompt Injection (MCP06). Incluso si tu servidor MCP usa stdio y no está expuesto a la red, la indirect prompt injection puede armar al LLM para que emita un comando que golpee tu servidor. La divulgación de Snyk Labs mostró cómo una página web envenenada, obtenida por un servidor MCP diferente, puede instruir al LLM a llamar tus herramientas con argumentos controlados por el atacante. La mitigación no está del lado del LLM — está en el límite de ejecución de la herramienta, con controles de acceso backend que las instrucciones inyectadas no pueden anular. (Snyk Labs; OWASP MCP06.)

#Defensas que todo servidor en producción necesita

1. Validate every input. Validar cada entrada. Path traversal (../), null bytes, command-character escaping, regex bombs, oversized payloads. Incluso con un JSON Schema estricto, la entrada es no confiable por defecto. El modelo de ejecución STDIO en algunos SDKs tempranos de MCP ejecuta comandos incluso cuando el proceso local falla al iniciarse, exponiendo servidores a command injection a menos que el autor sanitice las entradas. La sanitización de argumentos es la mitigación, no esquemas más ricos. (AgentPatterns server design; OX Security; SecurityWeek.)
2. Treat tool responses as untrusted before they enter the LLM context. Tratar las respuestas de las herramientas como no confiables antes de que entren en el contexto del LLM. La especificación de MCP aconseja a los clientes considerar los límites de confianza pero no exige validación de respuestas. Los servidores en producción deberían sanitizar sus propias salidas — eliminar instrucciones incrustadas, enmascarar secrets, truncar payloads sobredimensionados — antes de retornar. (OWASP MCP Tool Poisoning page.)
3. Backend access controls cannot rely on system prompt instructions. Los controles de acceso backend no pueden depender de instrucciones del system prompt. «Do not read files outside /tmp» aplicado mediante system prompt es evitable. La misma restricción aplicada en la capa de la herramienta (la herramienta rechaza rutas fuera de /tmp) no lo es. Siempre aplica las restricciones en el lado del servidor. (OWASP MCP Tool Poisoning; OWASP issue 806.)
4. Trust-on-First-Use (TOFU) for tool definitions. Almacena en caché los schemas de herramientas en la primera conexión; alerta cuando cambien inesperadamente. Los ataques rug-pull (modificación silenciosa de descripciones de herramientas aprobadas) dependen de la ausencia de esta verificación. (OWASP Stuttgart slides; SAFE-MCP framework.)
5. Origin header validation on all incoming connections. Requerido por la especificación de MCP para prevenir ataques de DNS rebinding en servidores locales; requerido en la práctica para servidores remotos para prevenir ataques de estilo CSRF contra sesiones autenticadas. (modelcontextprotocol.io transports.)
6. Per-user, per-client consent for all tools and data access. Previene ataques de confused deputy donde un cliente confiable es engañado para actuar en nombre de uno no confiable. (Mindgard; OWASP MCP Top 10.)
7. Continuous adversarial testing. Red teaming con plataformas como Mindgard Offensive Security, además de escaneo pre-despliegue con Cisco mcp-scanner, Snyk agent-scan (anteriormente Invariant), Pipelock MCP proxy, o herramientas compatibles con SAFE-MCP. La revisión estática detecta inyección a nivel de descripción; los proxies en tiempo de ejecución detectan rug-pulls a nivel de sesión. (Mindgard; Pipelab.)

#Parte VI: Gobernanza empresarial

Para los equipos de SaaS que venden a compradores de mercado medio y empresariales, la capa de gobernanza marca la diferencia entre un ciclo de adquisición de 30 días y uno de 9 meses. Los equipos de adquisiciones, revisión de seguridad y cumplimiento normativo harán preguntas específicas: cómo se aplica la multi-tenencia, cómo se ve el registro de auditoría, cuál es la historia de la residencia de datos y qué regulaciones admite la implementación.

#Patrones de multi-tenencia

El handshake initialize de MCP incluye clientInfo (name, version) pero ningún identificador de tenant. La multi-tenencia es tu responsabilidad en la capa de infraestructura. Dos patrones dominan, con un claro intercambio. (MCP Find multi-tenant; Tetrate enterprise.)

Proceso por tenant. Cada tenant obtiene su propio proceso de servidor MCP. Aislamiento completo: el fallo de un tenant no afecta a los demás, los datos de un tenant no pueden filtrarse. Operativamente más pesado (gestión de procesos, contabilidad de recursos por tenant, latencia de inicio en frío). Adecuado para tenants de alta seguridad, industrias reguladas y recuentos pequeños de tenants (<100). Un caso de estudio de servicios financieros implementó 50 procesos de tenants dedicados; la lección operativa fue "automatizar la gestión de procesos desde el principio; la incorporación manual se convierte en un cuello de botella." (MCP Find.)

Proceso compartido con espacio de nombres por tenant. Un servidor MCP maneja todos los tenants, con nombres de herramientas y operaciones limitados por el ID de tenant extraído del contexto de autenticación. Menor costo operativo. Mayor carga de ingeniería: cada operación debe verificar el contexto del tenant, cada consulta a la base de datos debe incluir el filtro de tenant, cada clave de caché debe incluir el ID de tenant. Un caso de estudio de producto SaaS implementó más de 200 tenants en proceso compartido y reportó que el manejo de errores fue el diferenciador: "el código de herramienta defectuoso de un tenant bloqueó el servidor compartido tres veces en el primer mes; después de eso se agregaron disyuntores." (MCP Find.)

El valor predeterminado para SaaS a menos que sepas que necesitas lo contrario: proceso compartido con espacio de nombres por tenant, y límites de tasa por tenant en la capa MCP. El desafío de escalado más difícil suele ser los límites de tasa de la API upstream, no el servidor MCP en sí: tu servidor compartido alcanzará el mismo límite de tasa de API de terceros en nombre de todos los tenants, lo que requiere colas y retroceso por tenant en el límite del MCP.

#Registro de auditoría

SOC 2 Type II, ISO 27001, HIPAA, GDPR, SOX y PCI-DSS imponen requisitos específicos de auditoría que los servidores MCP deben cumplir cuando tocan datos regulados. El registro de auditoría mínimo viable para un servidor MCP en 2026:

• Un evento por llamada a herramienta — incluyendo llamadas fallidas y denegadas
• Identidad del usuario — verificada desde el token OAuth, no autoafirmada por el cliente
• ID de tenant — para implementaciones multi-tenant
• Nombre de la herramienta y parámetros — con PII hasheado o redactado; parámetros sin procesar en los registros de auditoría es una violación de GDPR a la espera de ocurrir
• Marca de tiempo — UTC, ISO 8601, precisión de subsegundo
• IP del cliente — para respuesta a incidentes y contexto de limitación de tasa
• Resultado — éxito/error, estado de respuesta, duración
• ID de auditoría — UUID para correlacionar entre flujos de registro

Según la implementación de referencia del servidor Greenplum MCP y el SDK de gobernanza Ithena MCP, los registros de auditoría deben:

• Ser un flujo separado de los registros operativos del servidor (el cumplimiento requiere un flujo limpio)
• Ser NDJSON para ingestión directa en SIEM (Splunk, Datadog, ELK, Vector)
• Ser a prueba de manipulaciones (encadenamiento criptográfico o almacenamiento inmutable como AWS S3 Object Lock)
• Tener una política de retención alineada con la regulación más estricta que aplique (7 años para SOX, 6 años para HIPAA, "mientras sea relevante" para GDPR)
• Capturar denegaciones de permisos por separado de fallos de autenticación

(Broadcom Tanzu Greenplum docs; Ithena governance SDK; Tetrate audit logging.)

#Retención cero de datos como acelerador de adquisiciones

El análisis de Truto (abril de 2026) es la articulación más clara de por qué la arquitectura de paso sin retención de datos importa para los servidores MCP de SaaS que venden a empresas. Cada base de datos que contiene registros de clientes se convierte en parte del alcance de tu auditoría SOC 2. Cada capa de caché que persiste respuestas de API necesita controles de cifrado, políticas de retención, registro de accesos y procedimientos de eliminación. El almacenamiento en caché de datos de terceros expande exponencialmente tu alcance de cumplimiento.

El patrón de retención cero de datos: operar como un proxy de paso sin estado que procesa cargas útiles de API completamente en memoria, mapea esquemas sobre la marcha y devuelve resultados directamente al LLM sin escribir datos de clientes en disco. Los beneficios se acumulan:

• El alcance de la auditoría SOC 2 se reduce drásticamente (sin datos en reposo en tu perímetro)
• El cumplimiento de minimización de datos de GDPR es estructural, no procedural
• El derecho a la eliminación se vuelve trivialmente cumplible (no tienes nada que eliminar)
• Los ciclos de adquisición se acortan de trimestres a días porque el cuestionario de seguridad se vuelve mucho más corto

El intercambio: algunas características son más difíciles. El almacenamiento en caché por llamada está limitado. El análisis entre llamadas requiere almacenamiento externo con consentimiento explícito. El patrón encaja bien con los servidores MCP precisamente porque la mayoría de las llamadas a herramientas MCP son búsquedas sin estado contra un sistema de registro externo. (Truto zero-data-retention; Tetrate MCP audit logging.)

#Política como código

Para implementaciones empresariales de varios equipos, expresar las políticas de acceso en forma legible por máquina (Rego, OPA, Cedar) es el único camino sostenible. Las políticas definen qué herramientas puede invocar cada rol, qué reglas de residencia de datos aplican, qué registro es obligatorio, qué alcances se requieren. Los flujos de trabajo de GitOps producen registros de auditoría completos de forma gratuita: cada cambio de política es un commit de Git con autor, revisor y marcas de tiempo de aprobación. (Tetrate enterprise deployment.)

#Parte VII: Observabilidad y evaluación

No puedes iterar el bucle de diseño de herramientas sin medición. Las herramientas dominantes en el ecosistema a mediados de 2026:

• mcp-eval — framework de evaluación integral. Conecta un mcp-agent a tu servidor, ejecuta escenarios programados, captura trazas de OpenTelemetry, aserta el uso de herramientas / contenido / eficiencia / calidad. Informes en JSON, Markdown, HTML. Integración con GitHub Actions. (mcp-eval.ai; mcp-eval Mintlify.)
• MCPJam Inspector — ejecuta tu servidor MCP contra agents simulados en múltiples LLMs (Claude, GPT, Gemini), reporta Accuracy, TPR, FPR, Precision, uso de tokens, rendimiento entre modelos. Genera automáticamente casos de prueba a partir de tus definiciones de herramientas. Se integra con OpenAI Apps SDK y MCP-UI. (MCPJam blog.)
• mcpchecker — pruebas de integración para servidores MCP usando agents de IA reales para completar tareas reales. Utiliza un proxy de grabación MCP para capturar cada llamada a herramienta. (mcpchecker GitHub.)
• Inspectr — proxy local-first que captura cada solicitud/respuesta MCP con clasificación consciente de MCP (herramientas, prompts, recursos). Se combina con MCPLab para ejecuciones de evaluación. (Inspectr docs.)
• Ithena — ithena-cli de código abierto más la Ithena Platform alojada para observabilidad empresarial y pistas de auditoría. (Ithena governance SDK.)

#Qué medir

Las cuatro métricas de MCPJam se mapean directamente a las reglas de diseño de herramientas:

• Accuracy — porcentaje general de ejecuciones en las que el agent invocó la herramienta esperada correctamente. La métrica de salud principal.
• True Positive Rate (TPR / Recall) — de las ejecuciones en las que esta herramienta debería haberse llamado, ¿con qué frecuencia se llamó? Un TPR alto significa que la descripción es clara y el agent sabe cuándo usarla.
• False Positive Rate (FPR) — de las ejecuciones en las que esta herramienta no debería haberse llamado, ¿con qué frecuencia se llamó de todos modos? Un FPR alto significa que la herramienta es demasiado genérica; ajusta el alcance o afina la descripción.
• Precision — de todas las veces que se usó la herramienta, ¿qué fracción fue correcta? Una Precision alta significa que la herramienta no se está usando en exceso.

Dos métricas operativas completan el panorama:

• Token usage per call — los esquemas dominan el costo de tokens por herramienta; haz seguimiento de esto para detectar deriva de esquemas que infla el contexto.
• Latency P50/P95/P99 — los agents degradan las APIs lentas. Cualquier cosa por encima de 500 ms para una lectura o 2 s para una escritura es un problema.

(MCPJam; mcp-eval; Inspectr.)

#Gates de CI

Los flujos de trabajo de mcp-eval y mcpchecker incluyen integraciones con GitHub Actions. El gate de CI mínimo que todo servidor MCP SaaS debería ejecutar en cada solicitud de extracción:

1. Validación de esquema — cada definición de herramienta es un JSON Schema válido con additionalProperties: false
2. Calidad de descripción — verificación heurística de que cada herramienta tenga una descripción ≥40 caracteres y cada parámetro tenga una descripción ≥10 caracteres
3. Compatibilidad entre clientes — ejecuta el esquema a través del validador en modo estricto de OpenAI y del validador en modo estricto de Claude; falla si alguno lo rechaza
4. Suite de pruebas de comportamiento — al menos 10 escenarios representativos por herramienta, asertados con Expect.tools.was_called, Expect.content.contains y Expect.performance.response_time_under
5. Escaneo de seguridad — ejecuta Cisco mcp-scanner o Snyk agent-scan contra las definiciones de herramientas para patrones de inyección conocidos

Empíricamente, los equipos que lanzan sin gates de CI ven una regresión en la accuracy del 5-10% por trimestre a medida que los ingenieros agregan herramientas o modifican descripciones sin probar. Los equipos con gates de CI mantienen la accuracy estable o la mejoran.

#Parte VIII: Distribución

Construir el servidor es la mitad del trabajo. La distribución es la otra mitad. El ecosistema MCP se ha consolidado alrededor de un pequeño número de registros y directorios, cada uno con una audiencia diferente y un flujo de envío.

#La stack de registros

(Guía de registros de MCPBlog; Comparación de directorios de AutomationSwitch; DYNO Mapper; Comparación de Skillful; Explicación de Glama; modelcontextprotocol.io Registry.)

#La secuencia de envío

Para un servidor MCP completamente nuevo, el orden de envío que maximiza la distribución con el mínimo esfuerzo:

1. Registro MCP Oficial primero. Usa mcp-reg publish (o el equivalente de GitHub Action) en cada lanzamiento. PulseMCP ingiere automáticamente en 7 días. ~10 minutos de configuración única; unos minutos por lanzamiento después de la CI.
2. Smithery segundo. Usa smithery mcp publish "https://your-server.com/mcp" -n yourorg/your-server. Smithery maneja el registro dinámico de clientes mediante Documentos de Metadatos de ID de Cliente — no se requiere configuración por cliente. Ventaja adicional: Smithery escanea tu servidor en busca de herramientas/prompts/recursos para completar tu listado; si el escaneo falla, sirve un /.well-known/mcp/server-card.json estático.
3. Glama tercero. Envía mediante formulario web. Glama ejecuta verificaciones de compilación; los servidores que fallan son rechazados. El listado en Glama ahora es un requisito previo para el PR de awesome-mcp-servers.
4. MCP.so cuarto. Formulario web; mayor cobertura por recuento bruto.
5. Lista awesome al final. PR a github.com/modelcontextprotocol/servers para servidores de nivel de referencia; PR a punkpeye/awesome-mcp-servers para visibilidad de la comunidad (se requiere listado en Glama).

Publica automáticamente desde CI con continue-on-error: true en el trabajo del registro — el Registro Oficial aún está en vista previa, y no quieres que una interrupción del registro bloquee tu lanzamiento.

#Más allá de los registros

Los registros cubren el descubrimiento para los desarrolladores que navegan activamente en busca de servidores MCP. Tres canales de distribución secundarios son importantes para el SaaS:

1. Documentación que ingieren los corpus de entrenamiento de IA. llms.txt, schema.org, publicaciones de blog indexadas. Los agents prefieren recomendar marcas que han visto mencionadas con autoridad. La optimización de motores generativos (GEO) es ahora una disciplina real y afecta si tu servidor es recomendado en lugar del de un competidor. (Yext; Seenos; AgentWiki.)
2. Integraciones directas con socios. El MCP Demo Day de Cloudflare (mayo de 2025) mostró PayPal, Sentry, Linear, Asana, Atlassian, Block, Intercom, Webflow, Stripe — cada uno aterrizó en Claude como una integración nativa el día que se lanzó. Anthropic y OpenAI ejecutan programas de socios. Los primeros 100 servidores son fáciles; los siguientes 1 000 están limitados por estas relaciones con socios.
3. El ecosistema de IDE/editor. Cursor, Windsurf, VS Code Copilot, Claude Code, GitHub Copilot. Cada uno tiene su propio mecanismo de configuración para servidores MCP; que se instale por defecto en cualquiera de ellos vale más que años de presencia en los registros.

#Parte IX: Monetización

De los más de 19.000 servidores MCP públicos, menos del 5 % están monetizados. La brecha representa la oportunidad. Todos los patrones de monetización del playbook de SaaS se adaptan a MCP, pero la dinámica de agente como comprador hace que algunos patrones sean dramáticamente mejores que otros.

#Los cuatro modelos de precios

(Godberry Studios; TutuoAI; AgentPay docs.)

El hallazgo no obvio único de la investigación de monetización de 2026: los precios por suscripción mueren más rápido en MCP. Los agentes son infinitamente pacientes y perfectamente racionales; no pagarán por funciones no utilizadas o asientos no utilizados. Un SaaS que anteriormente vendía suscripciones de $99/asiento/mes y lanza un servidor MCP descubre que la conversión de prueba originada por agentes es del 1-2 % — el agente está evaluando "¿es el valor marginal de esta única acción mayor que el costo marginal?" no "¿vale la pena $99/mes durante un año?". (FluxA; ATXP.)

La recomendación pragmática para el primer lanzamiento de un servidor MCP: implementa un nivel de precios por llamada junto con cualquier modelo de suscripción existente. Realiza un seguimiento de la conversión de agentes específicamente contra el nuevo nivel. Muchos operadores informan que los ingresos mediados por agentes bajo precios por llamada superan los ingresos por suscripción basada en asientos dentro de los 90 días.

#Los cuatro rails de facturación

1. Facturación de marketplace / proxy. AgenticMarket, MCPize, Apify MCP, Smithery (nivel pago). Agrega una sola verificación de encabezado a tu endpoint HTTPS existente, lista tu servidor, establece un precio, conserva el 80-90 % de los ingresos. AgenticMarket y MCPize publican ambos un 80 % de participación en ingresos en el piso; Apify Pay-Per-Event es el 80 % de los eventos cobrados. Configuración: ~10 minutos. Mejor para: servidores HTTPS existentes, camino más rápido a los primeros ingresos. (AgenticMarket; Godberry Studios; Apify.)

2. Plataformas de facturación nativas para agentes. ATXP (withBilling() wrapper en el límite de la tool), AgentPay (precios por tool con créditos freemium), FluxA (settlement en USDC vía x402), P402 (pagos de agentes respaldados por wallet con controles de política). Todos apuntan al mismo primitivo: decisiones de precios en el límite de la tool, legibles por máquina de antemano, auto-onboarding de agentes. Configuración: minutos a horas. Mejor para: servidores greenfield, flujos de trabajo nativos para agentes. (ATXP; AgentPay; FluxA; P402.)

3. Stripe Machine Payments Protocol (MPP) y servidores MCP pagos de Cloudflare. El MPP de Stripe se lanzó en marzo de 2026 — los agentes autorizan un límite de gasto de sesión por adelantado y transmiten micropagos. Se combina con la infraestructura PSP existente de Stripe. Cloudflare envía una clase experimental_PaidMcpAgent que integra sesiones de Stripe checkout en el gating de tools de MCP. Configuración: horas a días. Mejor para: cumplimiento fiat de nivel empresarial, sesiones de gran volumen. (Stripe MPP; Cloudflare paid MCP guide.)

4. Autohospedado con facturación medida. Moesif, Stripe metered, AWS API Gateway, mcp-billing-gateway. Máximo control, máxima retención de ingresos (~95 % después de tarifas), pero trabajo de ingeniería real — instrumentación, gestión de planes, aprovisionamiento de clientes, generación de facturas. Mejor para: servidores de alto volumen, contratos empresariales personalizados, compradores regulados que requieren facturación fiat. (Moesif; mcp-billing-gateway.)

#Estrategia de precios

El piso fundamentado empíricamente para servidores MCP de utilidad de propósito general es $0.03–$0.08 por llamada. Los servidores específicos de dominio o premium (datos financieros, investigación legal, consulta médica) se ubican en $0.15–$0.50 por llamada. El techo por encima del cual los agentes comienzan a resistirse en base por llamada es aproximadamente $1.00; más allá de eso, los precios basados en sesión o la suscripción se vuelven más eficientes. (AgenticMarket; Godberry Studios.)

Tres heurísticas operativas:

• Precio los eventos por llamada al 50–150 % de la mejor alternativa siguiente del comprador. Los agentes comparan silenciosamente; la elasticidad de precios es real.
• Establece límites de nivel gratuito que escalen con una unidad de crédito, no con un recuento plano de llamadas. $1 en crédito gratuito es una señal más honesta que "100 llamadas gratuitas" porque este último tienta al gaming.
• Publica los precios en tu manifest. Los agentes que pueden leer los precios programáticamente preferirán enrutar a servidores con precios transparentes y legibles por máquina sobre aquellos que requieren negociación fuera de banda. (AgentPay.)

#Parte X: Modos de fallo comunes

Una muestra representativa de patrones donde las iniciativas de servidores SaaS MCP se estancan o tienen un rendimiento inferior, extraída de análisis post-mortem públicos, análisis de proveedores y patrones recurrentes en el ecosistema de consultoría.

#Fallo 1: Generación automática de herramientas desde Swagger

El patrón. Un equipo escribe un script de 30 líneas que convierte cada endpoint en su especificación OpenAPI en una herramienta MCP. Lo lanza en un sprint. El servidor MCP tiene 80 herramientas, descripciones vagas heredadas de los resúmenes de la API, sin narrativa sobre cuándo usar cada herramienta. Los agents intentan las primeras tres, no logran desambiguar y dejan de llamar al servidor. (Diseño de servidor AgentPatterns; Apigene; análisis de consultas en capas de Datadog/Block/Cloudflare.)

La solución. Escribe manualmente las descripciones de las herramientas para los 5-15 flujos de trabajo de mayor valor. Trata MCP como un canal de distribución con un roadmap, owners y expansión trimestral de capacidades. La generación automática está bien para la implementación (llama a tu API existente internamente); nunca está bien para la interfaz.

#Fallo 2: Teatro de manifiestos

Un negocio publica llms.txt, una A2A Agent Card y un servidor MCP. Cada uno está escrito a mano. Cada uno se aleja de las capacidades reales en 60 días. Los agents los obtienen, encuentran información obsoleta y degradan la posición del negocio. (B2X Software; Strategic Inference.)

La solución. Genera los manifiestos desde el sistema fuente de verdad (PIM, registro de capacidades, API gateway). CI/CD valida la frescura de los manifiestos. Los trabajos programados confirman que cada URL referenciado está activo.

#Fallo 3: Omitir la capa de confianza hasta que duele

Un merchant lanza un checkout compatible con ACP, el tráfico originado por agents aumenta, el WAF lo marca como fraude y las transacciones fallan en silencio. El equipo agrega una regla de exención. Dos meses después, la exención es explotada por un estafador real que se hace pasar por un agent. (Preparación de merchants de HireNinja; HyperTrends.)

La solución. Implementa la verificación de identidad de agents estilo TAP antes de aumentar el tráfico de agents. La capa de confianza no es opcional; es la restricción que permite escalar de forma segura.

#Fallo 4: Modelo de precios equivocado

Un SaaS que antes vendía suscripciones de $99/seat/month lanza un servidor MCP. Las pruebas originadas por agents se disparan. La conversión a pago es del 2 %. El equipo concluye que “los agents no compran”. La causa real: el modelo de precios por suscripción es incompatible con la forma en que los agents evalúan el valor. (FluxA; ATXP.)

La solución. Agrega un nivel de precios por acción junto a la suscripción. Haz seguimiento de la conversión de agents específicamente contra el nuevo nivel.

#Fallo 5: Lanzamiento amplio prematuro

Un equipo se compromete a “MCP en todo el portafolio de productos”. Seis meses después, nada se lanza, porque cada equipo de producto está en plena implementación y ninguno ha alcanzado calidad de producción.

La solución. Elige una línea de producto. Lanza su superficie MCP con calidad de producción. Úsala como implementación de referencia. Pasa al segundo producto solo después de que el primero esté generando ingresos medibles mediados por agents.

#Fallo 6: Sin observabilidad, sin iteración

El equipo construye un servidor con excelentes herramientas. No lo instrumenta. Seis meses después, no puede saber qué herramientas se usan, cuáles fallan ni si algún agent ha completado alguna vez una tarea del usuario. (mcp-eval; MCPJam.)

La solución. Lanza el arnés de evaluación y la instrumentación de OpenTelemetry en el mismo PR que la primera herramienta de producción. Las métricas de conversión de agents se convierten en un KPI de negocio de primer nivel.

#Fallo 7: Tratar MCP como una función, no como un canal

Un equipo de SaaS lanza un servidor MCP en un solo sprint, publica un comunicado de prensa y pasa a otra cosa. La adopción se estanca porque el servidor tiene 8 herramientas, ninguna resuelve un flujo de trabajo real de principio a fin, los esquemas se generan automáticamente desde Swagger y son ilegibles para los LLMs, y nadie monitorea el tráfico de agents.

La solución. Trata MCP como un canal de distribución con un roadmap, owners, métricas y expansión trimestral de capacidades. La primera versión de MCP es una cabeza de playa, no un hito.

#Fallo 8: Construir todo internamente

Ingeniería decide construir un servidor MCP personalizado, una integración A2A personalizada, infraestructura de pagos personalizada, generación de manifiestos personalizada, analíticas de tráfico de agents personalizadas y una capa de confianza personalizada. Dieciocho meses después, el sistema funciona pero consume el 60 % de la capacidad de ingeniería.

La solución. Usa la capa productizada donde exista. Apideck, StackOne, Truto, Albato Embedded, Cyclr, NimbleBrain y Ampersand venden MCP-server-as-a-service para integraciones de SaaS. Stripe vende ACP-as-a-service para comercio. El trabajo diferenciado es tu lógica de negocio y tus datos verticales específicos, no la plomería del protocolo.

#Parte XI: El plan de implementación de 90 días

#Días 0–30: Fundamentos

Objetivo: lanzar un servidor MCP mínimo viable en producción, exponiendo 3-5 herramientas de alto valor, con OAuth 2.1 y observabilidad básica.

Semana 1: Arquitectura y decisiones

• Elige el transporte: Streamable HTTP para la extensión SaaS (predeterminado); stdio solo si tu "server" ya es un CLI distribuido a los desarrolladores.
• Elige el framework: Cloudflare Agents (createMcpHandler para stateless, McpAgent para stateful) o Vercel mcp-handler en Functions/Fluid Compute. Usa lo que ya despliegas.
• Elige el proveedor de autenticación: WorkOS, Auth0, Okta, AWS Cognito, Azure AD, Keycloak o Clerk. No lo implementes tú mismo.
• Haz un inventario de la API existente: ¿qué 3-5 endpoints resuelven flujos de trabajo completos del usuario que los agents invocarían?
• Establece la observabilidad de referencia: trazas de OpenTelemetry, métricas por herramienta, flujo de registro de auditoría.

Semana 2: Primeras herramientas y OAuth

• Implementa 3-5 herramientas siguiendo las ocho reglas de diseño de herramientas (una herramienta por acción distinta, descripciones claras, esquemas planos, descripciones de parámetros, restricciones visibles, mensajes de error útiles).
• Configura OAuth 2.1 a través de tu proveedor de autenticación. Implementa /.well-known/oauth-protected-resource. Valida los JWT (iss, aud, exp, scopes) en cada llamada a herramienta.
• Implementa RBAC: como mínimo, separa tools:read de tools:invoke:safe y de tools:invoke:destructive.
• Flujo de registro de auditoría que emite NDJSON con usuario, tenant, herramienta, hash de params, marca de tiempo y resultado.

Semana 3: Endurecimiento de seguridad

• Ejecuta Cisco mcp-scanner o Snyk agent-scan contra tus definiciones de herramientas; corrige cualquier hallazgo.
• Agrega validación de entrada: path traversal, command injection, payloads sobredimensionados, regex bombs.
• Sanitiza las salidas antes de devolverlas al contexto del LLM; enmascara cualquier secreto incrustado.
• Validación del encabezado Origin. Limitación de tasa (por usuario, por tenant, más el presupuesto de API upstream).
• Documenta el despliegue en un SECURITY.md.

Semana 4: Primer arnés de evaluación y compuertas de CI

• Configura mcp-eval o MCPJam contra tu servidor con al menos 10 escenarios por herramienta.
• Agrega compuertas de CI: validación de esquemas, calidad de descripciones, compatibilidad entre clientes (Anthropic strict + OpenAI strict), suite de pruebas de comportamiento, escaneo de seguridad.
• Captura las métricas de referencia del día 30: TPR, FPR, Precision, uso de tokens, latencia P95.

Lista de entregables del día 30

• Servidor en producción en una URL estable
• OAuth 2.1 con PKCE; endpoint PRM en vivo
• 3-5 herramientas en producción con descripciones completas
• Compuerta de evaluación de CI activa en cada PR
• Flujo de registro de auditoría conectado
• Métricas de referencia capturadas

#Días 30–60: Distribución y cumplimiento

Objetivo: hacer que el servidor sea descubrible, capturar tráfico de agents, lanzar el segundo lote de herramientas y aprobar la primera revisión de seguridad de nivel de procurement.

Semanas 5–6: Distribución

• Envía al Registro Oficial de MCP; publica automáticamente desde CI/CD con continue-on-error: true.
• Envía a Smithery (smithery mcp publish).
• Envía a Glama (formulario web, después de que pasen las verificaciones de compilación).
• Envía a MCP.so.
• Agrega llms.txt, llms-full.txt y JSON-LD de schema.org en tus páginas de marketing para que los corpus de entrenamiento de IA detecten tu servidor.
• Contacta al cohort de Cloudflare MCP Demo Day para presentaciones al programa de partners (Anthropic, OpenAI, Google).

Semana 7: Expansión de herramientas

• Lanza las siguientes 5–7 herramientas basadas en los datos de referencia: ¿qué flujos de trabajo intentaron los agents y fallaron? ¿Qué herramientas se llamaron más? ¿Dónde faltan las variantes por lotes?
• Actualiza las compuertas de CI para las nuevas herramientas.

Semana 8: Cumplimiento y gobernanza

• Implementa una arquitectura pass-through de retención cero de datos o documenta por qué no es posible.
• Multi-tenancy: proceso compartido con espacio de nombres por tenant; límites de tasa por tenant.
• Registros de auditoría endurecidos: a prueba de manipulación, NDJSON, política de retención alineada con la regulación más estricta aplicable.
• Redacta la narrativa de SOC 2 / GDPR / HIPAA (no la certificación en sí, sino las respuestas al cuestionario de procurement para compradores).

Lista de entregables del día 60

• Listado en 4+ registros
• 8–12 herramientas en producción
• Tráfico de agents visible en los paneles (seguimiento de visitas de agents/semana, llamadas a herramientas mediadas por agents, ingreso mediado por agents como marcador de posición)
• Primer cuestionario de seguridad del comprador respondido sin seguimiento
• Retención cero de datos o excepción documentada

#Días 60–90: Monetización y crecimiento compuesto

Objetivo: lanzar un nivel facturable, capturar los primeros ingresos originados por agents y demostrar el flywheel de datos.

Semana 9: Decisión del sistema de facturación

• Elige una de las siguientes opciones: proxy de marketplace (AgenticMarket / MCPize), nativo para agents (ATXP / AgentPay / FluxA), Stripe MPP / Cloudflare paid MCP, o medición autohospedada.
• Implementa precios por llamada en 1–2 herramientas; mantén el resto gratis como embudo freemium.
• Publica los precios en tu manifiesto (legible por máquina).

Semana 10: Instrumentación de resultados

• Crea el primer panel que rastree: visitas de agents/semana, llamadas a herramientas mediadas por agents/semana, ingresos mediados por agents/semana, herramientas más llamadas, agents que más llaman, embudo de conversión de agents (descubrimiento → consulta de capacidades → llamada a herramienta → éxito).
• Compara las métricas mediadas por agents con las métricas mediadas por humanos. La primera vez que el AOV mediado por agents supere al AOV mediado por humanos es el punto de inflexión estratégico: es la evidencia de que el canal merece inversión dedicada.

Semana 11: Optimización del embudo

• Identifica y corrige los 3 principales puntos de abandono del embudo. Patrones comunes: descripciones de herramientas ambiguas (reescribe para que coincidan con lenguaje natural), atributos requeridos faltantes (completa los campos opcionales), falta de confiabilidad de webhooks (reintento idempotente).
• Prueba precios basados en resultados en una herramienta. Realiza seguimiento del aumento de conversión de agents.

Semana 12: Activo compuesto y narrativa

• Captura las métricas del día 90. Una mejora del 30%+ en TPR y 2× en ingresos mediados por agents respecto a la referencia es realista.
• Publica el primer caso de estudio público (anonimizado si es necesario). Alimenta el flywheel de publicaciones; los corpus de entrenamiento de IA ingieren el post; los agents futuros recomiendan preferentemente tu servidor.

Lista de entregables del día 90

• Nivel facturable en vivo con ingresos medibles originados por agents
• Panel de métricas de agents revisado semanalmente por el liderazgo
• Las 3 fugas principales del embudo corregidas
• Caso de estudio o benchmark público publicado
• Métricas del día 90 capturadas; cadencia de revisión trimestral establecida

#Conclusión: La ventana de 12 meses

El Protocolo de Contexto de Modelo es el raro protocolo que triunfó en portabilidad sin perder significativamente en rendimiento. 97 millones de descargas mensuales de SDK. Más de 9.400 servidores públicos. Despliegues en producción en todas las principales plataformas SaaS. Estandarización entre proveedores completada en 12 meses — históricamente raro para un protocolo de integración.

Para los fundadores de SaaS en 2026, la pregunta no es si lanzar un servidor MCP. La pregunta es si lanzar uno de alta calidad en tu categoría antes de que lo haga un competidor. La brecha de 25 puntos porcentuales entre “el 5 % de los proveedores han lanzado” y “el 30 % lo habrá hecho para fin de año” es la ventana de operación. La infraestructura para hacerlo — Cloudflare Agents SDK、Vercel mcp-handler、WorkOS / Auth0 / Clerk para auth, mcp-eval / MCPJam para pruebas, AgenticMarket / ATXP / FluxA para monetización — ya está en producción. Nada de la plomería es novedoso.

Lo que queda es la disciplina de ejecución. Ocho decisiones, ordenadas por impacto:

1. Diseño de herramientas (el área de mayor apalancamiento individual)
2. OAuth 2.1 con PKCE (requisito básico para la distribución)
3. Postura de seguridad (OWASP MCP Top 10 es innegociable)
4. Multi-tenancy y auditoría (la puerta de entrada para la adquisición)
5. Observabilidad (el bucle de iteración que multiplica la calidad)
6. Distribución (el stack de registro y las relaciones con socios)
7. Monetización (el precio por llamada gana; la suscripción muere)
8. Arquitectura (Streamable HTTP + sin estado es el predeterminado)

Un equipo que ejecuta este playbook lanza un servidor MCP de calidad de producción en 90 días. Un equipo que espera lo lanza en 270 días, contra tres competidores que ya poseen los slots de registro y las señales de confianza del lado del agente.

Esta es la pregunta que todo fundador de SaaS debe responder en 2026:

Cuando los agentes que comprarán de tu categoría en 2027 están realizando ahora mismo la ingesta de datos de entrenamiento — ¿qué están leyendo sobre tu servidor MCP?

Si la respuesta es “nada”, tienes aproximadamente 12 meses para cambiar eso. El trabajo es técnico, disciplinado y abordable. El costo de omitirlo es la invisibilidad ante los compradores más influyentes de la próxima década.

— perea.ai Research, May 2026

#Apéndice A: Árbol de Decisiones para Fundadores de SaaS

Does your SaaS already have a public REST API?
├── No → Construye la API primero. MCP envuelve una API; no la reemplaza.
└── Yes →
    Are you trying to expose your product to AI agents specifically?
    ├── No → Todavía no necesitas MCP. Vuelve a revisar cuando el tráfico mediado por AI supere el 5% de las llamadas a la API.
    └── Yes →
        Are your customer workflows complete in 1-3 sequential API calls today?
        ├── No → Rediseña primero el flujo de trabajo del usuario. MCP magnifica la calidad del diseño del flujo de trabajo; no soluciona flujos de trabajo malos.
        └── Yes →
            Elige el despliegue:
            ├── SaaS extension (la mayoría de los casos) → Streamable HTTP, hosted on Cloudflare Workers / Vercel Functions / tu infra existente
            └── CLI augmentation → stdio, distribuye vía npm/PyPI/Homebrew
            ↓
            Elige auth:
            ├── B2C / usuarios individuales → OAuth 2.1 via Auth0 / Clerk / WorkOS
            ├── B2B / empresarial → OAuth 2.1 via WorkOS / Okta / Azure AD
            └── Internal-only → Static API keys + mTLS (aceptable; documenta la excepción)
            ↓
            Elige monetización:
            ├── Suscripción existente basada en asientos → Agrega un tier por llamada; rastrea la conversión por separado
            ├── Precios existentes por llamada a la API → Refleja los precios actuales, agrega un 5–15% de prima por conveniencia MCP
            └── Greenfield → Por llamada vía AgenticMarket (rápido) o ATXP (control total)
            ↓
            Lanza. Evalúa. Itera. Acumula.

#Apéndice B: Lista de verificación de implementación de 90 días (imprimible)

#Días 0–30 — Fundamentos

• Servidor HTTP streamable en producción en una URL estable
• OAuth 2.1 con PKCE obligatorio (S256)
• Endpoint /.well-known/oauth-protected-resource
• Validación de JWT: iss, aud, exp, scopes
• RBAC: división tools:read / tools:invoke:safe / tools:invoke:destructive
• 3–5 herramientas de producción, descripciones escritas manualmente, esquemas planos
• Suite de pruebas mcp-eval o MCPJam, ≥10 escenarios por herramienta
• Puerta de CI: validación de esquema + compatibilidad entre clientes + pruebas de comportamiento
• Trazas de OpenTelemetry y flujo de logs de auditoría NDJSON
• Métricas de línea base capturadas: TPR, FPR, Precisión, uso de tokens, latencia P95

#Días 30–60 — Distribución y Cumplimiento

• Listado en el Registro Oficial de MCP (publicación automática desde CI/CD)
• Listado en Smithery, Glama, MCP.so
• llms.txt, llms-full.txt, schema.org JSON-LD en páginas de marketing
• 8–12 herramientas de producción (agregadas según datos del día 30)
• Patrón de aislamiento multi-tenant documentado
• Logs de auditoría a prueba de manipulaciones con política de retención
• Arquitectura de retención cero de datos o excepción documentada
• Primer cuestionario de seguridad del comprador respondido

#Días 60–90 — Monetización y crecimiento compuesto

• Nivel facturable activo (recomendado por llamada)
• Precios publicados en el manifiesto (legible por máquina)
• Panel de métricas de agent activo y revisado semanalmente
• Los 3 principales puntos de abandono del embudo identificados y corregidos
• Métricas del día 90 capturadas (objetivo: mejora del 30%+ en TPR, 2×+ en ingresos mediados por agent)
• Caso de estudio público o benchmark publicado

#Apéndice C: Referencia de Herramientas

#Referencias

#Especificación y arquitectura de MCP

1. Model Context Protocol — Especificación de transportes (2025-06-18). https://modelcontextprotocol.io/specification/latest/basic/transports
2. Microsoft mcp-for-beginners — Guía de transporte stdio. https://github.com/microsoft/mcp-for-beginners/blob/main/03-GettingStarted/05-stdio-server/README.md
3. Model Context Protocol — Arquitectura (2025-06-18). https://modelcontextprotocol.io/specification/2025-06-18/architecture
4. Model Context Protocol — Descripción general de la arquitectura. https://modelcontextprotocol.org/docs/learn/architecture
5. MCP TypeScript SDK V2 — Guía del servidor. https://ts.sdk.modelcontextprotocol.io/v2/documents/Documents.Server_Guide.html
6. modelcontextprotocol/example-remote-server — GitHub. https://github.com/modelcontextprotocol/example-remote-server
7. OpenAI Agents SDK — Model Context Protocol. https://openai.github.io/openai-agents-js/guides/mcp
8. modelcontextprotocol/go-sdk — Documentación del protocolo. https://github.com/modelcontextprotocol/go-sdk/blob/main/docs/protocol.md
9. MCP Specification 2025-03-26 — Transportes. https://spec.modelcontextprotocol.io/specification/2025-03-26/basic/transports/
10. typescript-sdk — Documentación del servidor. https://github.com/modelcontextprotocol/typescript-sdk/blob/main/docs/server.md

#OAuth 2.1, autenticación y autorización

1. Ekamoira — Seguridad del servidor MCP: 7 mejores prácticas de OAuth 2.1. Enero de 2026. https://www.ekamoira.com/blog/secure-mcp-server-oauth-2-1-best-practices
2. WorkOS — Guía para desarrolladores sobre autenticación MCP. Octubre de 2025. https://workos.com/blog/mcp-auth-developer-guide
3. MCP Framework — Documentación de OAuth 2.1. https://www.mcp-framework.com/docs/authentication/oauth
4. ISE Developer Blog (Microsoft) — Creación de un servidor MCP seguro con OAuth 2.1 y Azure AD. Febrero de 2026. https://devblogs.microsoft.com/ise/aca-secure-mcp-server-oauth21-azure-ad/
5. Botoi — MCP OAuth 2.1 con PKCE: asegura tu servidor de agentes en 7 pasos. Abril de 2026. https://botoi.com/blog/mcp-oauth-2-1-pkce-authorization-guide/
6. STOA — OAuth 2.1 + PKCE para puertas de enlace MCP: El flujo completo. Febrero de 2026. https://docs.gostoa.dev/blog/oauth-pkce-mcp-gateway
7. MCP Framework — Descripción general de la autenticación. https://www.mcp-framework.com/docs/authentication/overview
8. Prefect — OAuth MCP: Cómo funciona OAuth 2.1 en el Model Context Protocol. Abril de 2026. https://www.prefect.io/resources/mcp-oauth
9. Collabnix — Creación de servidores MCP remotos seguros y escalables. Julio de 2025. https://collabnix.com/building-secure-and-scalable-remote-mcp-servers-a-complete-production-guide
10. Model Context Protocol Security — Patrones de seguridad OAuth. https://modelcontextprotocol-security.io/build/oauth-security/

#Diseño de herramientas

1. Anthropic / Model Context Protocol — Escritura de herramientas efectivas para agentes. Septiembre de 2024. https://modelcontextprotocol.info/docs/tutorials/writing-effective-tools
2. AgentPatterns — Estándares de esquema de llamada de herramientas para el desarrollo de agentes de IA. http://agentpatterns.ai/standards/tool-calling-schema-standards/
3. Workato — Diseño de herramientas para servidores MCP. https://docs.workato.com/mcp/mcp-server-tool-design
4. Axiom Studio — Escritura de implementaciones MCP eficientes. Abril de 2026. https://axiomstudio.ai/blog/writing-efficient-mcp-implementations-design-considerations
5. Inovaflow — Cómo diseñar herramientas MCP que tu agente de IA no abuse. Marzo de 2026. https://www.inovaflow.io/insights/how-to-design-mcp-tools
6. ChatForest — Patrones de diseño de herramientas MCP: Creación de herramientas amigables para agentes y componibles. Marzo de 2026. https://chatforest.com/guides/mcp-tool-design-patterns/
7. Apigene — Herramientas MCP: Qué son y cómo construirlas correctamente (2026). Abril de 2026. https://apigene.ai/blog/mcp-tools
8. Redpanda Cloud — Diseño de herramientas MCP. Marzo de 2026. https://docs.redpanda.com/redpanda-cloud/ai-agents/mcp/remote/best-practices/
9. AgentPatterns — Diseño de servidores MCP: Creación de servidores amigables para agentes. http://agentpatterns.ai/tool-engineering/mcp-server-design/
10. Leanmcp — Mejores prácticas de MCP. https://docs.leanmcp.com/building/best-practices

#Seguridad y OWASP MCP Top 10

1. OWASP — Envenenamiento de herramientas MCP. https://owasp.org/www-community/attacks/MCP_Tool_Poisoning
2. OWASP — MCP Top 10. https://owasp.org/www-project-mcp-top-10/
3. OWASP Gen AI — LLM01:2025 Inyección de prompts. Abril de 2024. https://genai.owasp.org/llmrisk/llm01-prompt-injection/
4. OWASP Top 10 LLM — Problema 806: Mecánica de ataques MCP faltante en LLM01 y LLM06. Marzo de 2026. https://github.com/OWASP/www-project-top-10-for-large-language-model-applications/issues/806
5. PipeLab — Defensa contra el envenenamiento de herramientas MCP. https://pipelab.org/learn/mcp-tool-poisoning/
6. Snyk Labs — Inyección de prompts se encuentra con MCP: ¿Un nuevo vector de explotación emergente? Julio de 2025. https://labs.snyk.io/resources/prompt-injection-mcp/
7. Tenable — Inyección de prompts en servidores MCP. Abril de 2026. https://www.tenable.com/plugins/was/114928
8. OWASP Stuttgart — Todo sobre la seguridad de MCP (diapositivas). Septiembre de 2025. https://owasp.org/www-chapter-stuttgart/assets/slides/2025-09-25_All_About_MCP_Security.pdf
9. OWASP MCP06:2025 — Inyección de prompts mediante cargas útiles contextuales. https://owasp.org/www-project-mcp-top-10/2025/MCP06-2025%E2%80%93Prompt-InjectionviaContextual-Payloads
10. Mindgard — Inyección de prompts en servidores MCP: Riesgos, ejemplos y prevención. Febrero de 2026. https://mindgard.ai/blog/how-to-secure-mcp-servers-against-prompt-injection-attacks

#Registros y distribución

1. Model Context Protocol — El registro de MCP. https://modelcontextprotocol.io/registry
2. Smithery — Documentación de publicación. https://smithery.ai/docs/build/publish
3. Smithery — Servidores de búsqueda en el registro. https://smithery.ai/docs/concepts/registry_search_servers
4. MCPBlog.dev — El panorama del registro de MCP. Marzo de 2026. https://mcpblog.dev/blog/2026-03-17-mcp-registry-guide
5. Automation Switch — Más de 12 000 servidores MCP: Comparación de todos los directorios. Abril de 2026. https://automationswitch.com/ai-workflows/where-to-find-mcp-servers-2026
6. Smithery — Conectar agentes a MCPs. https://smithery.ai/
7. xmcp Documentation — Integración con Smithery. https://xmcp.dev/docs/discoverability/smithery
8. DYNO Mapper — Directorios de servidores MCP: La lista completa. Abril de 2026. https://dynomapper.com/blog/ai/mcp-server-directories/
9. Skillful.sh — Comparación de registros de servidores MCP. Marzo de 2026. https://skillful.sh/blog/mcp-server-registries-compared-smithery-glama-mcp-get-and-the-awesome-lists
10. Glama — Explicación del registro de MCP: Estandarización del descubrimiento de servidores. Julio de 2025. https://glama.ai/blog/2025-07-05-mcp-registry-standardizing-server-discovery

#Monetización

1. AgenticMarket — Cómo monetizar servidores MCP en 2026. Marzo de 2026. https://agenticmarket.dev/blog/how-to-monetize-your-mcp-server
2. TutuoAI — Cómo vender servidores MCP: Empaquetado, precios y distribución. Marzo de 2026. https://www.tutuoai.com/solutions/mcp-marketplace
3. AgentPay — Definición de tu modelo de precios. https://docs.agentpay.me/mcp-server-developers/platform/pricing
4. Apify — Precios · Servidor MCP Exa. Octubre de 2025. https://apify.com/agentify/exa-mcp-server/pricing
5. MCP Hive — White paper de monetización de MCP. https://mcp-hive.com/docs/mcp-monetization-whitepaper
6. FluxA — Cómo monetizar un servidor MCP: 3 métodos de facturación. Abril de 2026. https://fluxapay.xyz/learning/how-to-monetize-an-mcp-server-3-billing-methods
7. Godberry Studios — Cómo monetizar servidores MCP en 2026. Abril de 2026. https://godberrystudios.com/posts/how-to-monetize-mcp-servers-2026/
8. P402 Router — Integración de servidores MCP. https://www.p402.io/docs/mcp
9. AgentPay — Introducción. https://docs.agentpay.me/
10. ATXP — Cómo monetizar tu servidor MCP. Febrero de 2026. https://atxp.ai/blog/how-to-monetize-your-mcp-server/

#Marcos, SDKs e implementación

1. Cloudflare Agents — Crear un servidor MCP remoto. https://developers.cloudflare.com/agents/guides/build-mcp-server/
2. Vercel — MCP con plantilla de Vercel Functions. https://vercel.com/new/builds/templates/template/model-context-protocol-mcp-with-vercel-functions
3. Cloudflare Agents — Documentación de McpAgent. https://developers.cloudflare.com/agents/model-context-protocol/mcp-agent-api/
4. Vercel — Implementar servidores MCP en Vercel. Febrero de 2026. https://vercel.com/docs/mcp/deploy-mcp-servers-to-vercel
5. Vercel — Registro de cambios de compatibilidad con servidores MCP. https://vercel.com/changelog/mcp-server-support-on-vercel
6. Cloudflare Agents SDK — Crear servidores MCP (registro de cambios). Abril de 2025. https://developers.cloudflare.com/changelog/2025-04-07-mcp-servers-agents-sdk-updates
7. PropelAuth — Servidor MCP listo para producción usando Cloudflare Workers. Febrero de 2026. https://www.propelauth.com/post/cloudflare-worker-mcp-server
8. cloudflare/skills — Referencia de integración de servidores MCP. https://github.com/cloudflare/skills/blob/main/skills/agents-sdk/references/mcp.md
9. Toolradar — Cómo implementar un servidor MCP remoto. Marzo de 2026. https://toolradar.com/blog/deploy-remote-mcp-server
10. Cloudflare Agents — Crear un servidor MCP remoto (documentación en vivo). Abril de 2026. https://developers.cloudflare.com/agents/guides/remote-mcp-server/

#Gobernanza empresarial, multiarrendamiento y cumplimiento

1. MCP Find — MCP para empresas: Arquitectura multiinquilino y patrones de seguridad. Abril de 2026. https://mcp-find.org/blog/mcp-enterprise-multi-tenant
2. Tetrate — MCP para empresas: Implementación y gobernanza para varios equipos. Enero de 2026. https://tetrate.io/learn/ai/mcp/mcp-enterprise-deployment
3. Tetrate — Registro de auditoría de MCP: Rastreo de acciones de agentes de IA para cumplimiento. Enero de 2026. https://tetrate.io/learn/ai/mcp/mcp-audit-logging
4. Broadcom — Tanzu Greenplum MCP Server: Observabilidad y cumplimiento de auditoría. Abril de 2026. https://techdocs.broadcom.com/us/en/vmware-tanzu/data-solutions/tanzu-greenplum-mcp-server/1-0/tnz-gp-mcp-server/logging.html
5. MCP Engine — Registros de auditoría (Enterprise). https://www.mcpengine.dev/wiki/tools/manage_audit
6. Truto — Servidores MCP con retención de datos cero: Creación de agentes de IA compatibles con SOC 2 y GDPR. Abril de 2026. https://truto.one/blog/zero-data-retention-mcp-servers-building-soc-2-gdpr-compliant-ai-agents
7. Ithena — Rutas de auditoría de MCP: Cumplimiento empresarial cuando los agentes de IA acceden a tus datos. https://www.ithena.one/blog/mcp-audit-trails
8. ithena-one/mcp-governance-sdk — Documentación de auditoría y registro. https://github.com/ithena-one/mcp-governance-sdk/blob/master/docs/auditing-logging.md
9. Microsoft MCP Server for Enterprise — registro. Noviembre de 2025. https://github.com/mcp/microsoft/EnterpriseMCP
10. IBM/mcp-context-forge — Problema 1223: Ruta de auditoría de acceso a recursos. Octubre de 2025. https://github.com/IBM/mcp-context-forge/issues/1223

#Observabilidad y evaluación

1. mcp-eval — Evaluación de servidores MCP. https://mcp-eval.ai/server-evaluation
2. mcp-agent — Evaluación de servidores MCP. https://docs.mcp-agent.com/test-evaluate/server-evaluation
3. Inspectr — Observabilidad para servidores MCP. https://inspectr.dev/docs/guides/mcp-observability
4. mcp-agent — Marco mcp-eval. https://docs.mcp-agent.com/test-evaluate/mcp-eval
5. Inspectr — Evaluaciones de servidores MCP con MCPLab. https://inspectr.dev/docs/guides/mcp-server-eval-with-mcplab/
6. mcp-agent — Evaluación de agentes. https://docs.mcp-agent.com/test-evaluate/agent-evaluation
7. mcp-agent — Documentación de observabilidad. https://docs.mcp-agent.com/cloud/observability
8. mcpchecker — Repositorio de GitHub. Septiembre de 2025. https://github.com/mcpchecker/mcpchecker
9. mcp-eval Documentation — Mintlify. https://mcp-eval.mintlify.app/
10. MCPJam — Evaluación de servidores MCP: una guía rápida. Noviembre de 2025. https://www.mcpjam.com/blog/mcp-evals

#Estudios de caso de producción

1. All Things Open — Cómo Block escaló MCP en 12 000 empleados en dos meses. Diciembre de 2025. https://allthingsopen.org/articles/block-scaled-mcp-12000-employees-15-job-functions
2. Ry Walker Research — Stripe Minions. Febrero de 2026. https://rywalker.com/research/stripe-minions
3. Engineering.fyi — Minions: Los agentes de codificación de extremo a extremo de una sola pasada de Stripe. Febrero de 2026. https://www.engineering.fyi/article/minions-stripe-s-one-shot-end-to-end-coding-agents
4. Stripe — Caso de estudio de Atlassian. https://stripe.com/customers/atlassian
5. Cloudflare — Repositorio mcp-server-cloudflare. Noviembre de 2024. https://github.com/cloudflare/mcp-server-cloudflare
6. Stripe — Caso de estudio de GitHub. http://stripe.com/customers/github
7. dev.to — Creación de un servidor MCP de pago con Cloudflare Workers y Stripe. Mayo de 2025. https://dev.to/hideokamoto/building-a-paid-mcp-server-with-cloudflare-workers-and-stripe-1m96
8. Medium — Cómo Stripe construyó agentes de IA seguros no supervisados que fusionan 1 000 solicitudes de extracción por semana. Febrero de 2026. https://medium.com/@oracle_43885/how-stripe-built-secure-unattended-ai-agents-merging-1-000-pull-requests-weekly-1ff42f3fe550
9. Cloudflare — Día de demostración de MCP: Cómo 10 empresas líderes de IA crearon servidores MCP. Mayo de 2025. https://blog.cloudflare.com/mcp-demo-day/
10. Better Programming — Datadog, Block y Cloudflare abandonaron el patrón MCP predeterminado. Marzo de 2026. https://betterprogramming.pub/i-built-3-mcp-servers-for-the-same-api-one-used-98-fewer-tokens-4b70c6eae6b8

Este documento técnico es un borrador público publicado por perea.ai Research bajo la licencia CC BY 4.0. Los comentarios, las correcciones y los casos de estudio son bienvenidos en research@perea.ai. El marco, la rúbrica de puntuación y la guía de implementación se publican para uso gratuito. Se agradece la atribución, pero no es obligatoria.

Versión 1.0 — Mayo de 2026