Pendo MCP: what it reaches, how to connect it, and what it won't fix.

For most of Pendo's life, the answer to “how are they actually using it?” had to come from a few people with a Pendo account. The support agent handling a complaint, the account manager preparing for a renewal, the founder who wants one number before a board meeting had to find someone with access, and wait. Pendo's pitch for its MCP server is that this stops being true, and that any AI tool can become a product expert.

The server is now a remotely hosted gateway between your subscription and any AI client that speaks the Model Context Protocol (MPC). You ask a question in Claude, ChatGPT or Cursor, and the answer comes from your Pendo data, in the tool where you already work, with no dashboard and no export. Pendo has improved reach.

The catalogue is broader than most people expect. Page and feature usage is the obvious part, but guides, sentiment surveys, session replays, raw customer feedback and Orchestrate journeys are all reachable too. What matters more is that every area carries a ceiling, and the ceilings decide which workflows are viable.

Nothing works until a subscription admin turns it on, under Settings, Subscription settings, AI access. Read-only tools and write tools are separate toggles there, and read-only has to be on first.

After that, connecting is a per-user job, and the experience is not the same across tools. That difference matters more than Pendo lets on, because the client you pick decides whether your non-technical people ever actually use this.

# Claude Code, US region
claude mcp add --transport http pendo \
  https://app.pendo.io/mcp/v0/shttp

# Use the endpoint that matches your Pendo login region
# US1        https://us1.app.pendo.io/mcp/v0/shttp
# EU         https://app.eu.pendo.io/mcp/v0/shttp
# Japan      https://app.jpn.pendo.io/mcp/v0/shttp
# Australia  https://app.au.pendo.io/mcp/v0/shttp

# Any other MCP client
{ "mcpServers": { "Pendo": { "url": "<your-regional-endpoint>" } } }

Whichever client you use, you are sent through an OAuth prompt and sign in with your normal Pendo credentials. In Claude, every tool starts on “needs approval”, so it asks before each query until you tell it otherwise. When a connection fails it is almost always the URL: people paste their Pendo login address instead of the full /mcp/v0/shttp path, and the client caches the mistake.

These get confused, and they answer different questions. Leo is Pendo's built-in AI. You use it inside Pendo, it needs no setup, and it hands you curated insights without leaving the product. The MCP server does the opposite: it brings your Pendo data out to the tool you already work in, and lets you sit it next to your CRM, your tickets or your docs.

The rule of thumb is simple. Reach for Leo when you want a quick, curated answer and you are already in Pendo. Reach for the MCP server when the work is happening somewhere else, or when you want product data combined with another source, or when you are building something that runs on a schedule. They are not rivals. One keeps you in Pendo, the other meets you where you left it.

The write tools are deliberately narrow. They cover creating and updating feedback items and ideas, and linking the two together, so the worst case is a cluttered Listen backlog rather than a damaged analytics record. An admin has to opt into them separately.

Everything else is inherited rather than configured. Every request runs as the person who signed in, so nobody can reach data they could not already open in Pendo, and nothing crosses regions.

Interactive OAuth covers a person asking questions. For anything that runs on its own, a scheduled digest, a churn-risk check, a support bot with live product context, Pendo provides service accounts: a client credentials grant exchanged for a bearer token that lasts sixty minutes and carries no refresh token. You get twenty-five per subscription, and they need the API package.

One warning in Pendo's documentation is worth repeating, because it is easy to get wrong in a hurry. The credential grants access to everything that account can see, so it must never sit behind anything your end users can type into.

The ceilings are inconsistent, and hitting one rarely produces an error you would notice. You get a shorter answer than you expected, delivered with the same confidence as a complete one.

• Date windows: most usage tools reach back 367 days, but Product Engagement Score stops at 180, agent analytics at 90, and single-visitor timelines and replay searches at 31.
• Result caps: feedback and ideas return thirty items per call, replay searches fifty, developer logs a hundred.
• No replay content: you get links, metadata and the console and network logs, never the recording itself.
• Pendo's own boundary: the documentation recommends the Pendo UI for historical trends and in-depth guide reporting. That is Pendo drawing the line, not me.

None of this checks whether the data underneath is worth querying. An LLM will not tell you your feature tags are broken. It answers the question you asked, fluently, using whatever is there, and it sounds exactly as certain when the numbers are wrong.

So the problems I usually find in an installation audit get amplified rather than exposed. Internal users nobody excluded now inflate the adoption figure a sales rep quotes on a call. A feature tagged with a positional selector that broke three releases ago now reads as a feature nobody wants. Before, a bad number reached one analyst who might have questioned it. Now it reaches everyone at once, in prose that sounds like an answer.

If you want a sequence: verify the installation first, then enable read-only tools, connect one client, and give the fastest questions to the people who already know your data. Used that way it makes your Pendo team considerably quicker, which is a better outcome than handing the whole company a confident answer nobody checks. If you would rather have the verification done properly first, or the whole thing set up and governed, that is what I do.