Un MCP server dentro de tu producto: cinco decisiones

Añadir un MCP server a tu propio editor es un cambio de configuración de cinco líneas y el radio de acción es tu máquina. Distribuir uno dentro de un producto que ejecutan otras personas es otra decisión. Heredas los permisos del servidor, su coste unitario y su modo de fallo en nombre de cada usuario, y cuando se inventa una fuente, el enlace falso lleva encima el nombre de tu producto, no el del modelo.

Acabamos de hacerlo. LightAudit Score es una consola gratuita y de código abierto que ejecuta Lighthouse contra localhost, staging y hosts tras una VPN a los que PageSpeed Insights no puede llegar. Haces clic en una puntuación baja y una IA lee los datos reales de la auditoría y devuelve correcciones priorizadas. Esas correcciones llevan citas solo cuando hay un servidor de investigación MCP conectado — y CrawlForge es la opción nombrada.

Este post es la arquitectura, no el argumento de venta. Cinco decisiones, y por cada una de ellas va a preguntar alguien en tu revisión de seguridad.

LightAudit Score se lanza pronto. El repositorio se hará público en breve, y cuando lo haga será gratuito y con licencia MIT — sin cuenta, sin licencia, sin límite de uso. Para que te avisen el día que salga, deja tu correo en lightauditscore.com: un solo email con el repositorio y la guía rápida, y nada más.

Índice

• Por qué una función de IA necesita un servidor de investigación
• Decisión 1: desactivado por defecto y honesto cuando falta
• Decisión 2: diez tools de veintinueve
• Decisión 3: la key del usuario nunca toca tu app
• Decisión 4: fija la versión, no la resuelvas al arrancar
• Decisión 5: nombra un servidor, admite cualquiera
• Lo que cuesta cada análisis
• La forma general

Por qué una función de IA necesita un servidor de investigación

Una puntuación de Lighthouse de 71 le dice a quien programa que algo va mal. No le dice cuál de las cuarenta auditorías atacar primero, y desde luego no le dice por qué. Ese es el hueco que cubre un panel de IA: leer el árbol de auditoría, nombrar la causa, ordenar las correcciones.

En el momento en que esas correcciones citan web.dev o developer.chrome.com, tienes un problema que no va de la calidad del modelo. Un modelo al que le pides citas producirá URLs plausibles las haya abierto o no. Pídele que no lo haga y casi siempre obedece — hasta la vez que no, que es justo la vez en que un cliente hace clic y se encuentra un 404 y deja de fiarse del panel entero.

Un servidor de investigación cierra ese bucle por mecánica, no por instrucción. El modelo solo puede citar una fuente que haya descargado mediante una llamada a una tool, porque la cita se compone a partir del resultado de la tool y no del recuerdo que el modelo tenga de la web. Es la misma propiedad de trazabilidad que hace útil a un servidor de datos web genérico en trabajos de due diligence: el valor no son los datos, es el camino auditable desde la afirmación hasta la página.

Decisión 1: desactivado por defecto y honesto cuando falta

El servidor de investigación es un interruptor en Ajustes, y arranca apagado.

Con él apagado, el análisis se diagnostica solo a partir de los datos de auditoría y el resultado lleva una etiqueta llana de Sin investigación web. Cada análisis va además sellado con el proveedor y el modelo que lo produjo. Nada se degrada en silencio, y nada se inventa una fuente para rellenar el hueco donde habría ido una cita.

Es la decisión que más equipos toman al revés. El instinto es hacer obligatoria la integración para que la función luzca siempre lo mejor posible; la consecuencia es que la credibilidad de tu función pasa a depender de que un tercero esté accesible. Degrádala de forma visible. Quien ve Sin investigación web sabe exactamente qué está leyendo. Quien ve una cita que resulta ser inventada ha aprendido algo mucho peor sobre tu producto.

Decisión 2: diez tools de veintinueve

CrawlForge expone veintinueve tools. A la ruta de análisis de LightAudit se le entregan diez: buscar, descargar, extraer, resumir. Los crawlers de sitios, los trabajos por lotes, la automatización de navegador y la investigación profunda se deniegan de plano.

El motivo es el coste unitario, no la paranoia. Una pasada de citas necesita encontrar una página y leerla. No necesita rastrear un dominio, y la diferencia aparece en la factura del usuario:

deep_research es la ilustrativa. Es la mejor tool del catálogo para una pregunta de investigación, y está denegada. Un modelo que eche mano de ella en cada puntuación baja convierte un análisis de 11 credits en uno de 10 más el abanico, y quien hizo clic en un anillo de puntuación no pidió un proyecto de investigación. La tool que más disfrutaría tu agente no es la tool que tu producto debería concederle.

Si te llevas una sola cosa de este post: enumera las tools que concedes. El catálogo de un MCP server es la idea que su autor tiene de lo útil, y la intersección con el trabajo de tu función suele ser un tercio de él.

