Review those PRs: how ThinkReview lives in Cursor, Copilot, and Claude Code

Review those PRs: how ThinkReview lives in Cursor, Copilot, and Claude Code

You already ask the agent to write the feature. Ask it to review the pull request the same way.

The new SaaS wave is being built in chat windows. A founder with no production coding background opens Cursor, GitHub Copilot, or Claude Code, describes a billing flow, and watches a branch appear. That is the boom: AI writing tools turned “I have an idea” into “I have a repo.”

The missing habit is the one professional teams never dropped — open a pull request, review it, then merge. ThinkReview is built for that habit. With ThinkReview MCP, the review happens in the same assistant that wrote the code. You can trigger it in three words:

thinkreview those PRs

Why the review has to leave the chat transcript

Agents are optimistic. They summarize what they intended to change. A pull request shows what they did change — including the webhook path they forgot, the catch that only console.errors, and the eligibility check they put on the client.

If you only read the agent’s recap, you are reviewing a story. If you review the PR URL, you are reviewing the product.

That is the whole reason ThinkReview MCP exists. Your assistant calls review_url_code with the live GitHub, GitLab, Azure DevOps, or Bitbucket link. ThinkReview fetches the diff through the git credentials you already stored in the portal and returns the same structured review the browser extension uses: summary, suggestions, security notes, best practices.

Credits and cached reviews match the extension. Custom rules from the portal apply. You are not pasting a patch into chat and hoping the model notices the cancel path.

Three clients, one tool

ThinkReview MCP is a hosted server at https://mcp.thinkreview.dev/v1. You add it once. After that, the same review_url_code tool shows up wherever you work.

OAuth is the recommended path: no long-lived token sitting in a JSON file. Bearer still works if you prefer the portal token. Either way, git integrations in the portal are required — without a PAT, the tool cannot fetch a private diff.

Full copy-paste configs, OAuth notes, and troubleshooting live in MCP Integration.

What three words actually look like

Here is a real Cursor session after two branches were pushed and two pull requests were opened. The prompt was not a spec. It was a sentence: create the PRs, then ThinkReview them.

The assistant discovers the ThinkReview tool, hits the live URLs, and comes back with a review you can prioritize — not a wall of lint.

That is the point for a non-engineer founder. You do not have to know Lemon’s retry semantics. You need a review that says: if cancel fails we still return “repeat trial blocked” with HTTP 200, Lemon will not retry, and the trial can stay live on their side while we never grant the plan. Then you can tell the same agent to patch it.

Keep the merge request. Shorten the ceremony.

The process does not go away because AI wrote the diff:

1. Feature branch, not commits on main
2. Open the PR or MR so there is a URL
3. Review that URL — in the browser extension or with three words in the IDE
4. Merge only after the findings you care about are fixed

ThinkReview shortens step 3. It does not delete steps 1, 2, or 4. Those steps are how a weekend SaaS stops being a demo and starts being something you can charge for.

If you already use ThinkReview on the PR page, MCP is the same engine in the editor. If you have never reviewed a PR because you did not write the code, start here: connect the server, open one merge request, and ask your assistant to ThinkReview it.

Setup: MCP Integration docs · portal.thinkreview.dev/mcp · git integrations. Then say it in three words.