TL;DR

  • BugHerd is a genuinely strong website feedback and bug-tracking tool: point-and-click element pinning, auto-captured browser/OS/URL/screenshot metadata, a kanban board, and integrations with Jira, Trello, Asana, GitHub and more.
  • BugHerd also shipped an MCP server, which is a real signal that they take the agent workflow seriously. As documented at the time of writing, its tools read and write tasks: the client comment text, a screenshot, the page URL, browser and OS, status, severity, assignees, tags and comment history.
  • That is the ticket, in text and static-image form. What the BugHerd MCP does not appear to hand an agent is a recording's structured context — a transcript, timestamped key-moment frames, or the click coordinates of what the reporter actually did.
  • Clipy takes the opposite starting point. You record the bug, and Clipy's MCP hands the agent the recording itself: a summary, key moments with frames and click coordinates, and the full transcript — delivered through real MCP tools your coding agent can call.
  • The honest way to choose is to ask one question: when my AI agent picks up this bug, what does it actually receive? If the answer needs to include "what happened on screen, in order, with the clicks," that is the axis this post is about.

Why BugHerd having an MCP at all is worth noticing

Most bug-tracking and feedback tools still assume a human is going to read the ticket. BugHerd is one of the few incumbents that has actually shipped a Model Context Protocol server, which means it is telling an "agent" story out loud. That is worth taking seriously rather than dismissing.

An MCP server is the thing that lets a coding agent — Claude, Cursor, ChatGPT, a Codex or Gemini CLI, and so on — call structured tools instead of screen-scraping a dashboard. When a tool ships one, it is making a bet that the next "user" of a bug report is a machine, not just a developer with coffee. BugHerd made that bet, and this comparison is a fair fight because they did.

So the question this post asks is not "does BugHerd have an agent story" — it clearly does. The question is narrower and more useful: what does that agent story actually put in front of your AI when it opens a bug?

What BugHerd (and its MCP) is genuinely good at

Let's be specific and fair, because BugHerd earns it.

Element-pinned visual feedback. BugHerd's core move is letting a client or teammate drop a pin directly on a live web page — point, click, comment — and that feedback stays attached to the exact element. For website QA and client review cycles, this is a legitimately great pattern. Nobody has to write "the button near the top-ish, on the right, you know the one" ever again.

Automatic technical capture. Every comment arrives with browser version, operating system, screen resolution, device info and the page URL captured automatically, plus a screenshot of what the reporter saw. That removes the tedious back-and-forth of "what browser were you on?" It is exactly the metadata a triage step wants.

Kanban and integrations. Feedback becomes a trackable task on a board, and BugHerd pushes into Jira, Trello, Asana, ClickUp, GitHub, Slack and Teams. If your workflow already lives in one of those trackers, BugHerd slots in cleanly.

A real MCP surface. The BugHerd MCP exposes tools to read task details, list a project's tasks, list your tasks, list projects, get project details — and to write: update a task, add a comment, create a task, create a project, update a project. An agent can triage, prioritize, comment, close, and open new work from a single prompt. That is a genuinely useful loop for keeping a tracker tidy.

None of that is faint praise. If your problem is "clients leave vague feedback on our website and it gets lost," BugHerd is a strong answer, and its MCP makes that answer scriptable by an agent.

What the BugHerd MCP actually hands an agent

Here is the careful part. As documented at the time of writing, when a BugHerd task is read through its MCP, the agent receives the task's data:

  • the client's comment as verbatim text,
  • a screenshot of what the reporter saw,
  • the page URL,
  • browser version and OS,
  • task status, severity, assignees, due date and tags,
  • the client-visibility flag,
  • and the full comment history.

Read that list again through the eyes of a coding agent that has been asked to reproduce and fix the bug. It is a rich description of the ticket and a single static frame of the outcome. It tells the agent the "where" (URL, element, browser) and the "what the human typed." It is excellent for triage, routing and prioritization — which is exactly what the MCP's write tools are built to do.

What it does not appear to include is the sequence of events that produced the bug. A comment plus a screenshot captures the end state and the human's interpretation of it. It does not capture the three clicks that got there, the order they happened in, the transient toast that flashed and vanished, or the exact coordinates the user pressed before the app broke. BugHerd does offer a video-feedback capability for humans to record and share sessions — but that is a human-viewing artifact, and the MCP's documented tool surface is task, comment, screenshot, project and metadata text. It does not appear to hand the agent a recording's transcript, its timestamped frames, or click coordinates as structured data the agent can reason over.

