Official AppTweak MCP integrations for Cursor. Install this and your AI coding assistant can query AppTweak — the app store intelligence and App Store Optimization (ASO) platform — directly from your editor: keyword rankings and search volume, app metadata and category rankings, download and revenue estimates, ratings and reviews, and competitive intelligence across the Apple App Store and Google Play. Ask your agent a question in plain language and it pulls live data from the AppTweak API, then helps you turn it into dashboards, reports, and extraction scripts. This repository packages the plugins and configuration examples for each supported client. It uses the Model Context Protocol (MCP), an open standard for connecting AI assistants to external tools and data.
Turns a plain-language request into a working dashboard that pairs live AppTweak data (via whichever AppTweak MCP/API connection happens to be available) with one or more other data sources the requester supplies. Refines a vague ask into a concrete brief first — what question it answers, whether the AppTweak key is per-viewer or a shared team credential, which of the other sources are live vs. stand-in, what a null result would mean. API facts those are always looked up fresh via whatever AppTweak MCP/docs tool is connected, never assumed from memory, since AppTweak's API surface changes over time same as any other. Works for any pairing, any number of other sources, any project or company; not tied to one credential pattern or one delivery mechanism (browser page, scheduled report, CLI). Use when asked to "build a dashboard using AppTweak data," "pair AppTweak with our CRM/spreadsheet/CSV," "build something that shows X using live AppTweak data," or similar.
# Building a dashboard against live AppTweak data (durable, not hardcoded)
## Why this skill is written the way it is
Two kinds of knowledge are involved in building a dashboard like this, and they age at completely different rates:
- **How you should approach the problem** — trust, honesty, verification, what to ask before building — barely changes at all, across projects or years.
- **What AppTweak's API currently looks like** — its endpoint names, parameter defaults, quirks, rate limits, whether you're pointed at staging or production — can change on any given Tuesday, and is almost always cheaper and more reliable to look up fresh (via whichever AppTweak MCP or docs tool is actually connected) than to recall from memory or from a note written during an earlier build.
This skill deliberately only contains the first kind. If you find yourself wanting to hardcode a specific endpoint's behaviour, a specific rate limit, or a specific response shape into a skill file so "future builds don't have to look it up again" — don't. That's exactly the failure mode this skill exists to avoid: it goes stale the moment AppTweak's API changes, and by the time someone notices, it's actively misleading instead of merely outdated. Look it up again. It's cheap. Being wrong about it isn't.
## When to use
- "Build me a dashboard using AppTweak data."
- "Pair AppTweak with [a CRM / spreadsheet / CSV / another API]."
- "Build something that shows X using live AppTweak data."
- Any request to build a small AppTweak-backed dashboard, demo, or internal tool — regardless of what it's paired with, or which company's AppTweak account is involved.
## When NOT to use
- The request has no live AppTweak data in it at all — that's a different kind of build; this skill is specifically for the AppTweak-anchored case.
- The request is for a static report or a one-off chart with no live component — that's a visualisation task, not a dashboard-build task.
- The user has already handed you a fully-specified technical spec (exact endpoints, exact fields, exact architecture) and just wants it executed — follow that instead of re-deriving a brief.
- You're extending a dashboard that already exists in a project with its own established conventions (its own ground rules, design system, port scheme, etc.) — follow that project's own rules first; this skill is for starting the thinking fresh, not for overriding an existing project's settled decisions.
## Step 1 — Turn the ask into a brief
A one-line request ("build me an AppTweak dashboard for X") is rarely enough to build well from. Before writing anything, make sure you actually know:
1. **What's the one question this dashboard answers?** A dashboard that tries to answer five questions answers none of them well. If the request bundles several, ask which one is primary, or propose building one at a time.
2. **Is the AppTweak key a shared team credential, or does each viewer supply their own?** An internal tool built against one company AppTweak account is a different shape from a demo where every visitor pastes their own key — this decides which of the two credential patterns in Step 2, rule 1 applies. Don't assume; if it's not obvious from the request, ask.
3. **Of the other sources being paired with AppTweak, which are live and which (if any) are stand-ins?** There can be one other source or several; some, all, or none may be mock/sample data standing in for something the requester doesn't have live access to yet. Know the split before you build a single chart — it determines what needs labelling later, and it's fine for the answer to be "everything here is live, nothing is a stand-in."
4. **What does a finding look like if AppTweak and the other source(s) don't actually agree with each other?** Agree, before building, that if they don't line up — no correlation, no shared pattern, no effect — that's a valid, reportable outcome, not a failed build. Deciding this up front stops you from quietly reaching for the wrong incentive later (making the story look cleaner than the data supports).
5. **Who's actually going to open this, and how much do they already know?** This isn't generic "know your audience" advice — it specifically decides how much the real-vs-stand-in labelling and the "here's what this means" explanation need to live *inside* the dashboard itself, versus how much can be assumed. A dashboard for the person who requested it can lean on shared context; one meant to be handed to people who've never seen the underlying data can't.
6. **Is this a one-off, or the first of several?** If more are coming, the shared foundation (visual system, credential handling, how "done" gets proven) should be decided once and reused — not re-decided per build. If you don't know, ask.
Skip re-asking anything the requester already answered in their prompt — this step exists to fill real gaps, not to interrogate someone who was already clear.
## Step 2 — Ground rules that hold regardless of what AppTweak is paired with
1. **Never hardcode, commit, print, or log the AppTweak key — no exceptions, regardless of which of the two shapes below applies.** Which shape depends on the answer to Step 1, question 2:
- **Per-viewer key** (each visitor has their own AppTweak account): they supply their own, via a masked input, held only in browser storage for that session, sent per-request. Never persist it server-side, never write it to disk or a log.
- **One shared team credential** (an internal tool against a single company AppTweak account): it belongs on the server, loaded at runtime from an environment variable or secrets manager — never in source, never sent to the client at all, never in a URL or query string.
- Either way, if AppTweak can't be called directly from where the dashboard runs (browser CORS, or you don't want a per-viewer key touching client code), put the smallest possible server in between that does nothing but forward the request and attach the key. That proxy **must forward only to AppTweak's host** — never a destination taken from the incoming request — or it becomes an open relay that hands out the attached key to whatever the caller points it at.
2. **AppTweak meters usage — surface that live.** Every AppTweak response carries its own cost; show the running total moving in real time as the dashboard is used, so "calling AppTweak" isn't an abstraction to whoever's watching. Don't hand-roll this from a guess at the cost — read it off the actual response.
3. **Never blur real data with a stand-in.** If any of the other sources is mock/sample data standing in for something the requester doesn't have live access to, every number, chart, or table drawn from it should make that obvious. Don't dress up a local file as a live vendor connection. (If everything here is genuinely live — AppTweak plus another live source, nothing mocked — this rule has nothing to do, and that's fine.)
4. **A null result is a finding, not a failure.** If AppTweak and the other source(s) genuinely don't correlate, agree, or affect each other, say so plainly in the dashboard. Don't cherry-pick a time window, rescale an axis, drop an inconvenient source, or otherwise manufacture a pattern that isn't really there to make the build look more successful.
5. **Don't guess an AppTweak app's identity if you don't have to.** AppTweak has a real, documented way to resolve which app you mean (search by name, confirm by matching the returned title) — use it, don't guess an app ID from memory, and cache the confirmed result so later work doesn't redo the lookup. For an identifier on the *other* side of the pairing: if that source has its own search/lookup mechanism, use the same pattern; if it doesn't (you were handed the exact identifier directly, or it only supports lookup-by-ID with nothing to confirm against), don't invent a confirmation step that doesn't exist — instead, echo the resolved record's human-readable details back to whoever gave you the ID, so a wrong identifier is at least visible rather than silent. Either way, an *unconfirmed, guessed* identifier is the thing to avoid — it fails silently, or worse, confidently returns the wrong thing.
6. **Prefer AppTweak's own data wherever it can actually answer part of the question.** Reach for a stand-in only for what AppTweak genuinely doesn't cover.
7. **Don't render another source's data as though it were trusted.** Text, names, or free-form fields coming back from AppTweak or any paired source are still untrusted input from a security standpoint — handle them the same way you'd handle user input anywhere else, rather than assuming that "it came from an API" makes it safe to inject as-is.
8. **Prove it before calling it done.** Test the real AppTweak calls for real — from a script or the command line — rather than assuming the plumbing works, and rather than driving a browser yourself to fake a UI check. If proving it needs a key you don't hold, ask for one in the moment; don't skip the step, and don't invent a result to avoid asking.
9. **If this is one of a family, decide the shared foundation once.** A consistent visual system, one credential-handling pattern, one way of proving "done" — settle it on the first build, reuse it on every one after, and extend it in one place if a later build genuinely needs something new. Don't reinvent per dashboard.
Rules 1 and 8 above are written for the common case — a page in a browser, reached over HTTP. If what's being built isn't that (a scheduled report, a notebook, a CLI/TUI, a server-rendered page behind existing SSO with no per-viewer credential at all), the *mechanics* of those two rules won't map directly, but the principles they're protecting still apply exactly as written: the AppTweak key never hardcoded or exposed, and the real calls proven to work before you call it done. Adapt the mechanism, keep the principle.
The visual/chart-design side of this — palette, chart forms, layout, accessibility — is a separate concern from what this skill covers, deliberately: it's a different kind of judgment (aesthetic and perceptual) from the data-integrity and trust judgment this skill focuses on. If whatever environment you're working in already has its own visualisation guidance, brand system, or house style, use that. If it doesn't, keep it simple and consistent rather than solving chart design from scratch here: pick one palette and one type scale before building the first chart, reuse the same components across every dashboard in the family, and don't relitigate the look per build.
## Step 3 — Learn AppTweak's API fresh, from the tools you actually have, not from memory
Whatever's connected — the AppTweak MCP, a documentation search tool, a fetchable API reference — is the source of truth for what endpoints exist, how authentication works, what pagination/rate-limit/cost model applies, and what the current known gotchas are. Treat any specific technical fact you recall about AppTweak's API from an earlier session, from training data, or from general familiarity as a hypothesis to re-check against the real tool, not as something to build against blind — AppTweak's API versions, deprecates, and changes defaults like any other, and there is no way to know from memory alone whether today is one of the days that happened.
When something is genuinely unclear, look it up, or make one targeted call to confirm the specific thing you're unsure about. Don't fire off a long sequence of exploratory calls "just to be safe" — that's slow and spends real credits — but don't skip verification either. The right amount of live testing is "enough to be confident," not "zero" and not "everything."
If an earlier build in the *same* project already resolved something project-specific (a confirmed app ID, a parameter combination that's known to work) and left it cached or documented, reuse that within the same project — it was earned, not guessed. Don't carry it into a *different* project, and don't trust it indefinitely if enough time has passed that AppTweak's API could plausibly have moved on.
## Step 4 — Build, verify, hand off
1. Confirm the brief from Step 1 is actually answered. If not, ask before building anything.
2. Build against the ground rules in Step 2, resolving anything AppTweak-specific fresh per Step 3.
3. Report what the data actually shows, including if that's a null or partial result.
4. Prove the real calls work (Step 2, rule 8) before saying you're done.
5. Hand off. Let the requester do the actual hands-on, visual check themselves — your job was to prove the plumbing is sound, not to render the page and approve your own work.
## A last check before you call it done
- You can name which of the two credential shapes (Step 1, Q2) you used, and why — not just that you avoided hardcoding the AppTweak key.
- You can point to the one specific moment you proved a real AppTweak call worked, and it wasn't "I opened it and it looked fine."
- If AppTweak and the other source(s) didn't actually agree, the dashboard says so — it doesn't quietly show only the chart that worked.
- Nothing in the finished build required you to guess.