Cursor lleva Team MCPs al marketplace: el punto ya no es instalar tools, es gobernarlas

Cursor publicó el 30 de junio de 2026 una mejora que parece administrativa, pero toca el núcleo de los agentes de coding en equipos: Team Marketplaces ahora soporta Team MCPs y grupos de organización. En palabras prácticas, un admin puede configurar servidores MCP una vez y distribuirlos a cloud agents, Agents Window, IDE y CLI sin pedirle a cada persona que copie JSON, tokens o instrucciones sueltas.

La noticia no es "Cursor tiene más plugins". La noticia es que las herramientas de los agentes empiezan a parecerse a infraestructura administrada. Si un agente puede leer issues, consultar datos, abrir PRs o tocar servicios internos, instalarlo por entusiasmo individual deja de ser suficiente.

Por qué esto importa para equipos

El patrón débil es conocido: una persona configura un MCP server local, otra usa una versión distinta, alguien pega un token en un archivo, y el equipo termina sin saber qué herramientas están realmente disponibles para sus agentes.

Team MCPs cambia el contrato. Cursor dice que esos servidores se pueden configurar desde Dashboard -> Integrations & MCP y luego hacerlos disponibles en el marketplace del equipo. Eso permite que el mismo conector llegue a agentes de nube, sesión local, IDE y CLI con menos drift entre entornos.

Para builders de Latinoamérica que están pasando de "mi agente local funciona" a "mi equipo quiere usarlo", la decisión útil es esta: cada MCP que llegue a producción debería tener dueño, alcance, documentación y forma de revocación. Un marketplace de equipo no resuelve todo, pero vuelve visible el inventario.

La parte nueva: grupos de organización

Cursor también agregó acceso por organization groups para Team Marketplaces, además de grupos SCIM a nivel de equipo. Eso permite restringir qué marketplace ve cada grupo desde Dashboard -> Plugins -> Team Marketplaces.

La diferencia importa. No todos necesitan el mismo set de tools. Un equipo de soporte puede necesitar CRM, logs y documentación; un equipo de plataforma puede necesitar deploy, métricas y cloud; un equipo de data puede necesitar notebooks y warehouse. Mezclarlos en una sola lista hace que el agente tenga demasiadas llaves y demasiada superficie para equivocarse.

Checklist antes de mover MCPs al equipo

Yo no activaría un marketplace compartido sin revisar cinco puntos.

Primero, separa MCPs de lectura y escritura. Un conector que solo consulta docs no tiene el mismo riesgo que uno que modifica tickets, despliega código o escribe en una base.

Segundo, documenta para qué casos se debe usar cada server. Un agente con diez tools parecidas puede elegir la incorrecta si el nombre y la descripción no son claros.

Tercero, prueba desde todas las superficies que Cursor menciona: cloud agent, Agents Window, IDE y CLI. Si una credencial funciona solo localmente, el fallo aparecerá justo cuando delegues trabajo largo.

Cuarto, evita que el marketplace se vuelva basurero. Lo que nadie usa o nadie mantiene debería salir.

Quinto, guarda evidencia: qué servidor se aprobó, quién lo administra, qué permisos pide y qué grupos lo reciben.

Señales de demanda

No hay SEO tooling conectado en esta corrida. La demanda se infiere por señales actuales: changelog oficial reciente, marketplace público de Cursor, adopción de MCP en coding agents y búsquedas previsibles como Cursor Team MCP, Cursor team marketplace, Cursor MCP organization groups y Cursor cloud agents MCP.

Agente IA puede competir porque la cobertura en español suele quedarse en instalar MCPs uno por uno. El ángulo útil para builders es otro: cuándo un MCP deja de ser configuración personal y pasa a ser control de plataforma.

Si todavía estás armando el loop base de herramientas y verificación, empieza por el curso gratis. Si ya estás distribuyendo agentes a más personas, la lección de Cursor es directa: el problema dejó de ser "conectar una tool" y pasó a ser gobernar el catálogo que tus agentes pueden usar.