Agente IA, servidor MCP

Hola a todos,

En los últimos años hemos visto una gran ola sobre la IA y más recientemente se habla cada vez más de los agentes de IA, de hecho seguramente muchos ya los hemos utilizado.

He entrado en el universo de los servidores MCP y pensé que sería muy útil tener uno directamente en Gladys. Para los que no lo conozcan, MCP es el protocolo Model Context Protocol, un protocolo imaginado por Anthropic, los creadores de los modelos Claude. Permite exponer herramientas y funciones que los agentes pueden llamar para obtener información adicional o interactuar con dispositivos del mundo real. Es un protocolo abierto, la mayoría de los grandes nombres del sector han comenzado a implementarlo después de Anthropic, incluyendo OpenAI, y recientemente Perplexity.

He desarrollado una primera versión del servicio que actúa como servidor. Por ahora permite:

  • recuperar los valores de los sensores (temperatura, humedad, apertura…)
  • ver las cámaras, no estoy seguro de que sea posible mostrar en el chat del agente la imagen de la cámara, pero según las capacidades del modelo utilizado, puede describir lo que ve
  • encender/apagar las luces de una habitación

Os dejo ver la demostración en mi entorno de desarrollo (las temperaturas no son necesariamente pertinentes, así como las cámaras que son cámaras públicas).

En la demo, utilizo el agente asociado a GitHub Copilot en VSCode, pero normalmente si tenéis Claude o cualquier otro agente compatible con MCP en vuestro ordenador debería funcionar.

Todavía hay que mejorar las funciones expuestas, pero ya me parece bastante bien y se pueden imaginar muchas cosas, también hay que poner más seguridad para autenticar al agente que se conecta.

La PR está aquí

En las próximas horas habrá una imagen Docker disponible bertrandda/gladys:mcp-server

Por ahora es solo el backend, por lo que no hay nada visible en la lista de servicios. Para probar, podéis usar la ruta /api/v1/service/mcp/proxy en la configuración de vuestro agente. ¡Cuidado! la ruta no está segura, así que no probéis si la máquina que usáis para ejecutar Gladys está expuesta a Internet.

No dudéis en probar y decir qué os parece.

No sé mucho de la tecnología de todo esto, pero ¡me parece muy interesante el vídeo de la demostración! !

Hola @bertrandda

Reconozco que estoy realmente impresionado por la demo :heart_eyes: ¡Excelente trabajo :slight_smile:

Estoy (AHMA como muchos otros aquí…) muy interesado en obtener más información técnica, por ejemplo, el hardware utilizado, o cómo interconectar Gladys y el servidor MCP.

¿Podríamos también imaginar reemplazar el prompt manual por una solución STT, ya que ya estoy implementando una solución de audio « casera » en mi casa que soporta multi-room, con Gladys respondiéndome, y no estamos muy lejos de poder llegar a conversar naturalmente con Gladys :+1:

¡Muy contento de que haya tanto interés en este trabajo!

Para explicar un poco más, aquí tienes un esquema de un conjunto que funciona con el protocolo MCP

Por lo tanto, hay el host que contiene el cliente MCP. Hoy en día, suelen ser agentes bien conocidos como Claude desktop, ChatGPT… que integran este cliente. Como decía, en el vídeo de demostración de arriba, es el agente presente en VSCode con Github Copilot.
Su trabajo será, por un lado, comunicarse con el llm (a menudo Claude Sonnet o GPT-4) que se encargará de entender las solicitudes y analizar los datos, y por otro lado, con el servidor MCP.

El servidor MCP se encarga de declarar funciones que el cliente MCP puede llamar para interactuar con el recurso (en nuestro caso, el recurso es Gladys, pero podría ser una base de datos, Google Drive, Slack… cualquier herramienta local o remota). En nuestro caso, actualmente 4 funciones:

  • device.get-state para obtener los datos de los sensores
  • camera.get-image para recuperar las imágenes de la cámara
  • light.turn-(on|off) para encender/apagar las luces de una habitación
  • scene.start para iniciar una escena

