Permission grant flow

확대

Items reviewed from the manifest

• capabilities: format-validated capability tags. The host's runtime enforcement set holds exactly two ids, and a string outside that set does not open one of those two gates. But "not a gate" is not the same as "no effect" — there are places where the host uses one of these strings as a lookup key to find which plugin fills a role, so a single declaration can be what wires that role's whole tool surface to that plugin.
• tools[]: pure MCP Tool objects. The Host classifies risk from each input schema and execution path; signed operation policy may only raise the minimum risk or require read-before-write.
• pluginAccess: which other plugin's tools/events this plugin will use (e.g. work-assistant calling ms-graph's msgraph_calendar_today).
• agentApprovalScopes: standard labels for cross-plugin risky actions (e.g. agent_file_share, agent_task_delegate, agent_external_api_call).
• hostSecrets / llmKeySource: secret access / LLM key vendor declarations.
• configSchema: user-editable config fields + defaults.

What the user sees

1. 01

   Deeplink from Marketplace

   The "Install" button on the web page fires lvis://install/<slug> or lvis://install/<type>/<slug>. The host receives and handles the URL (src/main/lvis-protocol.ts).

2. 02

   Package + signature verification

   sig

   The host verifies the Ed25519 signature envelope issued by the Marketplace. It passes once at least one signature matches a known public key (marketplace/server/src/lvis_marketplace/signing.py).

3. 03

   Permission dialog — everything at once

   The parsed manifest is grouped by category — capabilities / tools / pluginAccess / secrets — and shown together. The grant is saved once the user confirms.

4. 04

   First activation

   start()

   Its own namespace ~/.lvis/plugins/<pluginId>/ is created (0o700). The validated Skills, Hooks, and MCP servers are activated atomically with the plugin runtime.