M
MCP Directory CURATED DIRECTORY
911 MCP servers indexed
中文
← Back to directory
O

OtaKit MCP Server

Official
Push OTA updates to your Capacitor app without app store reviews
How to install ↓ Compare GitHub source repository ↗
Category
Dev Tools #158 of 438
Stars
★ 46 Popular
Transport
stdio (local process) · Streamable HTTP
Runtime
Node.js 20.9+ · Hosted (no local runtime)
Credentials
API key / credential required
License
MIT
Last commit
57FMRS · C

OtaKit is an open-source Capacitor OTA update framework maintained by its upstream project, and its MCP server lets coding agents inspect, upload, release, monitor, and revert updates while stopping for human approval before anything reaches a device. It suits teams using Capacitor that want to ship web asset updates without app store reviews, and is not aimed at non-Capacitor projects or updates requiring native code changes. Watch for the account permissions granted, the effect of upload and release operations on live channels, and the operational overhead of self-hosting.

Strongest · Setup experience 13/20 Weakest · Reliability 10/20

Reliability
10/20
Security and permissions
10/20
Maintenance
13/20
Documentation
11/20
Setup experience
13/20
Why each score
Reliability 10/20
server.json declares an npm package @otakit/[email protected] over stdio with a positional `mcp` argument, plus a streamable-http remote endpoint; both paths are echoed by the README (`npx -y @otakit/cli@latest connect` and remote OAuth), so the declared entry points are at least internally consistent. However, this is a static-only review: no committed tests, CI workflows, or reproducible execution evidence were supplied, so the MCP init handshake and the claimed inspect/upload/release/monitor/revert tool behaviors cannot be verified against real behavior. The docs themselves admit that upload/release depends on Postgres, S3-compatible storage and a CDN, and no error taxonomy or diagnosability guidance is given for those failure surfaces. Static calibration caps reliability at 12; the absence of tests and execution evidence lowers it to 10.
Security and permissions 10/20
No red line is triggered: no malware, credential theft, covert exfiltration, fabricated maintainer identity, or real tokens in install examples; the project is MIT-licensed and states it is fully open-source and self-hostable. However, permission and confirmation evidence is thin: the README's claim that nothing reaches a device before user approval is a product-level description, not auditable server-side confirmation logic; the CLI login writes a config file (the README says it prints the exact file) but how credentials are stored, whether they land in plaintext, and how scopes are minimized are unstated; the remote endpoint https://console.otakit.app/mcp involves external network and OAuth with incomplete data-flow disclosure (which project metadata and bundles go where); and upload/release/revert are dangerous or irreversible side effects with no static evidence of default double-confirmation or per-channel scoping. Scored 10 as 'main risks visible but permissions/confirmation/scoping incomplete'.
Maintenance 13/20
Repo metadata shows not archived, 0 open issues, 86 stars, MIT license, and version 1.5.0 matching the package version, with a clearly organized monorepo (capacitor-plugin, cli, mcp-core, console, ingest, site, tinybird), indicating a healthy, actively versioned project. Deductions: no visible CHANGELOG or release notes, no CI workflows, no documented security-response channel or disclosure policy, and no commit cadence or issue-response data (0 issues may equally mean no community feedback yet). The explicit license and versioned path in the manifest are positives. Scored 13 as 'active but with governance/versioning gaps'.
Documentation 11/20
Documentation is layered: the top-level README covers self-hosting architecture (console + Postgres + S3-compatible bucket + CDN), a seven-step how-it-works flow, core concepts (App/Bundle/Release/Channel/runtime version), a package structure diagram, per-package README pointers, local dev prerequisites (Node 20.9+, pnpm 9+, .env.example), and links to the agents and self-host guides. Real gaps remain: concrete MCP tool parameters, return shapes, permissions/scoping, rate or quota limits, and cost/billing details are absent from the supplied material; there is no troubleshooting or error-handling section; and the `connect` UX is described only in prose with no reviewable sample output or client config example. Docs do not contradict capability, so 11 as 'usable but with hidden assumptions and troubleshooting gaps'.
Setup experience 13/20
The install path is comparatively clear and short: standard npm ecosystem, a single `npx -y @otakit/cli@latest connect` that detects the client, signs in, and writes config, with an explicit promise to print the resolved console/org/project/app and target file first and a `--dry-run` flag; mainstream clients (Claude Code, Codex, VS Code) are named, and Claude Code additionally gets a plugin marketplace install. Deductions: the stdio path requires a Node.js 20.9+ runtime; the self-host path needs Postgres plus S3-compatible storage and a CDN, which is heavy manual setup; and OAuth details for the remote streamable-http endpoint are offloaded to external docs, so they cannot be statically verified. Static calibration caps setup at 15; with no client config sample or reproducible execution evidence in the supplied material, scored 13.

