Skip to content
MagicFrog

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 consume the same aggregation layer over the same catalog sources, 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. The full three-family catalog — MCP servers, plugins, and skills — is the same data layer the desktop market renders.

The official registry is always present and cannot be removed. Beyond it you can configure custom sources — your own catalog endpoints speaking the same registry API shape.

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.

Two install payloads exist today:

  • mcp — an MCP server from a source (source base URL plus server name);
  • plugin — a plugin spec string.

That is the honest boundary: skills are browsable in the desktop market, but a web-initiated install currently covers MCP servers and plugins only.

How the queue behaves

Queue items carry only catalog identity — never a pre-built install configuration. The desktop resolves the concrete install name against its own set of installed names at execution time, because the web side cannot know what your desktop already has.

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: it checks a processed journal before acting and records after success, so a retry never double-installs, and an unknown-outcome run 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 three families plus an OAuth connectors tab for authorizing external services. Because both front doors share one aggregation layer, browsing on the web and installing on the desktop stay consistent about what exists and what is installed.