RevenueScope: revenue-first analytics for your EC site
REMOTE · MCP.REVENUESCOPE.JP · SCANNED SEP 20
Ask AI about your EC site's revenue by channel, RPS/AOV/CVR, search & AI traffic, budget split.
Available components
How this component scores in each security and reliability category. Every signal is checked automatically against the live server, and we only credit what we can confirm. How we score → Why this is hard to score →
Endpoint Security94
- The endpoint's TLS certificate is valid, in date, and uses a strong key. View diagnostics → Pass
- Authorisation is enforced on tool calls, advertised via RFC 9728 protected-resource metadata. Discovery is public, which costs nothing: no tool can be invoked without a token. View diagnostics → Pass
- HTTPS is enforced; there's no plaintext access path. View diagnostics → Pass
- The HSTS (Strict-Transport-Security) header is present. View diagnostics → Pass
- DNSSEC check failed: this domain isn't protected by DNSSEC. See how to fix → View diagnostics → Fail
- The authorisation server offers only Dynamic Client Registration (RFC 7591), which MCP 2026-07-28 deprecated in favour of Client ID Metadata Documents. View diagnostics → Partial
Transport & Reachability100
- Verified streamable-http transport via a live MCP handshake. View diagnostics → Pass
Schema Quality & AI Usability55
- AI-judged instruction clarity (good).Pass
- Context-footprint check failed: tool/resource definitions use about 4961 tokens (~496/item across 10 items; 10 tools + 0 resources), over budget; trim descriptions and params. See how to fix → Fail
- Usage-examples check failed: none of the tools include examples. See how to fix → Fail
Stability & Change Management100
- No destabilizing schema changes in the last 30 days.Pass
Tool Coverage71
- 100% of tools have a non-trivial description (not blank, and not just the tool's name).Pass
- 0% of tool parameters carry a description.Fail
- Structured output schemas are declared (100% of tools); any adoption earns full credit.Pass
Tool Safety100
- No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.Pass
- We read all 10 captured tool definition(s), and no name or description among them implies an irreversible operation.Pass
- An AI judge read all 10 captured unit(s) of tool text and found none that tries to manipulate the model reading it.Pass
Capabilities100
- Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28.Pass
How do I install the RevenueScope: revenue-first analytics for your EC site MCP server?
RevenueScope: revenue-first analytics for your EC site is a hosted endpoint at https://mcp.revenuescope.jp/api/mcp, so there is nothing to install locally. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation.
remote · mcp.revenuescope.jp
claude mcp add --transport http toshihiroshishido-revenuescope-mcp 'https://mcp.revenuescope.jp/api/mcp'
{
"mcpServers": {
"toshihiroshishido-revenuescope-mcp": {
"url": "https://mcp.revenuescope.jp/api/mcp"
}
}
} {
"servers": {
"toshihiroshishido-revenuescope-mcp": {
"type": "http",
"url": "https://mcp.revenuescope.jp/api/mcp"
}
}
} [mcp_servers.toshihiroshishido-revenuescope-mcp] url = "https://mcp.revenuescope.jp/api/mcp"
{
"$schema": "https://opencode.ai/config.json",
"mcp": {
"toshihiroshishido-revenuescope-mcp": {
"type": "remote",
"url": "https://mcp.revenuescope.jp/api/mcp",
"enabled": true
}
}
} openclaw mcp add toshihiroshishido-revenuescope-mcp --url 'https://mcp.revenuescope.jp/api/mcp' --transport streamable-http
mcp_servers:
toshihiroshishido-revenuescope-mcp:
url: "https://mcp.revenuescope.jp/api/mcp" {
"McpServers": {
"toshihiroshishido-revenuescope-mcp": {
"Transport": "http",
"Url": "https://mcp.revenuescope.jp/api/mcp"
}
}
} assistant mcp add toshihiroshishido-revenuescope-mcp -t streamable-http -u 'https://mcp.revenuescope.jp/api/mcp'
{
"mcpServers": {
"toshihiroshishido-revenuescope-mcp": {
"type": "http",
"url": "https://mcp.revenuescope.jp/api/mcp"
}
}
} The mcpServers block is a cross-client convention. Remote transports vary, so check your client's docs.
Every change we have recorded for this component, newest first. Security-relevant changes are always shown. ▲ marks a change for the better, ▼ a change for the worse; unmarked changes are neutral.
- 6 Sept 26 0
- Tool “get_breakdown” rewrote its description, which is the text the model reads security
- Schema quality: excellent → good functional
- 5 Sept 26 0
- Tool “get_priority_insights” rewrote its description, which is the text the model reads security
- Tool “get_summary” rewrote its description, which is the text the model reads security
- Schema quality: good → excellent functional
- Server version: 1.12.0 → 1.14.0 functional
- 4 Sept 26 0
- Tool “get_breakdown” rewrote its description, which is the text the model reads security
- 3 Sept 26 0
- Server version: 1.11.0 → 1.12.0 functional
- 2 Sept 26 0
- Tool “get_breakdown” rewrote its description, which is the text the model reads security
- Server version: 1.10.0 → 1.11.0 functional
- “get_breakdown” added an optional parameter “visitor_type” cosmetic
- 1 Sept 26 0
- Tool “get_breakdown” rewrote its description, which is the text the model reads security
- 30 Aug 26 0
- Stability: 0.97 → pass security
- 29 Aug 26 0
- Tool “get_summary” rewrote its description, which is the text the model reads security
- Schema quality: excellent → good functional
- Stability: pass → 0.97 functional
Diagnostic detail from the automated scan of this channel: what the scanner observed at each step, so you can see exactly where a check passed or failed. It is informational only and never changes the trust score.
Captured 20 Sept 2026 · Probed https://mcp.revenuescope.jp/api/mcp
TLS valid
Negotiated TLS 1.3 with TLS_AES_128_GCM_SHA256 .
| Subject | Issuer | Valid from | Valid until | Key | Signature | Serial |
|---|---|---|---|---|---|---|
| CN=mcp.revenuescope.jp | CN=YR1,O=Let's Encrypt,C=US | 18 Jul 2026 | 16 Oct 2026 | RSA 2048 | SHA256-RSA | 54b0d70b68db391f604f77cf2136818afc5 |
| SANs: mcp.revenuescope.jp | ||||||
| CN=YR1,O=Let's Encrypt,C=US (CA) | CN=Root YR,O=ISRG,C=US | 3 Sept 2025 | 2 Sept 2028 | RSA 2048 | SHA256-RSA | a20253f15f2691c05dc1ce13b9bcca4e |
| CN=Root YR,O=ISRG,C=US (CA) | CN=ISRG Root X1,O=Internet Security Research Group,C=US | 13 May 2026 | 2 Sept 2032 | RSA 4096 | SHA256-RSA | f24b6d17f9d9ad7cb1c9fea78782699f |
Background: What to check on a remote MCP endpoint →
DNSSEC insecure
Validation of mcp.revenuescope.jp. — Not signed
| Zone | DS | Keys | Algorithms | Outcome |
|---|---|---|---|---|
| . | trust_anchor | 20326, 38696 | 8, 8 | Verified |
| jp. | present | 33631 | 8 | Verified |
| revenuescope.jp. | absent | Unsigned (proven) parent-signed NSEC/NSEC3 proves an unsigned delegation |
Authentication Enforced and verified
The endpoint asked for a token and published valid RFC 9728 metadata describing how to get one.
| Result | Enforced and verified |
|---|---|
| Enforced | On tool calls |
| HTTP status | 200 |
WWW-Authenticate challenge Bearer realm="https://mcp.revenuescope.jp", resource_metadata="https://mcp.revenuescope.jp/.well-known/oauth-protected-resource"
Bearer realm="https://mcp.revenuescope.jp", resource_metadata="https://mcp.revenuescope.jp/.well-known/oauth-protected-resource" | Header | Value |
|---|---|
| strict-transport-security | max-age=63072000 |
Protected resource metadata
| Document | https://mcp.revenuescope.jp/.well-known/oauth-protected-resource |
|---|---|
| Retrieved | Yes |
| Resource | https://mcp.revenuescope.jp/api/mcp |
| Authorisation server | https://mcp.revenuescope.jp |
Background: How OAuth 2.1 works in the 2026 MCP spec →
Transports 2 probes
| Transport | URL | Outcome | Status | Location |
|---|---|---|---|---|
| streamable-http | https://mcp.revenuescope.jp/api/mcp | Verified | 200 | |
| http (plaintext) | http://mcp.revenuescope.jp/api/mcp | HTTPS enforced | 308 | https://mcp.revenuescope.jp/api/mcp |
The tools this component advertises to a client, with an estimated token cost for each. Expand a tool to see its parameters and schema. The per-tool counts are indicative and are not scored directly; the schema's total context footprint is one signal in Schema Quality & AI Usability. A tool's description is untrusted text the model reads on every call, which is what makes this list a security surface and not just an inventory: how tool poisoning works →
get_ai_traffic AI assistant traffic ~319
Return AI-assistant (ChatGPT/Claude/Perplexity/Gemini/Copilot) traffic for the given period. mode='referred' (default) lists landing pages that received clicked AI traffic — per page × AI source: sessions, bounce rate (%, always computed; judge reliability via the sessions count), summed revenue, and last citation date (last_cited_at is JST ISO8601 with a +09:00 offset — the same basis as the dashboard, so dates line up when compared) (default limit 100); a view GA4/GSC cannot produce (GSC is Google-search only; GA4 lacks an AI-source breakdown). mode='gaps' returns where the site leaves AI value on the table as a ranked action list: (1) missed_citation_pages — content articles with real audience but ~0 AI traffic (push for AI citation / GEO), ranked by engagement-weighted reach; (2) under_monetized_ai_pages — pages WITH AI traffic engaging below the site's own AI norm (improve landing/CTA), ranked by AI arrivals lost below benchmark (default limit 10/list); methodology fixed in code. site_id is OPTIONAL when OAuth-authenticated. Default period is the last 30 days; pass period='today'/'7d'/'90d' or a raw day count (1-365). Scope is clicked citations only.
| Name | Type | Req | Description |
|---|---|---|---|
| limit | integer | – | – |
| mode | string | – | – |
| period | – | – | – |
| site_id | string | – | – |
| Name | Type | Req | Description |
|---|---|---|---|
| ai_sources | array | – | – |
| assumptions | array | – | – |
| basis | string | yes | – |
| criteria | object | – | – |
| limitations | array | – | – |
| missed_citation_pages | array | – | – |
| mode | string | yes | – |
| notes | array | – | – |
| period | object | yes | – |
| rows | array | – | – |
| site_benchmark_engaged_rate | number | – | – |
| site_id | string | yes | – |
| total_ai_sessions | number | – | – |
| under_monetized_ai_pages | array | – | – |
No examples provided.
get_breakdown Revenue breakdown by dimension ~1,021
Consolidated breakdown tool. Pick `dimension`: 'channel' returns per-channel sessions/revenue/RPS plus engagement (visitors, avg dwell seconds, bounce rate) and bot_excluded_count (bot sessions removed from human metrics; a channel with sessions=0 but bot_excluded_count>0 is bot-only traffic, kept so it is not mistaken for 'no traffic') and — when ad spend is connected (Path B) — spend/ROAS/saturation; plus an 'Unattributed' row (is_unattributed=true) for purchase revenue not tied to any channel, with a revenue_breakdown summary (total_event_jpy/attributed_jpy/unattributed_jpy); pass attribution_model ('last_touch' default / 'first_touch' / 'linear' / 'time_decay') to switch how purchase revenue and orders are attributed across channels — same models as the dashboard's attribution selector; revenue_jpy/rps_jpy/orders/aov_jpy/cvr change, while sessions/engagement/bot/spend/ROAS are model-independent [ad-platform rows, is_ad_platform=true, are entirely model-independent, revenue_jpy and rps_jpy included — they are the spend-basis view, so on them revenue_jpy ÷ spend_jpy always equals roas, up to the rounding of roas to 2 decimals; under a non-default model their revenue_jpy/rps_jpy keep the database_statement_time_window boundary shown for roas rather than the reference_timestamp_window that presentation_hints lists for rows[*].revenue_jpy], so compare models to see e.g. how much an awareness channel gains under first_touch vs last_touch. each channel row also carries orders (purchase orders counted by our own tracker), aov_jpy and cvr derived from it — withheld as null below 10 orders, and always null on ad-platform / Unattributed rows; do NOT divide revenue_jpy by `conversions` to rebuild AOV, `conversions` is the ad platform's self-reported count, a different denominator. pass filter.channel to drill into that channel's campaigns (utm_campaign) with RPS/AOV/CVR — the value must be a channel name exactly as this tool returns it, case included (e.g. 'Google Ads', 'M…
| Name | Type | Req | Description |
|---|---|---|---|
| attribution_model | string | – | – |
| country | string | – | – |
| device | string | – | – |
| dimension | string | yes | – |
| filter | object | – | – |
| limit | integer | – | – |
| period | – | – | – |
| site_id | string | – | – |
| visitor_type | string | – | – |
| Name | Type | Req | Description |
|---|---|---|---|
| assumptions | array | – | – |
| attribution_model | string | – | – |
| basis | string | – | – |
| data_freshness | object | yes | – |
| dimension | string | yes | – |
| filter | object | – | – |
| limitations | array | – | – |
| notes | array | – | – |
| path | string | – | – |
| period | object | yes | – |
| period_boundary_definitions | object | yes | – |
| presentation_hints | object | yes | – |
| previous_period | – | – | – |
| revenue_breakdown | object | – | – |
| rows | – | – | – |
| session_attributes | object | – | – |
| site_id | string | yes | – |
| total_pages | number | – | – |
| total_pageviews | number | – | – |
| truncated | – | – | – |
No examples provided.
get_competitor_keywords Competitor keywords (external SEO snapshot) ~429
Return the latest competitor SEO snapshot for the site (FD-041): which keywords each tracked competitor DOMAIN ranks for on Google (Japan/ja), at what position, with monthly search_volume, cpc and etv (estimated monthly traffic — a visit estimate, not a monetary value), plus how each rank moved vs the previous snapshot. READ-ONLY — this tool never runs a research (that costs money and is triggered separately from the dashboard, the competitor-research Edge Function); it only reads what was already fetched. The response is summary-first (token-aware): each domain carries a constant-size `summary` (total_keywords, total_etv, volume_bands and rank_bands histograms, and vs_previous new/lost/improved/declined/same counts) that always reflects the FULL keyword set, while `keywords` returns only the top rows ranked by `sort` (etv default | volume | rank; default limit 10 per domain, max 100) with a `truncated` block (shown/matching_total/lost_total). rank is a POSITION: smaller is better, so a NEGATIVE rank_delta means the competitor's ranking IMPROVED (change ∈ new/improved/declined/same/unknown). Keywords the competitor ranked for before but lost are disclosed in `lost_keywords` (top 10 by previous etv), never dropped silently. Pass `domain` to focus one competitor, `min_volume` to drop low-volume keywords. When the site has NO completed research yet the response is { researched:false } with a `guidance` string explaining a research must be triggered from the dashboard first — this tool cannot start one. site_id is OPTIONAL when OAuth-authenticated. This is the external competitor lens (third-party SERP data); for YOUR OWN search performance use get_keyword_performance, and for your content playbook use get_content_actions.
| Name | Type | Req | Description |
|---|---|---|---|
| domain | string | – | – |
| limit | integer | – | – |
| min_volume | integer | – | – |
| site_id | string | – | – |
| sort | string | – | – |
| Name | Type | Req | Description |
|---|---|---|---|
| assumptions | array | yes | – |
| available_domains | array | – | – |
| basis | string | yes | – |
| domains | array | – | – |
| fetched_at | string | – | – |
| guidance | string | – | – |
| keyword_count | number | – | – |
| language_code | string | – | – |
| limit | number | – | – |
| limitations | array | yes | – |
| location_code | number | – | – |
| min_volume | number|null | – | – |
| research_id | string | – | – |
| researched | boolean | yes | – |
| sort | string | – | – |
No examples provided.
get_content_actions Content actions (classify pages + playbook) ~943
Return a content 'playbook' for the site: every content page classified into ONE of five action buckets over a weekly-style window comparison (current window vs the immediately preceding window of equal length), ranked by search-opportunity × session gain so you can tell the user which page to GROW next and what to do: within the 'striking' bucket rows are ordered by expected_sessions_gain DESC (the band-CTR headroom that is the actionable lever there), while the other buckets keep real landing revenue DESC (largest revenue at stake first). This surfaces search intent to add sessions (grow the traffic denominator), NOT CVR — a page already winning on sessions/revenue but with zero clicks still shows up. Buckets: 'decaying' (search clicks actually fell, OR the page had real traffic (previous clicks ≥3) and its rank slid ≥2 positions from within the click zone while clicks did NOT grow → refresh/rewrite; a rank slide alone with growing/negligible clicks is NOT decay — search clicks are the primary signal, position only a leading indicator), 'striking' (has striking-distance queries at positions 4-20 with click upside but clicks still low → push those queries up; top 3 listed in striking_queries), 'rising' (clicks grew significantly → produce more of this, strengthen CTA), 'dormant' (has impressions but ~0 clicks and its main query is far below the click zone → big rewrite or consolidate; zero-pageview pure-rank pages surface here), 'stable' (none of the above → watch). Each page also carries current/previous clicks·impressions·avg_position, is_new, landing sessions/engaged/revenue_jpy, AI-referred sessions/revenue/sources, expected_sessions_gain (the window's expected incremental sessions from striking-band queries — a search click is ~1 session, so it is NOT re-converted via CTR; normalize to a monthly figure with the window length), and expected_revenue_gain (expected_sessions_gain × page RPS, returned ONLY when revenue>0 and sessions>=5 — display-only projection,…
| Name | Type | Req | Description |
|---|---|---|---|
| bucket | string | – | – |
| limit | integer | – | – |
| period | – | – | – |
| site_id | string | – | – |
| Name | Type | Req | Description |
|---|---|---|---|
| assumptions | array | yes | – |
| basis | string | yes | – |
| bucket_summary | object | yes | – |
| criteria | object | yes | – |
| limitations | array | yes | – |
| pages | array | yes | – |
| period | object | yes | – |
| site_id | string | yes | – |
| total_pages | number | yes | – |
| truncated | object | – | – |
| warning | string | – | – |
| window | object | yes | – |
No examples provided.
get_keyword_performance Search keyword performance ~335
Return search-query performance from Google Search Console for the given period. band='all' (default) returns per-query metrics — clicks/impressions/CTR/avg position/top landing page plus an estimated revenue per query (= 検索 organic RPS × clicks, a conservative estimate, 0 until the site has 検索 organic revenue), ranked by clicks (default limit 100). Each row also carries the period-over-period change vs the previous equal-length window: clicks_change (traffic) and est_revenue_change (money), both % deltas (null = the query is NEW, i.e. had no clicks/revenue last period — render as '新規', not 0%). Comparing the two surfaces RS's signature insight — e.g. clicks +74% but est_revenue −21% means traffic grew while money fell, something GA4/GSC cannot show side by side. band='striking' returns the SEO action list: queries 'striking distance' from the top (ranking ~4-20 with real impressions) where improving a few positions yields the biggest click/revenue gain, ranked by estimated revenue opportunity (incremental clicks × search-organic RPS, default limit 10); the methodology is fixed in code. site_id is OPTIONAL when OAuth-authenticated. Default period is the last 30 days; pass period='today'/'7d'/'90d' or a raw day count (1-365). Google-search only.
| Name | Type | Req | Description |
|---|---|---|---|
| band | string | – | – |
| limit | integer | – | – |
| period | – | – | – |
| site_id | string | – | – |
| Name | Type | Req | Description |
|---|---|---|---|
| assumptions | array | – | – |
| band | string | yes | – |
| basis | string | – | – |
| criteria | object | – | – |
| limitations | array | – | – |
| period | object | yes | – |
| revenue_estimate_basis | string | – | – |
| rows | – | yes | – |
| rps_search_jpy | number | – | – |
| site_id | string | yes | – |
| warning | string | – | – |
No examples provided.
get_page_trend Page search trend over time ~364
Return how ONE page's Google Search performance changed over time (FD-040) — the time-axis drill-down for a page surfaced by get_breakdown(dimension='page'). Given a `page` (a normalized path like '/news/rps-revenue-per-session-guide' or a full URL — both resolve), returns a `series` of day or week buckets, each with clicks, impressions, and impression-weighted avg_position, plus a `summary` (first/last/best/worst position, position_delta, click & impression totals). avg_position is a RANK: smaller is better, so a NEGATIVE position_delta means the page's ranking IMPROVED over the window (e.g. 12.0 → 9.0 = delta −3.0). Use this to verify whether SEO work on a page paid off (rank rose / clicks grew) or slipped. Buckets where the page never appeared in search are omitted (gaps), so the series can be shorter than the period. `granularity` defaults to 'day' for windows up to ~35 days and 'week' for longer (weekly smooths daily noise); pass it to override. site_id is OPTIONAL when OAuth-authenticated. Default period is the last 30 days; pass period='today'/'7d'/'90d' or a raw day count (1-365). Google-search only; data lags 1-2 days. This is per-page; for the cross-page snapshot use get_breakdown(dimension='page'), and for per-query (keyword) trends use get_keyword_performance.
| Name | Type | Req | Description |
|---|---|---|---|
| granularity | string | – | – |
| page | string | yes | – |
| period | – | – | – |
| site_id | string | – | – |
| Name | Type | Req | Description |
|---|---|---|---|
| assumptions | array | yes | – |
| basis | string | yes | – |
| granularity | string | yes | – |
| limitations | array | yes | – |
| page | string | yes | – |
| period | object | yes | – |
| series | array | yes | – |
| site_id | string | yes | – |
| summary | object | yes | – |
| warning | string | – | – |
No examples provided.
get_priority_insights Top priority insights ~263
Return the top 3 prioritized, pre-computed DIAGNOSES for the site over the given period — 'what should I act on this week', ranked by revenue impact. Unlike get_summary / get_breakdown (which return data), this applies a deterministic rule engine over KPI period-over-period changes, per-channel RPS/ROAS/saturation, and AI-assistant referral growth, and returns ranked findings (revenue-trend swings, high-efficiency channels to scale, over-allocated low-efficiency channels, loss-making/saturated ad channels, revenue concentration risk, emerging AI traffic) — each with a severity (risk/opportunity/watch), the numbers, and a recommended action. The priority judgment is fixed in code (not LLM-generated). site_id is OPTIONAL when OAuth-authenticated. Default period is 30 days; pass period='today'/'7d'/'90d' or a raw day count (1-365). period and previous_period describe the KPI engine's current and previous windows; each returned insight carries source_boundaries because channel, ad-spend, and AI signals can use different source windows. Returns fewer than 3 when fewer rules fire (no padding).
| Name | Type | Req | Description |
|---|---|---|---|
| period | – | – | – |
| site_id | string | – | – |
| Name | Type | Req | Description |
|---|---|---|---|
| assumptions | array | yes | – |
| basis | string | yes | – |
| data_freshness | object | yes | – |
| insights | array | yes | – |
| limitations | array | yes | – |
| period | object | yes | – |
| period_boundary_definitions | object | yes | – |
| presentation_hints | object | yes | – |
| previous_period | – | yes | – |
| rules_evaluated | number | yes | – |
| site_id | string | yes | – |
No examples provided.
get_summary Site KPI summary ~761
Return the full headline summary for a site and period in ONE call: the 5 KPIs (revenue, sessions, RPS, AOV, CVR) PLUS two engagement KPIs (avg_duration = average dwell time in seconds, bounce_rate = % single-page-exit sessions) each with value AND the period-over-period change vs the previous equal-length window, PLUS a daily revenue/sessions/conversions trend, PLUS ad-spend availability (connected_channels, ad_spend_data_status, ad_spend_channels_in_period) and the Path A/B recommendation. avg_duration/bounce_rate are useful for sites with no revenue yet (engagement view). scroll_depth is the average scroll depth (%), taken per session as its deepest point then averaged; its change is a percentage-point delta. IMPORTANT: its denominator differs from avg_duration/bounce_rate — depth only covers sessions whose exit beacon landed, and sessions without one are excluded rather than counted as 0. scroll_depth is null when the window holds no depth signal at all (0% would read as 'read shallowly' when the truth is 'not measured'); depth has only been collected since 2026-06-15, so longer windows are partial. Pass optional country (ISO2, e.g. 'JP') and/or device ('mobile'/'desktop'/'tablet') to scope the session-derived KPIs and trend to that segment (omit = all); ROAS stays site-wide (ad spend has no country/device dimension). This is what the dashboard's KPI cards + revenue-trend chart show, merged with the site's ad-spend context. Call this first when a user asks 'how is my site doing?'. site_id is OPTIONAL when OAuth-authenticated (server falls back to the primary site). Default period is the last 30 days; pass period='today'/'7d'/'90d' or a raw day count (1-365). change is a percentage for revenue/sessions/RPS/AOV/avg_duration and an absolute percentage-point delta for CVR and bounce_rate. For period='today' the comparison is today-so-far vs the SAME elapsed window yesterday (e.g. midnight→now vs midnight→same-time-yesterday), so 'previous' can read below yesterday'…
| Name | Type | Req | Description |
|---|---|---|---|
| country | string | – | – |
| device | string | – | – |
| period | – | – | – |
| site_id | string | – | – |
| Name | Type | Req | Description |
|---|---|---|---|
| ad_spend_channels_in_period | array | yes | – |
| ad_spend_data_status | string | yes | – |
| ad_spend_rows_in_period | number | yes | – |
| basis | string | yes | – |
| connected_channels | array | yes | – |
| data_freshness | object | yes | – |
| kpis | object | yes | – |
| path_recommendation | string | yes | – |
| period | object | yes | – |
| period_boundary_definitions | object | yes | – |
| presentation_hints | object | yes | – |
| previous_period | – | yes | – |
| site_id | string | yes | – |
| trend | array | yes | – |
No examples provided.
list_sites List available sites ~164
List the sites this caller can analyze, in two groups. my_sites = the sites connected to the signed-in account (each with its display name + domain, so you can match phrases like "the production site" or "revenuescope.jp" without the user pasting a UUID); empty when the caller is not signed in. demo_sites = ready-made sample sites for trying RevenueScope before connecting your own — each is a fictional site with sample data, not a real customer. When signed in (OAuth), prefer my_sites and, if site_id is omitted, default analytics tools to the is_primary=true site. When NOT signed in, my_sites is empty: use a demo_sites site_id and tell the user the numbers come from a sample site, not their own.
Input schema present but exposes no named parameters.
| Name | Type | Req | Description |
|---|---|---|---|
| demo_sites | array | yes | – |
| my_sites | array | yes | – |
| note | string | yes | – |
No examples provided.
suggest_budget_allocation Suggest budget allocation ~362
Return a proposed monthly budget split across paid ad channels (Google Ads / Meta / TikTok Ads / Yahoo! Ads / LINE Ads etc.). site_id is OPTIONAL when the request is OAuth-authenticated. Path B (ad spend connected — any channel with spend>0 in the period): weight = ROAS × (1 − saturation) where ROAS is RS-measured revenue ÷ spend (FD-030 A-1, same as the dashboard — NOT platform-reported conversion_value). saturation は RS 自身では推定せず、広告データとして供給された場合のみ使用する (推定エンジンは W17+)。値が無いチャネルは ROAS のみで加重し効率投下上限をかけない — limitations に明記する。⚠ 配分候補は広告プラットフォーム単位 (Meta / Google Ads …) で、Instagram と Facebook のようにセッション側の粒度が細かいチャネルは所属プラットフォームへ畳んで扱う (FD-055)。 Path A (no ad spend): RPS-weighted proportional split with explicit ±20-30% caveats and a connect_incentive_message. Default period for the underlying ROAS/RPS data is 30 days; pass period='today' / '7d' / '90d' or a raw day count (1-365) to override. LLMs should pass `assumptions`, `limitations`, and `connect_incentive_message` through verbatim — they are hardcoded honest axis.
| Name | Type | Req | Description |
|---|---|---|---|
| monthly_budget_jpy | number | yes | – |
| period | – | – | – |
| site_id | string | – | – |
| Name | Type | Req | Description |
|---|---|---|---|
| allocation | array | yes | – |
| assumptions | array | yes | – |
| connect_incentive_message | string|null | yes | – |
| expected_roas_current | number|null | yes | – |
| expected_roas_proposed | number|null | yes | – |
| expected_roas_uplift_pct | number|null | yes | – |
| limitations | array | yes | – |
| monthly_budget_jpy | number | yes | – |
| next_action | string | yes | – |
| path | string | yes | – |
| site_id | string | yes | – |
| unallocated_jpy | number | yes | – |
No examples provided.
What is the RevenueScope: revenue-first analytics for your EC site MCP server?
RevenueScope: revenue-first analytics for your EC site is an MCP server listed in the public MCP registry as io.github.toshihiroshishido/revenuescope-mcp. Ask AI about your EC site's revenue by channel, RPS/AOV/CVR, search & AI traffic, budget split. This page covers its hosted endpoint (https://mcp.revenuescope.jp/api/mcp).
Is the RevenueScope: revenue-first analytics for your EC site MCP server safe to use?
RevenueScope: revenue-first analytics for your EC site scores 87 out of 100 on VerifyMCP. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm.
What tools does the RevenueScope: revenue-first analytics for your EC site MCP server expose?
RevenueScope: revenue-first analytics for your EC site exposes 10 tools: list_sites, get_summary, get_breakdown, get_keyword_performance, get_ai_traffic, and 5 more. Their descriptions and schemas cost roughly 4,961 tokens of context every time the server is loaded.
Does the RevenueScope: revenue-first analytics for your EC site MCP server require authentication?
Yes. RevenueScope: revenue-first analytics for your EC site asked us for credentials when we connected, so you will need to authorise it in your MCP client before it can do anything.
Is the RevenueScope: revenue-first analytics for your EC site MCP server still maintained?
RevenueScope: revenue-first analytics for your EC site is still listed as active in the MCP registry. We last reached this channel on 20 September 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.