When you connect an AI agent to the Uprate MCP server, you decide how much it can do in your App Store Connect and Google Play apps. This page lists what the agent can change by itself, what waits for you, and how to take access back. For how Uprate keeps your store keys, see Security and access.

Access levels

You choose the access on the sign-in page when your client connects:

  • Read only (mcp:read): reviews, ratings, listings, releases and the status of changes.
  • Read and edit (mcp:write): also changes inside Uprate, such as reply drafts, release notes and file uploads.
  • Read, edit and publish (mcp:publish): also replies, listing copy and releases sent to App Store Connect and Google Play.
  • Workspace settings (mcp:account): also apps, team, billing, store connections and automation rules. It's a separate switch on top of the level, and it only works when the connection can use all apps.

The first three levels build on each other. The connection also never goes beyond your own role and app access in the workspace. Uprate checks the access on every call and again before it runs an approved change.

What the agent can do

Yes means the change waits for your approval, unless you let the connection approve that kind of change by itself (see below). Always means it waits for you every time.

Action Access Asks you first
list_reviews mcp:read No
search_reviews mcp:read No
export_reviews mcp:read No
get_rating_trend mcp:read No
get_review_overview mcp:read No
get_release_feedback mcp:read No
plan_review_replies mcp:read No
save_reply_draft mcp:write No. The draft stays private in Uprate.
draft_review_replies mcp:write Only when it writes more than one draft, which uses credits, or replaces drafts you already have.
publish_review_replies mcp:publish Yes, with the exact text of each reply.
get_listing mcp:read No
set_listing_text mcp:publish Yes, for Google Play listing text and App Store promotional text. App Store fields saved for your next release don't ask.
list_builds mcp:read No
get_release mcp:read No
prepare_release mcp:write No. It starts a release with an existing build and submits nothing for review.
set_release_notes mcp:write No. Saved in Uprate.
set_export_compliance mcp:write No. Saved in Uprate.
submit_release mcp:publish Yes
submission.start_analysis mcp:write Yes, because finishing the analysis of an update can write its listing to the store and start the build.
Team changes: creating, renaming, leaving or deleting a workspace, inviting or removing members, roles, app groups, moving apps between workspaces, transferring ownership and accepting an invitation mcp:write mcp:account Yes
Billing changes: checkout, buying credits and opening the billing portal mcp:write mcp:account Yes
review.process_historical mcp:publish Always. It runs your automatic reply rules on up to 500 older reviews.
review.set_automation when it changes automatic replies mcp:publish Always
system.create_rule, product.update_automation_rule, product.set_automation_rule_active, product.delete_automation_rule mcp:write mcp:account Always
system.create_scheduled_task, and system.manage_scheduled_task when it runs, resumes or changes a task mcp:write mcp:account Always
system.manage_routine_offer when it accepts a routine mcp:publish mcp:account Always

Names with a dot are actions the agent runs through run_action. Every other action that publishes to a store, such as replies, listing changes, prices and submissions, asks you too. Many changes inside Uprate, like deleting an app or a document, also show a preview before they run.

An automation rule you set up in Uprate can block an action or make it ask you. A connection never approves a change held by such a rule by itself. One exception: set_listing_text still saves App Store fields for your next release without asking, because they don't reach the store until you submit a release.

How an approval works

When a change needs your approval, Uprate doesn't run it. It returns an operation with a preview: the app, the store, the targets and how many items it changes. The agent shows you the preview and then calls approve_operation with the exact summary from the preview and a confirmation token. For previews without an approval type, it calls confirm_operation, which also rejects a change.

The token works for 15 minutes and only for that exact preview. If the change behind it changes or the time runs out, the agent has to request the operation again.

Your MCP client decides whether it asks you before a tool call. Uprate marks approve_operation as a tool that needs your interaction, and both approval tools as destructive, so clients that follow these hints ask you first. If you set your client to run tools without asking, it can approve changes without you.

Let a connection approve by itself

On the sign-in page, or later in Settings > MCP under Change approvals, you can let one connection approve some kinds of changes by itself:

  • replies, listing changes and releases, when the connection has mcp:publish
  • team and billing changes, when the connection has mcp:account

For each kind, choose up to 5, 20 or 100 a day, or no limit. The day follows your Uprate timezone, and every reply in a batch counts. Over the limit, your client asks you again. The connection never approves changes marked Always in the table, or changes held by an automation rule, by itself.

How long access lasts

  • A connection lasts 30 days from the day you signed in. Settings > MCP shows the date. Refreshing tokens doesn't extend it. After that, sign in again from your client.
  • The access token your client uses expires after one hour. The client gets a new one with its refresh token.
  • Every refresh replaces the refresh token, and the old one stops working. If an old refresh token is used again, or a different client sends it, Uprate disconnects the whole connection.
  • The connection only works in the workspace you were in when you signed in. If your client refreshes its access while you're in another workspace, Uprate disconnects it.

Revoke access

Open Settings > MCP, find the client under Connected clients and select Disconnect. The client loses access right away and its refresh token stops working. Uprate checks the connection again before it starts an approved change, so a change that hasn't started yet doesn't run.

A client can also revoke its own tokens through Uprate's OAuth revocation endpoint, which is listed in the server's OAuth metadata.

The connection uses your permissions at the time of each call. When you lose access to an app or your role in the workspace changes, the connection loses that access too.

To cut off Uprate's own access to your stores, remove the store key in Uprate and revoke it in App Store Connect or Play Console. See Security and access.

What you can check

  • Settings > MCP shows each connection's workspace, apps, access, expiry date and how many changes it approved by itself today.
  • Ask the agent to call get_context. It returns the connection's access, its approval rules and how many of them it used today.
  • Ask the agent to call get_operation without an ID. It lists the connection's recent operations with their status.