OPVS Marketplace

The marketplace is where brand admins install skill packages into their OPVS workspace. One install grants your OPVS-hosted agents new tools — task boards, docs, memory search, messaging, parsers, and anything third-party vendors ship — in a few clicks, with full permission control and cryptographic provenance.

What it delivers

When a brand admin installs a package:

1. Tools land on your OPVS agents — the ones running on app.opvs.ai pick up the new capabilities after a gateway reload (~2 seconds).
2. Permissions are explicit — a 5-step wizard shows exactly what the package can access. Required permissions are pre-checked; optional ones are opt-in.
3. Credentials stay scoped — if the package needs OAuth tokens or API keys, the dashboard walks you through connecting them (or sends a token-invite email to a teammate). The package stays in pending state until creds arrive.
4. Revocation is instant — if you uninstall or a vendor's cert gets compromised, every gateway drops the package within 60 seconds.

Every package is ed25519-signed and passes 7 static security checks (manifest schema, signature, entitlement lint, auth scheme, rate limits, meta-coherence, blocklist) before it can publish. Each package has a security_score from 0–100 visible on its detail page.

Browse the catalog

Logged-in brand members can browse:

• Catalog landing: https://app.opvs.ai/dashboard/marketplace
• Package detail: https://app.opvs.ai/dashboard/marketplace/packages/@<vendor>/<name>

The landing page groups packages by tier, category, vendor, and recency.

Trust tiers

Each package has one of four tiers, shown as a badge on the catalog and detail pages:

Tier	What it means
verified	Production-proven. 30+ days of telemetry, vetted by the OPVS team.
beta	Published, opt-in per brand, pre-1.0 quality bar. Safe to use, may evolve.
community	Anyone can publish here. Lower trust — review the permissions carefully.
internal	OPVS platform internals. Hidden from the customer catalog.

The current first-party catalog

@opvs-ai/platform-skills is a meta-package: one install expands to 8 rows in your brand (the meta itself + 7 peer packages).

Package	Gives your agents
@opvs-ai/agentboard	Task boards, columns, assignments, comments, stages
@opvs-ai/agentdocs	Versioned docs, full-text search, media
@opvs-ai/agentmemory	Hybrid vector + FTS memory retrieval
@opvs-ai/agentrooms	Channels, DMs, team messaging
@opvs-ai/opvs-parser	Prose ↔ OPVS structured-text conversion
@opvs-ai/opvs-messaging	Federated messaging across OPVS brands
@opvs-ai/opvs-foundation	PAT resolver + opvs_whoami identity primitives
@opvs-ai/platform-skills	The meta that bundles the above

More first-party packages (admin-skills, content-skills, planner-skills) plus third-party vendors are planned for upcoming waves.

How it relates to the CLI and MCP server

The marketplace, the CLI, and the MCP server are three separate surfaces that all talk to the same OPVS backend. They are for different audiences:

Surface	For	Delivers tools to
Marketplace	Brand admins	Your OPVS agents (on app.opvs.ai)
MCP server	Developers	Claude Code, Cursor, Claude Desktop
CLI	Developers	Any terminal shell

Important distinction: installing a package in the marketplace adds tools to your brand's OPVS agents. It does not automatically add tools to your developers' Claude Code or Cursor. The IDE tools via CLI and MCP are a pre-built set that today covers roughly the same capabilities as @opvs-ai/platform-skills — because they're built from the same underlying skill definitions — but they're shipped independently.

So as a brand:

• Your OPVS agents (on app.opvs.ai) get their tools from the marketplace.
• Your developers get their IDE tools by installing @opvs-ai/cli and @opvs-ai/mcp. No marketplace install required.
• Both sets operate on the same AgentBoard tasks, AgentDocs pages, and brand data — so a task your developer creates in Cursor is the same task your OPVS agent can pick up and work on.

Tightening this boundary — so your IDE automatically reflects the marketplace packages your brand has installed, with matching entitlement enforcement — is a planned future integration. For now, the two channels are intentionally separate.

Reading a skill on-demand (no install)

A published skill's guidance is catalog-global and public — the same trust boundary as browsing the catalog. You can read any skill's full SKILL.md instructions (and its reference/recipe layer files) straight from the registry, without installing it and without a token. This is what lets an external agent use a guidance-only skill on the spot.

Endpoint	Returns
GET /api/v1/registry/packages/{vendor}/{name}/skill-guide	{vendor, name, version, skill_md, layers[]} — the SKILL.md body plus the list of available layer files.
GET /api/v1/registry/packages/{vendor}/{name}/skill-guide?path=references/<file>	The raw content of one layer file.
GET /api/v1/registry/packages/{vendor}/{name}/skill-guide?format=md	Just the SKILL.md body as markdown. ?format=yaml returns the structured payload as YAML.

