Las herramientas MCP de btlabs Core combinan un modelo de lenguaje con contenido y funciones de sistema limitadas de forma controlada: el modelo de lenguaje puede sugerir una llamada a una herramienta, el cliente MCP gestiona los permisos y el acceso, y el servidor MCP ejecuta la llamada autorizada. Es fundamental tener en cuenta no solo la disponibilidad técnica, sino también qué herramienta ha sido autorizada para cada cliente, rol y propósito.
El Protocolo de Contexto de Modelo (MCP) estandariza la conexión entre aplicaciones con modelos de lenguaje y datos o funciones externas. En btlabs Core, las herramientas MCP están diseñadas para reducir el trabajo repetitivo sin provocar accidentalmente lanzamientos, cambios de permisos u otras decisiones importantes.
Una entrada en el catálogo de herramientas constituye una oferta técnica. Solo una clase de derechos adecuada, un propósito permitido y un estado de lanzamiento documentado hacen que el uso real de la herramienta sea operativamente admisible.
Herramientas MCP en btlabs Core: Roles y flujo de trabajo
La arquitectura MCP distingue entre host, cliente y servidor. En la versión de la especificación utilizada, con fecha del 28 de julio de 2026, el host coordina los clientes y las reglas de seguridad. Cada cliente MCP se comunica con un servidor MCP específico, mientras que el servidor proporciona herramientas y otras funciones.
- Modelo de lenguaje: El modelo interpreta la tarea y puede sugerir una herramienta adecuada. El modelo de lenguaje no proporciona la herramienta ni otorga ningún permiso.
- Anfitrión: La aplicación coordina el modelo de lenguaje, los clientes MCP, la interacción del usuario y las reglas de seguridad.
- Cliente MCP: El cliente conecta el host a un servidor MCP, procesa el catálogo de herramientas visible y transmite las llamadas permitidas.
- Servidor MCP: El servidor proporciona las herramientas MCP definidas y ejecuta las llamadas dentro de los permisos otorgados.
- Persona responsable: Los seres humanos evalúan las acciones delicadas o de gran trascendencia y aprueban o rechazan su ejecución.
Una llamada controlada se desarrolla en siete pasos:
- Un usuario o el modelo de lenguaje sugiere una tarea.
- El cliente MCP realiza consultas con herramientas/lista las herramientas visibles en el contexto actual.
- El cliente verifica el cliente, el rol, la clase de derechos, el propósito y el estado de la publicación.
- Para las acciones que requieren aprobación, el anfitrión solicita autorización humana.
- El cliente MCP envía la llamada confirmada con herramientas/llamada al servidor MCP.
- El servidor MCP ejecuta la herramienta y devuelve un resultado o un error.
- La llamada, el resultado, el estado de la versión y la decisión de lanzamiento quedan documentados en el registro de auditoría.
El contexto operativo debe establecerse mediante identidades únicas, roles, información del cliente, parámetros y permisos. Un permiso previo no debe considerarse automáticamente válido para una solicitud posterior.
Estado de referencia del catálogo de herramientas MCP de btlabs
Es necesario generar un catálogo fiable de herramientas MCP para btlabs Core directamente desde la implementación desplegada. Si bien los datos de la empresa especifican un punto final técnico para las herramientas, no incluyen una exportación verificada con los nombres, permisos e información de versión de las herramientas. Por lo tanto, este artículo no proporciona un número total fijo ni una lista de nombres no confirmados de las herramientas MCP de btlabs supuestamente implementadas.
- producto: Núcleo de btlabs
- Versión del producto: no se muestra en el conjunto de datos actual
- Versión del catálogo de herramientas: no se muestra en el conjunto de datos actual
- Plazo límite para la exportación técnica: no se muestra
- Revisión técnica responsable: no se muestra
- Nombres de herramientas MCP validados individualmente: La documentación no es posible sin una exportación de servidor verificada.
Hasta que dicha exportación esté disponible, el artículo describe un modelo de gobernanza y documentación. Las áreas funcionales mencionadas no constituyen un compromiso con los puntos finales de MCP individuales.
Información obligatoria para cada herramienta real
Cada entrada en el catálogo de herramientas MCP debe contener al menos la siguiente información:
- Nombre técnico: Nombre único para herramientas/llamada
- Tarea operativa: descripción comprensible del propósito específico
- Alcance de los datos: contenido, campos o estados del sistema accesibles
- Clase de derechos: Leer, escribir, ejecutar o gestionar
- Estado de lanzamiento: Permitido automáticamente, sujeto a consentimiento, restringido o deshabilitado
- Impacto externo: posible publicación, comunicación, intercambio de datos o cambio de sistema
- Relación con el cliente: Espacio de datos y autorización claramente definido
- Versión: Versión del producto y versión de la definición de la herramienta
- Fecha límite: Fecha de la última inspección técnica
En el artículo sobre la arquitectura de btlabs Core , explico la estructura técnica del repositorio central de contenido y datos . La base de datos compartida está diseñada para evitar que el sitio web, las versiones lingüísticas y la salida legible por máquina utilicen información de empresas diferentes.
Las funciones internas no son automáticamente herramientas MCP.
Una función interna del sistema, una interfaz de usuario y una herramienta accesible a través de MCP son tres cosas distintas. Por lo tanto, una función solo puede designarse como una herramienta MCP disponible cuando el catálogo del servidor actual incluya su nombre técnico, parámetros y estado de lanzamiento.
Designar como herramienta MCP únicamente tras verificación técnica.
- Lectura de un registro de contenido específico mediante una llamada MCP con nombre.
- Creación o actualización de un borrador no público
- Comprobando las versiones en idiomas relacionados
- Realizar una verificación de SEO, GEO o de integridad.
- Consulta del estado de una versión o del registro de auditoría
- Desencadenar un proceso de publicación o gestión
Las fases de expansión planificadas no constituyen un compromiso de producto actual.
- Agentes de IA para reservas
- Funciones de tienda e inventario
- áreas protegidas para clientes
- Calculadora de precios en tiempo real y visualización de citas
- Aplicaciones u otras ubicaciones basadas en los mismos datos.
Una función técnicamente preparada no se activa ni se libera automáticamente. El proyecto específico, la implementación y el catálogo de herramientas actual siguen siendo factores determinantes.
tools/list muestra las herramientas, pero no otorga permisos.
El comando `tools/list` consulta las herramientas que ofrece el servidor MCP. La especificación de herramientas de MCP permite que el alcance visible dependa de la autorización enviada y de los permisos otorgados.
Para btlabs Core, `tools/list` solo debería devolver las herramientas MCP que el inquilino y el rol actuales tengan autorización para ver. Si una instalación específica ya aplica este filtrado, se debe confirmar mediante una prueba técnica en la fecha límite documentada.
tools/list responde a la pregunta: "¿Qué herramientas se me ofrecen?". La respuesta no otorga automáticamente permiso para todos los posibles efectos de estas herramientas.
El comando `tools/call` transmite el nombre de la herramienta y los argumentos necesarios al servidor MCP. Antes de la ejecución, la identidad, el cliente, la clase de privilegio y el estado de los permisos deben coincidir con la llamada planificada.
Cuatro clases de privilegios MCP para btlabs Core
Las cuatro clases de derechos MCP constituyen un modelo de gobernanza operativa para btlabs Core. La especificación MCP no define estas clases como niveles de autorización normativos.
- leer: Busca, visualiza, compara y revisa el contenido sin modificar los datos ni las condiciones.
- Escribir: Crea borradores, actualiza campos o cambia asignaciones. Este derecho no incluye automáticamente la publicación ni la eliminación.
- Realizar: para iniciar un proceso limitado, como una inspección o una etapa de procesamiento reversible.
- Administrar: Modificar roles, derechos, exportaciones, configuraciones globales o estados de todo el sistema.
Los permisos se otorgan según el principio de mínimo privilegio : un usuario, servicio o agente recibe únicamente los derechos necesarios para una tarea claramente definida. El permiso se aplica a un cliente específico, áreas de datos definidas y, cuando sea posible, a un período de tiempo limitado.
Mi experiencia trabajando con pequeñas empresas demuestra que los roles predeterminados demasiado amplios generan más riesgos que las herramientas claramente definidas. Un proceso editorial no se vuelve más seguro simplemente otorgando derechos administrativos a todos los participantes como medida de precaución.
La separación de clientes protege los datos y las responsabilidades.
La separación de clientes impide que una herramienta mezcle datos de diferentes empresas, sitios web o unidades organizativas. Una llamada MCP para la Empresa A no debe acceder al contenido de la Empresa B ni utilizar sus recursos compartidos o registros.
- Cada solicitud requiere una identidad de cliente única.
- Los roles y derechos se asignan de forma individualizada para cada cliente.
- El acceso a los datos y los protocolos siguen siendo independientes.
- Las aprobaciones previas no se pueden transferir a un contexto de cliente diferente.
- La llamada se interrumpirá si existe un conflicto con la referencia del cliente o del rol.
Una interfaz de usuario común no debe debilitar los límites de seguridad de las empresas individuales.
¿Qué herramientas de MCP requieren aprobación humana?
La especificación de la herramienta MCP no impone un modelo de interacción específico. Sin embargo, recomienda llamadas a herramientas visibles, diálogos de confirmación y la intervención de un usuario humano con la opción de rechazar la acción. Para btlabs Core, esto se traduce en un modelo operativo más estricto para las acciones con consecuencias.
Todavía se requiere la aprobación humana para:
- Publicaciones: El contenido se vuelve visible públicamente.
- Eliminaciones finales: Se pueden perder datos y romperse los enlaces.
- Cambios en los derechos: El marco de seguridad para las llamadas posteriores está cambiando.
- Exportación: Los datos pueden salir del área de procesamiento prevista.
- Comunicación externa: Los correos electrónicos, las ofertas o las reservas pueden tener consecuencias para el negocio.
- Intervenciones a nivel de todo el sistema: Los cambios globales pueden afectar a múltiples contenidos, idiomas o sitios web.
La autorización debe especificar qué herramienta procesa qué datos y con qué efecto previsto. Un permiso general sin propósito, alcance ni período de validez es insuficiente.
Qué debe documentar un registro de auditoría
Un registro de auditoría permite rastrear las llamadas a las herramientas, los errores y las decisiones de lanzamiento. El registro solo debe contener la información necesaria para la seguridad, el análisis de errores y la rendición de cuentas.
- Identidad: usuario, servicio o agente que activa el proceso
- Cliente: Datos afectados y área de responsabilidad
- Trabajo: Nombre técnico y versión de la herramienta
- Tiempo: Inicio, fin y duración de la llamada
- Clase de derechos: nivel de autorización utilizado
- Estado de lanzamiento: aprobado, confirmado, rechazado o caducado
- Parámetro: Datos de entrada requeridos en un formato que minimice los datos.
- Resultado: Cambio, devolución, cancelación o error
- Decisión de liberación: persona responsable y tiempo
- Versión: Versión del núcleo de btlabs y catálogo de herramientas
Las contraseñas, los tokens de acceso, las claves de seguridad y los datos personales innecesarios no deben figurar en el registro de auditoría. La trazabilidad y la minimización de datos deben planificarse conjuntamente.
Ejemplo práctico: Actualización controlada de contenido multilingüe
Anterior: Los cambios se transfirieron varias veces.
Una pequeña empresa turística está actualizando sus horarios de apertura y descripciones de servicios en alemán e italiano. Un empleado busca las páginas relevantes, transfiere cada cambio individualmente y verifica los metadatos y los enlaces de idioma. Es posible que quede información obsoleta en una de las versiones lingüísticas.
Después: revisar, guardar como borrador y publicar.
- El empleado selecciona el contenido y el cliente que cumple los requisitos.
- El cliente MCP utiliza tools/list para recuperar las herramientas MCP visibles para el rol editorial.
- Una herramienta de lectura validada compara el contenido en alemán e italiano.
- El modelo lingüístico pone de relieve las posibles inconsistencias y sugiere cambios.
- Una herramienta de escritura crea borradores exclusivamente privados.
- Una herramienta de verificación comprueba los hechos, las relaciones lingüísticas, los metadatos y los campos obligatorios.
- El empleado recibe una lista de cambios con el valor inicial y el valor propuesto.
- Solo después de la aprobación humana, el cliente MCP envía las herramientas/llamadas válidas al servidor MCP.
- La herramienta, el cambio, la versión y el resultado quedan documentados en el registro de auditoría.
Caso de error y reinicio
Si el servidor MCP devuelve un error o el miembro del personal detecta un cambio incorrecto, la publicación se detiene. El borrador permanece separado de la última versión pública válida.
El editor responsable corrige el borrador o lo restaura a la versión anterior. Se registra el estado del error y la restauración. Se ahorra tiempo mediante búsquedas, comparaciones y borradores preparados, en lugar de publicaciones sin revisar.
Introducir herramientas MCP con privilegios mínimos.
No recomiendo el acceso completo inmediato para pequeñas empresas. Un proyecto piloto limitado permitirá determinar si la herramienta, la calidad de los datos y las responsabilidades se ajustan a sus necesidades.
- Limitar la tarea: Elija un caso de uso claro, como por ejemplo comparar dos versiones de un idioma.
- Comienza a leer: Inicialmente, solo se permitirá buscar, recuperar y comparar el contenido seleccionado.
- Defina el área de clientes: Limite la prueba a un solo sitio web o área de contenido.
- Verificar resultados: Compare la salida de la herramienta con los datos de origen reales.
- Específicamente, agregue permisos de escritura: Después de eso, solo se permitirán borradores no públicos.
- Versión de prueba: Simular la publicación, el rechazo, los errores y la reversión.
- Comprobar permisos: Elimine los roles no utilizados y las credenciales de acceso caducadas.
La guía práctica sobre las directrices de IA en las PYMES le ayuda a regular las responsabilidades y los datos permitidos más allá de las llamadas individuales a las herramientas.
Información de estado en el catálogo de herramientas MCP
- Accesible: La herramienta está implementada en la versión documentada, activada para el cliente y utilizable con el rol asignado.
- Disponibilidad limitada: La herramienta requiere configuración adicional, clase de permisos o aprobación humana.
- personas con discapacidad: Esta herramienta no se ofrece al cliente ni al cliente de MCP en cuestión.
- Etapa de expansión preparada: La arquitectura puede incorporar una función futura; actualmente, dicha función no está disponible ni se ha prometido.
Un estado de lanzamiento sin número de versión está incompleto. El estado, la versión de la herramienta y la fecha de lanzamiento siempre deben documentarse conjuntamente.
Guía de selección de herramientas MCP
Antes de activar una herramienta, debe responder a las siguientes preguntas:
- objetivo: ¿Qué cuello de botella operativo específico resuelve la herramienta?
- Datos: ¿Qué contenido o datos personales puede procesar la herramienta?
- Cliente: ¿A qué espacio de datos definido se aplica el acceso?
- Clase de derechos: ¿Es suficiente con leer, o se requieren derechos adicionales?
- Impacto externo: ¿Puede la solicitud publicar, comunicar, exportar o modificar derechos?
- Recuperabilidad: ¿Se puede deshacer por completo una acción errónea?
- Liberar: ¿Quién es el responsable?
- Explotación florestal: ¿Qué información aparece en el registro de auditoría?
- Referencia de versión: ¿Para qué versión del producto y de la herramienta se probó el proceso?
Si una pregunta queda sin respuesta, la herramienta debe permanecer desactivada o utilizarse inicialmente con acceso de solo lectura en un entorno de prueba. Por lo tanto, al asesorar sobre IA y digitalización, analizamos no solo la conexión técnica, sino también el propósito, la calidad de los datos, la responsabilidad y la reversibilidad.
Preguntas sobre el catálogo de herramientas MCP de btlabs Core
¿Qué son las herramientas MCP?
Las herramientas MCP son funciones estructuradas que un servidor MCP ofrece a un cliente MCP compatible. Una herramienta puede leer datos, editar un diseño o ejecutar un proceso limitado, siempre que el rol y el estado de la versión lo permitan.
¿Quién ejecuta técnicamente una llamada MCP?
El modelo de lenguaje puede sugerir el uso de una herramienta, pero no ejecuta la acción del sistema por sí mismo. El cliente MCP envía la llamada válida; el servidor MCP ejecuta la herramienta proporcionada.
¿La lista de herramientas ya tiene algún permiso?
No. `tools/list` muestra las herramientas que el servidor devuelve para el contexto actual. Es posible que se requieran privilegios adicionales o aprobación humana para una llamada específica a `tools/call`.
¿La opción tools/list siempre muestra el catálogo completo del servidor?
La especificación MCP permite limitar el alcance visible según la autorización. Para confirmar si una instalación específica de btlabs Core filtra por cliente y rol, se debe realizar una prueba técnica en la fecha límite documentada.
¿Qué acciones requieren aprobación humana?
Las publicaciones, las eliminaciones permanentes, los cambios de derechos, las exportaciones sensibles, las comunicaciones externas y las intervenciones en todo el sistema están sujetas a aprobación. La decisión debe asignarse a una persona responsable y documentarse en el registro de auditoría.
¿Cómo puedo identificar la versión actual?
Una entrada fiable especifica la versión del producto, la versión del catálogo de herramientas, la versión de la herramienta, el estado de lanzamiento y la fecha de vigencia. Si falta esta información, la entrada no es una referencia de producto fiable ni actualizada.
¿Qué ocurre si hay un error?
El servidor MCP devuelve un error; los pasos de escritura o publicación dependientes se detienen. Los cambios reversibles se revierten al último estado válido por el rol responsable y se registran.
¿Puede un agente ampliar sus propios derechos?
No. Un agente no puede cambiar su clase de privilegio ni omitir los pasos de aprobación ni los límites del cliente. Los cambios de privilegio corresponden a la clase de Gestión y requieren una decisión humana independiente.
¿Por qué el artículo no especifica un número fijo de herramientas MCP?
Es necesario obtener un número fiable a partir del catálogo de herramientas específico de cada versión. Sin una exportación verificada del servidor, un número estático confundiría las funciones disponibles, deshabilitadas y preparadas.
Conclusión: Las herramientas MCP requieren permisos verificados.
Un buen catálogo de herramientas MCP no solo documenta los nombres técnicos. El catálogo muestra quién tiene permiso para usar una herramienta, con qué propósito, con qué datos, bajo qué clase de permisos y según qué reglas de lanzamiento.
Para las pequeñas empresas, la automatización controlada tiene más sentido que la autonomía sin restricciones. btlabs Core está diseñado para reducir los esfuerzos de búsqueda, verificación y transferencia de datos, al tiempo que garantiza que las decisiones delicadas permanezcan en manos de las personas responsables dentro de la empresa. Puede encontrar más información en la página sobre sitios web preparados para IA con btlabs Core.
