RefLink actions through MCP

This example shows how RefLink implements application actions.

How an action runs

1. The developer marks permitted operations with SDK decorators. Read, create, update, and archive campaign examples are in campaign.controller.ts.
2. NestJS Swagger generates OpenAPI. The AppAction decorator adds x-senler-app-action to a selected operation; other endpoints do not become actions automatically.
3. After the plugin is installed, Senler loads OpenAPI from the URL configured for the application. AI discovers an action through search, reads its complete schema through describe_method when needed, and calls it through execute.
4. Before calling the backend, Senler creates a short management session by sending a signed one-time launch_code to POST /api/embedded/management-session.
5. RefLink verifies the code and returns its own management_token. Only this token is sent in Authorization: Bearer when the action is called. The user's MCP key or OAuth token is never forwarded to the plugin.
6. The same EmbeddedSessionGuard verifies the management token and passes the confirmed project to the controller. Therefore, an application action does not accept project_id from AI.
7. If the action also needs Senler data, the backend separately uses the stored project-scoped OAuth access token.

A separate configurator example is in app-action-configurator.controller.ts. The AutomationStepConfigurator decorator tells MCP that the method result contains normalized step configuration and branches.

Access verification

The project comes from the verified management session, not an AI argument. Token differences and trusted-context rules are described in the example architecture.