An MCP server, or the files already in your repo

MCP, the Model Context Protocol, lets an AI client call tools on a server, so an agent can reach data it otherwise couldn't see. Nearly every feedback tool in this category has built one. The interesting question isn't whether to use one, it's whether your setup needs one at all.

This page is one part of a larger guide. For the whole subject in one place, see running support with a coding agent.

Checked 22 August 2026, against each vendor's own developer docs, help centre or homepage.

What is an MCP server, actually?

MCP is a protocol that lets an AI client, an agent, a chat assistant, a coding tool, connect to a server and call the tools that server exposes. The server might expose "search these tickets", "create this note" or "look up this customer". The client doesn't need custom code written for each one: it speaks MCP, the server speaks MCP, and the tools appear in the conversation the moment the connection is made.

Before MCP, giving an agent access to a vendor's data meant writing an integration by hand, one for every tool, rewritten whenever either side's API changed. MCP standardises that handshake so the integration is written once, by the vendor, and reused by every client that speaks the protocol.

Which vendors have actually shipped one?

Ask around and you'd guess three or four. Checked properly, it's closer to the whole category.

Frill.co is the one worth reading carefully rather than taking at face value. Their homepage says: "Connect Frill to Claude, ChatGPT, Cursor, and any MCP-capable AI assistant." Their /product/mcp page adds: "No SDK to install. No OAuth flow. No self-hosting." Neither claim is backed by anything in their developer docs: no MCP page, no endpoint, no repository. That doesn't prove nothing exists behind it. It means it couldn't be verified, so it belongs in this table as advertised rather than shipped, unlike the six above it.

Separately, several unofficial third-party MCP servers for Canny.io exist on GitHub, built by outside developers rather than by Canny.io itself. Worth knowing if you go looking, but not the same claim as a vendor shipping one.

What problem does an MCP server genuinely solve?

A real one, and it deserves full credit. Your feedback data lives in the vendor's database. An agent, running in your repository or your terminal, has no native way to reach it: no file to open, no folder to search. An MCP server is the bridge, a defined set of tools the agent can call to read and sometimes write that data, built once by the vendor so nobody else has to reinvent the handshake.

That's real engineering, not a marketing checkbox: scoping which actions a tool exposes, handling auth, keeping a schema in sync with a product that keeps shipping features. The seven vendors above that shipped one did that work so their customers' agents don't have to.

So what changes when the feedback is already files?

The problem an MCP server solves is created by where the data lives, not by anything inherent to feedback itself. If your feedback data is Markdown files in a repository your agent already has open, there is nothing to bridge. The agent reads files and writes files, because that's most of what a coding agent does all day, and it's already extremely good at both. No server to run, no auth handshake, no tool schema to keep in sync with something else.

The support inbox as a git repository is the shape this depends on: a reply is a file change, reviewable the way any other change to the repository is reviewable, before anyone builds a review feature for it.

Where does a repository genuinely fall short?

Three places, honestly.

A repository gives an agent a filesystem, not an API. Reading and writing a Markdown file is not the same operation as sending an email, posting to Slack or updating a billing record. "Notify this voter their request shipped" still needs something that isn't a file, whatever shape the feedback data takes underneath it.

An MCP server also gives structure and permissions a folder of files doesn't have on its own. A well-built server can expose exactly one action, create a changelog draft, say, without handing over write access to everything else. A repository checkout is usually broader than that by default, and that gap matters once an agent actually has write access and someone has to decide what it's allowed to touch. An AGENTS.md for your support centre is one way to draw that boundary in files instead of in a server's permission model, but it's a convention the agent is expected to respect, not a wall it structurally cannot get past.

And if your feedback already lives in a hosted tool, none of this is an argument to migrate off it. The MCP server is the pragmatic answer to the problem you actually have. Rebuilding your stack around files purely to avoid running one would be a worse trade than the plumbing it saves.

So which is it, an MCP server or a repository?

Their AI reads your feedback. Your agent does the work.

That's the real distinction, and it's smaller than it sounds until you sit with it. An MCP server, in nearly every case above, exposes a vendor's product to your assistant: your agent can look something up, sometimes create or update a record, always speaking through the vendor's own tool definitions and the vendor's own rules for what a tool is allowed to do.

A repository lets your agent operate the whole thing: read the request, draft the reply, edit the file, commit the change, open the pull request. Not because a repository is smarter than an MCP server, but because there's no boundary between the agent and the data to begin with. The seven vendors that shipped one built a genuinely good bridge. The question worth asking before reaching for one yourself is whether you need a bridge, or whether the water was never actually in the way.

Frequently asked questions