Skip to main content
The Rippit MCP server connects your AI assistant to Ask Rippit, Rippit’s conversation-analysis tool, through the Model Context Protocol. Rippit hosts and manages the server. There is nothing to deploy on your side. The endpoint is:
Your assistant authenticates each user individually through app.rippit.com, and can only read what that user could already read in Rippit.

Which clients are supported?

Compare Claude, ChatGPT, Codex, Copilot, Gemini, Cursor, and anything else that speaks MCP.

Connect your client

Setup steps for admins and end users, one page per client.

Skills

Ready-made analysis workflows for Claude.

Security

Authentication, permissions, and data handling.

​
How setup works

Most clients follow the same two-stage pattern:
  1. An admin adds Rippit once for the whole organization or workspace.
  2. Each user signs in individually the first time they use it, with their own Rippit account.
The admin step never grants data access; it only makes Rippit available. Every user still authenticates as themselves, which is what keeps Rippit’s existing permissions intact, so each user needs their own Rippit account. See Security for the details.

​
What Rippit can do for AI assistants

Rippit gives an AI assistant structured access to your customer conversations (support tickets, chats, calls, and bot transcripts), along with the ability to classify them at scale and aggregate the results. Your client shows the exact tool list it received, which is always the authoritative version. The sections below explain what those tools make possible.

​
What this adds to an assistant that already reads well

An assistant on its own can read conversations you paste into it. That works for a handful. It doesn’t answer “why are customers frustrated this month” across 40,000 tickets, because 40,000 transcripts don’t fit in a context window and sampling twelve of them isn’t an answer. Rippit closes that gap in a specific way: it applies a judgment you describe in natural language to every row in a dataset, then returns the aggregate. The classification happens row by row, server-side, against the full text of each conversation. Your assistant gets back counts, breakdowns, and citable examples: the shape of the answer, computed over everything rather than estimated from a sample. Three properties make that practical rather than theoretical: Each judgment reads the entire conversation. Every message, in order. Not a summary, not the subject line, not a pre-existing text field. So questions that depend on what was actually said are answerable: what the customer asked for before escalating, whether the issue was resolved in-thread, what the agent missed, how the customer reacted. A summary would have flattened all of that away. Cost scales with rows, not rows × questions. Every column in one enrichment request is filled together in a single model call per conversation. Asking ten things about each conversation costs about the same as asking one, so there’s little reason to narrow the question prematurely. Results land in typed columns. Classifications are constrained to the categories you define, so the output is immediately aggregatable: group by root cause, filter to the urgent ones, cross-tab theme against channel. It doesn’t come back as prose your assistant then has to re-parse.

​
The dimension you need usually isn’t a column yet

Most reporting questions stall for the same reason: the cut you want to slice by doesn’t exist in the data. Tickets carry tags, queues, and timestamps, but nothing recording why the customer contacted you, whether the answer was correct, or which of six distinct problems a “Billing” tag actually covers. Approximating with the nearest existing column is where analyses go wrong, because a tag-based breakdown answers how tickets were labeled, not what happened in them. Rippit’s core move is to create the missing dimension: describe the judgment, apply it to the rows, then aggregate over the result. That’s the difference between reporting on your metadata and reporting on your conversations.

​
Where the data comes from

Conversations reach Rippit through your connected platforms (helpdesk, voice, and chatbot systems), so analysis runs against the systems your team already works in. Your assistant can list the integrations active on your workspace.

​
Getting good results

Name Rippit in the prompt. Most assistants need the nudge to reach for it: “Use Rippit to…”. Ask for the judgment, not the query. “Why are people contacting us about billing” uses what Rippit is for. “Count tickets tagged billing” is just a query, and the tag was probably wrong anyway. Let it enrich. Under-enriching, meaning forcing an answer out of whatever columns happen to exist, is a more common failure than adding a column that turns out unnecessary. In Claude, Skills package the deeper workflows as single commands.