# pubnub/pubnub-mcp-server [Health: Active]

**Category:** 💬 Communication  
**Repository:** https://github.com/pubnub/pubnub-mcp-server  
**GitHub Stars:** 33  
**npm Downloads (last month):** 1931  
**Views:** 0  
**Installs:** 0  
**Upvotes:** 0  
**Directory Page:** https://allmcps.com/mcp/mcp-server-152

## Description
PubNub MCP for Real-time messaging. API Access and SDK documentation.

## Tools
Capabilities this server exposes over MCP:

- **get_sdk_documentation** — Retrieve Core SDK documentation for low-level real-time features.

      **When to use:**
      - Building NON-CHAT real-time apps (IoT, gaming state sync, live analytics, notifications)
      - Need fine-grained control over pub/sub, presence, storage, or access management
      - Implementing custom real-time patterns
      - Need API reference for specific SDK methods (publish, subscribe, history, etc.)
      - For Python SDK usage always request about sync or asyncio version of langauge. 

      **Do NOT use for:**
      - Chat/messaging apps → use "get_chat_sdk_documentation" instead
      - Conceptual guides → use "how_to"

      Returns code examples, API references, and implementation guides for the specified language/feature combination.
- **get_chat_sdk_documentation** — Retrieve Chat SDK documentation for building chat/messaging applications.

      **When to use:**
      - Building ANY chat or messaging application (1:1, group, channels)
      - Need typing indicators, read receipts, @mentions, unread counts
      - Want message threads, reactions, pinned messages, moderation
      - Need user/channel management with chat-specific features
      - Prefer rapid development with intuitive methods like sendText(), startTyping(), join()

      **Do NOT use for:**
      - Non-chat real-time apps (IoT, gaming state, analytics) → use "get_sdk_documentation"
      - Conceptual guides → use "how_to"

      **Example features:**
      - messages-send-receive, messages-threads, messages-reactions
      - channels-create, channels-join, channels-typing-indicator
      - users-mentions, users-presence

      Returns code examples and API references for the specified language/feature.
- **get_sdk_migration_guide** — Retrieve SDK migration guides for upgrading between PubNub SDK versions.

      **When to use:**
      - Upgrading a PubNub SDK to a newer major version
      - Need step-by-step instructions for migrating breaking changes
      - Refactoring a codebase after a PubNub SDK version bump

      **Do NOT use for:**
      - General SDK documentation → use "get_sdk_documentation"
      - Chat SDK documentation → use "get_chat_sdk_documentation"

      Returns the migration guide content for the specified language and target version.
- **get_general_migration_guide** — Retrieve general migration guides for cross-cutting PubNub platform changes.

      **When to use:**
      - Migrating to a new encryption standard (e.g. 256-bit encryption)
      - Upgrading push notification setup (e.g. APNs HTTP/2, FCM v1)
      - Migrating to new API versions (e.g. Access Manager v3, Objects v2)
      - Replacing deprecated features (e.g. legacy webhooks)

      **Do NOT use for:**
      - SDK version upgrades (e.g. JavaScript v7→v8) → use "get_sdk_migration_guide"
      - General SDK documentation → use "get_sdk_documentation"

      Returns the migration guide content for the specified slug.
- **how_to** — Retrieve conceptual guides for specific PubNub use cases and integrations.
      **When to use:**
      - Learning how to implement a specific use case (gaming, healthcare, IoT)
      - Need step-by-step integration guide for a platform (Unity, Unreal etc)
      - Understanding PubNub features in context (presence, push notifications, functions)

      **Do NOT use for:**
      - API reference or code samples of a specific PubNub features → use `get_sdk_documentation` or `get_chat_sdk_documentation`
      - General best practices → use `write_pubnub_app`
      
- **write_pubnub_app** — Retrieve PubNub best practices guide covering:
      1) Architecture & project setup (environments, payload sizes), 2) Security (Access Manager tokens, least privilege, PII hygiene),
      3) Channel & data modeling (naming conventions, message schemas), 4) Publish/Subscribe patterns,
      5) History usage, 6) Client reliability (reconnect, idempotency, ordering),
      7) Functions/edge logic, 8) Presence & state, 9) App Context, 10) Mobile specifics (push notifications, caching),
      11) Web specifics (tab lifecycle, Service Workers), 12) Observability & ops, 13) Performance & cost optimization.
      Call this tool when building PubNub applications to ensure robust, scalable, and secure implementations.
