Actualizado el Aug 4, 2026

Usando Tipos Personalizados con MCP e IA

Qué vas a aprender

• Cómo se exponen los Tipos Personalizados a agentes de IA y clientes MCP
• Cómo los agentes descubren tus tipos y escriben registros
• Cuándo agregar Consejos para MCP para guiar el comportamiento del agente

El servidor MCP de AutoTalk permite que cualquier cliente LLM — Claude Desktop, Cursor, ChatGPT, un agente personalizado — lea y escriba los datos de tu empresa a través de una interfaz de herramientas uniforme. Los Tipos Personalizados se exponen a través de esa misma interfaz.

Lo que los agentes obtienen sin configuración

Cuando creas un Tipo Personalizado, el servidor MCP lo expone automáticamente. Un agente conectado a tu workspace con una clave de API válida puede:

• Descubrir tus tipos con list_custom_types
• Leer la forma de un tipo con get_custom_type_definition
• Consultar, crear, actualizar y eliminar registros usando las herramientas genéricas query_documents, get_document, create_document, update_document, delete_document con el identificador ct:<slug>
• Crear nuevos Tipos Personalizados con create_custom_type (además de update_custom_type y delete_custom_type para evolucionarlos o retirarlos)

No tienes que configurar nada extra — en cuanto el tipo existe en tu empresa, está disponible para cualquier cliente MCP autenticado.

Cómo un agente usa tu tipo

Supongamos que creaste un tipo con slug helpdesk_tickets. Un agente al que se le pide "abrir un ticket para el contacto Alice" haría:

1. Llama a list_custom_types y encuentra helpdesk_tickets.
2. Llama a get_custom_type_definition para ver la forma de los campos y los valores requeridos.
3. Llama a create_document con type: "ct:helpdesk_tickets" y los campos completados.

nota

Los slugs que coinciden con nombres de colecciones nativas (contacts, messages, support_tickets, …) están reservados — create_custom_type los rechaza con reserved_slug. Los slugs además son inmutables después de la creación, así que elige con cuidado.

Las preguntas de seguimiento ("muéstrame todos los tickets abiertos de alta prioridad") se traducen en llamadas a query_documents.

Escribiendo buenos Consejos para MCP

Al crear o editar un Tipo Personalizado, el campo Consejos para MCP es donde le dices al agente cómo usar tu tipo. El agente los ve junto con la definición.

Buenos consejos se ven así:

• "Siempre completa status al crear un lead."
• "Vincula al contacto vía contactId cuando el lead viene de una conversación conocida."
• "Cuando cambies status a resolved, también completa resolvedAt con la hora actual."
• "La prioridad por defecto es 3. Solo súbela si el usuario dice explícitamente que el problema es urgente."

Mantenlas cortas e imperativas. Piénsalas como reglas para un system prompt.

Escribiendo un buen purpose

El campo Propósito en la definición del tipo es igual de importante. Le dice al agente cuándo elegir tu tipo en primer lugar. Trátalo como una nota de traspaso:

"Rastrear leads comerciales desde el primer contacto hasta la calificación. Cuando el usuario mencione generación de leads, oportunidades, prospectos o pipeline comercial, busca o crea un registro aquí en lugar de usar la entidad Contactos nativa."

Un propósito claro con un par de consejos concretos mejora cómo los agentes enrutan las solicitudes a tu Tipo Personalizado.

Creando un Tipo Personalizado desde un agente

No tienes que definir Tipos Personalizados por la interfaz. Un agente con una clave de API válida puede llamar directamente a create_custom_type, por ejemplo después de una conversación como:

"Necesitamos llevar registro de los cursos de capacitación de la empresa — nombre del curso, fecha de inicio, instructor, capacidad, número de inscriptos. Créalo."

El agente traduce eso en una llamada create_custom_type con la lista de campos correcta. Verás aparecer el nuevo tipo en tu menú lateral, listo para usar.

Límites y seguridad

• Por MCP, create_custom_type, update_custom_type y delete_custom_type están protegidos solo por una clave de API válida de la empresa, que otorga acceso total al tenant — la restricción a dueños (requireOwner) aplica a la interfaz dentro de la app y las rutas /data, no al MCP. Considera que cualquier clave de API que pueda llegar al endpoint MCP puede crear y eliminar Tipos Personalizados.
• Los agentes no pueden definir nuevas funciones / acciones en Tipos Personalizados — esta versión está enfocada en datos.
• Todo el CRUD está aislado por tenant — un cliente MCP solo alcanza los registros de tu propia empresa. Sin embargo, los clientes MCP operan a nivel de dueño: las listas de acceso por rol configuradas en el Tipo Personalizado (acceso del tipo) restringen a tus empleados en la app, no a los clientes MCP/clave de API.
• Las automatizaciones reaccionan a los registros de tu tipo: los workflows y los webhooks salientes con disparador de hook en el modelo ct:<slug> se ejecutan al crear/actualizar/eliminar registros. (La gestión de webhooks sigue siendo solo dentro de la app — no se expone por MCP.)

Ejemplo: conectar con entidades nativas

Los campos de referencia permiten que tu Tipo Personalizado se conecte con el resto de AutoTalk. Por ejemplo, un tipo helpdesk_tickets con estos campos:

Campo	Apunta a	Efecto
contactId	contacts (nativo)	Vincula el ticket con el contacto
assignedTo	employees (nativo)	Muestra al responsable
relatedLeadId	ct:leads (otro Tipo Personalizado)	Enlaza con el lead original

Los agentes (y la interfaz) navegan estas referencias — hacer clic en contactId abre la página del contacto, por ejemplo.

Próximos pasos

• Tokens de API — crea la clave que el cliente MCP usará
• Servidores MCP — referencia completa del endpoint MCP