That is not a knock on BugHerd's quality. It is a statement about what layer its MCP operates at: the ticket layer. If you want the agent to receive the recording layer, you need a tool whose MCP was built to serve the recording.

What Clipy's MCP hands an agent — the recording itself

Clipy starts from the other end. You record the bug — screen, and on Mac or the Chrome extension, the cursor and clicks too — and Clipy turns that recording into something an agent can read directly. The whole design goal is stated on the for-agents page: the recording is the source of truth, and the agent gets structured access to it.

There are two doors into that structured context.

The .md door. Every Clipy recording has a plain-text agent view at https://clipy.online/video/<id>.md. Append .md to the watch URL and you get a document written for a machine to read: a short NOTE-for-agents preamble, the title, the summary, and — for feedback-style recordings — a "Requested changes" / "Fix checklist" section. Then the key moments as timestamped JSON, each with a frame, a pointer crop, and where the recording supports it, the click coordinates expressed as fractions of the frame, a source label (fused, click, or hover), a confidence value, and a burned-in marker drawn on the coordinate frame. Then the full transcript. It follows the same access rules as the watch page, so a private recording stays private.

The MCP door. For agents that speak MCP, Clipy ships a server you run with npx -y @clipy/mcp, authenticated with a key from clipy.online/settings/api-keys. It is read-only and scoped to your own recordings. The tools are the ones an investigating agent actually wants:

  • get_agent_context — the whole structured package for a recording in one call,
  • get_key_moments — the timestamped moments, with frames delivered as inline images and click coordinates where available,
  • get_transcript — the words that were said,
  • get_summary — the recording distilled,
  • search_recordings and list_recordings — find the right recording,
  • get_recording — pull one by id.

The difference from the ticket layer is concrete. When a Clipy-backed agent opens a bug, it is not reading a human's paraphrase and squinting at one screenshot. It is reading what happened, in order, with the clicks: the summary tells it the gist, the transcript tells it what the reporter narrated, and the key moments tell it — frame by frame, with coordinates — where the cursor went and what it hit right before things went wrong. Frames arrive as inline images through the MCP, so a vision-capable agent can actually look at the state at each step.

One honest boundary: click coordinates are captured on the Mac app and Chrome-extension recordings. The web recorder gives the agent the summary and transcript but not coordinates. And Clipy does not claim to auto-fix your bug — it hands the agent the context; the fixing is still your agent's job. Full setup lives in the MCP docs.

The comparison, on the one axis that matters

Strip away everything else and line the two MCPs up on the single question: what does the agent receive when it opens the bug?

  • Client's words. BugHerd: yes, verbatim comment text and comment history. Clipy: yes, as the transcript of what the reporter narrated while recording, plus a generated summary.
  • A picture of the problem. BugHerd: a screenshot of the end state. Clipy: multiple timestamped key-moment frames across the recording, delivered as inline images.
  • The sequence of actions. BugHerd: not part of the documented MCP surface — you have the end state, not the steps that led there. Clipy: yes, the key moments are ordered through the recording.
  • Where the user clicked. BugHerd: not exposed as structured data to the agent. Clipy: click coordinates as frame fractions on Mac and Chrome-extension recordings, with a burned-in marker on the coordinate frame.
  • Environment metadata. BugHerd: excellent — browser, OS, resolution, device, URL, all automatic. Clipy: this is BugHerd's strength; Clipy's focus is the recording's content, not the client's browser fingerprint.
  • Element pinning on a live site. BugHerd: yes, its signature feature. Clipy: no — Clipy records the session rather than pinning to DOM elements.
  • Write-back into a tracker. BugHerd: yes — update tasks, add comments, create tasks and projects from the agent. Clipy: read-only by design; it feeds context in, it does not manage your board.
  • Cost to the viewer. Clipy is free, with no watermark and no signup required to watch a shared recording. BugHerd is a paid team product (its MCP is free for BugHerd users).

Notice that the two lists barely overlap. BugHerd's MCP is strongest exactly where Clipy is quiet (element pinning, environment metadata, tracker write-back), and Clipy is strongest exactly where BugHerd's MCP is quiet (the ordered sequence, the clicks, the transcript, multiple frames). These are not the same product wearing different hats. They are answers to two different questions.

A concrete example: the same bug through both MCPs

