# Kimi Code Plugin Marketplace Architecture and Distribution Model Explained

> Explore the Kimi Code plugin marketplace architecture and distribution. Learn how to discover and manage extensions easily through GitHub repositories, ZIP URLs, or local paths. Get started today.

- Repository: [Moonshot AI/kimi-code](https://github.com/MoonshotAI/kimi-code)
- Tags: architecture
- Published: 2026-07-26

---

**Kimi Code provides a built-in plugin marketplace that uses a manifest-driven, MCP-backed architecture to enable users to discover, install, and manage extensions via GitHub repositories, ZIP URLs, or local paths.**

The **Kimi Code plugin marketplace architecture** is implemented across the MoonshotAI/kimi-code repository as a multi-layered system that separates contract definitions, high-level APIs, and low-level service implementations. This design allows the CLI and TUI to extend core functionality with third-party skills, MCP servers, and data sources while maintaining strict validation and security controls.

## Core Architecture Components

### Plugin Manifest Schema

Every plugin in the marketplace must conform to a strict **manifest schema** defined in [`packages/klient/src/contract/global/plugins.ts`](https://github.com/MoonshotAI/kimi-code/blob/main/packages/klient/src/contract/global/plugins.ts). This TypeScript contract specifies required metadata including `author`, `commands`, `interface`, and `source type`, creating a standardized interface that the marketplace can consume and validate.

The manifest serves as the single source of truth for plugin capabilities, ensuring that the CLI can parse plugin functionality before execution.

### Plugin Source Types

The distribution model supports three distinct **source types** enumerated in the same contract file (lines 69-71):

- **`github`** – References a public or private GitHub repository
- **`zip-url`** – Points to a downloadable ZIP archive containing the plugin
- **`local-path`** – Specifies a filesystem path for local development and testing

These source types determine how the `IPluginService` implementation fetches and verifies plugin contents during installation.

### Global Plugins Facade

The high-level API exposed to users resides in [`packages/klient/src/core/facade/global.ts`](https://github.com/MoonshotAI/kimi-code/blob/main/packages/klient/src/core/facade/global.ts) (methods 393-404). This **Global Plugins Facade** provides intuitive methods including `list()`, `info()`, `installPlugin()`, and `setPluginEnabled()` that abstract the underlying RPC communication.

When users invoke marketplace commands through the CLI, they interact with this facade, which translates user actions into service calls sent to the agent core.

### Core Service Implementation

At the server level, the `IPluginService` interface defined in [`packages/agent-core/app/plugin/plugin.ts`](https://github.com/MoonshotAI/kimi-code/blob/main/packages/agent-core/app/plugin/plugin.ts) handles the **low-level plugin lifecycle**. This service manages loading, validation, activation, and error recovery for all installed plugins, ensuring that malformed or incompatible extensions cannot crash the core system.

### Event-Driven Lifecycle

Plugin state changes propagate through a dedicated **event system** defined in [`packages/protocol/src/events.ts`](https://github.com/MoonshotAI/kimi-code/blob/main/packages/protocol/src/events.ts) (schemas 62-64, 1469-1472). Key events include:

- `plugin_command.activated` – Fired when a user invokes a plugin command
- `plugin.not_found` – Triggered when a referenced plugin is missing
- `plugin.load_failed` – Indicates initialization or runtime errors

These events enable the TUI to provide real-time feedback and error handling without blocking the main execution thread.

## Distribution Model and Installation Flow

### Marketplace Discovery

The CLI discovers available plugins by calling `global.plugins.list()`, which executes the `pluginService.listPlugins` RPC against configured MCP servers. By default, Kimi Code queries the Moonshot AI public server, though users can configure alternative MCP servers for private or enterprise plugin repositories.

### Installation Sources

When users execute `installPlugin({ source })`, the system processes one of three distribution methods:

1. **GitHub repositories** – The server clones the repo, extracts the manifest from the root directory, and validates the plugin structure before copying files to the local storage.

2. **ZIP archives** – Direct download URLs trigger an unpacking sequence where the server verifies archive integrity and extracts contents to the plugin directory.

3. **Local filesystem paths** – Development mode allows loading plugins directly from `~/.kimi-code/plugins/<plugin-id>` without network transfer, enabling rapid iteration.

### Verification and Trust Levels

Each manifest includes `source` metadata and optional `author` fields that the CLI evaluates to assign **trust levels**: "official", "community", or "untrusted". Before installation completes, the interface displays these classifications, requiring explicit user confirmation for non-official sources.

Error states surface through the protocol events, allowing the UI to present actionable recovery options when `plugin.load_failed` or validation errors occur.

### Runtime Activation

Once installed, plugins register their **commands** (slash commands and skill hooks) with the agent core. When invocation occurs, the server emits `plugin_command.activated`, which [`packages/transcript/src/history/groupTurns.ts`](https://github.com/MoonshotAI/kimi-code/blob/main/packages/transcript/src/history/groupTurns.ts) treats as a genuine user prompt in the conversation history. This ensures that plugin actions appear in context with natural language interactions.

## MCP Integration Architecture

The marketplace leverages the **Model Context Protocol (MCP)** to enable collaborative distribution across environments. As defined in [`packages/klient/src/contract/mcp.ts`](https://github.com/MoonshotAI/kimi-code/blob/main/packages/klient/src/contract/mcp.ts), plugins can attach to MCP servers and expose their capabilities through the `/mcp-config` command interface. This architecture allows teams to share curated plugin sets across organizations while maintaining centralized governance.

## Working with the Plugin API

The following examples demonstrate interacting with the marketplace architecture programmatically:

```typescript
// List all plugins available from the configured MCP server
const plugins = await klient.global.plugins.list();
console.log('Marketplace plugins:', plugins);

```

```typescript
// Install a plugin from a GitHub repository
await klient.global.plugins.installPlugin({
  source: 'github',
  url: 'https://github.com/example/example-plugin',
});

```

```typescript
// Enable or disable a plugin after trust verification
await klient.global.plugins.setEnabled({
  id: 'example-plugin',
  enabled: true,
});

```

These operations trigger the full lifecycle: validation against the manifest schema, storage in the local plugin directory, registration with the service layer, and event propagation to the UI components.

## Summary

- The **Kimi Code plugin marketplace** implements a manifest-driven architecture defined in [`packages/klient/src/contract/global/plugins.ts`](https://github.com/MoonshotAI/kimi-code/blob/main/packages/klient/src/contract/global/plugins.ts) that standardizes plugin metadata and capabilities.
- Distribution supports **three source types** (`github`, `zip-url`, `local-path`) handled by the `IPluginService` implementation in [`packages/agent-core/app/plugin/plugin.ts`](https://github.com/MoonshotAI/kimi-code/blob/main/packages/agent-core/app/plugin/plugin.ts).
- The **Global Plugins Facade** in [`packages/klient/src/core/facade/global.ts`](https://github.com/MoonshotAI/kimi-code/blob/main/packages/klient/src/core/facade/global.ts) provides high-level APIs that abstract RPC communication for CLI and TUI consumers.
- **Event-driven lifecycle management** via [`packages/protocol/src/events.ts`](https://github.com/MoonshotAI/kimi-code/blob/main/packages/protocol/src/events.ts) ensures real-time UI feedback for activation, errors, and loading states.
- Plugins integrate with the **Model Context Protocol** to enable team-based distribution and centralized configuration management.
- Runtime activation treats plugin commands as first-class conversation participants, recorded in transcript history through [`packages/transcript/src/history/groupTurns.ts`](https://github.com/MoonshotAI/kimi-code/blob/main/packages/transcript/src/history/groupTurns.ts).

## Frequently Asked Questions

### How does Kimi Code validate plugin security before installation?

Kimi Code validates plugins through a multi-stage process: the server parses the **manifest schema** to verify structural integrity, checks the `source` type against allowed protocols, and assigns trust levels based on author metadata. The CLI displays these trust classifications ("official", "community", or "untrusted") before completing `installPlugin()`, requiring explicit user confirmation for non-official sources. Errors during validation trigger `plugin.load_failed` events with detailed diagnostics.

### Where are Kimi Code plugins stored on the local filesystem?

Installed plugins are stored under the user-specific Kimi Code data directory at `~/.kimi-code/plugins/<plugin-id>`. This location persists across sessions and serves as the root for the `local-path` source type during development. The `IPluginService` manages this storage layer, handling extraction from ZIP archives or GitHub clones before validation.

### What is the relationship between MCP servers and the plugin marketplace?

The **Model Context Protocol (MCP)** serves as the distribution backbone for the marketplace. While individual plugins run locally, the `global.plugins.list()` method queries configured MCP servers to discover available extensions. Organizations can host private MCP servers to distribute internal plugins through the same `installPlugin()` interface used for public GitHub repositories, enabling centralized governance of approved extensions.

### Can plugins be activated and deactivated without uninstalling?

Yes. The **Global Plugins Facade** exposes `setPluginEnabled({ id, enabled })` which toggles plugin availability without removing files from `~/.kimi-code/plugins/`. This allows users to temporarily disable plugins that conflict with specific workflows while preserving configuration data. Disabled plugins remain in the local registry but do not register their commands with the agent core until re-enabled.