Roles MCP

Cómo los roles MCP controlan lo que Claude puede hacer en los servidores de Business Central y Dynamics 365 CRM de Plur-e — entidades, acciones, el rol por defecto y los mensajes exactos de denegación.

Respuesta rápida

Un rol MCP es un conjunto con nombre de entidades (Dynamics 365 CRM) o áreas (Business Central), cada una con las acciones que un usuario puede realizar sobre ella — Read, New, Update, Delete para CRM; Read, Write, Post para Business Central. Un administrador del tenant crea roles y los asigna a usuarios concretos en AI & MCP → Roles. Sin un rol que conceda la entidad y la acción, una herramienta deniega al instante con un mensaje claro — nada queda en cola de aprobación ni nadie tiene que confirmar algo a mitad de la conversación.

Qué es un rol

Un rol pertenece a un destino: Business Central, o una conexión concreta de Dynamics 365 CRM. Un tenant con dos conexiones de CRM tiene roles separados por conexión.
Un rol lista entidades (nombres lógicos de tabla de CRM) o áreas (secciones de Business Central como bc_wms_receipts, o áreas legacy como customers), cada una con sus propios flags Read / New / Update / Delete (CRM) o Read / Write / Post (Business Central). Read se activa solo al añadir una entidad; el resto empieza desactivado.
Un rol se asigna a usuarios concretos del tenant. Los permisos efectivos de un usuario son la unión de todos los roles que tiene asignados, más el rol por defecto del tenant para ese destino — gana el flag más permisivo cuando una entidad aparece en más de un rol.
Deny-by-absence: si un usuario no tiene ningún rol para el destino, la entidad/área no está en ninguno de sus roles, o la acción concreta está apagada, la herramienta deniega de inmediato. No hay estado pendiente ni elicitación — la llamada se ejecuta o se deniega.

Entidades y acciones

Cada herramienta declara la entidad/área que toca y la acción que realiza; un rol solo necesita las acciones que sus usuarios realmente usan.

Dynamics 365 CRM

Acción	Desbloquea
Read	`crm_query`, `crm_get_record`, `crm_describe_entity`, `crm_fetchxml` (incluida cada tabla unida mediante un `link-entity`); que `crm_search` la ofrezca y que `crm_list_entities` la liste
New	`crm_create_record`
Update	`crm_update_record`, `crm_set_state`, `crm_assign`, `crm_associate`; `crm_execute_action` sobre una entidad bound (una acción unbound necesita al menos una entidad con Update en la conexión)
Delete	`crm_delete_record`

Las herramientas de Customer Insights - Journeys siguen las mismas entidades: leer journeys y segmentos necesita Read en msdynmkt_journey / msdynmkt_segment, redactar un journey necesita New en msdynmkt_journey, y crm_journey_publish / crm_segment_publish necesitan Update en la entidad correspondiente. crm_whoami, crm_list_connections, crm_select_connection y crm_get_skill nunca comprueban un rol — no transportan datos por sí mismas.

Business Central

Acción	Desbloquea
Read	Los métodos de lectura de una sección (`bc_setup` … `bc_payments`) o de un área legacy, más las tools clásicas equivalentes (`search_customers`, `get_customer`, `search_items`, `get_availability`, `list_sales_documents`, …)
Write	Los métodos de escritura sin registro de esa sección o área, más `create_sales_quote`, `create_sales_order`, `bc_print_document`
Post	Los métodos marcados como posting en las skills — registrar recepción, registrar pick, registrar recuento, registrar diario, enviar pedido — que no se pueden deshacer en Business Central

Las tools de plataforma (list_environments, list_companies, select_tenant, bc_get_skill, bc_list_methods, bc_resolve_codes, bc_decode_barcodes, bc_handoff_*, bc_list_printers) y las de memoria del tenant (plure_recall, plure_remember, plure_forget) tampoco comprueban ningún rol — ver Memoria del tenant.

El rol por defecto

La primera vez que un tenant conecta un entorno de Dynamics 365 CRM, o habilita Business Central con un entorno, Plur-e crea un rol llamado Default access para ese destino — pero solo si el tenant todavía no tiene ninguno. Es:

Solo lectura en todas las entidades/áreas que se listan abajo.
Marcado como Default, así que aplica a todos los usuarios del tenant, además de cualquier otro rol que tengan asignado.
Para Dynamics 365 CRM, se puede volver a crear en cualquier momento desde AI & MCP → Dynamics 365 CRM, en la fila de la conexión, Create default role, si un administrador lo borró. Para Business Central se crea la primera vez que un administrador habilita el servidor con un entorno en AI & MCP → Settings; si se borra, un administrador (o el soporte de Plur-e) puede volver a crearlo llamando a POST permission-sets/{customerId}/seed-defaults.

Entidades CRM por defecto: las tablas que la skill de CRM de Claude documenta de fábrica — account, contact, lead, opportunity, incident, quote, salesorder, invoice, product, pricelevel, campaign, list, las tablas de actividades, knowledgearticle, queue, systemuser, team, businessunit, transactioncurrency, uom, territory, y sus tablas msdynmkt_* de Customer Insights - Journeys (journeys, segmentos, plantillas, correos, formularios, disparadores…).

Áreas de Business Central por defecto: todas — las 16 secciones móviles (bc_setup … bc_payments) y las áreas legacy (customers, items, sales, purchasing, warehouse, documents, reports).

Crear un rol

Abre AI & MCP → Roles

Pulsa New role, dale un nombre y elige su Destination — Business Central, o Dynamics 365 CRM agrupado por conexión.

Añade entidades

Abre el rol y pulsa Add entities: busca, filtra por All / System / Custom (solo CRM — Business Central tiene un catálogo fijo de áreas) y añade las que este rol necesita. Las entidades ya asignadas se ocultan de la lista.

Revisa entidades relacionadas (solo CRM)

Añadir entidades de CRM abre Related entities con las que acabas de añadir como semillas: un switch "System tables", cada sugerencia etiquetada como Child table, Lookup o Many-to-many, las entidades ya presentes en el rol marcadas como tal, las que Plur-e recomienda premarcadas, y un aviso a partir de 25 seleccionadas. Skip, o Add N related.

Activa las acciones que necesita cada entidad

Read ya está activo. Activa New / Update / Delete (CRM) o Write / Post (Business Central) solo para lo que los usuarios de este rol realmente necesitan hacer.

Asigna usuarios

En la sección Users del rol, pulsa Assign users y busca por login o nombre. Los usuarios sin ningún rol asignado siguen teniendo lo que conceda el rol Default access.

Mensajes de denegación

Esto es lo que ve Claude cuando una herramienta comprueba un rol y la llamada no está permitida. Los tres mensajes terminan con la misma instrucción, así Claude siempre sabe qué decirle al usuario:

Mensaje	Por qué ocurre	Qué hacer
"No permission sets are assigned to you for this connection."	El usuario no tiene ningún rol — ni siquiera el por defecto — para este destino o conexión	Pedir a un administrador del tenant que asigne un rol existente, o cree uno, en AI & MCP → Roles
"Entity 'x' is not allowed for you in this connection."	Ninguno de los roles del usuario lista esa entidad o área	Pedir a un administrador del tenant que añada la entidad/área a uno de los roles del usuario
"Read, Create, Update, Delete or Post is not permitted on entity 'x'." — el verbo es la acción que se comprobó (el flag Write de Business Central se comprueba como Update)	La entidad/área está en un rol, pero esa acción concreta está apagada	Pedir a un administrador del tenant que active la acción en ese rol

Los tres terminan con: "Ask a tenant administrator to grant it in the Admin Center (AI & MCP > Roles)." Claude debe transmitir esa instrucción en vez de reintentar la llamada o inventar un rodeo.

Los permisos se cachean hasta 60 segundos por usuario y conexión: justo después de que un administrador conceda una entidad, área o acción, una llamada denegada puede necesitar hasta un minuto antes de que un reintento recoja el cambio.

Relacionado: Modelo de seguridad de MCP · Herramientas de Business Central · Dynamics 365 CRM · Conectar Claude

Roles MCP

On this page