Ahora, si miramos más de cerca, pero manteniéndolo simple, el funcionamiento de la parte host, cuando usamos, por ejemplo, Claude Desktop, esto es lo que se hará:

  • Al inicio, Claude Desktop pedirá a todos los servidores MCP a los que está conectado las funciones disponibles que cada uno ofrece (en nuestro caso device.get-state, camera.get-image…)
  • Cuando el usuario le pide algo a Claude Desktop (digamos « Dime la temperatura del salón ») enviará al llm la pregunta especificando en el contexto de la solicitud que tiene acceso a varias funciones y que, si la solicitud del usuario lo requiere, se puede hacer una llamada a estas funciones
  • El llm responde a Claude Desktop, « Necesito que uses device.get-state con el parámetro de la habitación salon »
  • Claude Desktop llama a la función del servidor MCP de Gladys device.get-state(salon) y devuelve el dato solicitado al llm
  • el llm construye la respuesta con este nuevo dato y la envía a Claude Desktop que te la muestra

Hay que entender bien que no es Gladys quien responde aquí, Gladys solo devuelve un estado y el llm construye la respuesta. No sé si usas Google Home, Homekit/Siri o Amazon Alexa con Gladys, pero creo que podemos hacer una comparación para entenderlo bien. Tenemos un servicio Gladys que expone dispositivos a través de un protocolo, y el cliente Claude Desktop (que podríamos comparar con la app Google Home, Apple Maison o incluso Siri) hace consultas a este servicio para obtener información. La ventaja con respecto a estas soluciones propietarias es que el MCP es un protocolo abierto e implementable por cualquiera (ya sea cliente o servidor). Por lo tanto, para responder a tu pregunta:

se puede imaginar perfectamente un cliente MCP, integrado con un modelo STT (ya sea en la nube o local) y comunicándose con Gladys a través de MCP.

Para responder a tu otra pregunta:

Respuesta corta el servidor MCP ya está integrado en Gladys a través del servicio que he desarrollado, la conexión que tendrás que realizar es entre el agente/cliente MCP y el servidor MCP (cf tutorial al final de este post).
La respuesta larga será un poco técnica, pero para explicar al mejor el porqué de hacerlo un servicio y entender los tutoriales de abajo, es interesante.
Para la conexión entre el cliente MCP y el servidor MCP tenemos 2 medios de comunicación posibles:

  • ya sea en stdio (entrada/salida estándar)
  • ya sea en HTTP (a través de la red)
    El stdio es el medio de comunicación original del MCP, el cliente MCP lanzará un subproceso que ejecuta el servidor y escucha las entradas/salidas del proceso (esquematizando mucho, es como si tuviera un teclado para escribir y leía los registros del terminal para comunicarse). Hay más agentes compatibles que con el http, pero como el servidor debe ejecutarse en la misma máquina que el agente, esto implica desarrollar y gestionar un nuevo proyecto en paralelo a Gladys.
    El HTTP permite hacer que el cliente MCP y el servidor MCP se comuniquen a través de la red cuando no están en la misma máquina. Esto da la posibilidad de agrupar el servidor MCP y el recurso en el mismo lugar. Integrar el servidor MCP en un servicio Gladys tiene varias ventajas
  • a nivel de código, es lo que me ha parecido más simple, para tener fácil acceso a todos los datos y funciones de Gladys
  • a nivel de estructura del proyecto, evita tener que mantener un segundo proyecto MCP-servidor-Gladys además de Gladys
  • si un día los clientes MCP salen en teléfonos (o altavoces como tú pides), hay muchas posibilidades de que se haga en HTTP, ya que instalar un servidor MCP en este tipo de dispositivos será necesariamente más complicado
  • si el agente que usas no es compatible con MCP a través de HTTP, puedes usar mcp-proxy que se encarga de hacer una pasarela entre stdio y HTTP (te lo explico abajo cómo usarlo).

Para los tutoriales de conexión, aquí tienes algunas explicaciones para VSCode (directamente en HTTP), Claude Desktop y Perplexity (uso de mcp-proxy porque Claude Desktop y Perplexity son hoy en día únicamente compatibles con stdio). Si tienes otros agentes, podemos verlo juntos.


VSCode con GitHub Copilot

Inicias el Chat Copilot.
Abajo, selecciona bien Agent y haz clic en el icono de la llave inglesa

En la lista desplegable que se abre, al final, elige « Add more Tools… »

« Add MCP Server »

« HTTP »

Finalmente, introduce esta URL http://GLADYS_IP_ADDRESS/api/v1/service/mcp/proxy reemplazando GLADYS_IP_ADDRESS por la dirección IP de tu Gladys.
Elige un nombre y listo, deberías poder usar en tu Agent Copilot

