Operate App Store Connect and Google Play Console workflows from agents without skipping safety.
Expose the same governed Launch and update workflows to agents and CLI clients with dry-runs, confirmation tokens, scopes, and idempotency. Agents can prepare Launch readiness, inspect state, stage updates, run ASO checks, and queue supported store work without bypassing SyncStore’s confirmation model.
Endpoint
Streamable HTTP + JSON-RPC
POST /api/mcpDry-run first
Every mutating tool defaults to dryRun: true and returns the planned work, payloadHash, and confirmToken.
Confirm the same payload
To execute, repeat the exact same input with dryRun: false, confirmToken, and an idempotencyKey.
Replay safely
The same idempotencyKey and payload returns the stored result; a different payload is rejected.
Manual Setup
Create a scoped key, add the MCP server to your client, then use dry-run confirmation for writes.
1. Generate an MCP key
2. Configure your MCP client
{
"mcpServers": {
"syncstore": {
"url": "https://your-syncstore-domain.com/api/mcp",
"headers": {
"Authorization": "Bearer sk_your_key"
}
}
}
}3. Confirm mutating operations
AI Agent Shortcut
One-shot setup prompt
Copy this into an AI agent or CLI assistant. It gives the agent the MCP endpoint, config shape, safety contract, and the exact operating model for SyncStore store writes.
You are helping me connect SyncStore as a remote MCP server and use it safely for app store operations.
SyncStore MCP endpoint:
https://syncstore.app/api/mcp
Authentication:
- Use an HTTP Authorization header: Bearer <SYNCSTORE_MCP_KEY>
- If I have not provided the key yet, ask me for the SyncStore MCP key from Settings > MCP.
- Never print, log, or expose the key after I provide it.
Client configuration shape:
{
"mcpServers": {
"syncstore": {
"url": "https://syncstore.app/api/mcp",
"headers": {
"Authorization": "Bearer <SYNCSTORE_MCP_KEY>"
}
}
}
}
After connecting:
1. Call initialize.
2. Call tools/list and summarize the available SyncStore tools.
3. Call resources/list and resources/read for the SyncStore safety/manual resource if available.
4. Use read tools first to inspect apps, listings, screenshots, reviews, smart links, legal pages, update workspaces, sync rules, usage, integrations, and jobs.
Safety rules for all mutating SyncStore tools:
- Always call the tool with dryRun: true first.
- Show me the planned result, payloadHash, and affected apps/stores/locales.
- Do not execute writes until I explicitly approve the dry-run plan.
- After approval, repeat the exact same input with dryRun: false, the confirmToken returned by dry-run, and a unique idempotencyKey.
- Reuse an idempotencyKey only for retrying the same exact payload.
- Treat tools requiring mcp:store_write as production store-affecting operations.
- For SyncStore Launch, Read + Write can discover/import apps, create a Launch, update the shared brief/declarations, including structured Google Play Console policy answers, refresh state, and preview apply/submission readiness. Store Write + Admin are required to record attestations, execute apply, delete unsubmitted Launches, or submit for review.
Goal:
Help me manage the full app store workflow through SyncStore MCP: app discovery, SyncStore Launch, listing updates, screenshot uploads/reorder/delete, API-backed declarations, ASO audits, review sync/replies, smart links, legal pages, update workspaces, sync automation, bulk operations, and job status.Dry-run call
{
"jsonrpc": "2.0",
"id": "1",
"method": "tools/call",
"params": {
"name": "syncstore.create_sync_rule",
"arguments": {
"dryRun": true,
"input": {
"name": "Nightly sync",
"schedule": "0 3 * * *",
"scope": { "operations": ["sync"] }
}
}
}
}Confirmed call
{
"jsonrpc": "2.0",
"id": "2",
"method": "tools/call",
"params": {
"name": "syncstore.create_sync_rule",
"arguments": {
"dryRun": false,
"confirmToken": "confirm_token_from_dry_run",
"idempotencyKey": "client-operation-001",
"input": {
"name": "Nightly sync",
"schedule": "0 3 * * *",
"scope": { "operations": ["sync"] }
}
}
}
}Read coverage
Write and full-ops coverage
Production Safety
Store writes are tenant-scoped, auditable, confirmed, and idempotent.
Keys are hashed at rest, checked for active/expiry state, scoped by organization, and filtered by permissions before tools are listed or called.