When you open Connect apps in Grok Bot, you see a list of plugins: Gmail, Slack, Notion and more. If you build a product, the obvious question is how to get *yours* on that list.
On October 14, two posts on X answered it with the same link.
shub called it “one of the top requests from founders”: bring your product to Grok Bot as a connector, and let Grok Bot users discover you. Kiara posted the form directly.
This guide covers what a plugin is in Grok Bot, what the submission form asks for, what to prepare, what the linked publisher terms say, and some honest notes on what isn't public yet.
What a plugin does for Grok Bot users
From the official help: plugins let a Bot talk to an external service, using the account the person signs in with. A plugin can only do what that account can already do in the service. It can't raise access or change sharing. Once installed, a plugin is available to every Bot on that person's account.
For a product, that means a Grok Bot user can say “check my orders” or “create a ticket” in plain words, and the Bot can do it through your service, with your service's permissions.
Where to submit
The form lives at [x.ai/bot/marketplace/submit-a-plugin](https://x.ai/bot/marketplace/submit-a-plugin). Its own description: distribute your plugin or MCP server to Grok (coming soon) and Grok Bot users. Submit it, and x.ai reviews it before listing.
Approved plugins appear in x.ai's official Marketplace, the store where people browse and add Bots.
What the form asks for
As of October 14, the form has these fields (starred ones are required):
- First name, last name, work email
- Organization name and an organization handle (a unique handle, no spaces or capitals)
- Website URL
- Logotype URL: a 1:1 SVG or PNG “with a background plate”
- Where you want to be listed, with Grok (marked coming soon) and Grok Bot among the options
- MCP server URL or public GitHub repository
- Brief description: what your plugin does and how it helps users
- Testing instructions: a link or steps for testing locally and in-app, including any test credentials
- A checkbox confirming you've tested the plugin locally and in-app and it works as expected
- Agreement to the Publisher Terms when you press Submit Plugin
Prepare before you submit
1. Decide: hosted MCP server or a repository
The form accepts either. A hosted MCP server URL is a server your users connect to over the network. A public GitHub repository holds the plugin's code and configuration.
If you're new to MCP (Model Context Protocol), the SpaceXSI docs for Grok Build show the shape of it: MCP servers expose external tools, and a remote server can run over HTTP with OAuth handled automatically on first use. That page is about Grok Build, but it's a good primer on how an MCP server plugs in.
2. Get your logo right
A square logo, SVG or PNG, with a solid background behind the mark. Transparent logos that vanish on dark backgrounds are a common miss.
3. Write the description for a user, not an investor
The form asks “what your plugin does and how it helps users.” One or two sentences that name real tasks work best: “Look up an order, issue a refund, and check stock levels in your store.”
4. Make testing painless
Reviewers need to try it. Provide a test account with sample data, the exact steps, and what success looks like. If your product needs a paid plan, give reviewers a way in.
5. Test in the app yourself
The checkbox asks you to confirm you tested in-app, not just locally. Add your server or plugin in your own Grok Bot, ask a Bot to do three or four real tasks, and fix anything confusing in your tool names or descriptions.
Read the Publisher Terms
The form links a set of Publisher Terms. Read them in full before you submit. A few points stood out to us:
- Review covers identity and code. The terms say each application is reviewed to verify the publisher's identity and business legitimacy, and the plugin's code is reviewed too. Applications can be approved or rejected without a reason given.
- Free to users. Plugins listed under these terms must be available to users at no cost, and publishers agree not to charge users, directly or indirectly, for use through the store. (Your underlying product can still be a paid service; read the exact wording with that in mind.)
- Permissive open-source only. Open-source components must use permissive licenses such as MIT, BSD or Apache 2.0. Copyleft licenses like GPL, AGPL and LGPL aren't allowed.
- No model training. Publishers may not use plugin data or user content to train AI or machine-learning models.
- You support it. The publisher is responsible for keeping the plugin working and secure, for user support, and for reporting security incidents.
- Updates. A new application isn't needed for each update; you request a re-index after changing the plugin.
A separate path for Grok Build
If your plugin is meant for Grok Build, xAI's coding tool, there's a different route: xai-org's open plugin index repository on GitHub. Its contributing guide explains that a pull request adds one catalog entry pointing at your plugin's source, pinned to a full commit SHA, and that review checks source legitimacy, security, duplication and conventions. Two of its tips apply to any submission:
- Publish from your official organization, not a personal account. A branded plugin hosted on a personal account “reads as a possible impersonation.”
- Scope to least privilege. Only request the tools and access you actually need.
What happens after you submit
Here the public information runs out. We didn't find a published review timeline, an acceptance rate, or a notification process for the Grok Bot form. Plan for a wait, keep your test account active, and keep your MCP server stable while it's under review.
Who this is for
- SaaS founders whose customers already use Grok Bot and keep asking for a connection.
- Developer-tool makers with an MCP server that already works elsewhere.
- Not for sharing a Bot you built. A Bot is a different thing from a plugin. If you want people to find a Bot you made, you can also list it in the Botski directory.
Gotchas
- “Coming soon” means not yet. The form lists Grok as a destination, marked coming soon. Don't promise customers availability in Grok until it's live.
- Team admins can turn plugins off. The help notes that on team accounts, an admin controls which plugins are available. If an enterprise customer can't see your plugin, that's the first thing to check.
- Company Google accounts may need admin approval for Google sign-in flows. That's about Google's own plugins, but it's a reminder that enterprise customers often have an approval step outside your control.
- Keep your listing honest. The publisher terms prohibit false or unsubstantiated claims about functionality or compatibility.
The takeaway
The front door is now public: one form, a working plugin or MCP server, a clear description and an easy way for reviewers to test. Prepare those, read the publisher terms closely, and test it in your own Grok Bot first.