Para más información: Add and manage MCP servers in VS Code


Claude Desktop y Perplexity aún no admiten servidores MCP (han anunciado que lo harán pronto), por lo tanto, es necesario pasar por mcp-proxy

Para la instalación, todo está indicado aquí GitHub - sparfenyuk/mcp-proxy: A bridge between Streamable HTTP and stdio MCP transports · GitHub

Claude Desktop

Una vez instalado mcp-proxy, inicia Claude Desktop
En Configuración → Desarrollador → MCP Locales, haz clic en « Modificar la Config »
En un editor de texto, modifica el archivo claude_desktop_config.json para que se parezca a

{
    "mcpServers": {
        "mcp-proxy": {
            "command": "FULL_PATH/mcp-proxy",
            "args": [
                "http://GLADYS_IP_ADDRESS/api/v1/service/mcp/proxy",
                "--transport",
                "streamablehttp"
            ],
            "env": {}
        }
    }
}

Para encontrar FULL_PATH, en una terminal de comandos escriba where mcp-proxy (en macOS/Linux, para Windows escriba where.exe mcp-proxy) y reemplace FULL_PATH por la ruta obtenida.

También reemplace GLADYS_IP_ADDRESS por la IP de su Gladys

Guarde la configuración y reinicie Claude, si todo ha ido bien, debería poder acceder a las funciones MCP en el chat

Perplexity

Una vez mcp-proxy instalado, inicie Perplexity
En Configuración → Conectores → Agregar un conector
Seleccione la pestaña « Avanzado »
Ponga un nombre « Gladys »

Modifique la configuración para que se parezca a

{
  "args" : [
    "http://GLADYS_IP_ADDRESS/api/v1/service/mcp/proxy",
    "--transport",
    "streamablehttp"
  ],
  "command" : "FULL_PATH/mcp-proxy",
  "env" : {}
}

Para encontrar FULL_PATH, en una terminal de comandos escriba where mcp-proxy (en macOS/Linux, para Windows escriba where.exe mcp-proxy) y reemplace FULL_PATH por la ruta obtenida.

También reemplace GLADYS_IP_ADDRESS por la IP de su Gladys

Guarde la configuración y espere a que Perplexity detecte correctamente todas las funciones, si todo ha ido bien, debería poder acceder a las funciones MCP en el chat.

Para más información: https://www.perplexity.ai/help-center/en/articles/11502712-local-and-remote-mcps-for-perplexity


He intentado ser lo más completo y claro posible, espero que esto haya respondido a tus preguntas. Aunque el protocolo ya tiene algunos meses, aún está en sus inicios, es muy prometedor, especialmente viendo a todos los gigantes de la IA implementarlo. Por lo tanto, si la configuración de la conexión le parece complicada, no dude en pedir ayuda y esto permitirá mejorar los tutoriales según los comentarios de los usuarios.

Hola @bertrandda, tu demo es realmente muy instructiva y los resultados son realmente geniales.
Y como me gusta mucho experimentar, estoy probando tu imagen de Docker bertrandda/gladys:mcp-server pero mi VSCode (de base) me dice esto cuando pregunto por la temperatura de mi Dyson:

Veo que estás usando Gladys (sistema domótico) con una configuración en http://192.168.xxx.yyy/api/v1/service/mcp/proxy. Sin embargo, no puedo acceder directamente a la temperatura de tu Dyson porque:

Solo tengo el archivo de configuración mcp.json que muestra la URL del servidor
No tengo los permisos necesarios para consultar la API de Gladys
No sé si tu Dyson está configurado en Gladys
Para obtener la temperatura de tu Dyson, puedes:

Consultar la interfaz web de Gladys directamente en http://192.168.xxx.yyy
Usar la aplicación oficial de Dyson en tu teléfono
Acceder a la API de Gladys con los permisos adecuados
No puedo leer esta información a partir del único archivo de configuración que veo.

En resumen, como no soy desarrollador, me quedo atascado… Si tienes algún consejo, lo acepto con gusto :slight_smile:

EDIT: mi mcp.json por si ayuda

