Field comparison · AI brand-visibility tooling
We pulled the same AI brand-visibility metrics from Rankscale two ways - through its MCP server and through the raw REST API - and compared them on three points: what each one can do, whether they agree, and how many tokens each one costs. Token cost is the factor that decides which to use at scale.
Key findings
Both tools read the same data and return the same answers. The choice comes down to token cost - and which one is cheaper flips depending on how much data the task pulls in.
For a single narrow metric, the MCP is leaner: about 40k tokens against 56k. For a broad pull across many topics and competitors, the REST API costs roughly half: about 65k tokens against 128k. Neither one wins everywhere. The break-even point is the amount of data the task loads into context.
Where the scopes match, both tools return identical visibility values and identical brand ranks. They diverged only in the deep long tail, and only because the competitor pool was truncated - not because either tool was wrong.
Only the API can write (manage terms, spend credits, run prompts), read raw AI answer text, and query arbitrary date windows. Only the MCP exposes shopping data, per-term sources, and saved dashboard views as direct reads.
Custom metrics, calculations, and visualizations the web interface can't produce - Brand Rank is one example - work through either tool. The one thing reserved to the API is automation: scheduled or unattended runs need its write access.
The MCP connector and the REST key authenticate separately. In our tests they resolved to different workspaces: a key that sees one brand can be blind to another. Before you trust an empty result, check which account each one is bound to.
Background
Rankscale tracks how brands appear inside AI assistants. It feeds tracked prompts to ChatGPT, Gemini, Claude, Perplexity and others, then scores how often, where, and how favourably each brand is mentioned. Analysts pull that data out for reporting in one of two ways.
A set of read-only tools an AI agent can call directly. Responses are pre-digested, capped, and safety-wrapped. Tool schemas load on demand, so the ramp-up cost is tiny - but every response lands straight in the model's context.
Raw HTTP endpoints called with curl. Full read and write. Responses are large and monolithic, but the agent writes them to disk and extracts only what it needs - keeping bulk payloads out of context at the cost of a heavier instruction set to learn first.
In practice: the MCP is the tool an assistant reaches for to answer a quick question mid-conversation. The API is what you build a dashboard or a bulk export on. The rest of this page shows where each one pays off.
Detailed breakdown · 01
Both cover the core reporting metrics - visibility, sentiment, citations, competitor comparison, and filtering by topic, engine, or query. The differences are at the edges, and the edges are where the choice is made for you.
| Capability | MCP | REST API |
|---|---|---|
| Core metrics + time series (visibility, sentiment, citations, position, detection) | ✓ | ✓ |
| Competitor leaderboard + per-competitor series | ✓ | ✓ |
| Filters: topic / tag / engine / query | ✓ | ✓ |
| Arbitrary custom date ranges (ISO start/end) | preset only | ✓ |
| Raw AI answer text (“what did the model actually say”) | - | ✓ |
| Shopping analytics (products, providers, buybox, price) | ✓ | - |
| Per-term source-domain visibility (which sites the AI pulls from) | ✓ | - |
| Saved custom dashboard views | ✓ | - |
| Execution listing with time bounds + cursor pagination | ✓ | partial |
| Credits & runway balance | - | ✓ |
| Create / update / delete brands, topics, search terms | - | ✓ |
| Activate / deactivate / run a search term (spends credits) | - | ✓ |
since/until) + built-in paginationDetailed breakdown · 02
Token usage is driven by two costs that pull in opposite directions: a fixed ramp cost to make the tool usable, and a variable payload cost for the data itself.
The MCP's ramp is small - a single tool schema (about 2.75k characters) loads on demand. But its responses land directly in context: every capped, safety-wrapped payload is tokens the model has to read. The REST API is the reverse. Its ramp is heavy - the agent has to read about 24k characters of endpoint and quirk documentation before the first call - but a disciplined agent writes raw responses to disk and pulls only the extracted values into context. Bulk data then costs almost nothing.
So the arithmetic is simple. When the payload is small, the API's documentation cost dominates and the MCP is cheaper. When the payload is large, the API's file-first pattern keeps hundreds of kilobytes out of context while the MCP has to stream all of it in - and the API is cheaper, often by a wide margin.
Subagent tokens per task (thousands)
Reach for the MCP for narrow, interactive, read-only questions. Reach for the REST API for bulk pulls, full-history exports, raw-text analysis, or anything that writes. The break-even is roughly the point where a task's data payload would exceed the API's ~24k-character documentation ramp - a threshold a single multi-section report clears easily.
The task. Pull the visibility metric for De'Longhi (US) over the last 90 days, aggregated weekly, and chart it. A deliberately narrow request - the kind an analyst asks mid-conversation.
What happened. The MCP answered in a single call. The API answered too - but ~24k of its ~25k context characters were the documentation it had to read first. For five weekly data points, that ramp never pays for itself: the MCP came in ~29% cheaper.
Where they differed on capability. The MCP has no custom date range - only fixed presets - so its “90 days” was really the 3m preset. The API honoured an exact ISO window (and correctly handled the exclusive end-date quirk). Both agreed on the values wherever the windows lined up; the divergence was purely the API's finer window control.
Identity: the first API attempt failed outright - its key resolved to a different workspace that could not see the brand. The MCP could. Same brand name, different account.
Data reality: the requested 90 days cannot be filled by either tool - tracking only began in late May, leaving a real gap of about 41 days at the front. Neither tool can invent history that was never recorded.
The task. For all seven of De'Longhi's topics, pull the Visibility Index and compute Brand Rank - our own metric: position among all detected brands by visibility - over 30 days, daily - then deliver an aggregated table and a rank-over-time chart. A realistic reporting job, using the 30d preset that both tools support identically, for a fair comparison.
What happened. Seven rich competitor payloads. The MCP streamed all of them into context (~65k characters of data alone) and spent ~128k tokens. The API wrote ~325 KB of raw report JSON to disk and pulled only ~8k characters of extracted values through - finishing on ~65k tokens, roughly half. The doc ramp that sank the API in Case study 1 was dwarfed by the data it kept out of context here. The one place the MCP led: fewer network round-trips (it fired all seven topic calls in parallel).
| Topic | Brand Rank | Visibility Index |
|---|---|---|
| automatic coffee machines | 1 | 91.1 |
| best automatic latte machine for home | 1 | 87.4 |
| best automatic coffee machines with grinder | 1 | 84.6 |
| bean to cup coffee machines | 1 | 82.7 |
| best espresso machine under 500 | 3 | 42.8 |
| manual espresso machines | 22 | 3.9 |
| best drip coffee maker | 22-23 | 1.7 |
Brand Rank over time by topic · 30d daily (rank 1 = best)
Rank is yours to compute, by design. Brand Rank is our own metric, not a field either tool returns; you calculate it from visibility. The one field to be careful with is the MCP's own_brand_rank, which returns 1 for every topic - it pins the own brand to the top of the leaderboard for display. Trust that field blindly and you would report De'Longhi as #1 in all seven topics; it is actually #1 in only four.
Aggregate rank ≠ daily rank. A topic can be aggregate rank 1 yet daily rank 2 on most days, because the aggregate is period-weighted share-of-voice, not an average of daily positions.
Truncation & pool size. The MCP caps competitor leaderboards at the top 25; the true pools run 44-84 brands. This is what caused the only real disagreement - a one-position difference in the low-visibility long tail.
Practical guidance
They complement each other; they are not rivals. A typical workflow uses the MCP for exploration and quick reads, and the API for scheduled exports, bulk analysis, and any change to the workspace. The worked examples page shows the API side of that workflow end to end.
Methodology & caveats
Each task was run by a pair of AI sub-agents with the same model and settings, differing only in the tool they were allowed to use. Token counts, tool calls, and context volume are the harness's own accounting; context-character figures are the agents' self-reported numbers and are approximate.
Limits worth stating plainly: this is one brand with sporadic tracking under three months long, not a broad benchmark. The absolute token numbers reflect this agent harness and would shift under a different one; the direction of the crossover is the durable finding, not the exact figures. The REST API's token advantage on bulk pulls depends on the agent actually following the file-first discipline - a naive integration that reads full payloads into context would lose it. And both tools were tested as implemented today; capability gaps (for example, the API skill not exposing shopping data) reflect current coverage, not permanent limits.