Abstractions are easy to nod along to, so picture one specific bug: a user reports that clicking "Save" on a settings page silently does nothing — no error, no confirmation, the form just sits there. Here is what each agent actually gets to work with.

Through the BugHerd MCP, the agent calls something like get_task_details and receives: the comment "Save button doesn't work on the settings page," a screenshot of the settings page with the pin on the Save button, the URL app.example.com/settings, "Chrome 141 on macOS," severity high, assigned to nobody yet, and two follow-up comments from a teammate. This is a great triage packet. The agent can confidently label it, route it to the frontend team, set severity, and post a "looking into this" comment — all things BugHerd's write tools do well. But if the agent is asked to reproduce the failure, it has the destination without the road: it knows the Save button on the settings page is implicated, but not what field the user had just edited, whether a validation error flashed and disappeared, or whether the click even registered. It has to guess, or ask the human to go do it again.

Through Clipy's MCP, the agent calls get_agent_context for the recording the user made while hitting the bug, and receives an ordered story. The summary says the user changed their display name, clicked Save, and nothing happened. The transcript has the user saying, out loud, "I'm changing my name here, now I click Save, and — see, nothing." The key moments give it frames at each step with click coordinates: the cursor entering the name field, the click on Save at a specific point in the frame, and the frame immediately after — where a vision-capable agent can read a tiny red validation hint under a different field the user never scrolled to. That is the bug: a hidden validation error on an unrelated field is blocking submit, and the UI isn't surfacing it near the button. The agent didn't guess. It watched.

That contrast is the whole post in one story. The ticket layer tells you which button and which browser. The recording layer tells you the sequence that broke it. Neither is wrong; they are answers to different halves of "reproduce this."

Which one fits your workflow

Reach for BugHerd when the unit of work is website feedback from clients and reviewers, you want it pinned to the exact element, you want browser/OS/URL captured for you automatically, and you want an agent that can keep your kanban board and tracker organized. That is a real, well-served use case, and BugHerd's MCP makes it scriptable.

Reach for Clipy when the unit of work is a bug or a flow that has to be reproduced, and the thing your AI agent needs is not "which element" but "what sequence of actions, in what order, with which clicks, produced this." When the value is in the recording — the steps, the narration, the frames, the coordinates — you want the MCP that hands the agent the recording, not the one that hands it the ticket about the recording.

Plenty of teams will want both: BugHerd for structured client feedback on the website, Clipy for the messy "here, watch me break it" repro that a coding agent then reads end to end. They are complementary far more than they are competitive.

See it in practice

If you want to go deeper on the agent-reading workflow specifically, these walk through it:

FAQ

Does BugHerd have an MCP server? Yes. BugHerd shipped an MCP server that connects AI tools like Claude, Cursor and ChatGPT to your BugHerd projects and tasks. As documented at the time of writing, it can read task details and lists of tasks and projects, and it can write — update tasks, add comments, and create tasks and projects.

Does the BugHerd MCP give my agent a screen recording's transcript or click coordinates? Not that we can confirm from its documented tool surface. When an agent reads a BugHerd task it receives the client's comment text, a screenshot, the page URL, browser and OS, and task metadata such as status, severity, assignees, tags and comment history. It does not appear to hand the agent a recording's transcript, timestamped frames, or click coordinates as structured data. BugHerd does have a human video-feedback feature, but that is separate from what the MCP exposes.

What does Clipy's MCP expose that's different? Clipy's MCP is built to serve the recording itself. Its read-only tools — get_agent_context, get_key_moments, get_transcript, get_summary, search_recordings, list_recordings and get_recording — hand the agent a summary, a transcript, and timestamped key-moment frames with click coordinates (on Mac and Chrome-extension recordings). Frames come back as inline images the agent can actually see.

Do I need the MCP, or can I just use a URL? Either. Every recording has a plain-text agent view at https://clipy.online/video/<id>.md — append .md to the watch URL and paste it into any agent. The MCP is for agents that prefer callable tools over pasted text.

Is it a fair comparison? We think so, on the narrow axis of "what does the agent receive." BugHerd's element pinning, automatic environment capture, kanban board and tracker integrations are genuinely strong and, in several cases, things Clipy simply doesn't do. The comparison here is not "which tool is better" — it's "whose MCP hands the agent the recording's structured context versus the ticket's text."

Is Clipy free? Yes. Clipy is a free screen recorder with no watermark and no viewer signup. The MCP is authenticated with a key from your settings and is scoped read-only to your own recordings. Start on the for-agents page or read the MCP docs.