Static review · not runListed 2026-09-10

Read the FMRS scoring method →

Fit and risk

What it can accessReads local filesUses the networkChanges third-party account data

Best for

  • Teams building Android/iOS apps with Capacitor that want to ship web asset updates without app store reviews
  • Developers using Claude Code, Codex, or VS Code who want agent-assisted OTA releases
  • Organizations that need to self-host their OTA update platform

Not for

  • Non-Capacitor projects or apps that do not use OtaKit
  • Updates that require native code changes rather than web assets
  • Teams unwilling to grant an agent upload and release permissions

Required permissions

  • Requires signing in to an OtaKit account (npx @otakit/cli login) for access to consoles, organizations, and projects
  • The CLI writes client configuration files (connect prints the exact file it will write)
  • Uploading bundles and creating releases requires write access to the relevant project
  • The remote endpoint https://console.otakit.app/mcp involves OAuth authorization

Risks and side effects

  • Publishing without approval could push a broken build to real devices
  • Upload and release operations change the manifests served on a channel, affecting subsequent app launches or resumes
  • Self-hosting means maintaining Postgres, an S3-compatible bucket behind a CDN, and optionally the ingest service and a Tinybird workspace
  • The CLI writes config files, so the target path printed by connect should be verified first

Setup

Before you start

Runtime：Node.js 20.9+ · Hosted (no local runtime)

Run one command from your project directory: npx -y @otakit/cli@latest connect. It detects your client, signs you in if needed, and prints the console, organization, project, and app it resolved — plus the exact file it will write — before writing anything. Use --dry-run to see the plan and write nothing. Claude Code additionally has a plugin that ships the server and the OtaKit Agent Skill together: run npx -y @otakit/cli@latest login, then claude plugin marketplace add OtaKit/otakit and claude plugin install otakit@otakit.

Check that it works

Run npx -y @otakit/cli@latest connect --dry-run in your project directory; it should print the resolved console, organization, project, and app plus the exact file it would write without modifying anything, and once connected the OtaKit tools should appear in your client's tool list.

Troubleshooting

  1. Run connect with --dry-run first to confirm the resolved console, organization, project, and app
  2. Confirm you are signed in by running npx -y @otakit/cli@latest login
  3. Confirm the correct appId is set in capacitor.config.*
  4. If the remote connection fails, check that OAuth authorization for https://console.otakit.app/mcp completed
  5. In self-hosted setups, check the Postgres and S3-compatible storage configuration; see packages/console/.env.example
  6. If you are unsure about OTA compatibility, check the runtime version lane configured in the plugin

Things to try

Once connected, you can ask your AI assistant things like:

  • Check my Capacitor project and tell me if this change is safe to ship as an OTA update
  • Upload the current build to OtaKit and publish a release
  • Do a dry-run first and show me which files you would write
  • Revert to the previous OTA version

Use cases

Inspect, upload, and release Capacitor OTA updates from an editor or coding agent
Check whether a change is safe to send over the air before publishing
Monitor update status and revert a release when needed
Require human approval before anything reaches a device

Supported clients

Claude Code
Codex
VS Code

Listed from the project's documentation, not tested by this site.

Overview

OtaKit is a fully open-source, self-hostable over-the-air (OTA) update framework for Capacitor apps, letting you release updates directly to your Capacitor app without app store reviews. Its MCP server inspects, uploads, releases, monitors, and reverts OtaKit Capacitor OTA updates. It can be launched from the npm package @otakit/cli over stdio (via the mcp subcommand) or reached remotely over streamable-http at https://console.otakit.app/mcp. When asked to ship an update, an agent such as Claude Code, Codex, or VS Code can read your Capacitor project, check whether the change is safe to send over the air, upload the build, and stop for your approval before anything reaches a device.

Similar servers

Context7 80 · B

Upstash's official server providing up-to-date third-party library docs for AI coding assistants

★ 63.3k · Tools 2 Compare with this →
Compare with other MCP servers

Source revision 22a57011f7c3 Data synced 2026-10-19 Read the FMRS scoring method