AI integration examples
The NotificationCompass MCP server gives an assistant the documentation it needs to guide an integration. It does not connect to the application's database, inspect user preferences, or make authorization decisions for the application.
Plan a first integration
Connect the MCP server, then ask the assistant to help with a concrete project constraint:
Use the NotificationCompass documentation to plan an integration for a Laravel 12 application.
Users belong to fixed communities that administrators configure. Users can change their own global preferences, but community policies can be enforced. Notifications are queued and the application uses Redis for cache.
Give me the required definitions, context resolver, recipient authorizer, policy authorizer, cache configuration, and an implementation order. Mention the exact documentation pages used.
The assistant should identify the package contracts before proposing application-specific classes. Review its proposed context key, authorization rules, and enforced policy behavior before writing code.
Review an existing integration
Use the review-integration prompt when the application already has a partial implementation. Provide the stack, context model, authorization rules, delivery setup, and observability requirements. The prompt asks the assistant to return an architecture review, missing safeguards, relevant API names, and a short implementation checklist.
The assistant should treat the application as the source of truth for membership and administration rules. It should not infer authorization from a context identifier alone.
Configure notifications by community
Ask the assistant to focus on a fixed, application-owned context:
Our application has communities stored by integer ID. Users cannot create contexts. Each notification may support the community context, and an administrator can disable email for every member of one community.
Show the NotificationContext construction, notification context resolution, recipient authorization, policy manager calls, and the resolution order for a member with both global and community preferences.
The expected answer should use NotificationContext and NotificationContextPreferenceManager without introducing a package-specific Community model.
Diagnose a blocked notification
Use the decision reason to guide the investigation:
A notification is not sent through the mail channel for organization:42. Use the NotificationCompass documentation to list the possible decision reasons, the API that exposes each reason, and the checks I should perform in order.
The assistant should distinguish an undeclared channel, a missing or unsupported context, an unauthorized context, a mandatory rule, a context policy, and a user preference. It should recommend NotificationGate::decision() when the application needs the structured reason instead of only a boolean result.
Build audit and Telescope visibility
Ask the assistant to design observability without coupling NotificationCompass to a logging backend:
We need an audit trail for notification preference changes and delivery decisions. Show which NotificationCompass events to listen to, which fields to store, how after-commit behavior differs from runtime delivery decisions, and how Laravel Telescope can display the delivery events.
NotificationPreferenceChanged covers persisted preference and policy changes after the transaction commits. NotificationDeliveryDecided covers runtime delivery decisions, including blocked notifications, and can appear in Telescope's Event watcher.
Integration boundary
The MCP server exposes documentation, prompts, and a checklist. It does not expose application data or provide a replacement for NotificationContextAuthorizer and NotificationContextPolicyAuthorizer. Keep business data access in application-owned tools with their own authentication, authorization, and data minimization rules.