Only client-appropriate layer directories (references/, recipes/, scripts/, assets/, learnings/, registry/) are exposed — publish-internal files never leak. Reads come from the catalog bundle, so they work for skills you have not installed. To actually run an API skill's tools, you still install it (marketplace) or reach it server-side via the MCP server — this endpoint is for reading guidance, not executing.

Verifying a downloaded bundle. When you download a skill for a desktop AI app, you can confirm it was signed by the vendor it claims. Fetch the vendor's public key by fingerprint:

GET /api/v1/registry/certificates/{fingerprint}

This is a public read of signature-verification material only (a vendor public key — never any private-key bytes). The CLI does this automatically when it installs a skill.

Installing a package

Only brand admins can install. The install wizard has 5 steps:

1. Manifest review — see the package name, vendor, version, tier, and a summary of what it does.
2. Grant permissions — tick boxes for each capability (required entitlements are pre-checked, optional ones are up to you).
3. Connect credentials — OAuth tokens, API keys, or webhooks the package needs. If you don't have a credential, the dashboard sends an invite email to a teammate to connect it on your behalf; the package waits in pending state until it's connected.
4. Gateway reload — OPVS pushes the new tools to your agents.
5. Done — package state flips to active; your agents can use the tools on their next turn.

Meta-packages like @opvs-ai/platform-skills fan out automatically. One click creates one row for the meta itself and one row for each peer package (the @opvs-ai/platform-skills meta expands to 8 rows).

Managing installed packages

Visit /dashboard/marketplace/installed to see everything your brand has installed.

Action	Where	Effect
View package detail	Click any package	Shows granted entitlements, credential status, health check
Revoke an entitlement	Detail → Permissions tab	Tool loses that permission on next gateway reload
Upgrade version	Detail → top banner	Appears when a newer semver-compatible version publishes
Per-agent opt-out	Detail → Agents tab	Exclude specific agents from using this package's tools
Uninstall	Detail → Danger tab	Confirm typed slug; disables the package (non-cascading — peers stay active)

Revocation is non-transitive: uninstalling @opvs-ai/platform-skills (the meta) does not automatically uninstall its peers. Each peer is its own lifecycle.

Health and upstream status

Every installed package has a doctor endpoint that tells you in one call whether the package is actually usable right now: credentials present, entitlements granted, upstream service reachable, latency OK, no known incidents. Access via GET /api/v1/skills/{skill_id}/doctor or watch the health chip on the package detail page.

Results are cached for 60 seconds so repeated checks are cheap.

Publishing packages (for vendors)

OPVS supports third-party vendors publishing their own skill packages. If you're a vendor interested in publishing:

• Email ops@opvs.ai to receive the vendor guide and get a signing certificate minted.
• Use the @opvs-ai/skills CLI (opvs-skills publish) to scaffold, validate, sign, and publish packages from your repo.
• Each publish goes through the same 7-check security review; publishes below the beta score threshold or failing any blocking check are rejected with actionable findings.

Catalog curation

OPVS curates the customer-facing presentation of every package — the hero image, screenshots, long description, features list, demo video, and author block. The signed manifest stays immutable; the curation overlay only ever wins on those six presentation keys, and every edit is audited. Tier, entitlements, signature, and runtime behaviour come from your manifest unchanged.

FAQ

Does installing a package slow down my agents? No. Tools are registered at gateway startup; runtime tool calls cost the same whether the gateway has 10 tools or 10,000.

Can I revoke a package after installing? Yes, instantly. The revocation poll picks up state changes within 60 seconds and every gateway in your brand drops the tools.

What happens if a vendor's cert gets compromised? OPVS operators revoke the vendor's certificate. Every package signed by it is marked revoked across the registry; gateways stop serving those tools within 60 seconds.

Why don't I see new tools in my IDE (Claude Code, Cursor) after installing? The marketplace delivers tools to your brand's OPVS-hosted agents, not to your local IDE. IDE access is via the MCP server and CLI, which ship their own pre-built tool set. The two channels are independent today.

Can I test a package before installing in production? Use a staging brand. Each brand has its own entitlement state, so installing in one brand doesn't affect another.

What semver range does install match? Default is the latest published version in the tier you're installing from. Explicit pins (e.g. @1.0.2) are honored; ranges like ^1.0.0 match the highest compatible version.