Skip to content
MagicFrog
Menu

Market

Browse the market on the web and send installs straight to your desktop.

The MagicFrog market is one catalog with two front doors: the market built into the desktop app, and an independent web station that works without the client. Both show the same catalog, so the two surfaces stay consistent about what exists.

The web station

The market web station is an independent page on the MagicFrog website. Browsing, searching, category filtering, featured picks, and recently-updated streams all work without an account and without the desktop client. Each listed server opens a detail page with its metadata, source, and install action.

The station browses the MCP server catalog: tools the agent can use, from the official registry plus configured custom sources, merged into one list with an official-only facet when you want just the official catalog. MCP servers, plugins, and skills are the same catalog on web and desktop.

The official registry is always present and cannot be removed. Beyond it you can configure custom sources — your own catalog addresses compatible with the official registry format.

Sign in and send an install

Installing from the web station uses your MagicFrog account:

  1. Sign in with your account identifier and password (the same account gate as the rest of MagicFrog).
  2. Send the install. One click enqueues an install item on your account.
  3. The desktop pulls it. A desktop client signed in to the same account claims the item, installs it, and settles the outcome.

A web-initiated install covers two kinds of content today: MCP servers and plugins. That is the honest boundary: skills are browsable in the desktop market but cannot be installed from the web yet.

How the queue behaves

An install item records only what to install, never a concrete configuration; the desktop checks it against what your machine already has, so nothing installs twice or at the wrong version.

Items move through an explicit state machine:

pending → claimed → executed | failed
   ↘ cancelled
  • Only pending items can be claimed; only claimed items can be executed or failed; pending and claimed items can be cancelled. Terminal states are immutable.
  • A failed item always carries an explicit reason.
  • The desktop executes idempotently: a retry never double-installs, and an install with an unknown outcome is never falsely marked done.

Where your credentials live

The access token is held in memory on the web page for as long as the tab is open — it is never written to browser storage. The refresh token never reaches the web client at all. Leave the page and the session is gone; the next install asks you to sign in again. The desktop side uses the account's device credential channel, which is separate and independently revocable.

The desktop market

The embedded market in the desktop app shows the same content plus an OAuth connectors tab for authorizing external services. Browsing on the web and installing on the desktop stay consistent about what exists and what is installed.