ChiliASO MCP server documentation

Before you connect

You need two things:

1. A ChiliASO account. Sign up at chiliaso.lovemobile.com/users/sign_up. Registration is self-service and no separate plan or activation is required for the connector.
2. An MCP-capable client. Any assistant or agent that supports the Model Context Protocol and remote servers over HTTPS — Claude among them. The server is not tied to a specific client.

You do not need an API key. Access is granted through OAuth when you connect.

You do not need to add your apps first. Apps and search terms enter your account through the connector itself, as a side effect of the questions you ask — see What the connector writes.

Connecting the server

In any MCP client

1. Open the place where your client adds servers. In its settings, look for MCP, Connectors, Integrations, Tools or Apps.
2. Add the ChiliASO by Lovemobile server. Paste the URL https://chiliaso.lovemobile.com/.
3. Sign in to ChiliASO. A browser window opens. Log in and confirm access.
4. Return to the chat and ask. The tools become available to the assistant immediately.

Authentication

The server uses OAuth 2.0 with PKCE (S256). You authorise access on a ChiliASO by Lovemobile page, so your password is never passed to the assistant. The client receives an access token and a refresh token and uses them to call the server on your behalf.

To disconnect, remove the server in your client. The tokens it holds stop being used, and the assistant can no longer call the server for you. Data already shown in past conversations stays with your assistant's provider under that provider's terms.

Technical details

Store coverage

The server supports four stores. They are referred to by store_type in every tool:

The four are not equivalent. Each supports a different subset of the data:

Where a cell says “not collected”, the tool returns an empty result for that store. That empty result describes the store's coverage, not the app.

Stores are combined with countries, given as ISO 3166-1 alpha-2 codes in lowercase: ca, us, gb, de. Uppercase codes are rejected. The same app can rank differently in different countries, and each app × store × country combination is handled separately.

Apps are identified by store_id: a numeric string on the App Store (284882215), the package name on Google Play and RuStore (com.spotify.music), and a C-prefixed code on AppGallery.

Tool reference

The server exposes seven tools. Every tool requires country, and every tool except search_apps requires a store: pass store_type. (platform is accepted as a deprecated alias for store_type and will be removed — use store_type in new integrations.)

Dates are YYYY-MM-DD calendar dates in the server's time zone, UTC+03:00.

search_apps

Finds apps already present in your account, by name or bundle ID.

Returns: total_records, total_apps_count, next_offset (absent on the last page) and apps[], each carrying app_id, store_id, bundle_id, name, category, country and store_type.

Results come 10 per page. Pagination counts records, where one record is one app × store × country — an app tracked in three countries is three records, one app.

Use store_id when passing an app to another tool. app_id is internal and no other tool accepts it.

This tool searches your account, not the store. To look up an app you have never asked about, call get_app with its store_id.

get_app

Returns store metadata for one app.

Returns: store_id, bundle_id, name, developer_name, category, description, rating_value, rating_count, app_url, store_icon_url, size, price, currency, in_store, country, store_type and data_collected_at.

Notes

• This call registers the app. If the app is not yet in your account, it is added and its metadata returned in the same response. This applies to any app, including ones that are not yours.
• in_store: false means the app has been removed from the store or banned. Such an app will have no fresh positions, reviews or rating data.
• size is the download size in bytes. It is not collected on Google Play, where the field is always 0.
• price and currency are the app's own store price; price: 0 means free.
• data_collected_at is when the metadata — title, description, developer, category, icon — was last collected. rating_value and rating_count refresh on their own schedule, so a data_collected_at older than the rating is normal.
• description is the full store description and can run to several kilobytes.

list_keywords

Returns the search terms tracked for one app in one country and store.

Returns: keywords[], each with id, name, country, store_type, frequency, popularity, historic_frequency and historic_popularity.

Notes

• This call adds search terms to tracking. Terms that were not being tracked at the time of the request are added by the call itself, so the response reflects the set after that addition.
• frequency and popularity are the latest available snapshot, not an average over a period. See Metrics and scales for the historic_* fields.
• An empty keywords[] means either that nothing is tracked for this app, or that the app is not listed on this store at all.

get_positions

Returns search positions and volume over a date range.

Returns: positions[], one row per term per date, each with name, parsed_at (the date), frequency, popularity and positions — a map of store_id to position. Terms that have no position data yet come back separately in added_keywords.

Notes

• This call registers search terms. When store_id is given, requested terms that are not yet tracked are added automatically, and the app is added too if it is not in the account. Newly added terms come back in added_keywords; their position data becomes available within a few minutes.
• A first call on a term that has just been linked to the app can return an empty positions even though history exists. Repeat the call.
• The positions map contains store IDs only, with no names. Your own app appears in the same map alongside the others. Resolving the other IDs through get_app will add those apps to your account.
• top above 25 is clamped to 25, and the response does not say so.
• Rows do not carry store_type. When results from several stores are in play, track which call each set came from.

fetch_suggestions

Returns the store's own autocomplete suggestions for one seed term.

Returns: suggestions[] — the terms the store proposes around the seed.

Notes

• Suggestions are collected for the App Store and Google Play only. On AppGallery and RuStore the call returns an empty list because there is nothing to collect.
• An empty list on iOS or Android means the store returned nothing for this seed.
• This tool does not add anything to tracking. To start tracking a suggested term, pass it to get_positions or list_keywords.

get_app_rating_history

