Give your AI full access to your Help Scout inbox.
Every resolved conversation, your knowledge base, and your help center, searchable by meaning from Claude, Cursor, or any MCP client. Six tools, all read-only: your AI can find anything and touch nothing.
Finally, a search that works.
Help Scout’s search is keyword search: the exact words, or nothing. The customer wrote “billed twice”, you search “double charge”, and the ticket you know exists never comes up. Every support team knows the ritual: try three phrasings, give up, ask in Slack.
This server searches by meaning. ReplyScout embeds every resolved conversation, both the customer’s message and your team’s reply, so a query in your words finds the ticket in theirs. And because both sides are indexed, both questions get answered: have we seen this before, and what did we say?
refund double charge
“Hi, I think I was charged twice this month. Could I get one of those payments back?”
Zero keywords in common. Same problem.
cancel but keep data
“If I downgrade to the free plan, do my projects get deleted after 30 days?”
The customer never said “cancel”. Meaning matches anyway.
how we explain sso migration
Your teammate’s reply from March that walked a customer through the cutover, with all the phrasing and caveats.
type: "agent" searches what your team said, not what customers asked.
What you’ll actually ask it.
Connect it once and every AI tool you use gains your support history. These are first-day prompts, not a roadmap.
For support leads
“Summarize this customer’s history before my call with them.”
get_conversation loads the full thread plus every past conversation from that customer.
For engineers
“Have any customers hit this webhook timeout? How did we work around it?”
search_similar_tickets, from inside Cursor or Claude Code, while the bug is still on your screen.
For new teammates
“How do we usually phrase it when we decline a refund?”
Agent-side search over your team’s past replies. Institutional memory without interrupting anyone.
For docs writers
“What do customers actually ask about onboarding? Draft a help article that answers it.”
search_similar_tickets for the real questions, search_help_articles to check what’s already published.
For triage
“List unassigned open tickets tagged billing and flag anything about failed payments.”
list_conversations filters by status, assignee, and tag; get_conversation loads the ones that matter.
For anyone answering
“Find our policy on invoice reissues and what we told the last customer who asked.”
search_documentation plus search_similar_tickets in one pass: policy and precedent together.
It can find anything. It can’t touch anything.
Ask anyone who runs a Help Scout MCP server which feature gets requested most. The answer is write access: let the AI reply, tag, close. The community servers that shipped it ended up burying customer-visible sends behind two separate opt-in flags, because nobody actually wants an assistant that is one confused tool call away from emailing a customer.
So this server has no write surface at all. Not disabled, just absent. There is no flag to flip and nothing to misconfigure:
- No send
- No edit
- No tag changes
- No close
- No delete
That makes it safe to hand to anything: a model you’re still evaluating, an autonomous agent, an intern’s experiment. The worst thing that can happen is a read.
And when you do want AI-written replies, that’s ReplyScout itself: it drafts inside Help Scout, your agent reviews, and nothing ever auto-sends. Same retrieval layer, human hand on the send button.
Six tools, not sixty
Some MCP servers mirror the entire Help Scout REST API into a hundred tools, and your context window pays for every one of them on every request. These six cover the two jobs that matter: read the inbox, search it by meaning. All read-only. The search tools need an inbox ID, so call list_inboxes first.
- search_similar_tickets
- Semantic search across resolved conversations in an inbox. Matches both the customer message and your team’s reply, so "have we seen this before?" and "how did we phrase that?" both work. Narrow with type: customer or agent when you know which side you want.
- search_documentation
- Searches the knowledge base indexed for that inbox: internal policies, product details, runbooks. Returns passages with source URLs.
- search_help_articles
- Searches your public help center so answers stay consistent with what customers can already read. Returns article titles and shareable URLs.
- get_conversation
- Loads a full thread plus that customer’s history, with HTML email noise stripped. The context you need before answering, in one call.
- list_conversations
- Browses and filters an inbox by status, assignee, tag, or customer. For triage sweeps and reporting.
- list_inboxes
- Discovers the connected inboxes and their IDs. Call this first, since the search tools need an inbox ID.
Help Scout ships an MCP server. This one does retrieval.
Help Scout’s own MCP server went GA in July 2026, it’s free on every plan, and it’s a good piece of work: read-only access to live conversations and customer data, scoped to each teammate’s permissions. If you want your assistant to pull up a ticket, use it.
ReplyScout’s MCP server answers a harder question: have we solved this before, and what did we say? Its search tools run over the semantic indexes ReplyScout builds from your resolved conversations and your documentation. It finds the ticket that means the same thing, not the one that happens to share a keyword. The two servers compose, and most teams run both.
Live conversations, customers, and inbox analytics via the Help Scout API.
Per-user permission scoping. Free on every plan. Read-only.
Best for: pulling up and reporting on what’s in the inbox right now.
Semantic search over resolved tickets, your knowledge base, and your help center.
Matches customer questions and your team’s past replies. Read-only.
Best for: recalling precedent, policy, and phrasing before you answer anything.
Setup takes a minute
It’s a hosted remote server, so there is nothing to install: no npm package, no Docker container, no local process to keep alive. Streamable HTTP, MCP protocol 2025-06-18, one bearer token.
Generate a key in your ReplyScout account settings. Keys are stored as SHA-256 hashes and scoped to the inboxes on your account; rotating a key invalidates the previous one immediately.
Claude Code, in one command:
claude mcp add --transport http replyscout https://app.replyscout.com/mcp \
--header "Authorization: Bearer rs_your_api_key"Claude Desktop, Cursor, and other config-file clients:
{
"mcpServers": {
"replyscout": {
"type": "http",
"url": "https://app.replyscout.com/mcp",
"headers": {
"Authorization": "Bearer rs_your_api_key"
}
}
}
}Try “Which Help Scout inboxes can you see?” That’s list_inboxes, and if it answers, you’re live. Then ask the question you’ve given up typing into Help Scout search.
Help Scout MCP questions
Help Scout’s MCP server, generally available since July 2026, gives your AI assistant read-only access to live conversations and customer data through their API, scoped to each user’s own permissions. It is free with every Help Scout plan and it is genuinely good. ReplyScout’s MCP server solves a different problem: retrieval. Its search tools run semantic search over your resolved tickets and your indexed knowledge base, so the assistant finds the conversation that means the same thing rather than the one that shares keywords. Most teams run both.
No, and that is the point. All six tools read; there is no write surface at all: no send, no edit, no tag, no close, nothing to misconfigure. Community Help Scout MCP servers that added write tools ended up hiding customer-visible sends behind two separate opt-in flags, because nobody wants an assistant one confused tool call away from emailing a customer. We left writes out entirely. When you want AI-written replies, that is ReplyScout itself: it drafts inside Help Scout and a human reviews every draft before sending.
Help Scout searches keywords: the exact words, or nothing. ReplyScout embeds every resolved conversation in a semantic index, so a query matches tickets that mean the same thing. "Refund double charge" finds "I was billed twice this month". It also indexes both sides of each conversation, the customer’s message and your team’s reply, so you can search what was asked or how your team answered it.
Any MCP client that speaks streamable HTTP with a bearer token: Claude Code, Claude Desktop, Cursor, Windsurf, and others. It is a hosted remote server, so there is nothing to install. No npm package, no Docker container, no Node version to fight, no local process to keep alive. The server implements MCP protocol version 2025-06-18.
Yes. The MCP server authenticates with a ReplyScout API key and requires an active subscription or trial, because the search tools query the ticket and documentation indexes that ReplyScout builds for your inbox. The 7-day trial includes MCP access.
When you connect an inbox, ReplyScout indexes its resolved conversations and any knowledge base you point it at. Those indexes power the drafting engine, and the MCP server exposes the same retrieval layer to your own AI tools.
Whatever your team can see in the inboxes you connected: real conversation content, including customer names and email addresses. That is what makes the answers useful. You scope it by choosing which inboxes to connect; nothing outside them is reachable. Every request needs a bearer API key, keys are stored as SHA-256 hashes, access is read-only, and rotating a key in settings invalidates the old one immediately.
No. It is six tools with deliberately terse descriptions. Servers that mirror the full Help Scout REST API expose 50 to 100+ tools, and your AI pays for that entire toolbox in every single request. Six focused tools keep the footprint small enough to leave the server connected all day.
Give your AI tools your team's memory.
The MCP server is included with every ReplyScout plan, and the 7-day trial covers it. Connect an inbox, grab a key, ask your first question in five minutes.