Stripe MCP

Stripe MCP es el servidor oficial que ofrece a los agentes acceso a la API de Stripe y a su base de conocimiento. El cliente puede buscar documentación y artículos de soporte, descubrir métodos de la API, consultar sus parámetros y ejecutar las operaciones que permita la autorización. Esa combinación distingue la consulta de una explicación técnica de una petición que lee o modifica datos de la cuenta.

El recurso lo mantiene Stripe y se conecta mediante un endpoint remoto. La documentación ofrece configuración para clientes como Cursor y opciones de autenticación según el uso: OAuth cuando el cliente actúa en nombre de tu cuenta de usuario y agent API keys cuando una aplicación necesita acceso independiente y persistente. Elegir una de estas vías determina cómo se concede y se retira el acceso; no basta con añadir la dirección del servidor al cliente.

Al trabajar con una integración de pagos, un agente puede necesitar tanto entender un método como consultar el estado de un recurso. Stripe MCP reúne esas dos necesidades mediante herramientas distintas. La búsqueda documental responde preguntas sobre la integración; las herramientas de API permiten localizar un método, conocer su contrato y llamar a la operación correspondiente. Así se puede mantener una conversación apoyada en documentación y, con la autorización adecuada, en datos de la cuenta.

El servidor evita exponer cada método como una herramienta independiente. Las herramientas generales de lectura y escritura abren acceso a múltiples APIs sin aumentar innecesariamente el contexto del agente. Para entender una petición hay que seguir la cadena completa: qué método se descubrió, qué parámetros requiere, qué entorno está autorizado y si la llamada consulta datos o produce un cambio. La existencia de acceso técnico no convierte una petición ambigua en una operación aprobada.

El cliente MCP se conecta al servidor de Stripe y obtiene sus herramientas. En una tarea de API, el agente puede buscar un método por palabra clave y pedir después sus parámetros detallados. Con ese contexto decide qué llamada de lectura o escritura corresponde. Las consultas documentales siguen otro camino: la herramienta de búsqueda recibe una pregunta y el idioma para recuperar información de la base de conocimiento.

OAuth abre el consentimiento de Stripe y permite conceder acceso a cuentas de modo real o a sandboxes, con permisos diferentes para cada entorno. Para procesos autónomos sin OAuth, la documentación indica crear una agent API key con solo los permisos necesarios. Esa credencial se transmite como bearer token en la cabecera de autorización. La elección debe corresponder al agente y al ámbito al que necesita acceder.

La administración del acceso continúa después de conectar el cliente. Las sesiones OAuth aparecen en los ajustes de usuario y se pueden revocar. La revocación está acotada al ámbito de cuenta u organización y al entorno que se está viendo; una sesión puede seguir activa fuera de ese ámbito. Revisar el entorno es, por tanto, parte de entender qué acceso se ha concedido y cuál se ha retirado.

Ejemplo de KIRELEN (no oficial): investigar una consulta sobre un cliente de la cuenta. Primero se delimita si el trabajo consiste en explicar la API o en consultar datos autorizados. Para la explicación, el agente utiliza la búsqueda documental. Si hace falta una lectura, busca el método correspondiente, revisa sus parámetros y emplea la herramienta de lectura sobre el entorno acordado. El resultado esperado es una respuesta basada en la consulta; esta ficha no presenta una ejecución ni datos de clientes reales.

Una petición posterior de reembolso cambia el alcance. Stripe exige confirmación humana para ciertas operaciones de escritura, entre ellas los reembolsos y los pagos salientes. El agente proporciona una dirección donde revisar la operación. Si la persona la aprueba, Stripe devuelve un token y hay que indicar al agente que reintente la llamada. Esta confirmación específica convive con la aprobación de herramientas del cliente: cada mecanismo cumple una función en el recorrido de la petición.

La documentación distingue el consentimiento de una persona de la política del equipo. Una administración puede habilitar o deshabilitar el acceso MCP para todas las personas desde el panel. Esa configuración se realiza por separado para el modo real y para los entornos de prueba. Antes de interpretar un fallo de conexión como un problema de la herramienta, conviene comprobar qué ámbito está habilitado y cuál se está intentando utilizar.

También hay una capa de infraestructura ajena al consentimiento de Stripe. En dispositivos o redes gestionados, la administración de TI puede bloquear conexiones a servidores MCP externos. La guía identifica el dominio del servidor como el destino que se debe permitir cuando esa política impide conectar. Una credencial correcta no resuelve por sí sola un bloqueo de red, del mismo modo que una conexión de red disponible no concede permisos sobre una cuenta.

Para retirar acceso, hay que volver al ámbito concreto en el que se concedió. Las sesiones OAuth se administran desde los ajustes y su revocación no elimina las autorizaciones de cuentas que quedan fuera de la vista actual. Este detalle importa cuando una persona opera en varias cuentas o entornos: revisar solo una sesión en una vista puede dejar otras autorizaciones activas. La ficha recoge estas diferencias para que el recorrido de conexión incluya tanto el alta como la posterior retirada del acceso.