> ## Documentation Index > Fetch the complete documentation index at: https://docs.rippit.com/llms.txt > Use this file to discover all available pages before exploring further. # Rippit MCP server > Connect your AI assistant to your Rippit conversation data. The **Rippit MCP server** connects your AI assistant to Ask Rippit, Rippit's conversation-analysis tool, through the [Model Context Protocol](https://modelcontextprotocol.io/). Rippit hosts and manages the server. There is nothing to deploy on your side. The endpoint is: ```text theme={null} https://mcp.rippit.com/mcp ``` Your assistant authenticates each user individually through `app.rippit.com`, and can only read what that user could already read in Rippit. Compare Claude, ChatGPT, Codex, Copilot, Gemini, Cursor, and anything else that speaks MCP. Setup steps for admins and end users, one page per client. Ready-made analysis workflows for Claude. 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](/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](/skills)** package the deeper workflows as single commands.