assign_user_tags
ChatGPTAssign one or more tags to a user in a Buildfire app. Use this when the app owner wants to add a user to a segment, group, audience, permission set, or tagged workflow. This tool modifies user/tag membership. It is NOT read-only. MANDATORY SAFETY RULE: Do not call this tool until the app owner confirms the target user and tags. Before calling this tool, show the app owner: Tag Assignment Summary: • App: [friendly app name] • User: [username/email/display name] • Tags to assign: [tag names] Then ask: "Should I assign these tags to this user?" Only call this tool after the app owner confirms. GOLDEN RULE: - Do not ask the app owner for appId if the app can be resolved by name. - Resolve the target user with list_users when needed. - Use username internally. - Show friendly user and tag details.
create_user
ChatGPTCreate a new user in a Buildfire app. This tool creates a real user account. It is NOT read-only and it is NOT idempotent. MANDATORY SAFETY RULE: Do not call this tool until the app owner clearly confirms the new user details. Before calling this tool, show the app owner: New User Summary: • App: [friendly app name] • Email: [email] • Display name: [display name if provided] • First name: [first name if provided] • Last name: [last name if provided] • Profile fields: [summary if provided] Then ask: "Should I create this user?" Only call this tool after the app owner confirms. SECURITY: - Never display the password back to the app owner. - Never log or summarize the password in user-visible output. - Do not invent a password unless the app owner explicitly asks you to generate one. - If generating a password, make it strong and remind the app owner to store it securely. GOLDEN RULE: - Do not ask the app owner for appId if the app can be resolved by name. - Use appId internally. - Show friendly app/user details, not internal IDs.
get_app_analytics_bulk
ChatGPTFetch analytics metrics for selected Buildfire app events in a single request. Use this for app-level analytics dashboards, comparisons, summaries, and mixed analytics requests across system events, plugin events, tags, and action-items. This tool is read-only. It only reads analytics metrics. It does not create, update, delete, publish, send notifications, or modify app data, plugin data, users, tags, or analytics records. IMPORTANT LIMITATIONS: - Maximum 20 items per request. - Never fetch "all data" without the app owner specifying specific events, plugins, tags, or a clear business question. - For broad requests, ask the app owner to narrow the scope before calling this tool. ANALYTICS TYPES: - daily: Requires fromDate and toDate on each item. - monthly: Requires toDate on each item. - all-time: Use analyticsType "monthly" with only toDate and set metric.showAllTimeData to true when supported. ITEM ROUTING: - System events: use eventName. - Tag events: use tagName and eventName will be converted to app/tagAssigned/{tagName}. - Custom plugin/action-item events: use pluginId and instanceId, or pluginName only when it can be uniquely resolved. GOLDEN RULE - NEVER expose: - appId - pluginId - instanceId - technical eventName keys - raw ISO dates unless explicitly requested ALWAYS show: - Friendly metric names - Friendly app/feature/tag names - Human-readable time range - Clear totals and trends
get_app_users_count
ChatGPTGet the total number of registered users in a Buildfire app. Use this when the app owner asks how many users, members, signups, or registered users an app has. This tool is read-only. It only reads a user count. It does not list full user records, create users, update users, assign tags, remove tags, or modify app data. Use this instead of list_users when the app owner only needs a count.
get_plugin_instance_analytics_daily
ChatGPTFetch daily analytics counts for a specific plugin instance event in a Buildfire app. Use this when the app owner wants analytics for a specific feature/plugin event over a date range. Expected flow: 1. Resolve the app with list_apps if needed. 2. Resolve the feature/plugin with search_plugin_instances. 3. Discover available events with list_plugin_instance_analytics_events. 4. Ask the app owner for the time range if not already clear. 5. Convert the app owner's local time range to UTC. 6. Call this tool with the resolved internal IDs and eventName. This tool is read-only. It only reads analytics metrics and does not create, update, delete, or modify app data, plugin data, users, tags, notifications, or analytics records. TIME HANDLING: - fromDate and toDate must be UTC ISO 8601 strings. - Do not expose raw ISO timestamps to the app owner unless they explicitly ask. - Show human-readable dates in the app owner's local timezone. GOLDEN RULE - NEVER expose: - appId - pluginId - instanceId - eventName keys - raw ISO dates unless explicitly requested ALWAYS show: - App name - Feature name - Friendly event title - Human-readable date range - Total and daily counts
get_plugin_memory
ChatGPTGet the architecture memory for a Buildfire plugin. This tool returns plugin.plan.json and plugin.index.json when available. These files explain how the plugin is structured, how its datastore objects are shaped, what fields are expected, and how plugin data should be safely created, updated, imported, or transformed. Use this before helping an app owner manage plugin data, import spreadsheet/form content, transform external data into plugin datastore records, or understand how a specific plugin works. Provide exactly one of: - pluginId - pluginName - pluginToken This tool is read-only. It only reads plugin architecture memory. It does not create, update, delete, publish, or modify plugin data, app data, users, tags, analytics, or notifications. GOLDEN RULE - NEVER expose unnecessary technical details to the app owner: - Do not show raw plugin.plan.json or plugin.index.json unless the user explicitly asks for technical details. - Use the memory internally to explain the plugin in plain English or to safely prepare future data operations. - If multiple plugins could match, ask the app owner to choose by friendly plugin name/title.
get_tag_users_count
ChatGPTGet the number of users assigned to one or more tags in a Buildfire app. Use this when the app owner asks: - How many users have a specific tag? - How large is a tagged segment? - How many users are in a target audience before sending a notification? This tool is read-only. It only reads counts for tag membership. It does not assign tags, remove tags, update users, create users, or modify app data. Use this instead of list_users when the app owner only needs audience size/counts.
list_app_analytics_events
ChatGPTList available analytics event categories for a Buildfire app. Use this before querying broad app analytics so the assistant can understand which metrics are available and choose the right follow-up tool. Returns: - System analytics events such as installs, opens, registrations, and sessions - Available categories such as custom plugins, tags, and action-items - Friendly titles and technical event names for internal use This tool is read-only. It only reads analytics metadata. It does not create, update, delete, or modify app data, plugin data, users, tags, notifications, or analytics records. PREVENT HEAVY REQUESTS: If the app owner asks for "all data" or another unbounded query: 1. Ask which specific features, events, or tags they want to analyze. 2. Ask what time period they want. 3. Only then fetch analytics for a limited set of events or plugins. TIME RANGE LIMITS: - Daily/monthly analytics should normally be limited to practical date ranges. - For long historical views, prefer all-time/monthly summaries when supported. GOLDEN RULE - NEVER expose: - Technical eventName keys unless explicitly requested - Internal event formats ALWAYS show: - Friendly event titles such as Opens, Installs, User Signups - Plain-English categories and descriptions
list_app_features
ChatGPTList installed plugin instances and app features for a specific Buildfire app. Use this when the user asks what features/plugins an app has, wants to find a feature by name, or needs to select a feature before checking analytics, opening plugin memory, or creating a notification action. This tool is read-only. It only reads installed app features from Buildfire. It does not modify the app, publish features, update plugin data, send notifications, or change user data. Do not ask the user for appId directly if the app can be resolved from list_apps. If multiple apps match, ask the user to choose by friendly app name.
list_apps
ChatGPTList the Buildfire apps the authenticated app owner can access. Use this as the first step when the user asks about their apps, users, notifications, analytics, plugins, or app features and you need to resolve which app they mean. This tool is read-only. It does not create, update, delete, send notifications, or change app data. Return the app list with friendly app names and IDs so the assistant can silently use the correct appId in later app-specific tools. Do not ask the user for an appId when the app can be selected by name.
list_plugin_instance_analytics_events
ChatGPTDiscover what analytics events are available for a specific Buildfire plugin feature. Use this after resolving the plugin instance through search_plugin_instances. Do not ask the app owner for technical event keys. This tool returns: - Built-in event: "Opened" with key app/openedPlugin - Custom plugin events with friendly titles and descriptions Each event key is the exact value to pass internally as eventName to get_plugin_instance_analytics_daily and search_plugin_instance_event_users. This tool is read-only. It does not create, update, delete, or modify analytics, app data, plugin data, users, tags, or notifications. GOLDEN RULE - NEVER expose to the app owner: - appId - pluginId - instanceId - event key values like app/openedPlugin or custom event keys ALWAYS show the app owner: - Friendly event title, such as Opens, Messages Sent, User Joined - Event description when available DISAMBIGUATION: If multiple events are available, present friendly titles only and ask which event they want to analyze.
list_push_notifications_app_groups
ChatGPTSearch for push notification groups in a Buildfire app. Use this to resolve a friendly group name to a group ID before scheduling a push notification to a specific audience. This tool is read-only. It only searches push notification groups. It does not create, update, delete, send, or schedule push notifications. Use this when the app owner says things like: - Send this to the internal group - Send it to group 1 - Which push groups do I have? - Send it to the members group If multiple groups match, show the friendly group names and ask the app owner which one they mean. GOLDEN RULE: - Do not ask the app owner for group IDs. - Use the group ID internally only. - Show friendly group names to the app owner.
list_users
ChatGPTSearch for and list individual user records in a Buildfire app. Use this when the app owner needs actual user records, such as names, emails, usernames, devices, signup dates, or users matching a search/tag/date filter. ROUTING: - For total app user count: use get_app_users_count. - For user count by tag: use get_tag_users_count. - For actual user records: use this tool. This tool is read-only. It only searches and reads users. It does not create users, update users, assign tags, remove tags, send notifications, or modify app data. TIME / DATE FILTERING: - minSignUpDate and maxSignUpDate must be provided together. - Dates should be UTC ISO 8601 strings when possible. - Do not expose raw internal timestamps unless the app owner asks for technical detail. TAG FILTERING: - If tags are provided, searchTagsCriteria is required. - Valid criteria should match Buildfire supported behavior, such as includesAll, includesSome, excludeSome, or excludeAll. GOLDEN RULE: - Do not ask the app owner for appId if the app can be resolved by name. - Use appId internally. - Show user results in a friendly way. - Avoid exposing unnecessary internal IDs unless needed for a follow-up action.
schedule_push_notification
ChatGPTSchedule a push notification for users in a Buildfire app. This tool creates or schedules a real push notification. It is NOT read-only and it is NOT idempotent. MANDATORY SAFETY RULE: Do not call this tool until the app owner clearly confirms the final push notification summary. Before calling this tool, show the app owner: Push Notification Summary: • Title: [push notification title] • Message: [push notification text] • Recipients: [Group name / user count / all devices] • Action: [Opens feature / web link / phone / email / none] • Sending: [Now / scheduled local time] Then ask the app owner for clear confirmation in your own natural wording. The confirmation question should sound conversational and match the context. Do not use a fixed scripted sentence. Examples of acceptable confirmation wording: - Does everything look good to send? - Want me to send it now? - Should I schedule this for you? - Ready for me to send this push notification? - Can I go ahead with this? Only call this tool after the app owner clearly confirms with yes, send it, go ahead, schedule it, or another clear approval. USER EXPERIENCE: Think conversationally, not technically. When the app owner wants to send a push notification: 1. Ask who should receive it. 2. Ask what the title/message should say. 3. Ask what should happen when users tap it. 4. Ask when it should send. 5. Resolve all IDs internally. 6. Show a final summary and wait for confirmation. RECIPIENT TARGETING: Option 1 - All devices: - User says everyone, all devices, all users, or all. - Do not set group_id. - Do not set users. Option 2 - Specific group: - Use list_push_notifications_app_groups to find the group. - If multiple groups match, ask the app owner which one. - Use group_id internally. - Do not set users. Option 3 - Specific users: - Use list_users to find the users. - If multiple users match, show the full friendly list and ask which users to target. - Use the selected user objects internally. - Do not set group_id. PLUGIN TAP ACTION: - If the app owner says the push notification should open a feature, use search_plugin_instances. - Never use a plugin name as instanceId. - Resolve instanceId internally and do not expose it. ACTION ITEM BEHAVIOR: - Default behavior: show the in-app message with the action as a CTA. - Only set autoExecuteActionItem true when the app owner explicitly wants the tap action to run automatically. TIME HANDLING: - sendAfter must be a future UTC ISO 8601 timestamp. - Convert the app owner's local time to UTC before calling this tool. - Do not expose raw ISO timestamps unless explicitly requested. - Show human-readable local time in the confirmation. GOLDEN RULE - NEVER expose: - appId - group_id - instanceId - actionItem objects - URL query strings - raw ISO timestamps unless explicitly requested ALWAYS show: - Friendly app name - Friendly group name or user count - Friendly feature/action name - Human-readable sending time
search_plugin_instance_event_users
ChatGPTSearch user-level analytics event records for a specific plugin instance event in a Buildfire app. Use this when the app owner asks who performed an event, which users opened a feature, which users triggered a plugin event, or similar user-level analytics questions. Important: - eventName must exactly match the key of one of the events returned by list_plugin_instance_analytics_events. - limit is capped at 15 to avoid heavy responses. - Use pagination with skip/limit when more records are needed. This tool is read-only. It only reads analytics event records and related user metadata. It does not create, update, delete, or modify app data, plugin data, analytics data, users, tags, or notifications. GOLDEN RULE - NEVER expose: - appId - pluginId - instanceId - eventName keys - raw ISO dates unless explicitly requested ALWAYS show: - Friendly feature name - Friendly event title - Human-readable date range - User names/emails when available
search_plugin_instances
ChatGPTSearch for installed plugin instances/features by name inside a specific Buildfire app. Use this when the app owner asks about a feature/plugin by friendly name, such as Chat, Community Wall, Places, Forms, or any installed app feature. Use this before: - Querying analytics for a plugin instance - Resolving where a notification tap action should open - Finding the correct pluginId and instanceId for a feature - Loading plugin memory for a selected plugin - Helping the app owner understand which features exist in an app This tool is read-only. It only searches installed plugin instances. It does not create, update, delete, publish, send notifications, or modify app data, plugin data, users, tags, or analytics. GOLDEN RULE - NEVER ask the app owner for appId, pluginId, or instanceId directly if they can be resolved by name. If multiple plugin instances match, show friendly feature names/titles and ask the app owner which one they mean.
unassign_user_tags
ChatGPTRemove a tag from a user in a Buildfire app. Use this when the app owner wants to remove a user from a segment, group, audience, permission set, or tagged workflow. This tool modifies user/tag membership and removes an existing relationship. It is NOT read-only and it may affect app behavior, permissions, audience targeting, or notification eligibility. MANDATORY SAFETY RULE: Do not call this tool until the app owner confirms the target user and tag to remove. Before calling this tool, show the app owner: Tag Removal Summary: • App: [friendly app name] • User: [username/email/display name] • Tag to remove: [tag name] Then ask: "Should I remove this tag from this user?" Only call this tool after the app owner confirms. GOLDEN RULE: - Do not ask the app owner for appId if the app can be resolved by name. - Resolve the target user with list_users when needed. - Use username internally. - Show friendly user and tag details.
