> For the complete documentation index, see [llms.txt](https://docs.mediafier.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.mediafier.ai/partners/publishing-to-the-marketplace.md). # Publishing to Mediafier's Marketplace Build to the contract, get listed, earn per call: what publishing requires and what the review promises. > **Build to the contract. Get listed. Earn per call.** This page is for engineers, partners, and third-party builders who want to ship a governed resource through Mediafier's Marketplace and have it reachable from any organization on the platform. > **Availability: operator-assisted during the invite-only pre-launch.** There is no self-service publishing today — our team runs the review, registration, and listing with you. This page describes the contract your resource is built and reviewed against; treat it as forward documentation of the self-service path, not a flow you can complete alone right now. [Request access](https://mediafier.ai/request-access) to start. Most publishing paths today ship an **MCP server** — the most mature publishing surface and the worked example throughout this page. **Skills, MediaClaw super-agents, and workflows** publish through the same governance contract; the platform-side review, listing, installation, metering, and audit chain is identical. Where the runtime contract differs by resource type, the qualified partner onboarding packet covers the type-specific spec. *** ## The publishing path in one diagram ``` Build → Submit → Review → List → Install (per org) → Earn (per call) │ │ │ │ │ │ Resource Contract Contract Discoverable Org admin binds Per-call against + identity + identity org-wide credentials and ledger spec + billing verified (subject to enables the movements by publisher's resource platform visibility) ``` Six stages. The first three (build, submit, review) are one-time work for the publisher. The last three (list, install, earn) are per-organization adoption events repeated for each customer that installs the resource. *** ## What you build You build a standard MCP server (or other governed-resource runtime) that conforms to the platform's contract. The platform requires: * **A documented JSON-RPC surface** — the standard MCP protocol over HTTPS. * **A `tools/list` capability description** — the tools your server exposes, each with input schema and a clear description. * **Per-tool input schemas** — JSON Schema the gateway can validate against before dispatch. * **Idempotency hints** for tools that can safely be retried. * **Risk-profile metadata** (read-only, mutating, destructive) so planners can reason about what your tools do. Everything else — identity, org isolation, credentials, metering, audit, rate limiting — the platform handles on every call; see [What the platform handles for every listed resource](#what-the-platform-handles-for-every-listed-resource) below. Your server's job is the work. The platform's job is everything around it. *** ## What you submit Submission is a contract step, not just a technical handoff. The platform reviews: * **Server contract** — the tools, schemas, and capability descriptions match what the runtime actually exposes. * **Identity ownership** — you can demonstrate you own the runtime endpoint and the upstream systems your tools touch. * **Billing setup** — the per-call earnings split, payout details, and settlement preferences are agreed and recorded. * **Operational expectations** — your runtime can meet the platform's expectations for behaviour and reliability under load. What gets reviewed is the contract, not the source code. Mediafier supports multiple integration models; during the invite-only pre-launch, the Mediafier team determines the appropriate model with each provider. Whatever the model, the platform governs the access path, meters the calls, and audits what happened. *** ## What you control about your listing Publishers choose how a listing appears in the catalog and who can install it. The two control axes — **visibility** (listed vs. unlisted) and **access** (public vs. allowlist) — are summarized in [The Marketplace](/partners/marketplace.md#what-tool-publishers-control). The short version: * **Visibility** lets you ship a discoverable catalog entry or keep the resource off the catalog and reachable only via a direct reference. * **Access** lets you allow any org admin to install (the default growth path) or restrict installs to organizations on a publisher-managed allowlist. Both settings are publisher-controlled and changeable after listing. Use them to model private partnerships, early-access pilots, beta cohorts, or fully private integrations without leaving the governed publishing contract. *** ## What happens after listing A listed resource is discoverable platform-wide (subject to your visibility setting). It is **not** runnable until an org admin installs it for their organization. The installation step is what: * Binds your resource to that org's tenant context. * Triggers credential binding for any upstream APIs your tools need. * Makes your tools appear in the org's `tools/list` discovery for any agent the org runs. * Enables per-call metering against the org's wallet, with earnings routed to your settlement record. After installation, every call from that org's agents to your tools walks the same gateway chain as every first-party tool. There is no "Marketplace fast-path" — and you don't have to build one. *** ## What the platform commits to Three things the platform delivers to publishers without further negotiation: * **Per-call metering with trace correlation.** Every call to your tools is recorded against the trace ID, attributed to the calling organization, and priced per the listing. * **Append-only earnings ledger.** Every accrual is an immutable ledger entry. Corrections are new offsetting entries, not edits. * **The same governance contract as first-party tools.** Identity, org isolation, authorization, billing, audit. Your tools inherit the platform's enforcement model — they don't have to implement one. Specific split percentages, payout cadence, and settlement currency are publisher-specific terms in the publisher agreement, not in launch documentation. *** ## What the platform handles for every listed resource The Marketplace contract is uniform across every publisher. Five things the platform handles on every call to your runtime so your server doesn't have to: * **Identity.** The gateway resolves the caller and hands your runtime a principal. Your server doesn't accept client-supplied identity, and doesn't need to. * **Org isolation.** Tenant context is server-derived. Your runtime sees the org context the gateway determined; cross-org leakage is not a failure mode you have to defend against. * **Audit.** Every call to your tools produces the same audit row as any first-party tool — you inherit the chain instead of building one. * **Credential governance.** The gateway prepares and injects credentials your tools need; your runtime never reads a credential store directly. You don't operate a vault. * **Metering.** Calls that reach your runtime are metered against the calling org's wallet; earnings flow back through the same ledger. Because the contract is uniform, your publisher account scales without a separate compliance investment. Your tools sit behind the same enforcement chain customers review for first-party tools. *** ## What this page is not * It is not the full onboarding checklist. The runtime spec, the exact schemas, the certification checklist, the submission process, and the publisher agreement template live in the **qualified partner onboarding packet**, issued through the operator-assisted flow once you have requested access and been qualified. This page is the orientation; the packet is the step-by-step. The path is always the same: understand the opportunity here → review the public integration contract → [request access](https://mediafier.ai/request-access) → receive the partner onboarding packet. * It is not a guarantee that any submission will be approved. Listing is reviewed and accepted on contract. * It is not the Marketplace economics page. See [Provider Earnings & Marketplace Economics](/partners/provider-earnings-and-marketplace-economics.md) for how per-call earnings work. *** ## Where to go next | If you're… | Read next | | ---------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------- | | Looking at Marketplace economics for publishers | [Provider Earnings & Marketplace Economics](/partners/provider-earnings-and-marketplace-economics.md) | | Looking at the Marketplace itself | [The Marketplace](/partners/marketplace.md) | | Studying the gateway your resource will be reached through | [The Gateway](/platform/gateway.md) | | Connecting your existing tools without publishing | [MCP Access](/connect/mcp-access.md) | | Ready to build an MCP server or MediaClaw end-to-end | **Operator-assisted during the invite-only pre-launch** — [request access](https://mediafier.ai/request-access) and our team builds and publishes with you |