Returns daily rating snapshots over a date range.

Returns: one row per date with date, rating (rounded to hundredths) and rating_by_stars.

rating_by_stars is the store's own counter of how many ratings sit at each star value, snapshotted daily. It is a running total, not the count for that day: the difference between two dates is what came in between them.

list_reviews

Returns the most recent user reviews for one app.

Returns: reviews[], each with id, rating, title, text, author_name, country, language, first_known_published_at, actual_published_at, external_deleted_at and developer_response (an object with text, external_id and external_updated_at, or null).

Notes

• Reviews are not collected on AppGallery. On the other three stores an empty list means review collection is not connected for this app.
• external_deleted_at is set when the review has been deleted in the store. Deleted reviews stay in the response on purpose: that a review existed and was then removed is information in itself.
• first_known_published_at and actual_published_at are usually identical. They diverge when a review has been edited — the store then reports the edit date as the publication date, and that is what actual_published_at carries, while first_known_published_at keeps the date the review was first seen. A gap between them means the review was edited after publication.
• The tool returns the most recent reviews. It is not a full export of an app's review history.

What the connector writes

The connector does not change anything in the stores, does not act on your behalf outside ChiliASO, and never deletes anything. It does add records to your own ChiliASO account, and three tools do so:

This is how data collection starts: an app or a term has to be registered before ChiliASO can collect data for it and return it to you. Registration is what makes the next question about that app answerable.

Two consequences worth knowing:

• Asking about a competitor's app adds that app to your account. So does resolving the store IDs that get_positions returns for the apps ranking around yours.
• Nothing in the connector removes an app or a term once added. To remove them, contact support.

search_apps, fetch_suggestions, get_app_rating_history and list_reviews only read.

Metrics and scales

Positions

The rank of an app in store search results for a term on a date, tracked daily. Lower is better; position 1 is the first result.

Tracking depth differs by store: top 100 on the App Store, top 250 on the other three. A position beyond that depth, or null, means the app was not visible in search for that term on that date — not that the term has no data.

Search volume

How often people search for a term. It is reported differently by store:

• App Store — popularity, an index from 0 to 100.
• Google Play — frequency, an estimate of monthly searches.

Both trace back to the same source: keyword popularity as Apple Search Ads reports it. On Google Play the monthly-search figure is computed from it.

In October 2025 Apple stopped reporting popularity for low-popularity keywords. For a term affected by that change, the live popularity and frequency fields lose their meaning, and the last value from before the change is kept separately — historic_popularity on the App Store, historic_frequency on Google Play. A term with a historic value and no live value is a low-volume term, and its historic figure describes the past, not today.

Search volume is not collected on AppGallery or RuStore.

Ratings

rating_value in get_app is the app's current store rating. get_app_rating_history returns the same value day by day, plus rating_by_stars — the store's own counters per star value, snapshotted daily.

Example prompts

These work on a fresh account, with nothing set up in advance.

Where an app ranks, and how the position moved

Where does Duolingo rank for "learn spanish" in the US App Store, and how did the position move over the last two weeks?

What reviewers complain about

Read the latest reviews of app 1609833428 in the US App Store and tell me what people complain about repeatedly. Note anything that was deleted.

Competitors on the same query

For the query "language learning" in the US App Store, show me the top 10 apps day by day over the last month, and tell me which of them gained or lost ground.

Limits

There is no request quota and no per-call charge on the connector.

Errors and empty responses

Errors come back as messages describing what was wrong with the request — an unknown store, a malformed country code, an app that could not be found in the store.

An empty response is not an error, and it rarely means “there is nothing there”. What it usually means:

Troubleshooting

The assistant says it has no tools, or cannot reach the server.

Check that the URL is exactly https://chiliaso.lovemobile.com/ and that the sign-in window completed. Removing and re-adding the server restarts the authorisation.

An app appeared in my account that I did not add.

Asking about an app registers it — see What the connector writes. This includes competitors you asked about and apps whose store IDs were resolved from a positions response.

I asked about a new search term and got nothing back.

Terms added during a call need a few minutes before position data is available. Ask again.

Positions are empty for a term I know the app ranks for.

Check the store and country in the question. Positions are tracked per app, per country, per store, and a term tracked in one country has no data in another. Also check the tracking depth: beyond the top 100 on the App Store, or the top 250 elsewhere, the app is reported as not visible.

Search volume is missing for some terms.

Low-volume terms have not been reported by the source since October 2025. The last known figure is kept in historic_popularity or historic_frequency. See Metrics and scales.

No reviews come back.

Reviews are not collected on AppGallery. On the other stores, review collection may not yet be connected for that app — contact support.

My assistant asks for confirmation on every call.

That is the client's permission model, not a server setting. Clients treat tools that write differently from tools that only read, and three of these tools register apps and search terms.

Data and privacy

Your assistant sends the server the parameters of each request — app identifiers, search terms, store, country and date ranges — and receives the results. The server does not receive the text of your conversation, and does not read your assistant's memory, chat history, summaries or uploaded files.

The apps and search terms your requests refer to are recorded in your ChiliASO account, which is what allows data to be collected for them.

Reviews returned by list_reviews are published by the app stores and can include the display name the store shows for the review's author.

Full details: Privacy Policy.

Support

• Email: hello@lovemobile.com
• Office: Larnaca, Cyprus

Write to us for account or data deletion, to remove an app or a search term from your account, or to connect review collection for an app.