Autenticación

El servidor MCP de Platica reutiliza exactamente el mismo mecanismo de autenticación que la API REST: un token Bearer con tu API Key.

Authorization: Bearer pl_key_xxxxxxxxxxxxxxxx_yyyyyyyyyyyyyyyy

Cada herramienta MCP que ejecutes hace internamente la misma llamada autenticada que harías al endpoint REST correspondiente, así que:

• Los scopes son exactamente los del API Key (workspace al que tiene acceso, permisos, etc.).
• Los rate limits, validaciones y errores son idénticos.
• No hay un "modo MCP" separado: si la API Key puede hacer POST /v1/clients, la tool create_client funciona; si no puede, devuelve el mismo 403.

Generar una API Key

Las API Keys se crean desde el dashboard de Platica, no desde el servidor MCP:

1. Abre Configuración → API Keys en tu dashboard.
2. Crea una nueva Key con un nombre descriptivo (ej. cursor-personal).
3. Copia la Key en formato pl_key_KEY_ID_SECRETO. Se muestra una sola vez.
4. Pégala en el Authorization header del config de tu cliente MCP (ver Configuración ).

Multi-workspace

Si tu API Key tiene acceso a varios workspaces, las herramientas de escritura aceptan un argumento opcional workspace (mismo nombre que el query param ?workspace= del REST). Si lo omites con una key multi-workspace, la API responderá con 400 Must specify a valid workspace... y la herramienta devolverá ese mensaje como error para que el modelo corrija.

Con keys single-workspace puedes omitir el argumento siempre — el workspace se deduce automáticamente.

¿Por qué Bearer y no OAuth?

El spec MCP recomienda OAuth 2.1, pero también permite esquemas de autenticación personalizados . Para integrar con la API existente, Bearer + API Key es:

• Equivalente en seguridad a la API REST (que ya usa el mismo mecanismo).
• Soportado nativamente por Cursor, Claude Code, mcp-remote y los clientes Streamable HTTP modernos.
• Sin pasos extra para los usuarios: la misma key que ya generaron para curl/Postman.