Developer Experience

The OrbitKit MCP server: manage App Store web compliance from an AI agent

OrbitKit hosts a Model Context Protocol server so Claude, Cursor, and other MCP clients can generate and deploy your privacy policy, AASA, and more. How it works.

By · · 7 min read

If you drive your development from an AI agent — Claude, Cursor, or any Model Context Protocol client — the web side of App Store compliance can be part of that loop instead of a context switch. OrbitKit hosts an MCP server at https://mcp.orbitkit.io/ that exposes the same operations as the CLI and dashboard as MCP tools, so an agent can read your privacy policy, update your AASA config, generate a PrivacyInfo.xcprivacy, and deploy — all from the conversation.

This is how it works, what tools it exposes, and the safety model.

For what these files are and why Apple requires them, see every URL and file Apple requires for an iOS App Store submission.

What it is

A hosted MCP server speaking JSON-RPC 2.0 over HTTPS, authenticated with the same ORBITKIT_API_KEY Bearer token as the CLI. Point any MCP client at it:

{
  "mcpServers": {
    "orbitkit": {
      "url": "https://mcp.orbitkit.io/",
      "headers": { "Authorization": "Bearer ok_live_…" }
    }
  }
}

(Exact client config syntax varies — Claude Code, Claude Desktop, and Cursor each have their own MCP config file; the server URL and Bearer header are the constants.)

The tool surface

The server exposes ~30 tools mirroring the dashboard. Read tools have no side effects; write tools are explicit:

Group Tools
Identity whoami, list-apps
Site get-site, update-site, get-custom-homepage-html, set-custom-homepage-html
Privacy policy get-policy, update-policy
Support / deletion get-support-page, update-support-page, get-deletion-page, update-deletion-page
AASA get-aasa, update-aasa
Smart App Banner get-banner, update-banner
TestFlight get-testflight, update-testflight
Privacy manifest get-privacy-manifest, update-privacy-manifest, sync-privacy-manifest-from-wizard, download-privacy-manifest, get-privacy-manifest-reference
Domains check-domain-status, set-domain, remove-domain
Lifecycle create-app, delete-app, deploy, subscribe

A read like whoami returns the same JSON shape as GET /api/account ({profile, stats, paymentMethod, subscription}) — agents that know the REST shape already know the MCP shape.

What an agent can do with it

A representative agent loop:

You: "Set up the App Store privacy policy for my new app and deploy it."

Agent → create-app  { appName: "Capybara Cam" }
Agent → update-policy  { appId, policy: { app-info: {...},
         data-collection: { collects_data: true, data_types: [...],
         purposes: [...] }, ... } }
Agent → update-support-page  { appId, contactEmail: "help@…", faqItems: [...] }
Agent → deploy  { appId }
Agent ← "Deployed at https://sites.orbitkit.io/capybara-cam — privacy
         policy, support page, and AASA file are live."

The agent never has to leave the conversation to open a dashboard, and because the privacy manifest, policy, and nutrition-label answers come from one source, the three surfaces App Review cross-checks stay consistent (the thing that causes the data-mismatch rejection email).

Safety model

The destructive and billable operations are deliberately separated so an over-eager agent can’t surprise you:

  • Read tools (get-*, list-apps, whoami, download-privacy-manifest) — no side effects, safe to call freely.
  • Write tools (update-*, set-*) — modify config but are idempotent; a get→update round-trip with the same data is a no-op.
  • deploy publishes to your live hosted site. subscribe is billable. delete-app is destructive. Treat these like the agent treats git push — explicit user intent, not autonomous.
  • Auth is per-API-key; scope and rotate keys in the dashboard. The MCP server enforces the same rate limits and per-app access checks as the REST API.

A good agent harness will gate deploy / subscribe / delete-app behind explicit confirmation. The server doesn’t assume the client does, so design your automation accordingly.

CLI vs MCP — which to use

  CLI MCP server
Best for CI/CD pipelines, scripts AI-agent-driven dev (Claude/Cursor)
Invocation orbitkit <cmd> in a shell tool calls from an MCP client
Auth ORBITKIT_API_KEY env Authorization: Bearer header
Output text or --json structured tool results
Same operations Yes Yes

They’re two front-ends to the same API. Use the CLI in GitHub Actions; use the MCP server when an agent is doing the work.

Create an API key to connect an agent — start free or see the full feature list.