Promptwatch MCP vs REST API: Which One Should Your Team Use?
A practical comparison of the Promptwatch MCP server and the Promptwatch REST API v2 for team use, by auth model, scopes, read-only keys, and the jobs each one is built for.
Promptwatch exposes its data two ways: a hosted MCP server and a REST API v2. Both hit the same underlying data, both take the same Bearer or OAuth key, and both can be scoped to read-only. They are not two products. They are two surfaces for the same product, and the question a team has to answer is which surface fits the job in front of it. This post compares the two by auth, scopes, tool coverage, and the kind of work each one is built for, so a team can pick without re-reading the docs.
The short version: the MCP server is for agents that reason over live visibility data inside a conversation. The REST API is for pipelines, dashboards, and scheduled jobs that move data into your own warehouse or tooling. Most teams that take Promptwatch seriously end up using both, and the choice per job is which one of those two shapes the job takes.
The two surfaces
The MCP server is a hosted streamable HTTP server at https://server.promptwatch.com/mcp, with OAuth or Bearer key auth. It backs the ChatGPT plugin and the Claude connector, and Cursor connects through .cursor/mcp.json. Read-only keys hide the write tools, so an analyst agent sees only the read surface and cannot create, publish, or update anything.
The REST API v2 is the documented HTTP endpoint for the same data. It is what you call from a script, a scheduled job, a Looker Studio blend, a Slack bot, or a custom dashboard. The fact sheet lists REST API v2 among the integrations, alongside Google Search Console, Looker Studio, DataForSEO, Firecrawl, Slack, the Claude Connector, the ChatGPT plugin, and the MCP server itself.
The two share an auth model and a data model. They differ in how you call them and what you get back. The MCP server returns tool responses a model can read and act on. The REST API returns JSON a script can parse and store.
Auth, keys, and scopes
Both surfaces take the same key. The decision that matters for team use is the scope you put on the key, not the surface you call.
A read-only key is the right default for most team members and most agents. On the MCP server, a read-only key hides the write tools, so createContent, listContentSlots, acceptContentSlot, publishContentLive, createReport, createActionItem, updateActionItemStatus, createPrompt, createPromptsBulk, and addShoppingTrackedProducts do not appear in the tool list the server advertises. The agent cannot call what it cannot see. On the REST API, a read-only key refuses writes at the endpoint, so the same call returns an authorization error instead of a result.
The practical split is this. Give a read-only key to an analyst agent that should report on visibility, citations, and crawler logs. Give a write key only to an agent or a person that should publish content, create prompts, or update the action board. The MCP server makes this easy because the write tools disappear from the tool list under a read-only key, which removes the failure mode where an agent invents a write call it should not make. The REST API makes this easy because the scope is enforced server-side, so a script with a read-only key cannot write even if it tries.
What the MCP server exposes
The read surface is the part most teams use first. listPrompts and getPrompt read the prompt ledger. getVisibilityTimeSeries reads how visibility moved over time. getCitations and getCitationTopPages break citations to the page. listRedditCitations and listYoutubeCitations cover the social citation surfaces. getCompetitorHeatmap reads the competitor view. listContentGapPrompts and getContentGapRecommendations read the gap to close, and getContentGapStats reads the gap at site level. listQueryFanouts exposes the fan-out. getCrawlerTrend and getTopCrawlerPages expose the crawler-log layer. getVisitorTrend, getVisitorTopPages, and getVisitorTopSources expose the visitor layer. getResponseSentimentTimeSeries covers sentiment. listAds and listAdPrompts cover the Ads Radar surface. listShoppingItems covers the shopping surface. getSiteHealth reads site health, and listActionItems reads the AI-generated to-do list.
The write surface is where the loop closes. createContent, listContentSlots, acceptContentSlot, and publishContentLive draft, accept, and publish a GEO article to a connected CMS. createReport produces a report. createActionItem and updateActionItemStatus manage the action board. createPrompt and createPromptsBulk extend the tracking set, and addShoppingTrackedProducts extends the shopping set.
The reason to use the MCP server over the REST API is that the model picks the next tool call from the conversation. An analyst asks "did the rewrite move the citation," and the agent calls getCrawlerTrend to check the crawl, getVisibilityTimeSeries to check the visibility, and getCitationTopPages to check the page, in one turn, without the analyst naming the endpoints. The REST API can do the same work, but the human has to write the join.
What the REST API is for
The REST API is the right surface when the job is not a conversation. A scheduled job that pulls visibility into a warehouse every night is a REST call, not an MCP call. A Looker Studio blend that joins Promptwatch data to Search Console and GA4 is a REST call. A Slack bot that posts a daily digest of new citations is a REST call. A custom dashboard embedded in an internal tool is a REST call.
The REST API is also the right surface when you want to move data out of Promptwatch and into something you own. The MCP server is a live read; it answers the question you ask now. The REST API is a copy; it lets you store the answer and ask a different question of it later, in your own database, with your own joins. A team that needs a year of visibility history joined to revenue data is not going to re-ask the MCP server for every point. It is going to pull the series once over REST and store it.
The fact sheet lists the integrations that lean on the REST surface: Google Search Console, Looker Studio, DataForSEO, Firecrawl, Slack, and the Claude Connector. The MCP server is on the same list, which is the point. The two surfaces are peers, not substitutes.
When to use which
Use the MCP server when the work is exploratory and the next call depends on the last response. An analyst in Cursor or Claude asking "why did visibility drop on this prompt last week" is an MCP job. The agent reads the prompt, reads the visibility series, reads the crawler trend, reads the top pages, and reports back, and the analyst follows up in the same thread. The MCP server is built for that loop.
Use the REST API when the work is scheduled, repeated, or stored. A nightly ETL that pulls getVisibilityTimeSeries and getCitations into BigQuery is a REST job. A weekly report that joins Promptwatch citations to Search Console clicks in Looker Studio is a REST job. A Slack command that returns the latest action items is a REST job. The REST API is built for that loop.
Use both when the team has an analyst and a pipeline. The analyst works in the MCP surface and asks questions. The pipeline works in the REST surface and stores the answers. The two share a key, and the scope on the key decides what each one can do.
A note on read-only keys for teams
The cleanest pattern for a team is one write key and several read-only keys. The write key lives with the person or agent that publishes content and updates the action board. The read-only keys live with everyone else, including the analyst agents. This is the pattern the MCP server makes natural, because a read-only key changes the tool list the server advertises, so an agent on a read-only key cannot even see the write tools. The REST API enforces the same scope server-side, so a script on a read-only key cannot write.
The named feature that makes the MCP surface worth the switch for an analyst team is the crawler-log layer exposed through getCrawlerTrend and getTopCrawlerPages. That is the layer that answers "did the crawler read the page that became the citation," and it is the layer the REST API also exposes but that an analyst agent on MCP can call without naming the endpoint. If your team's work is asking that question in a conversation, Promptwatch over MCP is the surface to use. If your team's work is storing the answer, the REST API is the surface to use. Most teams do both.