{
	"servers": {
		"github": {
			"type": "http",
			"url": "https://api.githubcopilot.com/mcp/",
			"gallery": true
		},
		"gladys-mcp": {
			"url": "http://192.168.xxx.yyy/api/v1/service/mcp/proxy",
			"type": "http"
		}
	},
	"inputs": []
}

EDIT 2: me parece que la comunicación no es buena …?

2025-08-03 20:56:51.000 [info] Iniciando servidor gladys-mcp
2025-08-03 20:56:51.004 [info] Estado de la conexión: Iniciando
2025-08-03 20:56:51.029 [info] Iniciando servidor desde el host de extensión LocalProcess
2025-08-03 20:56:51.032 [info] Estado de la conexión: Ejecutándose
2025-08-03 20:56:51.164 [info] Estado de la conexión: Error Error al enviar mensaje a http://192.168.xxx.yyy/api/v1/service/mcp/proxy: TypeError: fetch falló
2025-08-03 20:56:51.165 [error] El servidor salió antes de responder a la solicitud `initialize`.

¿Hay que poner el puerto con la IP? En mi Gladys de prueba es 8001
→ OK hay que poner el puerto pero parece que aún tengo un pequeño error.

2025-08-03 21:01:41.138 [info] Iniciando servidor gladys-mcp
2025-08-03 21:01:41.140 [info] Estado de la conexión: Iniciando
2025-08-03 21:01:41.151 [info] Iniciando servidor desde el host de extensión LocalProcess
2025-08-03 21:01:41.157 [info] Estado de la conexión: Ejecutándose
2025-08-03 21:01:41.158 [debug] [editor -> servidor] {"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-06-18","capabilities":{"roots":{"listChanged":true},"sampling":{},"elicitation":{}},"clientInfo":{"name":"Visual Studio Code","version":"1.102.3"}}}
2025-08-03 21:01:41.224 [debug] [servidor -> editor] {"result":{"protocolVersion":"2025-06-18","capabilities":{"resources":{},"tools":{"listChanged":true}},"serverInfo":{"name":"Gladys","title":"Gladys","version":"1.0.O"}},"jsonrpc":"2.0","id":1}
2025-08-03 21:01:41.224 [debug] [editor -> servidor] {"method":"notifications/initialized","jsonrpc":"2.0"}
2025-08-03 21:01:41.225 [debug] [editor -> servidor] {"jsonrpc":"2.0","id":2,"method":"tools/list","params":{}}
2025-08-03 21:01:41.226 [debug] 404 estado al conectar a http://192.168.xxx.yyy:8001/api/v1/service/mcp/proxy para notificaciones asíncronas; se desactivarán: {"status":404,"code":"NOT_FOUND","message":"Ruta /v1/service/mcp/proxy no encontrada"}
2025-08-03 21:01:41.264 [debug] [servidor -> editor] {"result":{"tools":[{"name":"camera_get-image","title":"Obtener imagen de la cámara","description":"Obtener imagen de una cámara específica o de una habitación específica.","inputSchema":{"type":"object","properties":{"room":{"type":"string","enum":["maison"],"description":"Habitación de la que obtener la imagen."}},"required":["room"],"additionalProperties":false,"$schema":"http://json-schema.org/draft-07/schema#"}},{"name":"light_turn-on","title":"Encender la luz","description":"Encender una luz en una habitación específica.","inputSchema":{"type":"object","properties":{"room":{"type":"string","description":"Habitación en la que encender la luz."}},"required":["room"],"additionalProperties":false,"$schema":"http://json-schema.org/draft-07/schema#"}},{"name":"light_turn-off","title":"Apagar la luz","description":"Apagar una luz en una habitación específica.","inputSchema":{"type":"object","properties":{"room":{"type":"string","description":"Habitación en la que apagar la luz."}},"required":["room"],"additionalProperties":false,"$schema":"http://json-schema.org/draft-07/schema#"}},{"name":"scene_start","title":"Iniciar escena","description":"Iniciar una escena de domótica.","inputSchema":{"type":"object","properties":{"scene":{"type":"string","enum":[],"description":"Nombre de la escena a iniciar."}},"required":["scene"],"additionalProperties":false,"$schema":"http://json-schema.org/draft-07/schema#"}},{"name":"device_get-state","title":"Obtener estados de los dispositivos","description":"Obtener el último estado de un tipo de dispositivo específico o en una habitación específica.","inputSchema":{"type":"object","properties":{"room":{"type":"string","enum":["maison"],"description":"Habitación de la que obtener información."},"sensor_type":{"type":"array","items":{"type":"string","enum":["temperature-sensor","humidity-sensor"]},"description":"Tipo de sensor a consultar, array vacío para recuperar todos los sensores."}},"additionalProperties":false,"$schema":"http://json-schema.org/draft-07/schema#"}}]},"jsonrpc":"2.0","id":2}
2025-08-03 21:01:41.265 [info] Se descubrieron 5 herramientas
2025-08-03 21:01:41.314 [warning] 1 herramientas tienen esquemas JSON no válidos y serán omitidas

