Whooshly MCP

What whooshly-mcp MCP server does

whooshly-mcp MCP server exposes Whooshly account operations to MCP-compatible assistants. It supports short-link creation, dynamic QR generation, reusable UTM templates, hosted digital business cards, and landing pages built from content blocks. It can also retrieve click and scan totals, daily analytics, saved QR images, link records, and landing-page lead counts.

The server operates only on the authenticated user's Whooshly account. Link searches can match slugs or destinations, while detailed link records can be retrieved by ID. Landing pages can be created and edited, including their content blocks, theme, and slug. Updates do not delete pages.

How it works

Whooshly hosts the MCP service at https://app.whooshly.co/api/mcp. URL-based clients connect directly to that endpoint. For clients that use the stdio transport, the npm package acts as a small relay: it reads newline-delimited JSON-RPC messages from standard input, forwards them to the hosted service with a bearer token, and writes the corresponding responses to standard output.

The bridge requires Node.js 18 or newer and has no npm dependencies. Authentication, entitlement checks, rate limits, QR rendering, and analytics processing happen on Whooshly's service rather than in the bridge. As a result, the package is a transport adapter, not a local implementation of the Whooshly API.

Setup and configuration

To authenticate, create an agent token in the Whooshly application under Agents, then provide it to the client. For a stdio configuration, run npx -y whooshly-mcp and set WHOOSHLY_TOKEN in the MCP server environment. WHOOSHLY_API_TOKEN is also accepted as an alias.

The remote endpoint can be used directly by Claude or ChatGPT connectors. Claude Code can register it with the HTTP transport, using browser authentication or an authorization header containing the token. Claude Desktop and other stdio clients can use the npm bridge.

WHOOSHLY_MCP_URL optionally replaces the default endpoint, which is useful for a staging or self-hosted endpoint. WHOOSHLY_TOKEN is required for the stdio bridge. The get_billing_status tool can run on any account; the other listed operations require the Core entitlement.

Tools and capabilities

• Check account entitlement with get_billing_status.
• Create, list, search, and inspect short links with create_link, list_links, search, and fetch.
• Retrieve exact click and scan totals plus a daily series through get_link_stats.
• Generate or retrieve dynamic QR codes as PNGs using create_qr and get_qr.
• Save and list reusable UTM templates with create_utm and list_utm.
• Create hosted vCard pages with create_vcard.
• Create, edit, list, and inspect landing pages with create_page, update_page, list_pages, and get_page.

All tools are scoped to the connected account. Read operations are marked read-only. Write operations can create or edit resources, but the agent cannot delete them. It can see aggregate lead counts and webhook delivery rollups, not leads' personal details, and it cannot read or modify a lead webhook.

Limitations and notes

whooshly-mcp MCP server does not provide local storage or local QR rendering; those responsibilities remain with the hosted Whooshly service. A working agent token is needed for the stdio bridge, and most tools are unavailable until the account has unlocked Core. The endpoint and account access also determine whether the requested operation can complete.

The bridge does not expose arbitrary accounts or cross-account data. Its requests are authenticated with the supplied token, and the server prevents tools from operating outside that token's Whooshly account. Because deletion is not available through the tools, removing resources must be handled through another supported Whooshly interface if applicable.