The Reviewflowz MCP server

The Model Context Protocol is the standard way an AI client reads an outside system. Anthropic published it in November 2024 and it stopped being one company’s idea almost immediately. A server speaks it once and every compliant client can call it.

That is the difference between a standard and a plugin. A plugin is written for one product and dies with it. Before MCP, connecting your reviews to an assistant meant a bespoke integration per assistant, and a new assistant meant a new integration or nothing at all.

Reviewflowz runs one server, at one address: https://app.reviewflowz.com/mcp/tools. In Claude you add it under Settings, Connectors, Add a custom connector. In ChatGPT you turn on developer mode and create a custom connector with the same URL. Same URL, same tools, same answers.

You set it up once rather than once per assistant, and it keeps working as the clients change. When a client you already use ships MCP support, your reviews are already reachable from it. Nothing ships here for that to be true.

Pasting an export into a prompt has a hard ceiling: the rows that fit. You pick a window before you know what you are looking for, and the answer can only ever be about the window you picked.

A query has no such ceiling, because the client asks for what it needs when it needs it. It can pull five reviews or five hundred, narrow the dates, widen them again, and come back for more once your question has changed. Your reviews going back years are all in range.

Which makes the most useful question about any bad week answerable: has this happened before. A run of sync complaints after a June release looks like a catastrophe until the same keyword search over 2023 finds the same shape after the 3.0 release, and shows it settled in six weeks.

That 2023 spike is older than any export anyone would think to paste, and it is the one that tells you what to expect. Reviewflowz keeps the whole corpus in one place precisely so the comparison is available rather than remembered.

Language models are good at reading and unreliable at tallying. Hand one four thousand reviews and ask for an average and you are trusting arithmetic done a token at a time. get_stats exists so it does not have to.

One call returns the count, the average score, the breakdown by star, how many were replied to and the reply rate as a percentage. The numbers come out of the database, so they are the same numbers your reports show, not an estimate the model assembled on the way past.

Pass a start_date, an end_date and a period of day, week or month and it returns the series as well, so “did the rating actually move or does it just feel that way” is one question with a real answer.

Every get_reviews filter works on get_stats too. Counts for one platform, one language, one topic, one tag, or only the reviews nobody has answered yet. The assistant reads the reviews for the why and asks the server for the how many.

You connect by signing in. The client sends you to Reviewflowz, Reviewflowz shows you what is being granted, you approve it. OAuth 2.1 with PKCE, so there is no API token to generate, paste into a settings box, and forget about for two years.

The consent screen says read-only because the server is read-only. It grants access to your reviews and your review profiles, and there is no write permission to grant, because there is no tool that would use one.

The connection inherits the access of the person who authorised it. If you use access groups, an assistant connected by someone who only sees three locations only ever sees those three. It cannot reach further into the account than the human it belongs to.

Each client holds its own authorisation, so revoking Claude leaves ChatGPT alone and revoking one person’s connection leaves the rest of the team working. Publishing a reply still happens in Reviewflowz, Slack or your helpdesk, where your access rules decide who is allowed to send one.