Prompt templates
A prompt template is a named, pre-written prompt that the PubNub MCP server exposes to your AI coding assistant. It's a ready-made starting point for a specific task, so you don't have to write the prompt yourself. Every template on this page assumes the MCP server (hosted or locally installed, see Set up the MCP server) is connected to your AI coding assistant, and that you have a PubNub account, app, and keyset for it to work against.
Prompt templates are one of three primitives the MCP server exposes to an AI assistant, alongside tools and resources. Refer to Available MCP tools for the other two. How you select a named template depends on your AI coding assistant. Clients that support the MCP prompts primitive typically list connected servers' prompts as selectable entries, for example as a slash command. You can also paste any of the prompt text below directly into a chat with an MCP-connected assistant.
Templates that use Illuminate, PubNub Insights, or Functions need that feature available on the keyset you're working against. Some also assume Access Manager is enabled and require the keyset's secret key.
Healthcare and HIPAA compliance
Build chat applications with Pub/Sub messaging, Presence, and App Context using data-handling practices suited to a HIPAA-compliant application.
hipaa-chat-short
Quick prompt to create a HIPAA-compliant chat application.
Act as a senior software engineer and use PubNub MCP server to create a chat application for healthcare that is HIPAA compliant.
hipaa-chat-long
Detailed prompt for HIPAA-compliant chat with specific feature requirements.
Act as a senior software engineer and use PubNub MCP server to create a chat application for healthcare that is HIPAA compliant, with Pub/Sub messaging for real-time chat, Presence for patient/doctor availability, and App Context for roles.
React development
react-app-short
Scaffold a basic React application with PubNub.
Act as a frontend developer and use PubNub MCP server to scaffold a React app with Pub/Sub messaging and Presence.
react-app-long
Comprehensive React application with real-time features: Pub/Sub messaging, Presence, and App Context.
Act as a frontend developer and use PubNub MCP server to scaffold a React app with Pub/Sub messaging for real-time updates, Presence to show when users are online or typing, and App Context to handle user metadata. Include sample React components for subscribing to a channel, publishing messages, and displaying presence indicators for active participants.
Gaming applications
Build multiplayer game lobbies with PubNub's SDKs. Refer to Available SDKs for the full list, including Unity and Unreal Engine.
gamelobby-short
Build a multiplayer game lobby with basic features.
Act as a game developer and use PubNub MCP server to build a multiplayer lobby with chat and Presence indicators.
gamelobby-long
Advanced multiplayer lobby with team management.
As a game developer, use PubNub MCP server to build a multiplayer game lobby that supports real-time chat using Pub/Sub, Presence for tracking when players come online or leave, and App Context for managing team assignments (e.g., red vs. blue team).
OEM and multi-tenant solutions
These prompts help with programmatic account management for OEM (building resources used by someone else) and multi-tenant use cases.
oem-client-management
Create apps and configure keysets for OEM client deployments.
[OEM (building resources used by someone else)] As a developer, use PubNub MCP to create a new app, configure and assign keysets to clients.
multi-tenant-onboarding-short
Implement automated tenant onboarding for SaaS applications.
[OEM] Act as a senior developer and use PubNub MCP server to implement automated tenant onboarding for a multi-tenant chat application in SaaS or healthcare industries.
multi-tenant-onboarding-long
Enterprise-grade multi-tenant onboarding with data isolation and error handling.
Act as a senior developer and use PubNub MCP (which leverages Admin API for Keysets and Usage & Monitoring) to implement a multi-tenant chat application with automated tenant onboarding. The tenant Application will use: pubsub, History, App-Context, Presence For every new tenant or end-customer the application should: Create a new App (if required by your OEM model). Create and configure a new Keyset to ensure data isolation Make sure publish and subscribe keys are properly retrieved and propagated to the tenant's application as configuration variables The implementation should be fully automated, idempotent, and include error handling, and retries.
Illuminate analytics and automation
Set up Illuminate analytics and automation pipelines on top of your PubNub data. These prompts assume the manage_illuminate tool from Available MCP tools and, where they publish test data, a keyset secret key if Access Manager is enabled.
Run Illuminate prompts on a test keyset
These prompts create, activate, and sometimes delete Illuminate resources, and they publish test messages. They don't ask which keyset to use or wait for your approval before each change, so set the scope yourself:
- Use a test keyset whose channels have no real users, Functions, or Decisions you care about. Tell the agent which account, app, and keyset to use before you paste the prompt.
- An active Decision runs its actions for real. It publishes messages, calls webhooks, or updates App Context membership metadata. The spam detection prompt uses membership metadata to mute and ban users.
publish-fake-datapublishes real messages totest-channel, or totest-channel-0,test-channel-1, and so on for the cross-posting scenario, on the keyset you give it. Anything listening on those channels receives them.- Deleting a Business Object also deletes every resource that belongs to it. If a resource must be deleted, name it yourself.
To keep reading and changing separate, paste this text before any Illuminate prompt:
Before you change anything, tell me which account, app, and keyset you will use, and wait for me to confirm it's a test keyset. Until I approve, only read: list, get, get-fields, raw-snapshot, field-health, aggregate, verify-query, check-action-log. Before each create, update, activate, deactivate, or publish-fake-data call, show me the exact change and wait for my approval. Never delete a resource unless I name it.
illuminate-spam-detection
Set up a complete spam detection pipeline with escalating moderation actions for chat flooding and cross-posting.
Act as a community moderator and use PubNub MCP to set up Illuminate spam detection. Start by asking: Is the concern chat flooding (one user sending too many messages in one channel), cross-posting (the same message sent to many channels), or both? For each pattern, copy the Illuminate Query Builder predefined template — do NOT invent custom query logic when a template fits. There is no programmatic 'create from template' helper; instead, list existing queries with `manage_illuminate {resource:'query', operation:'list'}`, find one tagged `meta.template: 'spam_cross_posting'` (or `'topn'` / `'advanced'`), GET it to read its pipeline shape, then create a new query with that pipeline shape adapted to the user's BO field UUIDs. First check whether a Chat-spam-shaped Business Object already exists on this keyset (typical fields: user, channel, message, message_type — these are commonly auto-provisioned when the PubNub Chat SDK is in use, so list BOs first; if a matching one is present, reuse it; only create a new BO if no suitable one exists, and ask the user to confirm field shapes if creating). Before creating anything, describe the detection approach in 1–2 sentences in plain English. Then show an escalating decision table with three severity rows: Low → notify moderator (quiet alert); Medium → notify + mute user in channel; High → notify + mute + ban user from channel. The mute/ban actions use `actionType: APPCONTEXT_SET_MEMBERSHIP_METADATA` with the appropriate operations array (see existing 'Decision for Cross Posting' in the account for shape); the notify action uses `actionType: PUBNUB_PUBLISH` to a moderation channel or `actionType: WEBHOOK_EXECUTION` to an external endpoint. Ask the user to confirm: (a) the time window (default: 60 seconds), (b) the message count or channel count thresholds for each severity level, and (c) which actions to enable per row. After confirmation: create the Business Object if not already active, copy the Query Builder template's pipeline shape into a new query, then create the Decision with the confirmed escalating rules and activate. CRITICAL for QUERY-sourced decisions: every inputFields[].name must exactly match the source query's output field alias (run get-fields on the query first; common aliases are 'user', 'channel', 'message_count', 'channel_count'). The handler now blocks name mismatches pre-flight, but using the right names from the start avoids the round-trip. Publish fake test data to verify the Decision fires correctly — use scenario:'chat-flooding' (count=20, single user/channel) for flooding rules and scenario:'cross-posting' (count=15, single user across channels) for cross-post rules. NOTE: if the keyset has Access Manager enabled, also pass `secret_key` (the keyset's secret key from Admin Portal → Keysets) — without it the publish returns a 403. Show the action log (per-decision endpoint; loop if multiple) to confirm fires.
illuminate-reward-engagement
Build an engagement reward pipeline for live events and gaming, including Top N ranking queries and per-user rate-limited reward decisions.
Act as a live events manager and use PubNub MCP to set up Illuminate engagement rewards. Start by asking which participation behaviors to reward: poll answers, chat messages, reactions, or re-engaging low-engagement users (or a combination). For ranking rewards (Top N most chatty, Top N by reactions, Bottom N by engagement), copy the predefined Illuminate Query Builder template instead of inventing custom ranking logic. There is no programmatic 'create from template' helper; instead, list existing queries with `manage_illuminate {resource:'query', operation:'list'}`, find one tagged `meta.template: 'topn'`, GET it to read the pipeline shape, then create a new query with that pipeline shape adapted to the user's BO fields. For Bottom N (re-engagement), use the same topn template but reverse the orderBy direction (DESC -> ASC) on the count field. Before creating anything, describe the reward approach in 1–2 sentences in plain English. Then show a decision table: Poll answered → reward points or badge; Top N most chatty → Incentive A; Top N by reactions → Incentive B; Bottom N by engagement → Incentive C (re-engagement nudge). Ask the user to confirm: (a) which rows to enable, (b) the reward or incentive for each, (c) the evaluation window, and (d) a per-rule rate limit (default: once per day per user) to prevent duplicate rewards — translate this to `executionLimitType: 'ONCE_PER_INTERVAL_PER_CONDITION_GROUP'`, `executionLimitIntervalInSeconds: 86400`, and `executionLimitInputFieldIds: ['user']` (or the equivalent input field name on the decision; the handler resolves names to UUIDs automatically). After confirmation: create the Business Object capturing poll, chat, and reaction events (fields: user, channel, event_type). PRECHECK: list existing decisions and count those with sourceType='METRIC' — the account is hard-limited to 3 such decisions. If creating multiple per-behavior reward rules would push past the limit, consolidate them into multi-rule single decisions where possible. Create COUNT metrics — one per behavior being measured. Create a Dashboard with an engagement trend chart and active vs inactive user breakdown. Create the Decision(s) with the confirmed rules and rate limits, and activate. CRITICAL for QUERY-sourced ranking decisions (Top N / Bottom N): every inputFields[].name must exactly match the source query's output field alias (run get-fields on the query first; topn aliases are typically 'user', 'channel', 'message_count', 'rank_in_channel'). The handler now blocks name mismatches pre-flight, but using the right names from the start avoids the round-trip. Optionally: if the user wants an engagement drop alert, add a rule on the Chat Message Count metric using `operation: 'NUMERIC_LESS_THAN'` with the chosen threshold and an action that notifies moderators (PUBNUB_PUBLISH or WEBHOOK_EXECUTION). Publish fake test data with publish-fake-data (use scenario:'generic' with count=20 to spread events across users) to verify rewards fire correctly. NOTE: if the keyset has Access Manager enabled, also pass `secret_key` (the keyset's secret key from Admin Portal → Keysets) — without it the publish returns a 403. Show the action log per Decision (loop over decisions if more than one) to confirm.
illuminate-use-case
Guided setup of any Illuminate analytics and automation use case, from goal identification through build and validation.
Act as a product manager and use PubNub MCP to set up a complete Illuminate use case. Follow this guided flow: Step 0 — Identify the goal. Ask: (1) What outcome do you want? Choose from: reward and incentivize desired behavior (e.g. most engaged users, high spenders, poll participants); prevent spam or abuse; alert when operational metrics like wait time or failure rates exceed normal; or automate live event or auction actions. (2) What should Illuminate do when the condition is met? Options: notify via webhook or channel message, reward or badge a user, mute or moderate a user, or trigger an external workflow. (3) How quickly should it react? Immediately on each event, near real-time every 1–5 minutes, or trend-based every 10–60 minutes. Step 1 — Choose the simplest implementation path: if the goal is spam (flooding or cross-posting) or ranking (Top N / Bottom N), start from a Query Builder template by listing existing queries with `manage_illuminate {resource:'query', operation:'list'}`, finding one with the matching `meta.template` tag (e.g. 'spam_cross_posting' or 'topn'), GET it to read its pipeline shape, then create a new query with that pipeline shape adapted to the user's BO field UUIDs (no programmatic 'create from template' helper exists — copy the shape). Otherwise use Metrics + Dashboard + Decision. Step 2 — Confirm data. Ask for one of: a sample event (JSON), a list of fields already in the payload, or where the data currently lives. Step 3 — Preview before building. Describe the automation in 1–2 sentences in plain English. Present the decision logic as a conditions → actions table with one rule per row. Ask for confirmation and threshold adjustments before creating any Illuminate resources. Step 4 — Build: create the Business Object (or confirm the existing one is active), create 1–3 Metrics for KPI visibility and tuning, create a Dashboard chart, then create and activate the Decision using the confirmed thresholds. PRECHECK: list existing decisions and count how many have sourceType='METRIC' — the account is hard-limited to 3 such decisions; if already at 3, either delete one or consolidate behaviors into multi-rule single decisions before creating more. CRITICAL for QUERY-sourced decisions: every inputFields[].name must exactly match the source query's output field alias (run get-fields on the query first and use those exact aliases — case-sensitive). Mismatched names cause the decision to silently never fire; the handler now blocks this pre-flight, but using the right names from the start avoids the round-trip. Step 5 — Validate: publish fake test data, check the dashboard and action log, and suggest threshold or rate-limit adjustments based on results. NOTE: if the keyset has Access Manager enabled, also pass `secret_key` (the keyset's secret key from Admin Portal → Keysets) to publish-fake-data — without it the publish returns a 403 with an actionable error pointing at the same fix.
illuminate-test-verify
Step-by-step test and verification of an existing Illuminate configuration.
Act as a developer and use PubNub MCP to test and verify my existing Illuminate setup. 1. List all Business Objects and confirm the relevant one is active (isActive=true; if false, activate it before continuing). 2. Publish a small set of fake test messages (generic scenario, count=5) using publish-fake-data. NOTE: if the keyset has Access Manager enabled, also pass `secret_key` (the keyset's secret key from Admin Portal → Keysets) — without it the publish returns a 403; the tool will surface the AM error with the same fix suggestion. Wait 30 seconds for Illuminate ingestion. 3. Run a field-health query — flag any fields with populated=0 or with `sampleValues` containing only empty strings as potential JSONPath mismatches (every jsonPath should start with `$.message.body.`). On a brand-new BO, field-health is only meaningful AFTER step 2's publish has been ingested, which is why it follows the publish here. 4. Run a raw-snapshot query (limit=10) to confirm messages are being captured with the right shape. 5. List all saved queries; for any used as a Decision source, run verify-query to confirm the query returns rows for the time window it covers (an empty result here is the most common reason a QUERY decision doesn't fire). 6. List all decisions, filter to enabled=true, then for EACH active Decision call check-action-log (the endpoint is per-decision; loop over them). Report fires per decision over the last hour. Report any issues found and suggest fixes. If a QUERY-sourced Decision shows zero fires despite verify-query returning matching rows, check that every inputFields[].name on the Decision exactly matches a query output alias from get-fields (case-sensitive) — silent name mismatches are the #1 cause. If Decisions are firing too frequently or not at all, suggest adjustments to time window, thresholds, filters, and execution rate limits (executionLimitType, executionLimitIntervalInSeconds, executionLimitInputFieldIds).
Insights analytics
Query PubNub Insights metrics for an account, app, or keyset. These prompts assume the insights tool from Available MCP tools, an account on Insights Premium, and the MCP server's usual authentication: OAuth on the hosted server, or the Service Integration API key in PUBNUB_API_KEY on a locally installed server. Each prompt first asks which account, app, or keyset to query.
insights-snapshot
Quick high-level analytics snapshot for a date range, including unique channels, unique users, message volume, and top channels, with anomaly callouts.
Act as an analytics engineer and use PubNub MCP to produce an Insights snapshot. Step 0 — Confirm inputs: (1) the entity to query (entityType: account, app, or keyset, and the corresponding entityId — for keyset use the subscribe key), (2) the date range (default: last 7 days, YYYY-MM-DD in UTC), and (3) the time grain (default: daily). If the user encounters an authentication error, ensure OAuth is configured and point them to the how-to guide for getting Insights API access. Step 1 — Use the `insights` tool to query four metrics in parallel for the confirmed date range and grain: `unique_channels`, `unique_users`, `messages`, and `top_20_channels` with `category=by_messages`. Note that `top_20_channels` requires `period=hourly` or `period=daily` only — never `weekly` or `monthly`. Step 2 — Present the results in this order: (a) a one-line headline with the date range and the trend in unique users (e.g. "+12% week-over-week"), (b) a table of daily unique users / unique channels / messages, (c) the top 20 channels by message volume with their counts. Step 3 — Call out anomalies: any day with more than ±30% deviation from the period average, any channel that appears in the top 20 with more than 50% of total volume, or any drop in unique users greater than 20% day-over-day. Step 4 — Suggest 2–3 follow-up queries the user might want to run (e.g. "Want to see new vs recurring user breakdown?" or "Want to see the top message types?"). Always include the date range and timezone (UTC) in the response so the user has unambiguous framing.
insights-channel-analysis
Deep dive into top channels by ranking category, channel naming patterns, and cross-category engagement comparisons.
Act as a product analyst and use PubNub MCP to analyze top channels in detail. Step 0 — Confirm inputs: (1) the entity to query (entityType: account, app, or keyset, and the corresponding entityId), (2) date range (default: last 7 days, YYYY-MM-DD in UTC), (3) time grain (`hourly` or `daily` only — top metrics do not support weekly or monthly), and (4) which ranking categories to include (default: `by_messages`, `by_subscribers`, and `by_users_with_messages`). Step 1 — Use the `insights` tool to query `top_20_channels` for each requested category. Step 2 — Cross-reference the rankings: list channels that appear in all three categories (high engagement and high reach), channels that have many messages but few subscribers (chatty but small), and channels that have many subscribers but few messages (broadcast-style). Step 3 — If the user asks about a channel naming pattern (e.g. "channels starting with team." or "all room.* channels"), use the `channel_patterns` metric with a `filter=startsWith:` expression instead of post-filtering top-N results. Step 4 — Optionally query `unique_channels_combination` to show overlap between message-publishing channels and chat-publishing channels, and `percent_unique_channels_with_messages` to show how many of the entity's channels actually had messages in the period. Step 5 — Present results as: (a) a unified ranking table with all categories side-by-side, (b) the cross-category insights from step 2, (c) any pattern-based subtotals from step 3, and (d) 2–3 follow-up actions (e.g. "Want to look at user duration on these channels?"). Important: top-N counts cannot be summed across periods — when showing daily rankings, present one ranking per day rather than aggregating.
insights-user-growth
New vs. recurring user trends, daily/weekly/monthly breakdowns, top countries, and whale user identification.
Act as a growth analyst and use PubNub MCP to track user growth. Step 0 — Confirm inputs: (1) the entity to query (entityType: account, app, or keyset, and the corresponding entityId), (2) date range (default: last 30 days, YYYY-MM-DD in UTC), and (3) trend grain (`daily`, `weekly`, or `monthly` — note that `new_vs_recurring_users` does NOT support `hourly`). Step 1 — Use the `insights` tool to query in parallel: `unique_users` for the chosen grain, `new_vs_recurring_users` for the chosen grain, and `unique_users_by_country` (which only supports `hourly` or `daily`). Step 2 — Compute and present: (a) the headline week-over-week or month-over-month change in unique users, (b) the new-user count and the recurring-user count per period with a small chart-style table, (c) the new-to-recurring ratio (a healthy product typically has 20–40% new users in any given period), and (d) the top 10 countries by unique user count from `unique_users_by_country`. Step 3 — Call out: any period where new users dropped more than 30% from the prior period (acquisition issue), any period where recurring users dropped more than 20% (retention issue), and any geography that suddenly appears or disappears in the top 10 (potential market change or fraud). Step 4 — Optionally query `top_20_users` with `category=by_messages` to identify your most active users (whales), and `percent_unique_users_with_messages` to show the publish-vs-subscribe-only user split. Step 5 — Suggest 2–3 follow-up queries (e.g. "Want to see what channels new users are joining?"). Always frame results with the date range and UTC timezone.
insights-engagement-deep-dive
Average user duration, session-length bucket histogram, top channels by user-minutes, and device-type breakdown.
Act as a product analyst and use PubNub MCP to do an engagement and device deep dive. Step 0 — Confirm inputs: (1) the entity to query (entityType: account, app, or keyset, and the corresponding entityId), (2) date range (default: last 24 hours for duration metrics, last 7 days for device metrics, YYYY-MM-DD in UTC), (3) for duration metrics, use `period=hourly` (the ONLY supported period for duration). For device metrics, use `period=daily` by default. Step 1 — Use the `insights` tool to query duration metrics: `avg_user_duration` (hourly), `unique_users_by_duration_timeframe` (hourly — bucketizes users by session length), and `top_20_channels_with_user_duration` (hourly, top channels ranked by total user time spent). Step 2 — Use the `insights` tool to query device metrics: `publishes_by_device_type`, `subscribers_by_device_type`, and `unique_users_by_device_type`. Step 3 — Present results in this order: (a) average user duration trend across the chosen window, (b) duration bucket histogram (e.g. < 1 min, 1–5 min, 5–30 min, 30+ min), (c) top 20 channels ranked by total user-minutes, (d) device-type table with publishes / subscribers / unique users side-by-side and percent share for each device type. Step 4 — Insight callouts: channels with high user-duration but low message volume (lurker / read-only channels), unusual device-mix shifts (e.g. mobile share dropping or web share spiking week-over-week), and the channel with the highest engagement-per-user ratio (total duration / unique users). Step 5 — Suggest 2–3 follow-up queries (e.g. "Want to see device split for top channels only?"). Always frame results with the time window and UTC timezone, and remind the user that duration metrics are only available at hourly grain.
PubNub Functions
Create, deploy, and manage Functions serverless handlers on your keysets. These prompts assume the manage_functions tool from Available MCP tools.
functions-deploy
End-to-end guided deployment: author a Functions handler, create a package, deploy a revision to a keyset, and start it.
Act as a serverless engineer and use the PubNub MCP `manage_functions` tool to ship a Function end-to-end. Step 0 — Confirm inputs: (1) the target keyset — for deployment create you need the NUMERIC keyset id (keyset_id); account-level package/revision operations do not need a keyset; kv-store and secret operations use the subscribe_key (sub-c-...), (2) the trigger type (Before/After Publish/Signal/File, After Presence, On Request, or On Interval), (3) the channel or channel pattern (or path for On Request), and (4) what the Function should do. Step 1 — Author the Function code: follow how_to(slug=develop-pubnub-functions) so the default export has the correct signature for the type (request and response for On Request, request for Before/After events, event for On Interval) and returns the matching completion call (response.send / request.ok()/abort() / event.ok()/abort()). Each external module has its own independent per-execution budget (XHR 5, KV Store 10, PubNub API 10, Publish 10, Vault 10) — see how_to(slug=understand-pubnub-functions-limits-and-constraints). Step 2 — Show the user the proposed package name and function code and get confirmation before creating anything. Step 3 — Create the package with resource=package, operation=create (this also creates the initial revision and functions); capture the package id AND the package revision id from the response. Step 4 — Create a deployment with resource=deployment, operation=create, data set to the packageRevisionId, and keyset_id set to the target numeric keyset id; capture the deployment id. Step 5 — Before starting, check resource=limit, operation=get-running-deployments to confirm headroom; then start it with resource=deployment, operation=start and the id set to the new deployment id (start takes no keyset). Step 6 — Report the package id, revision id, deployment id, and running status. To view the Function's console.log/console.error output, subscribe to its log channel, which follows the pattern output-rev-REVISIONID-key-KEYSETID (use the subscribe_and_receive_pubnub_messages tool or any PubNub SDK). Never delete anything without explicit confirmation.
functions-manage-kv-store
Inspect and edit the Functions KV store (strings, JSON, counters) and the secrets Vault on a keyset.
Act as a platform engineer and use the PubNub MCP `manage_functions` tool to manage the Functions KV store and secrets for a keyset. Step 0 — Confirm the keyset (subscribe_key, sub-c-...). All KV and secret operations are keyset-scoped. Step 1 — To survey current state, run resource=kv-store, operation=list for each kv_type the user cares about (string, json, counter) and resource=secret, operation=list (secret values are never returned — only key names). Step 2 — For reads, use resource=kv-store, operation=get with kv_type and key. Step 3 — For writes, use operation=set with kv_type, key, value, and optional ttl (in seconds) for string/json entries; use operation=increment or decrement (kv_type=counter, optional amount) for counters. For secrets use resource=secret, operation=set with key and value. Step 4 — Always confirm before deleting: operation=delete (kv-store or secret) removes an entry permanently. Step 5 — Remind the user that this is the SAME store their Function code reads at runtime via require('kvstore') and require('vault') — see how_to(slug="use-pubnub-functions-kvstore-module") and how_to(slug="use-pubnub-functions-vault-module") — so edits take effect on the next Function execution. Present results grouped by type with key, value (or [secret]), and TTL where applicable.
functions-import-blueprint
Browse the Integrations Catalog and import a blueprint as a deployed package on a keyset.
Act as a solutions engineer and use the PubNub MCP `manage_functions` tool to import a Function from the Integrations Catalog. Step 0 — Confirm the target keyset as its NUMERIC keyset id (keyset_id; not the sub-c-... subscribe key) and the use case the user wants (e.g. moderation, translation, webhook forwarding). Step 1 — Browse blueprints with resource=catalog, operation=list-blueprints (optionally filter by name); present the matching package blueprints with their ids and descriptions. Step 2 — Once the user picks one, inspect it: resource=catalog, operation=get-blueprint with the id set to the package blueprint id, then operation=list-function-blueprints with the same id, and operation=list-parameters to discover the required parameters and their meanings. Step 3 — Collect values for all required parameters from the user (e.g. API keys, target channels, thresholds). Remind the user that any secrets the blueprint needs should be stored via resource=secret, operation=set on the keyset. Step 4 — Confirm the plan, then import with resource=catalog, operation=import, the id set to the package blueprint id, data set to the parameter values, and keyset_id set to the target numeric keyset id; capture the resulting package id and deployment id. Step 5 — Start the deployment (resource=deployment, operation=start) if the user wants it running, after checking resource=limit, operation=get-running-deployments. Report all created ids and the running status.
Next steps
- MCP server. What the PubNub MCP server is and how it fits into an AI-assisted workflow.
- Set up the MCP server. Connect the hosted or local MCP server to your AI coding assistant so these templates become available.
- Available MCP tools. The tools and resources these prompt templates call.
- Skills. Focused, reusable implementation guidance your AI assistant applies automatically, as an alternative or complement to a one-shot prompt template.