Conecta tu agente de IA a tus gastos con MCP

Respuesta rápida

Necesitas tres cosas: la URL del servidor, https://controlargastos.es/api/mcp; un token de agente creado desde tu perfil; y un cliente compatible con MCP sobre HTTP que te deje enviar una cabecera Authorization. En Claude Code se añade con claude mcp add --transport http. El token lleva permisos granulares que eliges tú: si no le concedes gastos:create, el agente no podrá crear un gasto por mucho que se lo pidas.

La diferencia entre hablar de tus gastos y tocarlos

Hay un momento incómodo cuando le pides a un asistente de IA que te ayude con las cuentas de casa. Le pegas un resumen, te contesta algo razonable, y ahí se acaba. Al día siguiente vuelves a pegar el resumen. El asistente no recuerda nada, no ha apuntado nada y no ha cambiado nada: ha sido un comentarista muy caro de tus propios datos.

El Model Context Protocol —MCP— existe para romper esa pared. Es un estándar abierto que permite a un modelo de lenguaje llamar a herramientas reales de un servicio: leer, escribir, calcular. Cuando un servicio publica un servidor MCP, deja de ser una web que tú abres y pasa a ser algo que tu agente puede operar.

ControlarGastos publica uno. No es una demo ni un envoltorio alrededor de un chat: las herramientas que expone son las mismas operaciones del producto —crear un gasto, listar los del mes, consultar saldos, confirmar una deuda, revisar un presupuesto—, y cada una pasa por los mismos servicios de dominio que usa la interfaz web. Eso significa que un gasto creado por un agente hereda las mismas validaciones, el mismo reparto y los mismos límites que uno creado a mano. No hay una puerta trasera con reglas más flojas.

Lo que necesitas antes de empezar

Una cuenta en la aplicación y un cliente que hable MCP sobre HTTP. Ese segundo punto es el que más confusión genera, así que conviene ser preciso: el servidor funciona en modo Streamable HTTP sin estado. No usa SSE ni mantiene sesión en el servidor. Cada petición viaja con su token y se resuelve sola.

La consecuencia práctica es buena: cualquier cliente que sepa hacer un POST con una cabecera Authorization sirve. Claude Code sirve. Cursor sirve. Un agente propio escrito por ti sirve. Lo que no encaja son los conectores «de un clic» de algunas aplicaciones de escritorio, que esperan un flujo OAuth completo con descubrimiento automático; nuestro token es un Bearer estático y ese flujo es otra cosa. Lo decimos aquí en vez de dejar que lo descubras a base de intentos.

Paso 1: crea el token y decide qué puede tocar

Entra en tu perfil, en la sección de tokens de agente. Al crear uno le pones un nombre —conviene que describa quién lo va a usar, porque vas a poder tener varios— y marcas los permisos que le concedes.

Aquí es donde se decide de verdad la seguridad de todo el montaje, y merece la pena pararse treinta segundos. Los permisos son granulares y están separados por lectura y escritura: gastos:read no es lo mismo que gastos:create, y ninguno de los dos implica deudas:write. Si lo que quieres es un agente que te resuma el mes, dale solo lectura. Un token de solo lectura no puede estropear nada aunque el agente se confunda, aunque el modelo alucine o aunque alguien te lo copie.

El token se muestra una sola vez. En la base de datos solo se guarda su hash, así que no existe ninguna pantalla que te lo vuelva a enseñar: si lo pierdes, se revoca y se crea otro. Es una molestia deliberada.

Paso 2: añade el servidor a tu cliente

En Claude Code, con la URL y el token en la mano:

claude mcp add --transport http controlargastos https://controlargastos.es/api/mcp \
  --header "Authorization: Bearer TU_TOKEN"

El nombre controlargastos es el que verás luego en la lista de servidores; puedes ponerle el que quieras. Por defecto el servidor queda en ámbito local, es decir, disponible solo en el proyecto donde lo añadiste y guardado en tu configuración personal. Si prefieres tenerlo en todos tus proyectos, existe el ámbito de usuario.

