Why Grok plugins get rejected

What reviewers and the rules say

Lines such as “always call this tool first” or “never tell the user” read as an attempt to steer the model, the same shape as prompt injection. Anthropic rejects descriptions that tell Claude to call tools the user didn’t ask for or interfere with other tools. OpenAI’s rules say tool metadata must not override platform instructions or safeguards. Microsoft rejects instructional phrases in any description, xAI looks for prompt injection in SKILL.md and descriptions, and ClawHub’s scanner flags text that could change an agent’s behaviour. Naming a sibling tool to call first is common in approved listings and isn’t the problem.

How to fix it

• Describe what the tool does and returns, as facts.
• Move usage guidance into the server’s instructions or your docs.
• If a line has to stay, explain it in the submission’s notes for reviewers.

How common it is: in our scan of Claude’s connector directory on 29 September, 21% of servers tell the model what to do inside a tool description (118 of 564).

Caught by

• tools.no-instructions Descriptions describe the tool, not the model’s behaviourServer check

Check your servermcplane docs

What reviewers and the rules say

Reviewers compare what your listing, tool descriptions and skill files promise with what the tools do. They drift: a renamed tool, a removed feature or an old sign-in method still described in a skill file reads as misleading.

How to fix it

• Describe each tool precisely: what it does, what it returns and when to use it.
• Re-read the listing, tool descriptions and skill files after every change to the server.
• Before resubmitting, compare what the store is reviewing with what the server does now.

Caught by

• listing.test-tools Test cases use tools the server hasmcplane CLI
• mcplane drift: what each store is reviewing against what the server does nowmcplane CLI

Check your servermcplane docs

What reviewers and the rules say

A tool such as api_request with a method and a path does reads and writes through one door, so its hints can’t be honest and nobody can review what it will do. Anthropic rejects a tool that accepts both safe and unsafe HTTP methods, OpenAI wants every operation the model can call exposed as its own tool, and xAI questions broad shell access where a narrow tool would do.

How to fix it

• Split it into read tools and write tools, each with honest hints.
• Expose each operation as its own tool, with its own description and input schema.
• If a tool has to accept free-form paths or queries, name or link the API it calls in the description.

Caught by

• tools.catch-all No catch-all request toolServer check

Check your servermcplane docs

What reviewers and the rules say

ChatGPT rejects names it judges too generic, sometimes automatically as soon as you submit, especially single dictionary words that aren’t tied to your brand. Its guidelines also rule out adding “MCP”, “MCP Server” or “Plugin” to a product name. Grok uses your keywords and domains to suggest your plugin in conversation, so its reviewers push back on generic ones.

How to fix it

• Use your brand or product name, not a category word.
• Don’t add “MCP”, “MCP Server” or “Plugin” to the name for ChatGPT.
• For Grok, keep keywords and domains scoped to your brand.

Caught by

No script can see this one. A server check rules out the mechanical causes first.

Check your servermcplane docs

What reviewers and the rules say

Reviewers run what you give them, as the account you gave them, against your live server: ChatGPT’s five positive and three negative test cases, Microsoft’s sample prompts, or a demo for Grok. A test that names a tool you have since renamed, or expects data that has since changed, reads as a broken app. OpenAI also expects the same test cases to pass on ChatGPT web and mobile.

How to fix it

• In each test case, name only tools the live server has.
• Seed the demo account with the data every test case expects, and check it again right before you submit.
• Record ChatGPT’s video walkthrough in developer mode, and again whenever tools change.
• Give write tools a safe target, so reviewers don’t post to a real account.
• For Grok, be ready to share a short demo of sign-in, OAuth consent and a harmless request.

Caught by

• listing.test-tools Test cases use tools the server hasmcplane CLI
• Demo data matches every test case, checked right before submittingBy hand

Check your servermcplane docs

What reviewers and the rules say

Stores that take plugins read them from a public GitHub repository at a pinned commit, and validate it before anyone reviews it. A private repository, a missing manifest, README or licence, a branch instead of a commit, or a failing CI run leaves nothing to review. Gemini CLI’s gallery skips a repository that fails validation without saying so.

How to fix it

• Host the plugin in its own public GitHub repository. A private monorepo can’t be pinned.
• Claude: add .claude-plugin/plugin.json, a README of at least 40 words and a LICENSE, then run claude plugin validate --strict.
• Don’t leave a SKILL.md at the root beside a skills/ folder. Claude loads it as a single-skill plugin and hides the rest.
• Grok: pin a full 40-character commit SHA, not main or a tag.
• Docker: use a licence that lets people run the server, such as MIT or Apache 2.0, and get CI green before asking for review.
• Gemini CLI: put gemini-extension.json at the root and add the gemini-cli-extension topic.

Caught by

• repo.public The plugin repository is publicmcplane CLI
• repo.claude-manifest .claude-plugin/plugin.json existsmcplane CLI
• repo.root-skill No root SKILL.md shadowing the plugin’s skillsmcplane CLI

Check your servermcplane docs

What reviewers and the rules say

xAI wants a branded plugin to come from the organisation that owns the brand. A repository under a personal GitHub account reads as possible impersonation.

How to fix it

• Transfer the repository to a GitHub organisation named after the product before you open the pull request.

Caught by

• repo.grok-org Grok plugin comes from an organisationmcplane CLI

Check your servermcplane docs

What reviewers and the rules say

Stores that take pull requests close one that adds something already in the catalog, or a second one for the same plugin. Updates go through the existing entry.

How to fix it

• Search the catalog and the open pull requests before you add an entry.
• To update a listed Grok plugin, bump its pinned commit instead of adding a new entry.
• Close your own older pull request when you open a replacement.

Caught by

No script can see this one. A server check rules out the mechanical causes first.

Check your servermcplane docs

What reviewers and the rules say

Some reviews end without an explanation. ChatGPT rejection emails have arrived with an empty details section, Claude’s old plugin portal showed “Rejected” with no notes, Grok and Docker maintainers often close pull requests without a comment, Gemini CLI’s crawler skips repositories silently, and Cursor’s publish form sends no confirmation.

How to fix it

• ChatGPT: reply to the rejection email with your case ID and ask for the specific finding.
• On a pull request, ask what would make it acceptable.
• Rule out the mechanical causes with a server check before you resubmit.

Of the 6 pull requests maintainers closed in the Grok and Docker queues we track, none had a comment saying why (checked 1 October).

Caught by

No script can see this one. A server check rules out the mechanical causes first.

Check your servermcplane docs