Skip to content

Pre-Install Plugin Transparency: Capability Inventory and Cost Projection

Pre-install plugin transparency is a two-column marketplace contract — a static capability inventory of every command, agent, skill, hook, and MCP or LSP server the plugin will install, beside its projected per-turn token cost — rendered before the operator commits.

Pre-install plugin transparency surfaces two facts beside the install button: what the plugin adds (capability inventory) and how much context it costs (cost projection). Claude Code v2.1.145 (2026-05-19) shipped the inventory half — a Will install section listing commands, agents, skills, hooks, and MCP and LSP servers (Discover and install plugins). The cost half landed in v2.1.143 (2026-05-15) and is treated in pre-install context-cost projection; the two columns are one contract.

When the Contract Earns Its Place

  • Operator comparison-shops in the browse pane. claude plugin install <name>@<marketplace> and README-link installs bypass the disclosure (Discover and install plugins).
  • Inventory or cost differs meaningfully between candidates. Two security plugins each shipping one MCP server and two skills do not differentiate on the inventory column.
  • A downstream budget gate exists. Without a per-session quota, runtime warning, or eval, awareness rarely changes behaviour. The Android permissions evidence is canonical: 17% of users paid attention to pre-install permission listings and only 3% answered comprehension questions correctly (Felt et al., SOUPS '12). Disclosure without enforcement is default-ignored.

The Two Columns

Column What it answers Reference implementation
Capability inventory Which commands, agents, skills, hooks, MCP servers, and LSP servers will this plugin add? /plugin Discover/Browse Will install section, v2.1.145 (Discover and install plugins)
Cost projection How many tokens will it cost per turn? /plugin Browse Context cost estimate, v2.1.143 (Claude Code changelog)

The inventory column answers a precision question — exactly which components arrive — and the cost column a budget question. Collapsing them to one number erases two independent decision axes.

How the Host Derives the Inventory

The harness owns the registry of every component a plugin contributes — skills in skills/, agents in agents/, hooks in declared paths, MCP and LSP servers in manifest entries (Plugins reference). Marketplace catalogues cache the manifest, so the same enumeration that resolves a skill at invocation time can list components before any plugin code runs. No plugin sandbox is started.

graph LR
    M["Plugin manifest"] --> R["Marketplace registry"]
    R --> I["Will install (v2.1.145)"]
    R --> C["Context cost (v2.1.143)"]
    I --> B["Browse pane: capabilities"]
    C --> B2["Browse pane: tokens/turn"]

LSP servers joined claude plugin details in v2.1.141 and the same component model in v2.1.145; future component types like background monitors inherit the convention without protocol changes.

Why It Works

Registry ownership makes both columns precise. The harness reads each component from a typed manifest slot, so the inventory is what the plugin will contribute, not what the marketplace claims (Plugins reference). The OS package-manager precedent is identical: apt show reads the same database dpkg consults at install, so the pre-install view matches post-install reality. The contract moves the what and how much signals from the post-install accountability moment — when the only remediation is uninstall — to the choice moment, when remediation is picking a lighter alternative for free.

When This Backfires

  • CLI bypass. claude plugin install <name>@<marketplace> does not render either column; operators installing from peer recommendations or repo READMEs never see the disclosure (Discover and install plugins).
  • Disclosure-fatigue baseline. The Felt et al. result generalises: pre-install listings are read by a small minority. Without a budget primitive — a token cap, a hook that blocks install over a threshold, an eval that fails on regression — the inventory is decoration (Felt et al., SOUPS '12).
  • MCP-server-heavy plugins. An MCP server entry hides dynamic tool surface area — servers return varying tool sets per session, and the static listing names the server, not the tools (apideck — MCP context window cost). Operators undercount exposure.
  • Cost-API fallback. When the tokenizer API is unreachable, the cost column falls back to a character-based estimate that distorts rankings (Plugins reference). The inventory stays accurate; the cost column drifts.
  • Comparable ecosystems do not ship it. The Visual Studio Marketplace has had an open feature request for install-size disclosure since 2022 without resolution — operating without the contract is feasible, so the disclosure is a deliberate design choice, not table stakes.
  • Single-plugin install, no comparison. A user installing one specific plugin for one task does not benefit from a comparison surface — the contract pays off only when alternatives are evaluated side by side.

Example

The Claude Code /plugin Discover view renders both columns in the plugin detail pane (Discover and install plugins):

security-guidance 1.2.0
  Real-time security analysis for Claude Code sessions
  Source: security-guidance@claude-code-marketplace

Context cost
  Always-on:  ~180 tok added every turn

Will install
  Commands:    /security:scan
  Agents:      security-reviewer
  Skills:      scan-dependencies, review-changes
  Hooks:       PreToolUse on Edit
  MCP servers: cve-lookup

Comparing security-guidance against an alternative that adds 800 tokens always-on and ships three more skills plus two more hooks shows both the 620-token cost gap and four extra components — neither observable post-install without paying both costs and running claude plugin details (Plugins reference).

The reverse case sharpens the limit: two plugins each showing 150 tokens and a single skill differ by rounding noise on both columns. The contract does not break the tie — functionality fit, vendor trust, or MCP server target decides.

Key Takeaways

  • Pre-install plugin transparency is two manifest reads — capability inventory plus cost projection — rendered beside the install button before the operator commits (Claude Code changelog v2.1.143, v2.1.145).
  • The inventory column lists commands, agents, skills, hooks, and MCP and LSP servers; the cost column projects per-turn tokens. Treat them as independent decision axes (Discover and install plugins).
  • The harness owns the component registry, so the same enumeration drives invocation and disclosure — pre-install view matches post-install reality without running plugin code (Plugins reference).
  • The contract pays off only when operators comparison-shop in the browse pane, candidates differ meaningfully, and a downstream budget primitive exists — Android permission disclosure shows pre-install listings without enforcement are read by ~17% of users (Felt et al., SOUPS '12).
  • CLI installs and MCP-server-heavy plugins are the dominant blind spots — the disclosure surface is bounded by the install path and by static-vs-dynamic surface area.
Last reviewed: 2026-05-27
Feedback