Un aviso que ahorra un rato de desconcierto: si configuras la cabecera Authorization y el servidor la rechaza, el cliente reporta la conexión como fallida y no cae hacia atrás a un flujo OAuth. Un fallo de conexión aquí casi siempre es un token caducado, revocado o mal copiado, no un problema del servidor.

Paso 3: comprueba con quién está hablando el agente

No des por buena la conexión porque no salga un error. Comprueba dos cosas.

La primera, que el cliente ve las herramientas: en Claude Code, el panel /mcp lista los servidores conectados y cuántas herramientas expone cada uno.

La segunda, y es la que de verdad importa, que el token es el que crees: el servidor publica un endpoint de identidad, GET /api/mcp/whoami, que devuelve el usuario dueño del token y los permisos efectivos de ese token. Es la respuesta a la pregunta correcta, que no es «¿me he conectado?» sino «¿qué puede hacer exactamente lo que acabo de conectar?». Si ahí ves un permiso que no querías conceder, lo has encontrado antes de que lo use.

Merece la pena mirar esa lista con calma, porque tiene un detalle que sorprende: puede devolver menos permisos de los que marcaste. No es un fallo. Algunos permisos exigen además una declaración de uso que se acepta aparte, y hasta que no está aceptada el permiso figura guardado pero no concede nada. El panel de tu perfil te lo explica para ese token concreto.

Qué no hace este servidor

Igual de importante que lo que hace. No se conecta a tu banco: no hay agregación bancaria por aquí, así que la pregunta «¿puedo enchufar mi cuenta corriente?» tiene una respuesta corta, que es no. No expone datos de otras personas: el token opera siempre en nombre de su dueño y no puede ver más de lo que ese dueño vería en la web. Y no atiende peticiones lanzadas desde el navegador de otro sitio: el servidor verifica el origen, que es la mitigación que el propio estándar recomienda contra el reenlazado de DNS.

Preguntas frecuentes

¿Puedo conectarlo desde ChatGPT o desde Claude de escritorio?

Depende de si esa aplicación te permite añadir un servidor HTTP con una cabecera propia. Los conectores «de un clic» esperan hoy un flujo OAuth con descubrimiento automático, y el servidor autentica con un Bearer estático, así que ese camino concreto no encaja. Con clientes que aceptan cabeceras personalizadas —Claude Code, Cursor o un agente propio— funciona hoy.

¿El agente ve todos mis gastos?

Solo si le das un permiso de lectura que se lo permita, y nunca más allá de lo que tú mismo ves en la aplicación. Un token sin gastos:read no puede listar gastos. La forma de salir de dudas no es fiarse de esta frase, sino llamar a GET /api/mcp/whoami y leer la lista de permisos que devuelve.

¿Puedo tener varios tokens?

Sí, y es lo recomendable. Un token por agente, con el nombre de ese agente y solo los permisos que necesita. Así, revocar uno no te tumba los demás, y en el listado puedes ver cuándo se usó cada uno por última vez.

¿Qué hago si se me escapa el token?

Revocarlo desde tu perfil. Deja de valer inmediatamente y creas otro. Como el token solo se guarda hasheado, revocar y regenerar es el único camino posible: no hay nadie, ni nosotros, que pueda recuperarte el original.

¿Puedo ponerle fecha de caducidad?

Sí. Un token admite fecha de expiración, que es lo sensato para pruebas o para un agente que solo vas a usar durante una temporada. Pasada la fecha deja de autenticar sin que tengas que acordarte de nada.

¿Qué pasa si el agente llama demasiadas veces seguidas?

Hay un límite de cadencia por token. Si se supera, el servidor responde con un 429 y el agente tendrá que espaciar las llamadas. El límite es por token, así que un agente desbocado no deja sin servicio a los demás.