MCP & Agent Skills

Ask your coding agent to ship an update and it will read your Capacitor project, check whether the change is safe to send over the air, upload the build, and then stop and show you exactly what it is about to publish. Nothing reaches a device until you approve it.

Set it up

One command, from your project directory:

npx -y @otakit/cli@latest connect

It detects your client, signs you in if you are not already, and prints the console, organization, project, and app it resolved — plus the exact file it will write — before writing anything:

Connecting Claude Code (detected).

  console       https://console.otakit.app
  organization  Acme Inc
  signed in as  dev@acme.example
  project       /Users/dev/shop
  app           com.acme.shop (from config)

Will add server "otakit" in .mcp.json:
  ...

Write it? [y/N]

--dry-run prints the same plan and writes nothing. --client overrides detection. --yes skips the prompt in scripts.

Claude Code

The official plugin ships the server and the OtaKit Skill together, so this is the whole setup:

npx -y @otakit/cli@latest login

claude plugin marketplace add OtaKit/otakit
claude plugin install otakit@otakit

Run /mcp and you should see otakit connected to whichever project you have open.

Codex

npx skills add https://github.com/OtaKit/otakit --skill otakit

npx -y @otakit/cli@latest login
codex mcp add otakit -- npx -y @otakit/cli@latest mcp

VS Code and GitHub Copilot

Create .vscode/mcp.json, then run MCP: List Servers to trust and start it:

{
  "servers": {
    "otakit": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "@otakit/cli@latest", "mcp", "--project-root", "${workspaceFolder}"]
    }
  }
}

What to ask for

Clients that support MCP prompts expose these as slash commands. Plain language works just as well.

Or just say what you want:

• “Upload version 2.4.1 to staging but don’t publish it — tell me the bundle ID.”
• “Prepare this for production with auto-revert on, then wait for me.”
• “Why are people on 1.4.2 seeing rollbacks?”
• “Roll production back to the previous release.”

Before anything ships

Publishing and reverting always stop for approval, and always show the same block — so you read it at a glance instead of parsing whatever the agent decided to write:

Publish  com.acme.shop
  lane       base · runtime 2026.04
  from       1.4.0  ->  1.5.0
  native     compatible (12 packages unchanged)
  immediate  no        auto-revert  on · 10% · min 100
Approve? This goes live for every device on that lane.

Uploading is separate from publishing, so an agent can prepare a build for you to look at with no risk of it reaching a device. A publish carries the release state the agent reviewed, so if a teammate releases in between, yours is rejected instead of silently overwriting theirs. Every write is attributed in the audit log.

Native compatibility is checked against what the current release actually shipped. If your app gained a native dependency, that needs a store build rather than an OTA update, and the agent stops and says so. If it cannot read your dependencies at all, it says that too instead of guessing.

Working without a checkout

The setup above runs OtaKit in your repository, which is what lets it inspect the project and upload builds. There is also a remote endpoint over HTTPS at console.otakit.app/mcp for clients that cannot run a local process, and for CI. It does everything except the parts that need your files:

Add it alongside the local server, not instead of it — running both means your agent sees two copies of the shared tools.

# Claude Code
claude mcp add-json --scope project otakit-remote \
  '{"type":"http","url":"https://console.otakit.app/mcp","oauth":{"scopes":"otakit:read otakit:app:write otakit:bundle:write otakit:release:write"}}'
claude mcp login otakit-remote

# Codex
codex mcp add otakit-remote --url https://console.otakit.app/mcp
codex mcp login --oauth-client-registration cimd \
  --scopes otakit:read,otakit:app:write,otakit:bundle:write,otakit:release:write,offline_access \
  otakit-remote

The browser flow shows the client, the organization, and what it is asking for before anything is granted. Drop the write scopes for a deliberately read-only connection. Revoke it from Settings → Agents and its tokens stop working immediately. For CI, use an organization key in OTAKIT_TOKEN and keep it in your secret store, never in a project file.

Which organization it uses

A connection is bound to one organization for its lifetime, and it tells the agent which one as soon as it connects. A project with a configured appId uses that app’s organization. Without one, it uses the default you chose at login — change it with otakit organization select and restart the server. Automation can set OTAKIT_ORGANIZATION_ID instead.

This is deliberately separate from the dashboard: switching workspaces in the browser does not move a running agent connection.

Self-hosting

Use your own console origin everywhere — otakit connect picks it up from plugins.OtaKit.serverUrl automatically. Remote MCP lives at <console-origin>/mcp.

The agent features roll out in stages and ship disabled. Back up and test the database, apply the additive migrations through your normal reviewed process, then deploy the code with every new flag off. Enable release reliability, remote MCP, and OAuth one at a time. OtaKit never migrates a live database for you.

See the self-hosting guide, and the Agent Skill source for the flags and rollout checklist.

Reference

• OtaKit CLI reference — every command the agent falls back to
• Codex MCP
• Claude Code MCP
• VS Code MCP
• Agent Skills specification