Grok Bot uses connectors and MCP where a clean interface exists, and computer use, meaning direct visual control of an application or website, where one does not. Connectors are installed from Settings then Plugins in the desktop app. MCP support means a Bot can call tools exposed by an MCP server rather than clicking through a screen, which is faster, cheaper in tokens, and more reliable than driving a browser. Credential handover is deliberate: when a Bot hits a login wall, you do not send the password through chat; xAI says Bot hands control to you so you can type the password, the 2FA code, or the CAPTCHA into the shared computer. The resulting session then persists on the machine, and because the documentation states all Bots share files, browser sessions, and app logins, that session is available to every Bot on the account. Grok Bot has no public API and no webhooks, so nothing in your own systems can trigger a Bot or read its output programmatically.
- Two routes, one preference order. The docs say connectors and MCP where available, computer use for apps and websites without a clean API.
- Connectors install from Settings then Plugins in the desktop app, per the get-started documentation.
- MCP is supported, which means a Bot can call tools instead of clicking screens. Prefer it wherever a server exists.
- You do not send the password through chat. xAI says Bot hands control to you at the auth wall so you can type it into the shared computer.
- The session it creates is shared. Every Bot on the account inherits it, including ones you create later.
- No public API, no webhooks. Nothing you build can trigger a Bot or read its output. Integration is one-directional.
The two integration routes, and the order they are tried
The documentation states the preference order in a single clause. Bots use "connectors/MCP where available, and computer use for apps and websites without a clean API".
| Connector or MCP | Computer use | |
|---|---|---|
| What it is | A structured call to an API or an MCP tool | The Bot looks at a screen and drives it |
| When it is used | Where a clean interface exists | Where none does |
| Reliability | High. Structured in, structured out | Lower. A redesign breaks it |
| Token cost | Low. A response is small | High. Reading screens is expensive |
| Speed | Fast | As fast as the interface |
| Coverage | Only where somebody built one | Anything with a login and a screen |
| Breaks when | The API changes | The layout changes |
The design is sensible and it is the right way round. What makes Grok Bot interesting is not the connector list, which every agent product has, but the fallback: when the connector does not exist, it does not give up, it opens the site. The cost of that fallback is the row you should plan around. Computer use is token-expensive by nature, because reading a screen costs far more than reading an API response carrying the same information, and the meter behind it is uncapped with an allowance xAI does not publish. Wherever a connector exists, using it is a cost decision as well as a reliability one.
Where connectors live: Settings, then Plugins
The get-started documentation names the path: connectors are installed from Settings then Plugins in the desktop app. The same settings area carries Settings then Beta, which is where "Check for Updates" lives, and on a product changing this fast that is worth knowing about separately.
AY Automate’s launch write-up is the only coverage with a screenshot of the plugins panel, which is the closest thing to documentation of what the catalogue contains. xAI publishes no connector directory that we could find, so the honest answer to "does Grok Bot connect to X" is that you have to open the panel and look.
The onboarding flow is relevant here too. After signing in, the first run "introduces Bots, the shared computer, and routines, then asks which tools you use". That question is what seeds the initial connector suggestions, so answering it honestly is the fastest way to see what exists for your stack.
What MCP support actually means here
MCP, the Model Context Protocol, is the emerging standard for exposing tools to an AI agent in a structured way, and it is why a single integration can serve many different agent products. Grok Bot’s documentation names it alongside connectors as the preferred route. If you are new to the protocol, what is MCP covers the concept.
What that support buys you in practice, and what it does not.
A Bot can call tools instead of clicking
Where an MCP server exposes your internal system, a Bot can invoke a tool with typed arguments and get a structured result. That is dramatically cheaper in tokens, far more reliable, and unaffected by anyone redesigning a page.
Your existing servers may already work
MCP is a shared protocol, so a server you built for another agent is a candidate here. That is the whole point of standardising, and it is the strongest practical argument for reaching for MCP before a connector.
The server still runs somewhere
A local MCP server on your laptop is not reachable from a cloud VM. Anything a Bot calls has to be reachable from xAI’s machine, which for internal systems means either exposing them or not using this route.
It does not give you an API into Grok Bot
MCP support is inbound only: Bots call your tools. It does not let your systems call a Bot. That distinction catches people out and is the subject of the next section.
There is no Grok Bot API
This is the question the search query "grok bot api" is really asking, and the answer is short. As of 22 August 2026 Grok Bot has no public API, no webhooks, and no programmatic surface. Neither documentation page describes one, and no launch coverage found one.
Integration is therefore one-directional. Bots can reach out to your systems through connectors, MCP, and computer use. Your systems cannot reach in.
| Product | Public API? | What it is for |
|---|---|---|
| Grok Bot | No | Always-on agents driven from the chat interface |
| Grok Automations | No | Scheduled and email-triggered prompts to the chatbot |
| Grok Build | It is a CLI, and speaks ACP | Scriptable. Headless mode, JSON output |
| The xAI API | Yes | Direct model access, OpenAI-compatible |
So if your requirement is "when this happens in our system, an agent does that", Grok Bot is the wrong product and the right ones are on the bottom two rows. Grok Build in headless mode with structured output is the scriptable agent; the xAI API is the raw model. The Grok CLI guide covers the headless flags, and Grok Bot vs Grok Build covers when each product is the right choice.
How credential handover works
This is the best-designed part of the product and the part with the most important consequence, and both halves deserve stating.
The design: when a Bot reaches a login wall, you do not send the password through chat; xAI says Bot hands control to you. You type the password, the second factor, or the CAPTCHA into the live session yourself, then hand control back. AY Automate’s write-up has a screenshot of this happening on a LinkedIn login, and it is the clearest illustration published.
The consequence: the session that login creates persists on the machine, and the machine is shared. The documentation is explicit on both points. "Named Bots keep memory, files, browser sessions, and preferences across turns." And: "All of your Bots use the same persistent cloud computer. They share files, browser sessions, and app logins." Followed by the instruction to "treat a login or file placed on the computer as available to all of your Bots".
| Question | Answer |
|---|---|
| How is my password entered? | You do not send it through chat; xAI says Bot hands control to you so you can type it into the session |
| Does the session persist after the task? | Yes. That is the design |
| Can other Bots use that session? | Yes. Every Bot on the account |
| Including Bots I create next month? | Yes. The machine is per account, not per Bot |
| Can I scope a login to one Bot? | No mechanism exists |
| Does deleting the Bot revoke the session? | No. The session is on the machine, not in the Bot |
| How do I actually revoke it? | Sign out of the service on the shared machine, reportedly a multi-step manual process |
A working order of preference
Given the cost, reliability, and credential properties above, there is a clear order to try things in.
- 1. An MCP server, if one exists for the system. Cheapest in tokens, most reliable, survives redesigns, and portable to other agent products.
- 2. A connector from Settings then Plugins. Same structural benefits, less work, whatever is in the panel on the day.
- 3. Computer use with a read-only account. When nothing structured exists. Create a scoped login rather than using your own, because whatever you sign in as is what every Bot is signed in as.
- 4. Computer use with a real account. Last resort, and only for credentials you are content to place on a shared machine with no boundary.
- Never: a credential that can move money, deploy code, or reset other accounts. There is no dry run, no per-Bot scoping, and no queryable organisation-wide audit view to reconstruct from.
One more practical note on cost. Because computer use is token-expensive and the meter is uncapped, an integration built on screen-reading is not just less reliable than one built on MCP, it is more expensive per run, indefinitely. If a system you use daily has an MCP server available, moving to it pays back every day the routine runs.
Questions people ask
Does Grok Bot support MCP?
Yes. The overview documentation lists the preference order as "connectors/MCP where available, and computer use for apps and websites without a clean API". A Bot can call tools exposed by an MCP server instead of clicking through a screen, which is cheaper in tokens, faster, and unaffected by interface redesigns. The server has to be reachable from xAI’s cloud machine.
How do I add a connector to Grok Bot?
From Settings then Plugins in the desktop app, per the get-started documentation. The first-run onboarding also asks which tools you use, which seeds the initial suggestions. xAI publishes no connector directory that we could find, so the only reliable way to know whether a specific integration exists is to open the panel and look.
Can my own systems trigger a Grok Bot?
No. Integration runs one way. Bots reach out to your systems through connectors, MCP, and computer use, but as of 22 August 2026 there is no public API, no webhook, and no programmatic surface for anything of yours to reach in. MCP support is inbound only: a Bot calls your tools, your tools cannot call a Bot. If you need an event in your system to start agent work, the scriptable xAI products are Grok Build in headless mode and the xAI API.
What is computer use in Grok Bot?
Direct visual control of an application or website that has no clean API. The Bot sees the screen on its cloud machine and drives the interface the way a person would. It is the capability that separates Grok Bot from a chatbot with plugins, and it is the reason it can work with legacy portals and admin consoles nothing else can reach.
How does Grok Bot handle passwords?
You do not send the password through chat; xAI says Bot hands control to you. You then type the password, the 2FA code, or the CAPTCHA into the shared computer. The consequence is that the resulting session persists on the shared machine and is available to every Bot on the account.
Can I give one Grok Bot access to an app and not another?
No mechanism exists. The documentation states all Bots share files, browser sessions, and app logins, and that each Bot’s own screen comes "without getting separate security boundaries". A login placed on the machine is available to every Bot on the account, including ones created after the login. The only boundary available is a separate account.
What happens to app logins when I delete a Grok Bot?
They stay. Sessions and files live on the shared account computer rather than inside a Bot, so removing the Bot does not remove what it authenticated to. Revoking access means signing out of the service on the shared machine, which is reported as a multi-step manual process, or revoking the session from the other service’s own security settings.
Can Grok Bot connect to Slack, Notion, or my CRM?
Either through a connector from the plugins panel if one exists for that product, or through computer use by driving the web interface if not. Because there is no published connector list, the answer for any specific product has to be checked in the panel. The computer-use fallback means the practical answer is usually yes, at a higher token cost and lower reliability.
Should I use a connector or computer use?
A connector or MCP server every time one exists. Computer use reads screens, which costs far more tokens than a structured response carrying the same information, and the meter behind it is uncapped with an allowance xAI does not publish. It also breaks whenever the interface is redesigned. Keep computer use for the systems that genuinely have no other route.
Sources
Every figure above was read from these pages on August 2026. Vendors reprice without notice; if you find a stale number, tell us.
- Grok Bot overview, docs.x.ai the shared cloud computer, per-Bot screens, memory, routines, connectors and MCP, computer use, group chats
- Grok Bot get started, docs.x.ai eligible plans, Cursor sign-in, platform downloads, the Linux statement, Settings paths
- AY Automate: what xAI’s always-on agents actually do the only launch-week write-up with real product screenshots: credential handover, plugins panel, teach-a-task recording
- Composio: a guide to Grok Bot hands-on setup walkthrough and skills as reusable procedures
- eesel AI: Grok Bot review metering behaviour, compliance gaps, no dry run, audit view described as coming
- xAI: the Grok Build CLI xAI’s own coding agent: install, access tier, AGENTS.md, plugins, hooks, skills, MCP, ACP
- xAI: Grok Automations 16 July 2026, schedules and email triggers, the product formerly called Tasks
- Hacker News: the Grok Bot launch thread launch-week reception, the trust and prompt-injection objections, the Linux download report
- Continuum pricing Free, Plus, Max 100, Max 200, Ultra, and the Team seat price