Plugin Store Guidelines

npx -p @enconvo/api enconvo plugin validate            # the store's rules
npx -p @enconvo/api enconvo plugin validate --openai   # also OpenAI's portal rules
npx -p @enconvo/api enconvo plugin scan                # starts the MCP server and checks its tools

​

Purpose and quality

• The plugin does something useful that Enconvo can’t already do, and does it completely. Placeholder, demo-only or trial versions are turned down.
• It behaves predictably. When something fails, such as a network error, a missing permission or a bad input, it says what happened instead of failing silently.
• It uses only code, names, icons and content you own or are licensed to use. It doesn’t impersonate another product, and doesn’t suggest that Enconvo or anyone else endorses it.

​

Name, description and listing

• Name and title: clear and specific. Avoid a generic single word, and don’t add “MCP”, “MCP Server” or “Plugin” to a company name.
• Description: says what the plugin does, accurately. No comparisons with other products, claims you can’t back up, or prices, discounts and free-trial offers.
• Icon and screenshots: the icon is a PNG, JPEG, WebP or GIF of up to 5 MB. Up to 8 screenshots go in a metadata/ folder and are shown in file name order. They show the plugin as it really works.
• Support: give people a way to reach you: interface.websiteURL and interface.supportURL, or homepage or repository for the website. A Claude Code plugin can use its supportUrl and documentationUrl instead. The store page shows these links before anyone installs the plugin.
• Version: raise it for every update. While an update is in review, the store keeps offering the version before it. plugin publish asks the store which version it released before it builds or uploads anything, and stops with the next version to use when yours isn’t higher.

​

MCP tools

• Names are plain verbs that say what the tool does, such as get_order_status, and are unique within the server. No jargon or unexplained abbreviations.
• Descriptions explain what the tool does, what it changes and what it can’t do, and match its input schema and real behavior. They don’t tell the model to prefer this plugin, to call other plugins, or to call the tool for everything.
• One operation per tool, each with its own input schema.
• Annotations are set explicitly on every tool:

​

Data and privacy

• Ask only for what the task needs. Tool inputs are specific to the task. Don’t ask for the whole conversation, earlier messages or broad profile data “just in case”.
• Return only what answers the request. Leave internal ids, trace data and debugging output out of tool results.
• Never collect payment card data, health records, government ids such as social security numbers, or passwords, API keys and one-time codes through tool inputs. Credentials go in the plugin’s preferences, where Enconvo keeps them.
• Privacy policy. A plugin that sends data to a server needs a published privacy policy saying what it collects, why, who receives it, how long it is kept and how people can delete it. Put its address in interface.privacyPolicyURL, and the terms of service, if you have them, in interface.termsOfServiceURL. The store page links both.
• No tracking of people, their queries or their usage beyond what the plugin needs to work and what its privacy policy discloses.
• Keep secrets out of the package. Anyone can download it. .env files are left out automatically, but check that no other keys or private files end up in it.

​

Sign-in and test accounts

npx -p @enconvo/api enconvo plugin publish --review-notes "Sign in as review@example.com with the password …"

​

Commerce

​

Safety

• The plugin is suitable for a general audience, including teenagers, and doesn’t target children under 13.
• It does what the user asked and nothing else: no unrelated content, redirects or ads.
• Its descriptions, prompts and skills never ask for secrets, move money or data without the user’s say, try to override Enconvo’s safeguards, or hide what the plugin does, including through encoded instructions.
• It doesn’t scrape websites or wrap other services against their terms, or get around their rate limits and access controls.
• It doesn’t sell or enable anything in OpenAI’s list of prohibited goods and services, such as weapons, drugs, gambling, adult content, malware or financial fraud.

​

Review materials

{
  "name": "notes",
  "version": "1.2.0",
  "extensions": {
    "com.openai": {
      "review": {
        "test_cases": {
          "positive": [
            {
              "description": "Finds a note by topic",
              "prompt": "Find my notes about the Q3 launch",
              "tools_triggered": "search_notes, read_note",
              "expected_behavior": "Lists the matching notes and quotes the most relevant one"
            }
          ],
          "negative": [
            { "description": "Unrelated question", "prompt": "What's the weather in Paris?" }
          ]
        },
        "demo_recording_url": "https://example.com/notes-demo.mp4",
        "commerce": false
      },
      "publication": {
        "release_notes": "Search now matches note titles."
      }
    }
  }
}

​

Submission checklist

• plugin validate reports no errors, and you have read its warnings.
• version is higher than the last version you published, and every manifest in the package gives the same name and version.
• For an update, plugin validate --previous with the zip of the release before it reports nothing you didn’t mean: an update replaces the whole plugin, so a skill or MCP server it leaves out is removed (plugin_components_removed).
• The title, description and icon say what the plugin does, and the screenshots show it working.
• A homepage or support address is set, and a privacy policy is linked if the plugin sends data anywhere.
• Every MCP tool has a clear name and description and sets readOnlyHint, destructiveHint and openWorldHint, and plugin scan lists them without problems.
• Skills say in their description when to use them.
• Required settings, such as an API key, are declared as settings, not asked for in chat.
• No keys, tokens or private files are in the folder.
• Review materials list prompts to try and prompts to leave alone, and a demo account is ready for --review-notes if sign-in is needed.
• You installed the package from its folder (plugin install .) and tried the test cases in Enconvo.

​

What happens after you submit

1. plugin publish checks the plugin and that its version is higher than the one the store released, then uploads it and submits the version for review. Until a new plugin is approved, only you can see it.
2. A reviewer reads the listing, the package’s files (with what changed since the released version), the review materials and your notes, and tries the test cases.
3. An approved version appears in the store, and installed copies are offered the update. If a version is turned down, you get an email with the reason. Fix it, raise the version and publish again.

​

Submitting to OpenAI as well

npx -p @enconvo/api enconvo plugin validate --openai
npx -p @enconvo/api enconvo plugin scan --openai
npx -p @enconvo/api enconvo plugin pack --openai

• interface.longDescription, and an interface.category; without one, the directory lists the plugin under Other.
• For a plugin with an MCP server, websiteURL, supportURL, privacyPolicyURL and termsOfServiceURL, each an https:// address of up to 1,024 characters.
• A listing of your own. A Claude Code plugin with only .claude-plugin/plugin.json gets one the portal fills in with defaults (claude_format_normalized), so add a .codex-plugin/plugin.json with an interface to write it yourself.
• Screenshots only when the MCP server has its own interface: one PNG or JPEG for each starter prompt, exactly 706 pixels wide and 400 to 860 pixels tall. The portal decides from its scan, so scan --openai refuses screenshots when no tool shows an interface (screenshots_not_allowed). OpenAI’s directory no longer shows screenshots and introduces a plugin by its starter prompts, so write those with care.