- **manage_apps** — Manages PubNub apps with operations: list, create, update.
      - 'list': List all apps on your account.
      - 'create': Create a new app. User must provide data.name.
      - 'update': Update an existing app name. User must provide data.id and data.name.
- **manage_keysets** — Manages PubNub keysets with operations: get, list, create, update.
      - 'get': Get a specific keyset information, including its current config (message persistence, App Context, files, presence including presence rules, etc.). User needs to provide the keyset id.
      - 'list': List all keysets for your account or a specific app.
      - 'create': Create a new keyset. New keyset is created with Message Persistence, App Context, Files, and Presence enabled by default;
        the user must provide name, production, and config with nested objects (messagePersistence, appContext, files, presence),
        and if any required parameter is missing, you must ask the user to provide it.
      - 'update': Update an existing keyset. User needs to provide the keyset id and the config to update. Only provided fields are changed.
        presence.rules replaces the stored rules entirely: before changing rules, call 'get' and send the full list including the existing rules to keep.
        If 'get' returns presence.rules as "UNREADABLE", the existing rules cannot be read back; tell the user that sending rules will overwrite them and ask before proceeding.
- **get_usage_metrics** — Fetches usage metrics from the PubNub Admin API for an account, app, or keyset.

      **Parameters:**
      - entityType: 'account', 'app', or 'keyset'
      - entityId: The ID of the entity
      - from: Start date (inclusive) in YYYY-MM-DD format
      - to: End date (exclusive) in YYYY-MM-DD format
      - metrics: Array of metric names to retrieve

      **Available Metric Categories:**
      - Core transactions: txn_total, mtd_txn_total, replicated, signals, edge
      - MAU/UUID: mtd_uuid, uuid, pn_uuid
      - Messages: msgs_total, publish, subscribe_msgs, history_msgs, files_msgs, push_msgs
      - Storage: bytes_stored, bytes_stored_messages, bytes_stored_files, etc.
      - Access Manager: accessmanager_grants_transactions, accessmanager_audits_transactions
      - Functions: executions, kv_read_transactions, kv_write_transactions
      - History: history_transactions, history_with_actions_transactions
      - Message Actions: message_actions_add_transactions, message_actions_get_transactions
      - Objects/App Context: objects_create_user_transactions, objects_get_user_transactions, etc.
      - Presence: presence_herenow_transactions, presence_wherenow_transactions
      - Push Notifications: apns_sent_transactions, gcm_sent_transactions
      - Subscribe: subscribe_transactions, subscribe_heartbeats_transactions
      - Publish: publish_transactions, publish_bytes
      - Signal: signal_transactions
      - Files: files_publish_transactions, files_get_file_transactions
- **manage_app_context** — Manages PubNub App Context (Objects API) for users, channels, and memberships.
      Supports CRUD operations including get, set, remove, and getAll.
      Use this tool to manage user profiles, channel metadata, and membership relationships in your PubNub application.
- **send_pubnub_message** — Send a message or signal to a PubNub channel in real-time. Supports both regular messages and lightweight signals.
      Plain strings are automatically wrapped in a 'text' field. Requires publish and subscribe keys from your PubNub keyset.
- **get_pubnub_presence** — Retrieves real-time presence information.
      Use 'channels'/'channelGroups' for HereNow (occupancy/users in channel) and/or 'uuid' for WhereNow (channels a user is in).
      Returns presence data in JSON format. Requires publish and subscribe keys from your PubNub keyset.
- **subscribe_and_receive_pubnub_messages** — Subscribe to a PubNub channel and receive messages in real-time.
      Specify the number of messages (default 1) and/or a timeout (default 10s, max 30s) to wait for.
      Requires publish and subscribe keys from your PubNub keyset.
