Esta es una guía completa para enviar tu servidor local (MCPB) al directorio público de Anthropic para una distribución y descubribilidad más amplia.
Requisitos previos
Antes de leer esta guía, deberías tener:
Un MCPB funcional
Código portátil usando sustitución de variables
Mensajes de error y experiencia de usuario de calidad
Dependencias limpias y agrupadas
¿Nuevo en el desarrollo de MCPB? Consulta Construyendo extensiones MCPB primero. Para mejores prácticas técnicas (pruebas, mensajes de error, portabilidad), consulta Repositorio MCPB.
Nota: Esta guía cubre servidores MCP locales. Para extensiones de escritorio remotas, consulta Guía de envío de servidor MCP remoto.
1. Descripción general del directorio
¿Cuáles son los beneficios de la inclusión en el directorio?
Descubribilidad y confianza:
Listado en el directorio oficial de Anthropic dentro de Claude Desktop
Buscable por usuarios individuales de Claude Desktop
Visible para usuarios de Teams/Enterprise cuando se agrega a la lista de permitidos por administradores
La revisión de Anthropic genera confianza del usuario
Experiencia del usuario:
Instalación con un clic desde el directorio
Integrado con la interfaz de usuario de configuración de Claude Desktop
Presentación estandarizada
Soporte y credibilidad:
Revisión de Anthropic de calidad y seguridad
Listado junto con otras extensiones revisadas
Visibilidad comunitaria y retroalimentación
Canal de distribución profesional
2. Requisitos obligatorios
Todos los requisitos en esta sección son obligatorios para la aprobación del directorio. La falta de cualquiera de estos resultará en rechazo o una solicitud de revisión.
Nota: Estos son requisitos específicos del directorio de Anthropic.
Para mejores prácticas generales de desarrollo de MCPB (pruebas, manejo de errores, portabilidad), consulta el README del repositorio MCPB.
¿Se requieren anotaciones de herramientas?
SÍ. Cada herramienta DEBE tener y mantener anotaciones de seguridad precisas.
Requerido en cada herramienta:
readOnlyHint: true - Para herramientas que solo leen datos
destructiveHint: true - Para herramientas que modifican datos o tienen efectos secundarios
Consulta Protocolo MCP - Anotaciones de herramientas para el esquema completo y detalles de implementación.
No es opcional. Este es un requisito obligatorio derivado de la Política del directorio MCP.
Cómo decidir qué anotación usar:
Comportamiento de la herramienta | Anotación | Ejemplos |
Solo lee datos | readOnlyHint: true | search, get, list, fetch, read |
Escribe/modifica datos | destructiveHint: true | create, update, delete, send, write |
Crea archivos temporales | destructiveHint: true | Incluso las escrituras temporales cuentan |
Envía solicitudes externas | destructiveHint: true | Correos electrónicos, notificaciones, webhooks |
Solo almacena en caché internamente | readOnlyHint: true | Optimización interna OK |
Detalles de implementación: Consulta Protocolo MCP - Herramientas para:
Esquema completo de herramientas con anotaciones
Estructura de definición de herramientas
Especificaciones de esquema de entrada/salida
Propiedades adicionales de herramientas (incluyendo campo de título opcional)
Validación antes del envío:
# Verificar que todas las herramientas tengan anotaciones
grep -A 5 -B 5 "readOnlyHint\|destructiveHint" server/
# Verificar que cada herramienta tenga exactamente una anotación
Impacto: Lo primero que verificamos y la razón más común para una solicitud de revisión.
Anotación adicional recomendada:
title - Nombre de herramienta legible por humanos para mostrar en la interfaz de usuario (mejora la experiencia del usuario)
¿Se requieren políticas de privacidad?
Sí, se requieren políticas de privacidad en dos ubicaciones:
Ubicación 1: README.md
Agrega una sección "Política de privacidad" a tu README con un enlace a tu política de privacidad completa para que los usuarios sean conscientes de tus prácticas:
## Política de privacidad
Esta extensión recopila [describe tipos de datos]. Para información completa de privacidad, consulta nuestra política de privacidad: https://tu-dominio.com/politica-privacidad
### Recopilación de datos
- [Lista qué datos se recopilan]
- [Cómo se usan]
- [Si se comparten con terceros]
- [Período de retención]
Ubicación 2: manifest.json
Agrega matriz privacy_policies con URLs HTTPS accesibles públicamente:
Implementación completa: Consulta Especificación del manifiesto MCPB - Políticas de privacidad para:
Estructura del campo de política de privacidad
Requisitos de versión del manifiesto (0.3+)
Soporte para múltiples URLs de política
Requisitos de validación
La política de privacidad debe cubrir:
Qué datos recopila tu MCPB
Cómo se usan y almacenan los datos
Si los datos se comparten con terceros
Políticas de retención de datos del usuario
Información de contacto para preguntas de privacidad
Requisitos:
Debe ser una URL HTTPS accesible públicamente
Debe ser de tu dominio (no alojamiento de terceros)
Debe ser actual y precisa
Debe estar en README Y manifest.json
Debe usar manifest_version "0.3" o superior
Errores comunes:
Política de privacidad en el manifiesto pero no en README
Política de privacidad en README pero no en el manifiesto
Usando manifest_version "0.2" o anterior
URLs inválidas o inaccesibles
Política de privacidad alojada en sitio de terceros
Impacto: Una de las causas más comunes de rechazo - sencilla de corregir pero frecuentemente pasada por alto.
¿Cuántos ejemplos se requieren?
MÍNIMO de tres ejemplos funcionales que demuestren la funcionalidad principal.
Qué califica como un buen ejemplo:
Muestra un caso de uso realista
Incluye entrada/indicación del usuario esperada
Muestra salida/comportamiento esperado
Demuestra uso real de herramientas
Flujo de trabajo claro y comprensible
Formato de ejemplo (en README.md):
## Ejemplos
### Ejemplo 1: Buscar archivos
**Indicación del usuario:** "Encuentra todos los archivos JavaScript en mi proyecto"
**Comportamiento esperado:**
- La extensión busca en el directorio del espacio de trabajo
- Devuelve lista de archivos .js con rutas
- Muestra el recuento de archivos en el resumen
### Ejemplo 2: Leer contenido de archivo
**Indicación del usuario:** "Muéstrame el contenido de config.json"
**Comportamiento esperado:**
- La extensión lee config.json
- Devuelve contenido JSON formateado
- Maneja gracefully archivo no encontrado
### Ejemplo 3: Crear nuevo archivo
**Indicación del usuario:** "Crea un nuevo archivo llamado notes.txt con 'Hola Mundo'"
**Comportamiento esperado:**
- La extensión crea notes.txt
- Escribe contenido en el archivo
- Confirma creación con ruta del archivo
Qué incluir:
Indicaciones de usuario realistas (cómo los usuarios interactuarán)
Llamadas de herramientas esperadas (qué sucede detrás de escenas)
Salidas esperadas (qué verán los usuarios)
Ejemplos de manejo de errores (opcional pero recomendado)
Requisitos:
Mínimo 3 ejemplos (sin máximo)
Cubren funcionalidad principal
Muestran diferentes herramientas/capacidades
Demuestran propuesta de valor
Incluidos en README.md
Impacto: Una fuente frecuente de retrasos o rechazos - los revisores necesitan documentación completa para evaluar adecuadamente los envíos.
¿Necesito proporcionar credenciales de prueba?
Si tu MCPB requiere autenticación o acceso a servicio externo, entonces SÍ.
Requerido cuando:
Tu MCPB se conecta a APIs externas
Se necesita autenticación para la funcionalidad
El usuario de MCPB debe tener una cuenta para usar características
Integración de servicio externo de otra manera presente
No requerido cuando:
MCPB puramente local (solo operaciones del sistema de archivos)
Sin conexiones externas
Sin autenticación necesaria
Completamente autónomo
Qué proporcionar:
Credenciales de cuenta de prueba (nombre de usuario/contraseña o claves API)
Datos de muestra en cuenta (útil para pruebas funcionales)
Instrucciones de configuración (cómo configurar y usar la cuenta de prueba)
Limitaciones o restricciones de acceso (si las hay)
Fecha de expiración de la cuenta (si es temporal)
Cómo proporcionar:
Incluir en formulario de envío
Enviar por método seguro si es altamente sensible
Asegurar que la cuenta permanezca activa durante el período de revisión
Proporcionar nivel de acceso suficiente para pruebas completas
Mejor práctica: Crear cuenta de prueba dedicada separada de la producción para:
Evitar exponer datos de producción
Controlar qué pueden acceder los revisores
Revocar fácilmente acceso después de aprobación
Rastrear uso de cuenta de prueba
Impacto: Retrasa el proceso de revisión si falta cuando es necesario
¿Qué documentación se requiere?
Documentación completa en README.md con secciones mínimas requeridas.
Secciones mínimas requeridas:
Descripción - Explicación clara de qué hace tu MCPB
Características - Capacidades clave y casos de uso
Instalación - Cómo instalar (típicamente: "Instalar desde el directorio de Anthropic")
Configuración - Pasos de configuración y configuración requerida
Ejemplos de uso - Mínimo 3 ejemplos (ver sección anterior)
Política de privacidad - Enlace a política de privacidad completa
Soporte - Cómo los usuarios pueden obtener ayuda o reportar problemas
Estructura de ejemplo README.md:
# Mi extensión MCPB
## Descripción
Breve descripción de qué hace esta extensión y por qué es útil.
## Características
- Característica 1: [descripción]
- Característica 2: [descripción]
- Característica 3: [descripción]
## Instalación
Instala desde el directorio de Anthropic en Configuración de Claude Desktop → Extensiones.
## Configuración
1. Abre Configuración → Extensiones → [Nombre de la extensión]
2. Agrega clave API (si es requerida)
3. Selecciona directorio del espacio de trabajo
4. Configura ajustes opcionales
## Ejemplos
[Ver sección de mínimo 3 ejemplos anterior]
## Política de privacidad
Consulta nuestra política de privacidad: https://tu-dominio.com/privacidad
## Soporte
Para problemas o preguntas: [email protected]
Problemas de GitHub: https://github.com/tu-usuario/tu-extension/issues
Secciones adicionales recomendadas:
Solución de problemas - Problemas comunes y soluciones
Compatibilidad de versión - Qué versiones de Claude Desktop se soportan
Registro de cambios - Historial de versiones y cambios
Contribuyendo - Cómo otros pueden contribuir (para código abierto)
Mejores prácticas:
Escritura clara y concisa
Capturas de pantalla (opcional pero muy útil)
Instrucciones paso a paso
Enlaces a recursos adicionales
3. Proceso de envío
¿Cómo envío al directorio?
Antes de enviar al directorio, completa este proceso de envío paso a paso:
1. Lista de verificación previa al envío:
Prueba tu MCPB:
Pasa todas las 4 fases de prueba (desarrollo, entorno limpio, multiplataforma, Claude Desktop)
Funciona en entorno limpio sin herramientas de desarrollo
Portátil entre macOS y Windows
Dependencias actuales y agrupadas
Los mensajes de error son útiles y accionables
El rendimiento es aceptable
Verifica requisitos obligatorios:
Todas las herramientas tienen anotaciones readOnlyHint O destructiveHint
Política de privacidad presente en README.md
Política de privacidad presente en matriz privacy_policies de manifest.json
Usa la versión de manifiesto más reciente para mejor compatibilidad
Mínimo 3 ejemplos funcionales documentados en README
Credenciales de prueba proporcionadas (si aplica)
Prepara documentación:
README.md completo con todas las secciones requeridas
Archivo LICENSE incluido
Icono incluido (recomendado, PNG 512×512px)
CHANGELOG.md (opcional pero recomendado)
2. Empaqueta versión final:
# Compilación limpia
rm -rf node_modules/.cache
npm install --production
# Empaquetar
mcpb pack
# Verificar paquete
mcpb info tu-extension.mcpb
3. Envía a través del formulario oficial:
Formulario de envío: https://forms.gle/tyiAZvch1kDADKoP9
Información requerida: Detalles del servidor, enlaces de documentación, credenciales de prueba, ejemplos (mínimo 3) e información de contacto. El formulario proporciona una lista completa.
Aunque nos esforzamos por revisar cada envío lo más rápido posible, debido a la cantidad de interés no podemos prometer que aceptaremos tu envío o responderemos a él individualmente.
4. Problemas comunes
¿Cuáles son las razones más comunes para solicitudes de revisión?
Estos son los principales problemas basados en datos de envío:
1. Anotaciones de herramientas faltantes
Problema: Herramientas sin anotaciones requeridas readOnlyHint o destructiveHint
Solución: Agrega anotaciones a TODAS las herramientas en tu implementación de servidor
Impacto: Rechazo inmediato, requiere cambios de código
Prevención: Ejecuta comando de validación antes del envío
2. Problemas de portabilidad
Problema: Funciona en entorno de desarrollador pero falla para usuarios finales
Causas comunes: Rutas codificadas, dependencias faltantes, suposiciones de plataforma
Solución: Prueba en entorno limpio, usa sustitución de variables, agrupa dependencias
Impacto: Retraso de 1-2 semanas para solución de problemas y re