If your app deploys to Vercel, every preview already has a comment toolbar, and Vercel's MCP server and CLI let an agent list, reply to and resolve those threads. For a team that works that way, it is built in and hard to beat. The difference is who can comment, and what you are reviewing.
Checked against Vercel's comments docs and MCP tool list in October 2026.
Side by side
| Onlay | Vercel preview comments | |
|---|---|---|
| What you can review | A single HTML or Markdown file, a folder or built app (Pro), or any app you deploy anywhere with one script tag (Pro) | Deployments on Vercel |
| Readers need an account to comment | No, unless you restrict it; app review links ask for a name once | A Vercel account; the Hobby plan allows one external collaborator at a time |
| Readers edit the text in place | Yes, on documents, when you allow it | No |
| What comes back to the agent | Edits, comment threads with quotes, the page, and with the build plugin the file and line that drew the element | Threads with page, excerpt and replies, through Vercel's MCP server or vercel comments --json |
| Ties into pull requests | No | Yes: a check flags unresolved comments on the pull request |
Choose Vercel comments when
- The app already deploys from Git on Vercel and the reviewers are on your Vercel team.
- You want comments tied to pull requests and branches.
Choose Onlay when
- Reviewers are clients or colleagues without a Vercel account.
- What you are reviewing is a document, a deck or a mockup, not a deployment.
- The app is hosted somewhere other than Vercel.
- You want the agent told which source file and line drew each commented element.