En mi docker de prueba, solo tengo un Dyson que puedo encender y apagar (a través de Matterbridge).
¿Sería sencillo añadir encender/apagar un enchufe o interruptor (no sé si es diferente en Gladys)? Me gustaría probar solicitudes más complejas así :wink:


En cualquier caso, es muy prometedor y responde mejor (o al menos eso creo) que ChatGPT en GladysPlus:

Por cierto, ¿cuáles serían las diferencias entre hablar con Gladys/ChatGPT y tu servicio?

¡Genial que lo hayas logrado! Es necesario agregar el puerto para que funcione correctamente con la IP.

De hecho, veo 2 errores. La línea con el 404 es normal, por ahora solo he implementado la declaración de las herramientas, hay varias otras funciones de MCP como las llamadas notificaciones, me ocuparé de eso en un segundo momento. La línea con el error del esquema inválido no es importante. ¿No tienes una escena en tu docker de prueba, verdad?

¡Claro! Intentaré hacerlo pronto.

Son dos implementaciones diferentes de IA. Técnicamente hablando, con Gladys Plus haces una solicitud, el modelo identifica la solicitud y devuelve a Gladys la intención de la solicitud y Gladys te responde. Aquí, con el servicio MCP, hablas con un agente externo a Gladys que tiene la capacidad de leer/escritura de datos de Gladys mientras crea tu respuesta. Funcionalmente no lo sé, no uso ChatGPT de Gladys Plus, pero con un agente+MCP puedes encadenar preguntas, incluso usar varios dispositivos en solicitudes, creo que si configuras bien tu agente tendrás más posibilidades con los MCP. Es allí donde Gladys Plus tiene una ventaja, no tienes que configurar nada, la IA está implementada directamente, además puedes usarla en las escenas.

Hola @bertrandda, muy chulo este pequeño desarrollo :slight_smile:

Efectivamente, hay que autenticar la conexión entre el cliente MCP y Gladys, si no es un bar abierto ^^

@jean_bruder Hay ElevenLabs (la empresa que uso, entre otras cosas, para la voz de Gladys Plus) que ha desarrollado 11ai, un asistente de voz que se conecta a los MCP, por lo que es compatible con este desarrollo:

Efectivamente, no tengo.

El objetivo sería tener un complemento agente+MCP en Gladys además/sustituyendo a chatGPT o bien de hablar desde « el exterior » de Gladys con Gladys?
Reconozco que no tengo GG Home, Siri o Alexa porque no soy nada de la nube para esas cosas, y quizá ahí es donde tu desarrollo encaja…

Sigue siendo cloud en todos los casos :stuck_out_tongue: La única forma de hacer IA local por ahora sería tener una máquina con un buen GPU, bastante RAM e instalar un modelo de código abierto que funcione localmente, pero bueno, no es barato y consume bastante.

Después, quizá tendremos mini-PC asequibles con chips dedicados a la IA en el futuro, está llegando poco a poco por el lado de Beelink con el Beelink SER9, por ejemplo (Disponible a 1599€).

Los rendimientos son bastante correctos con prompts simples (Benchmark: Beelink | Comparaison des performances entre Beelink SER9 Pro HX370 et SER9 Pro), en mi opinión, esto se va a democratizar en el futuro, ¡estamos al principio!

Mientras tanto, la nube es una buena opción, avanza tan rápido que sería una pena equiparse con hardware que quedaría obsoleto en 6 meses, mientras que, en la nube, se renueva constantemente y los costos por token no hacen más que bajar desde hace 2 años!

Gracias, no había entendido ese detalle :joy:

Efectivamente, muy buena máquina, pero vamos a esperar un poco por el precio…