Decisión 3: la key del usuario nunca toca tu app

LightAudit no reenvía nada al servidor de investigación. CrawlForge se autentica desde su propia configuración, escrita por su propio asistente de instalación, así que la API key del usuario nunca pasa por la app que se beneficia de ella.

Esa frase vale más en una revisión de seguridad que cualquier cantidad de retórica sobre cifrado en reposo, porque elimina la pregunta en lugar de responderla. No eres el custodio de una credencial de terceros. No hay key en tu base de datos que se filtre, ni key en tus logs que redactar, ni key en un paquete de soporte, ni párrafo de respuesta a incidentes que escribir sobre un proveedor que no controlas.

La forma general: cuando una integración puede autenticarse por su cuenta, déjala. Cada credencial que tu producto guarda en nombre de un usuario es un riesgo que asumiste para ahorrarle un paso de configuración.

Decisión 4: fija la versión, no la resuelvas al arrancar

Casi toda configuración MCP que vas a copiar de un README tiene esta pinta:

{
  "mcpServers": {
    "crawlforge": {
      "command": "npx",
      "args": ["-y", "crawlforge-mcp-server"],
      "env": {
        "CRAWLFORGE_API_KEY": "cf_live_YOUR_API_KEY_HERE"
      }
    }
  }
}

Esa es la configuración correcta para tu máquina y la equivocada para distribuir. -y suprime el aviso de instalación y un nombre de paquete pelado resuelve a lo que sea la última versión en el momento de arrancar, lo que significa que el código que tus clientes ejecutan mañana es código que nadie de tu equipo ha leído. Es una decisión de cadena de suministro disfrazada de flag de comodidad.

Fíjala:

{
  "mcpServers": {
    "crawlforge": {
      "command": "npx",
      "args": ["-y", "crawlforge-mcp-server@5.6.6"]
    }
  }
}

Después mueve la subida de versión a tu revisión de dependencias habitual, donde una persona lee un changelog antes de que tus usuarios reciban comportamiento nuevo. Esto te cuesta una pull request cada pocas semanas. La alternativa te cuesta un incidente que no puedes reproducir, porque la versión que lo causó ya no es lo que resuelve latest.

Decisión 5: nombra un servidor, admite cualquiera

LightAudit nombra a CrawlForge en su documentación y no distribuye nada. Cualquier servidor de investigación declarado en un .mcp.json estándar será el que se use en su lugar.

Esto no es altruismo, es cómo se sobrevive a una conversación de compras. Una dependencia MCP que tu comprador no puede sustituir es una pregunta sobre cautividad en cada revisión corporativa en la que te vayas a sentar. Como MCP es un protocolo y no un SDK, respetar el fichero de configuración estándar no te cuesta prácticamente nada y convierte el "¿a qué proveedor estáis atados?" en "al que tú prefieras".

También te mantiene honesto. Un valor por defecto nombrado pero sustituible tiene que seguir siendo la mejor opción por méritos.

Lo que cuesta cada análisis

Un análisis es una búsqueda y unas cuantas lecturas:

Los análisis se guardan junto con la ejecución, así que reabrir un informe no cuesta nada — la segunda persona que lea el mismo informe gasta cero credits. Una cuenta nueva de CrawlForge empieza con 1.000 credits gratis y sin tarjeta, que son unos noventa análisis con citas antes de que nadie tome una decisión de compra. El precio por tool está en la página de precios.

Ese número es el que hay que calcular antes de conectar el servidor, no después. Las tools que concede tu función y el número de veces que las llama son las dos variables de la factura de tus clientes, y la primera queda fijada en el momento de diseñar.

La forma general

Quita lo específico de Lighthouse y las mismas cuatro preguntas valen para cualquier MCP server que metas dentro de un producto que distribuyes:

1. ¿Cuál es el radio de acción? Enumera las tools concedidas. Deniega el resto por nombre.
2. ¿Quién guarda la credencial? Si el servidor puede autenticarse solo, no la guardes tú por él.
3. ¿Cuál es el coste unitario? Calcúlalo por acción del usuario, no por mes.
4. ¿Qué pasa cuando no está? Degrádate de forma visible. Una función que falta es recuperable; una función inventada no.

Nada de esto es exótico. Es la misma disciplina que aplicarías a cualquier llamada a un tercero en una ruta caliente — lo que pasa es que con los MCP servers se suele saltar, porque la configuración son cinco líneas y parece un cambio de ajustes en vez de una dependencia.

LightAudit Score se lanza pronto. Es gratuito, con licencia MIT y se ejecuta enteramente en tu propia máquina, y el repositorio se hará público en breve. Si quieres ver este patrón funcionando en vez de descrito, la web tiene el desglose completo de funciones y una lista de acceso anticipado que te mandará el enlace el día que salga — y el servidor de investigación que nombra es el que acabas de estar leyendo.