> ## Documentation Index > Fetch the complete documentation index at: https://agent.minimax.io/docs/llms.txt > Use this file to discover all available pages before exploring further. # Plugin Development and Submission Guide > Capability choices, package layout, manifest fields, Skills and MCP servers, size limits, and the submission process for MiniMax Plugins.
**Current submission scope (2026-09-08):** The third-party form currently accepts App, MCP, and Skill capabilities. When submitting, choose **Desktop (MiniMax Code)**, **Cloud (MiniMax Agent)**, or both. Delivery target and target region (CN/US) are independent dimensions. Delivery targets are managed in the Marketplace catalog and are not written to `plugin.json` inside the Plugin package. You can submit a ZIP file or a public GitHub repository. For GitHub, you may specify a branch, tag, commit, or Plugin subdirectory. Both source types follow the same validation, review, and publishing process. You must use the same Feishu account used for the original submission and provide the submission\_id and submission email. Once all three match, the result will be sent through a Feishu message. ## 1. Choose the capabilities to provide | Capability | Use cases | How to integrate | | - | - | - | | **Skill** | Provide the Agent with domain knowledge, operating procedures, and usage guidance | Place it directly at `skills//SKILL.md` in the Plugin | | **MCP** | Provide local or remote MCP tools that do not require MiniMax-managed user authorization | Place and reference `*.mcp.json` directly in the Plugin | | **App** | Integrate remote MCP through MiniMax Connector: OAuth accounts, user-entered API keys/tokens, or platform-managed services that require no user credentials. User-authorized integrations include connection status, reconnect, and disconnect flows. | Contact MiniMax before submission and complete Connector configuration and joint testing under the App (MCP Server) integration requirements. MiniMax will confirm the provider before the Plugin is created. | **Do not include OAuth credentials, access tokens, refresh tokens, client secrets, or API keys in a Plugin.** Capabilities that require user identity must first be integrated through App/Connector. If you are unsure whether a capability should be an App or a regular MCP, contact the MiniMax technical representative before submitting. A Plugin may contain only one capability type or combine App, MCP, and Skill capabilities, and must contain at least one capability. The current third-party intake does not accept the `hooks` manifest field or Hook JSON files. Packages in other plugin formats must first be converted to the package format in this guide. Desktop support for directly importing other formats does not mean those formats are accepted by this submission form. ## 2. Standard directory structure ```plaintext theme={null} acme-research/ .minimax-plugin/ plugin.json icon.png research.mcp.json calendar.app.json skills/ literature-review/ SKILL.md # Other ordinary files referenced by a Skill or MCP ``` * The ZIP root must directly contain `.minimax-plugin/plugin.json`. Do not wrap the Plugin in an additional top-level directory inside the ZIP. * File names and paths may contain only ASCII letters, digits, periods, underscores, and hyphens. Use `/` as the path separator. * Symlinks, hard links, Git LFS pointers, Git submodules, package installation lifecycle scripts (`preinstall`, `install`, or `postinstall` in `package.json`), platform-specific native binaries, and files that depend on the executable bit are not accepted. Portable Skill/MCP scripts may be included and run through an explicit interpreter. * Text files must use UTF-8 without a BOM. JSON files must be objects and must not contain duplicate keys. ## 3. Write the Plugin manifest `.minimax-plugin/plugin.json` is the package entry point. The following example contains both MCP and Skill capabilities. Use an empty array for any capability that is not included. ```json theme={null} { "schemaVersion": 1, "name": "acme-research", "displayName": "Acme Research Assistant", "version": "1.0.0", "description": "Search research materials and generate structured reviews.", "author": "Acme", "icon": "icon.png", "category": "Science & Healthcare", "exampleQueries": [ "Find recent research and summarize the main findings", "Generate a literature review from these materials" ], "apps": [], "mcpServers": ["research.mcp.json"], "skills": ["skills/literature-review/SKILL.md"] } ``` | Field | Requirements | | - | - | | `name` | A lowercase machine name of up to 80 characters. It must begin with a letter and may use digits and `._-` as separators, for example `acme-research`. | | `version` | A SemVer version, for example `1.0.0`. Increment it whenever any package content changes. An update that changes only Catalog `deliveryTargets` may keep the version if the package content is identical. First-time submission to another region uses the new-Plugin operation; see Section 8. | | `displayName` | Optional. A short, clear user-facing name; if omitted, `name` is used. If provided, it must be non-empty after trimming whitespace and must not exceed 1,024 UTF-8 bytes. | | `description` | Describe the problem the Plugin solves, without describing internal technical implementation. | | `author` | The name of the developer, team, or company. If provided, it must be non-empty after trimming whitespace and must not exceed 1,024 UTF-8 bytes. | | `icon` | A relative path within the package. Only lowercase `.png`, `.jpg`, `.jpeg`, and `.webp` extensions are supported. Use a clear, square, production-ready icon. Production publishing currently accepts `icon` only: omit `darkIcon` entirely, including empty or `null` values. | | `category` | Select one of the fixed categories listed below. | | `exampleQueries` | 0–3 realistic examples. Each entry must be non-empty and contain no more than 4,096 characters. | | `apps / mcpServers / skills` | Use relative paths within the package. Capabilities that are not used must remain as empty arrays. Do not add `deliveryTargets`, `installationPolicy`, `listed`, or ordering fields to `plugin.json`. The submission form provides no display-order, listing-status, or default-installation setting. | **Available categories:** `Office`, `Studio`, `Design & Sites`, `Code`, `Business`, `Sales`, `Productivity`, `Science & Healthcare`, `Education`, and `Other`. ## 4. Add a Skill Place each Skill at `skills//SKILL.md` and reference it in the manifest's `skills` array. The file must begin with YAML frontmatter: ```markdown theme={null} --- name: literature-review description: Search, screen, and summarize research materials to produce a structured literature review. --- First confirm the research topic, time range, and output format. After retrieving the materials, organize them by research question, methodology, main findings, and limitations... ``` * `name` must exactly match the Skill directory name, and `description` must not be empty. * The body must contain complete instructions that the model can execute directly, rather than only promotional copy. * Templates, references, and scripts used by the Skill must be included in the package and referenced with relative paths. * Skill names must be unique within a Plugin. At runtime, a Skill is exposed as `:` to avoid conflicts with other Plugins. ## 5. Add MCP Each `*.mcp.json` file may declare one or more MCP Servers and must be referenced in the manifest's `mcpServers` array. ```json theme={null} { "schemaVersion": 1, "mcpServers": { "acme-search": { "type": "streamable-http", "url": "https://mcp.acme.example/mcp", "description": "Search the public Acme knowledge base", "timeout": 30000 } } } ``` ```json theme={null} { "schemaVersion": 1, "mcpServers": { "local-analyzer": { "type": "stdio", "command": "python3", "args": ["./server.py"], "description": "Analyze local input files", "timeout": 30000 } } } ``` * `stdio`, `streamable-http`, and `sse` are supported. The `http` alias is not supported. * `timeout` is the timeout for a single tool call, in milliseconds. For example, `30000` means 30 seconds. If omitted, the runtime default is used. * `stdio.command` may contain only the name of an interpreter or executable available on PATH; it must not contain a path. Reference scripts in the package through relative `args`. * A remote MCP must use a real, stably accessible HTTP(S) endpoint. Complete `initialize`, `tools/list`, and `tools/call` validation before submitting. * Do not place any secret or user credential in `headers`, `env`, or any other file. If authentication is required, contact MiniMax first to evaluate App/Connector integration. ## 6. Prerequisites for App integration Do not place OAuth parameters, API keys, or other authentication data directly in a Plugin. First provide a remote MCP Server that follows the [MiniMax App (MCP Server) Integration Guide](https://vrfi1sk8a0.feishu.cn/wiki/HPtLwSJnHi2KMWkgUtfcWnk8nDc). MiniMax must complete Connector configuration and joint testing for every target region and confirm a stable `provider`. Static submission checks do not verify live Connector availability. After integration is complete, MiniMax will confirm the following reference file: ```json theme={null} { "schemaVersion": 1, "provider": "acme" } ``` Prepare the following before contacting MiniMax: test and production MCP endpoints, transport, suggested provider and display metadata, target regions, authentication mode, test credentials, rate limits, and error documentation. For OAuth, also provide issuer, discovery metadata, scope/resource, DCR/PKCE support, and callback requirements. For API keys or tokens, provide form fields, a static HTTPS acquisition link, and Header mappings. Standard configuration-only integration supports remote MCP servers that require no user credential; OAuth MCP with Authorization Code + PKCE S256, DCR, and refresh tokens; and non-OAuth MCP where users enter API keys or tokens and Connector injects them through controlled HTTP Header templates. New integrations should use HTTPS Streamable HTTP. Fixed client secrets, query/body/cookie authentication, or dynamic request signing require separate evaluation. ## 7. Package Size and Security Limits | Item | Limit | | - | - | | Original ZIP size | 64 MiB | | ZIP entries (including directories) | 2,048 | | Regular files | 1,024 | | Uncompressed size per file | 16 MiB | | Total uncompressed size of all regular files | 64 MiB | | Full path / individual path segment / path depth | 512 bytes / 128 bytes / 16 segments | Use a standard ZIP structure without a wrapper directory. Uploaded source packages may use unencrypted STORE or DEFLATE compression. The system rejects path traversal, absolute paths, backslashes, Unicode filenames, case conflicts, Windows reserved names, special files, and encrypted ZIP files, and enforces the file-count and size limits listed above. After validation succeeds, the system normalizes the contents into a deterministic, STORE-only Marketplace package. ## 8. Submit a New Plugin or an Update 1. In the submission form, select either “Submit a new Plugin” or “Update an existing Plugin,” then select the target region (CN/US) and delivery target (desktop/cloud; multiple selections are allowed). 2. Choose a source and complete only the corresponding fields. For a ZIP submission, the ZIP root must directly contain `.minimax-plugin/plugin.json`. For a GitHub submission, provide the public repository root URL and optionally a Ref and Plugin subdirectory. The system freezes the submitted source so that the same content is used throughout review and release. 3. When updating an existing Plugin, `name` must remain unchanged and proof of maintenance authorization must be provided. Increment `version` whenever package contents change. The version may remain unchanged when only Catalog `deliveryTargets` changes and the package contents are identical. First-time submission to another region still uses the new-Plugin operation. The system-generated MR diff shows the exact changes, so no separate change summary is required. 4. Save the `submission_id` after the submission succeeds. The system normalizes the source and runs script validation. If validation fails, the reason is written back to the record and sent proactively through a Feishu message. AI pre-review is an optional capability that is currently disabled and does not prevent the workflow from continuing. 5. After script validation passes, the system automatically creates a Release MR targeting the CN and/or US Marketplace `main` branch according to the selected region, and provides the MR link in the human-review group card. Reviewers inspect the MR diff, Markdown validation report, icon, and CI directly. After confirming that everything is correct, the repository owner merges the MR. 6. After the MR is merged, the Marketplace `main` Pipeline automatically packages and distributes the Plugin. Intake tracks the release job, updates the status to “Publishing,” “Published,” or “Publishing failed,” and proactively sends a Feishu message. To query the status, use the same Feishu account that made the submission and provide the `submission_id` and submission email address. **Submitting to multiple regions:** The selected operation applies to every target region in the submission. If a Plugin already exists in CN but is being submitted to US for the first time, submit two separate requests: an update for CN and a new Plugin for US. **Publishing and listing are separate:** “Published” describes the package distribution result, not its current Marketplace visibility. MiniMax manages display order and listing status independently. A newly published name is listed by default; this does not mean it is automatically installed. Updating an existing Plugin preserves its listing status, and updating a delisted Plugin does not relist it. Delisting does not reset a user's installation, uninstallation, enablement, or disablement choices. Relisting restores availability while preserving those choices. Clients apply the latest status during existing refresh flows, so the change may not take effect immediately on every client. The submission-status form does not read the current listing status. If a published Plugin is not visible, contact MiniMax with your `submission_id` and target region. ## 9. Pre-submission Checklist * [ ] The ZIP root or the specified GitHub subdirectory directly contains `.minimax-plugin/plugin.json` * [ ] `name`, the package directory, and the manifest are consistent; if package contents have changed, the version number has been incremented * [ ] The icon, name, description, category, and no more than three example queries are all production-ready content * [ ] The Plugin contains at least one capability, and all App, MCP, and Skill files are referenced by the manifest * [ ] Skill frontmatter is complete, and MCP endpoints/commands have been verified * [ ] The package contains no tokens, secrets, personal data, package installation lifecycle scripts (`package.json` entries: `preinstall`, `install`, or `postinstall`), symlinks, or platform-specific binaries. Any portable Skill/MCP scripts use an explicit interpreter. * [ ] You have the right to submit and distribute the code, copy, icons, and referenced materials * [ ] If the Plugin contains an App, you have contacted MiniMax in advance and confirmed the Connector provider ## 10. Common Reasons for Rejection * The ZIP contains an extra wrapper directory, the GitHub subdirectory is incorrect, or the target root is missing `.minimax-plugin/plugin.json`. * The Plugin name, version, paths, JSON Schema, or Skill frontmatter does not comply with the specification. * Capability files are not referenced by the manifest, or the manifest references files that do not exist. * An MCP uses an unsupported transport, absolute paths, platform-specific dependencies, or contains OAuth credentials/secrets. * The App provider has not completed Connector integration, or the target environment has not been verified. * Example queries, descriptions, or icons still contain test content, or copyright, privacy, or data-compliance information is incomplete. * An update changes package contents without incrementing the version, maintenance authorization cannot be proven, or the MR diff reveals an incompatible change. ## 11. Data Retention and Communication * Frozen submission packages, script validation reports, and optional AI pre-review reports in GitLab are retained for 180 days. Operational records and attachments in Feishu Base are not cleaned up automatically; they are retained according to the platform’s current behavior and are handled manually by the owner when there is a genuine operational need. * Do not include production secrets, user tokens, or unnecessary personal sensitive information in the submission package or form. * AI pre-review is an optional efficiency feature that is currently disabled. Whether or not it is enabled, the final listing decision is made by MiniMax human reviewers. * Specifications and validation rules may evolve with the platform. Refer to the current version of this guide and the automated validation results produced after submission. Passing automated prechecks does not guarantee acceptance: human review and production Marketplace CI validation are still required.