Muy interesante este proyecto, pero veo que los MCP deben ser accesibles a través de una URL pública para que funcione. Por ahora, el servicio solo puede funcionar si el agente está en la misma red que Gladys. Una vez que el servicio sea estable localmente, quizá valga la pena crear una ruta Gladys Plus autenticada que redirija al servicio MCP del usuario, ¿qué opinas?

¡Claro que sí! :slight_smile:

@mutmut acabo de actualizar la imagen con la adición de los interruptores. ¿Puedes ver si te conviene y si funciona bien?

@bertrandda imagen actualizada pero parece que no funciona, aunque tengo interruptores (1 Dyson, 2 para Matterbridge, 1 interruptor virtual en mqtt no encontrado):


y al insistir en el nombre gladys:

pero el Dyson no se apaga.
Debería probar con un enchufe Zigbee real para ver.

Si tienes comentarios con un verdadero dispositivo Zigbee, estoy interesado. Lo desarrollé con dispositivos virtuales MQTT.
Más generalmente, veo que basarme únicamente en los selectores de las funciones de los dispositivos no es quizás muy pertinente y, por falta de información, provoca malentendidos por parte del agente. Seguro que aún hay forma de mejorar esto.

Hola @bertrandda,

¿Has seguido trabajando en este tema desde entonces, o no mucho? :slight_smile:

Es un tema realmente interesante, creo. ¡No dudes en pedir ayuda si necesitas avanzar!

Sí, sigo avanzando, recientemente he añadido el sistema de sesión y los recursos para permitir que el agente recupere la estructura de la casa (no todos los agentes son compatibles con los recursos, pero será interesante para los que lo sean). Voy a subir todo esto y generar una nueva imagen. Queda principalmente la parte de autenticación por hacer. Me pregunto si es mejor una autenticación global (Gladys autentica el origen de la solicitud mediante una clave API y luego el servicio gestiona la respuesta) o si lo hago directamente a nivel del servicio (es el servicio el que gestiona la generación de la clave + autenticación). Pienso que a nivel de Gladys sería más limpio y permitiría tener un verdadero sistema de claves para todas las demás rutas de la API, pero puede que sea más largo de desarrollar.

¡Qué chulo todo esto! :slightly_smiling_face:

Para la autenticación, me dijiste que muchos sistemas piden una API disponible en internet, ¿quieres que te ponga a disposición una ruta Gladys Plus ahora mismo?

Es bastante trivial de hacer por mi parte porque ya tenemos el funcionamiento para varias integraciones (Owntracks, Netatmo, etc…)

Algo así:

https://api.gladysgateway.com/v1/api/mcp/:CLE_API

Edit: No he esperado tu respuesta, he hecho un pequeño PR rápidamente, con 3 rutas:

GET https://api.gladysgateway.com/v1/api/mcp/:CLE_API
POST https://api.gladysgateway.com/v1/api/mcp/:CLE_API
DELETE https://api.gladysgateway.com/v1/api/mcp/:CLE_API

Para coincidir con las 3 rutas que tienes en local

De lo contrario, para una autenticación local, ya tenemos un mecanismo de clave de API en Gladys (mira session.createApiKey), pero hasta ahora nunca se ha expuesto ni en la interfaz ni en ningún servicio, pero funciona :wink:

@bertrandda Está disponible en PROD en Gladys Plus, puedes usar las 3 rutas :wink:

Si miras el código en gateway.handleNewMessage.js, recibes un evento cada vez que llega una llamada API a la instancia local. Para la prueba, añadí esto de mi parte al final del archivo:

  if (data.type === 'gladys-open-api' && data.action === 'mcp-webhook') {
    console.log(data);
    cb({ status: 200 });
  }

Si llamo a la API con datos:

Recibo un « status »: 200 como respuesta, y veo pasar la llamada API localmente:

El atributo mcp_method contendrá ‹ POST ›, ‹ GET › o ‹ DELETE ›.

El atributo mcp_data contendrá los datos pasados en el cuerpo.

El atributo local_user_id corresponde al ID del usuario local de Gladys.

Puedes llamar a cb({ status: 200 }); con lo que quieras, es lo que enviará un JSON de respuesta al llamante.

No dudes en preguntar si tienes dudas :wink:

Al menos, a través de Gladys Plus toda la autenticación ya está gestionada de forma impecable y disponible desde una API abierta, por lo que es práctico para este tipo de casos.