- **get_pubnub_messages** — Fetches historical messages from one or more PubNub channels. Call this tool whenever you need to access past message history. Provide a list of channel names. Returns message content and metadata in JSON format. Supports pagination with start/end timetokens and count limit.
- **manage_illuminate** — Manages PubNub Illuminate resources with operations: list, get, create, update, delete, activate, deactivate, get-fields, execute-adhoc, publish-fake-data, verify-query, check-action-log, raw-snapshot, aggregate, field-health, and custom-query.

      Supports full CRUD for: Business Objects, Metrics, Queries, Decisions, and Dashboards.

      **Operations:**
      - list: GET all resources of a given type
      - get: GET one resource by id
      - create: POST a new resource (Decisions use automatic 2-step POST→PUT workflow)
      - update: PUT/replace a resource
      - delete: DELETE a resource (Business Object delete cascades to all associated resources)
      - activate / deactivate: toggle isActive (Business Object) or enabled (Decision)
      - get-fields: fetch Query output field definitions (required before building a Query Decision)
      - execute-adhoc: run a one-off Query pipeline without saving it
      - publish-fake-data: generate type-aware fake PubNub messages and publish them to test Decisions. Fetches BO field schema and produces realistic values per field type. Payloads are NESTED to match each field's JSONPath (e.g. `$.message.body.application.user_id` produces `{ application: { user_id: ... } }`, not the flat key `"application.user_id"`), so JSONPath resolution works against nested BO schemas. Pass secret_key when the keyset has Access Manager enabled — initializing with the secret key grants root permissions and bypasses 403 errors. Alternatively pass auth_key with a token from grantToken(). Failures are reported per-message; partial publishes return success with a 'failures' array. NOTE: Illuminate ingests with a 20–30 second delay — wait before querying after publish.
      - verify-query: execute a saved Query by id and return results (confirms data is flowing)
      - check-action-log: fetch recent Decision action log entries to verify a Decision fired
      - raw-snapshot: return the most recent rows from a Business Object via ad-hoc query
      - aggregate: group and count BO data by user/channel or custom group_by fields
      - field-health: check which BO fields are populated vs empty (reveals JSONPath mismatches)
      - custom-query: run a fully custom ad-hoc pipeline

      **ID Dependency Chain — always capture before proceeding:**
      Business Object → id, fields[*].id
      Metric          → id, measureId, dimensionIds
      Query           → id, then call get-fields for output field IDs
      Decision        → id, inputFields[*].id, outputFields[*].id, actions[*].id
      Dashboard       → id, charts[*].id

      **Critical Decision rules:**
      hitType ('SINGLE'|'MATCH_ALL') and executeOnce (boolean) are required — omitting causes HTTP 500.
      Handler auto-injects safe defaults (hitType=SINGLE, executeOnce=false, activeFrom=now, activeUntil=now+2yr).
      executionFrequency (NOT 'evaluationFrequency' — that name is invalid) is the decision evaluation
      cadence in seconds: it schedules evaluation for METRIC/QUERY decisions, and for BUSINESSOBJECT
      decisions must stay a plan-supported value (commonly 3600), never null (a null value passes the
      API but makes the portal reject saves). Per-action throttling goes on
      rules[].actionValues[].executionLimit*, not on executionFrequency.
      The 2-step create workflow resolves field/action names → UUIDs in: action templates
      (both output variable names AND input field names — input names are sentinel-substituted
      pre-POST and restored post-POST), inputValues.inputFieldId, outputValues.outputFieldId,
      outputValues.value (dollar-brace), actionValues.actionId, and
      actionValues.executionLimitInputFieldIds. Use names everywhere.
      If the PUT step fails the handler deletes the orphaned scaffold automatically.

      **CRITICAL — QUERY decision input field naming:**
      For sourceType=QUERY decisions, each inputField.name MUST exactly match the source
      query's output field alias (case-sensitive, including underscores). Illuminate binds
      query result rows to decision inputs by NAME — not by sourceId. If names don't match,
      the decision will be created and activated successfully but will silently NEVER fire
      even with valid data. Always run get-fields on the source query first and copy the
      'field' values verbatim into your decision's inputFields[].name.

      **Business Object limits (handler pre-flights and rejects on violation):**
      - name: 1-100 characters
      - fields[].name: 1-50 characters
      - max 100 fields per BO
      - **max 5 TEXT_LONG fields per BO** (use TEXT, which holds 256 chars, for shorter strings)
      - keep `description` to ONE concise sentence (~under 200 chars). The API does NOT reject long
        descriptions, but an overly long one breaks the Admin portal Business Object detail page (it
        fails to render) — treat 'concise' as a hard rendering requirement, not a style preference.

      **Decision action types:**
      - PUBNUB_PUBLISH (portal label: Publish) — requires ALL four fields nested inside 'template':
        pubkey, subkey, channel, body.
      - WEBHOOK_EXECUTION (Webhook)
      - APPCONTEXT_SET_USER_METADATA (portal label: Update User)
      - APPCONTEXT_SET_CHANNEL_METADATA (portal label: Update Channel)
      - APPCONTEXT_SET_MEMBERSHIP_METADATA (portal label: Update Membership)
      All action config goes INSIDE the action's 'template' object — never as top-level action props.
      Putting PUBNUB_PUBLISH channel/body at the action top level does NOT error but stores
      template:null, which then breaks the portal Decisions page ('There was a problem loading your
      Decisions').
      Metric/query filters can only reference dimensions (a filtered field must be in dimensionIds),
      else 400 'Filter fields must be dimensions'.

      **Decision action default:**
      When the user doesn't specify what action to fire, default to actionType='PUBNUB_PUBLISH'
      with a message body that includes the relevant input/output values via dollar-brace
      template references. PUBNUB_PUBLISH requires no external infrastructure and is trivially
      verifiable via check-action-log or by subscribing to the target channel. Only use WEBHOOK
      when the user has provided a specific URL.

      NEVER delete without explicit user confirmation.

      TOOL SELECTION GUIDE — Illuminate Claude Behavior:
      1. Intent-first: Always start from the user's desired outcome. Ask what they want
         to achieve before suggesting Business Objects, Metrics, or Decisions.
      2. Preview-first: Before creating any resources, describe automation in 1-2 sentences
         and show a conditions → actions decision table. Ask for confirmation before building.
      3. Predefined templates: For spam (flooding/cross-posting) and ranking (Top N/Bottom N),
         use the Query Builder predefined templates. Never recreate these from scratch.
      4. Built-in BO fields: For chat/moderation/ranking, User/Channel/Message/Message Type
         are auto-created. Never ask users to define them.
      5. Start simple: Minimal decision for the core goal; add complexity only when requested.
      6. PubNub extension: For delayed checks, scheduling, or orchestration beyond Illuminate,
         suggest PubNub Functions or pub/sub as the first extension path.
- **insights** — Queries PubNub Insights — read-only aggregated analytics scoped to an account, app, or keyset.

      **Entity scoping:** Every query requires an entityType ('account', 'app', or 'keyset') and
      an entityId. For 'account' and 'app', the entityId is the numeric ID. For 'keyset', the
      entityId is the subscribe key (sub-c-...).

      Two endpoints, picked automatically by metric name:
      - /v2/insights        → aggregated metrics (unique_channels, unique_users, messages, etc.)
      - /v2/insights/top    → ranked metrics (top_20_channels, top_20_users, top_10_message_types, etc.)

      TOOL SELECTION GUIDE — Insights Claude Behavior:

      1. Group-aware: Insights metrics are organized into 5 functional groups — Channels, Users,
         Messages, User Behavior, Devices. When a user asks an analytic question, pick the right
         group first and then the specific metric. See the how-to guides:
         how_to(slug="get-insights-api-access"), channels, users, messages,
         user-behavior-and-devices, filters.

      2. Period rules (enforced at runtime):
         - Duration metrics (avg_user_duration, unique_users_by_duration_timeframe,
           top_*_channels_with_user_duration) → period=hourly ONLY.
         - Top-N metrics (top_20_*, top_1000_*) → hourly or daily ONLY (no weekly/monthly).
         - Country metrics → hourly or daily ONLY.
         - new_vs_recurring_users → daily / weekly / monthly only (NOT hourly).
         - All other metrics → all four periods supported.

      3. Top metrics REQUIRE category. Without it, the call errors. Valid categories:
         by_messages, by_chats, by_subscribers, by_users_with_messages,
         by_users_with_chats, by_subscribed_channels, all.

      4. Top-metric filtering uses `filters` (JSON), not `filter`. Use `filters` on
         top_20_* / top_1000_* for thresholds (count_messages gt), allowlists (channel_name
         in), and prefixes (uuid startsWith). Use `filter` only on channel_patterns.

      5. UTC timestamps. fromDate and toDate are YYYY-MM-DD in UTC. Always frame the response
         with the date range and timezone so the user has unambiguous context.

      6. Top-N counts CANNOT be summed across periods. If the user asks for "top channels this
         week" and you query with period=daily, return one ranking per day, not a weekly sum.

      7. Default to period=daily for most queries. It supports the widest set of metrics and
         gives a clean trend view. Use hourly only when intra-day granularity is needed or for
         duration metrics.

      8. Account must be on Insights Premium. Free plan has no API access. Pro existing
         customers may need to upgrade from Standard to Premium. If a 403 comes back, surface
         this as the likely cause.

      9. The tool does not write or store anything. Insights is strictly read-only.
    
- **manage_functions** — Manages PubNub Functions v2 via the Functions Admin API (admin-api.pubnub.com/v2/faas).
      Covers the full resource surface: packages, revisions, deployments, KV store, secrets,
      scheduled events, catalog (blueprints), and account limits.

      **Resources and operations** (the handler validates the resource/operation pair):
      - package: list, get, create, update, delete, list-revisions
      - revision: get, create, update, delete, list-functions, list-deployments, list-test-inputs, create-test-input, update-test-input, delete-test-input
      - deployment: create, get, delete, start, stop, rolling-update, intersected, stop-by
      - kv-store: list, get, set, delete, increment, decrement (use kv_type: string | json | counter)
      - secret: list, set, delete
      - scheduled-event: list, get, create, update, delete
      - catalog: list-blueprints, get-blueprint, list-function-blueprints, list-parameters, list-all-parameters, get-parameter, import
      - limit: get-running-deployments

      **Core model (v2):** a Package groups Functions and tracks immutable Revisions. A Revision is
      deployed to a keyset as a Deployment, which you then start/stop. To ship a Function end-to-end:
      (1) package create (creates the initial revision + functions), (2) deployment create with the
      packageRevisionId on the target keyset, (3) deployment start. Use rolling-update to swap a
      running deployment to a new revision with no downtime.

      **Authentication:** uses the same Service Integration key as manage_illuminate (PUBNUB_API_KEY
      env var, or an OAuth Bearer token in HTTP mode). Permissions follow the Admin API model (each
      operation is annotated in the FaaS OpenAPI spec, the canonical source): packages, revisions,
      test-inputs, limits, and blueprint import require functions.package:read|write on the ACCOUNT;
      deployments and scheduled events require functions.package-deployment:read|write on the KEYSET;
      KV store and secrets require keyset:read|write on the KEYSET. (These are Admin API permission
      scopes, not portal user roles.)

      TOOL SELECTION GUIDE — Functions Claude Behavior:

      1. Keyset scoping differs by resource. kv-store and secret operations take subscribe_key
         (sub-c-..., sent as the subkey query param) — it must be provided as an argument.
         deployment create, deployment intersected, and catalog import take the NUMERIC keyset id as
         keyset_id (deployment lifecycle ops start/get/delete take only the deployment id; stop also
         accepts an optional force flag, and intersected accepts an optional function_type filter).
         scheduled-event operations take no keyset (the keyset is derived from the referenced
         deployment). Package, revision, catalog-read, and limit operations are account-scoped.

      2. ID chain — capture and reuse: package create → packageId + revision id; deployment create →
         deployment id. revision list-functions → function revision ids (needed for test inputs).

      3. KV store vs Vault: kv-store is the Functions KV database (string/json/counter). Use increment/
         decrement only with kv_type="counter". secret manages the Vault (encrypted; values are never
         returned by list). These mirror the require('kvstore') and require('vault') modules used in
         Function code — see how_to(slug="use-pubnub-functions-kvstore-module") and "...vault-module".

      4. Deployment lifecycle is stateful and has side effects. Account has a running-deployments limit
         (check via resource=limit, operation=get-running-deployments). Starting a deployment consumes
         the limit. NEVER delete a package, revision, or deployment without explicit user confirmation;
         a package must be stopped before it can be deleted.

      5. Authoring vs managing: this tool MANAGES Functions resources. To WRITE the JavaScript handler
         code, follow how_to(slug="develop-pubnub-functions") and the module guides. Function code must
         be a default export with the correct signature for its eventType (request/response for On
         Request, request for Before/After events, event for On Interval) and must return the matching
         completion call.

      6. Catalog: use list-blueprints to browse templates, then import to create a package (and deploy
         to a keyset) from a blueprint. Inspect required parameters via list-function-blueprints /
         list-parameters before importing.

      7. Function logs: a running Function's console.log/console.error output is PUBLISHED to the
         channel output-rev-<functionRevisionId>-key-<keysetId> (there is no log API). To read logs,
         subscribe to that channel with the subscribe_and_receive_pubnub_messages tool (or any SDK).
         Get functionRevisionId from revision list-functions; keysetId is the numeric keyset id.

      8. Errors: the API returns a FAAS-* envelope ({ errors: [{ code, message }] }). Surface the code
         and message. Common cases: 403/FAAS-1027 (the Service Integration lacks the required
         permission scope for the operation — e.g. functions.package-deployment:write on the keyset),
         running-deployment limit reached, and "package must be stopped before deletion".

## Claude Desktop Quick Installation
Install path detected from listing signals. Uses `npx` (confidence: high):

```json
"mcpServers": {
  "pubnub-mcp-server": {
    "command": "npx",
    "args": ["-y","@pubnub/mcp@latest"],
    "env": {
      "PUBNUB_API_KEY": ""
    }
  }
}
```

**Requires environment variables:** `PUBNUB_API_KEY` — the values above are empty placeholders; fill in real credentials before running (see the repository for what each one is for).

## Documentation

## What pubnub/pubnub-mcp-server MCP server does

pubnub/pubnub-mcp-server MCP server connects AI assistants with PubNub SDK guidance and PubNub API resources. It can provide implementation documentation, code examples, migration guidance, and how-to instructions for more than 20 programming languages, including JavaScript, Python, Java, Swift, Kotlin, C#, Ruby, and Go.

The server also exposes operations for PubNub administration and real-time application work. Agents can manage applications and keysets, send messages, subscribe to receive messages, retrieve message history, inspect presence, and work with app context. Additional tools cover usage metrics, Illuminate, and insights for monitoring or analyzing PubNub activity.

## How it works

The hosted deployment is available at `https://mcp.pubnub.com` and uses HTTP transport with OAuth authentication. An MCP-compatible client connects to that URL, then the user authorizes access to a PubNub organization. The repository documents setup for VS Code, Cursor, Claude Code, Claude Desktop, Codex, and Gemini CLI.

For clients without remote MCP support, the package can run locally with `npx @pubnub/mcp@latest`. The local setup uses Node.js 20 or newer. A PubNub API key is recommended because some local features work without one, while additional functionality becomes available when the key is supplied.

## Setup and configuration

For hosted use, configure the client with the server URL and complete the OAuth flow. No local installation is required. Client-specific setup may involve adding a remote server entry, using an MCP command, or adding a custom connector.

For local use, start the package with:

```bash
npx @pubnub/mcp@latest
```

The documented local configuration uses the `PUBNUB_API_KEY` environment variable for a PubNub service integration or API key. The README also refers to an alternative configuration for working with a single PubNub keyset, but the supplied setup details do not specify its variable names.

## Tools and capabilities

The listed MCP tools include:

- `get_sdk_documentation`, `get_chat_sdk_documentation`, `how_to`, and `write_pubnub_app` for SDK research and application guidance.
- `get_sdk_migration_guide` and `get_general_migration_guide` for migration-related information.
- `manage_apps` and `manage_keysets` for PubNub application and keyset administration.
- `send_pubnub_message`, `subscribe_and_receive_pubnub_messages`, and `get_pubnub_messages` for channel messaging workflows.
- `get_pubnub_presence` for presence information.
- `manage_app_context` for user, channel, and membership-related data.
- `manage_illuminate` and `insights` for real-time decisioning and analytics-related operations.
- `get_usage_metrics` for current or historical usage information.

## Limitations and notes

pubnub/pubnub-mcp-server MCP server depends on PubNub access and authorization for operations that interact with accounts, applications, keysets, or data. Some local functionality is available without an API key, but the README recommends supplying one to unlock more features. User, channel, and membership administration through the PubNub Admin Portal requires Manage Premium. Full analytics require Manage Premium, while limited metrics are available without it; Illuminate is required for the real-time decisioning and analytics capabilities described in the README.

The hosted deployment requires an MCP client that supports remote HTTP connections and OAuth. If a client cannot use remote MCP servers, use the local npx package instead. The documented local installation requires Node.js 20.0 or later.

_Full upstream README: https://allmcps.com/mcp/mcp-server-152/readme_