MCP server

Cascade speaks MCP, so you can point Claude, ChatGPT or any other MCP client at your own store and ask it questions in plain language:

Which products got 1-star reviews this week?
How many loyalty members are close to the next tier?
What is my average rating doing month over month?

There are two ways to connect. Both reach the same server and the same tools.

Connecting from a chat app

This is the one to use if your client has a "connectors", "integrations" or "custom MCP server" screen. There is nothing to install.

Add a connector with this URL:

https://api.cascade.dev/mcp

Your client will send you to Cascade to sign in and show you exactly what it is asking for. Read that screen: it lists every group of data the connection will be able to reach, and says plainly when something can change your data rather than only read it. If you belong to more than one organization, pick the one you want on the same screen. The connection is locked to that organization and can never reach another.

You can disconnect it later from your settings, and disconnecting takes effect immediately.

Connecting from a local tool

Editors and command-line assistants usually want a process to run instead of a URL. Those take a secret key rather than a browser sign-in:

{
  "mcpServers": {
    "cascade": {
      "command": "cascade-mcp",
      "env": {
        "CASCADE_API_KEY": "sk_your_key_here",
        "CASCADE_API_URL": "https://api.cascade.dev",
      },
    },
  },
}

Create the key under Settings, API keys, and give it the narrowest set of scopes that answers the questions you plan to ask. The server can never do more than the key allows.

What it can do

Rather than one tool per endpoint, which no assistant can use well, the server exposes a small set:

Tool	What it does
`list_` and `get_`	Browse reviews, products, customers, orders, surveys, wishlists, loyalty memberships, loyalty rewards, loyalty activity, saved charts and dashboards. They take the same filters and free-text `search` the API takes.
`run_analytics_query`	Counts, averages and trends in one request. This is what answers most questions.
`describe_schema`	What can be filtered, sorted and aggregated, so the assistant does not have to guess at field names.
`call_api`	Anything else in the API, checked against the documentation before it runs.

Two prompts ship with it as starting points: Summarize this week's reviews and Loyalty program health check.

Reading and writing

A connection is read-only by default. Nothing it does can change your store unless writes have been turned on for it, and it is not merely blocked from writing, it is never told the write tools exist.

With writes enabled, four things become possible: replying to a review, publishing or unpublishing a review, adjusting a member's points, and issuing a reward to a member. Deleting, bulk editing and importing are deliberately left out.

Every change an assistant makes is recorded in your audit log against the connection that made it, so you can always see what was done and by which application.

Limits

Responses are kept deliberately small: pages default to 25 records and long text is shortened, because a large response is slower and less useful to an assistant than a focused one. Your assistant can ask for the full version when it genuinely needs it.

MCP requests draw on their own rate limit, separate from the one your other integrations use, so an assistant exploring your store cannot slow down anything else you have running. See Rate limits.

#MCP server

#Connecting from a chat app

#Connecting from a local tool

#What it can do