XActions: browser scripts, a CLI and an MCP server for X/Twitter without API keys

The problem XActions solves is billing and access, not automation

Automating X/Twitter is not technically hard. The hard part is that the sanctioned route, the official API, is metered, and the README frames the entire project around that: 'No API keys. No monthly fees. 100% open source.' XActions instead drives the site the way a person would, through a browser session, and then exposes that session through several surfaces. The repository description lists them: scrapers, an MCP server for Claude and GPT, a CLI, browser scripts, and a browser extension.

That framing tells you who this is for. It is for people who already have an X account, are willing to have that account act on their behalf, and want to script it from a terminal or hand it to an agent. It is not for someone building a product on top of X data who needs a stable contract, rate-limit documentation and a support channel. The README does not claim that kind of stability anywhere, and the omission is the honest part of the pitch.

Two execution paths: a headless CLI and pasted console scripts

The architecture visible in the material splits into two halves that share the same underlying session model.

The CLI half runs under Node. The README shows `npx xactions profile nasa` returning name, bio, location, website, join date, following and follower counts, tweet count and verification status, and states that this works with no API key, no account and no browser. Commands that need more, search, followers, DMs, are gated behind `npx xactions login`. Output can go to a file: `npx xactions tweets nasa --limit 100 --output nasa.csv`. The CLI is described as 56 commands, with 152 MCP tools exposed to agents (the badge alt text says 153, and the README body says 153 elsewhere, so treat the exact figure as something to confirm in docs/mcp-setup.md).

The other half is browser console scripts, 95 of them according to the comparison table. These are pasted into the developer console on x.com while you are logged in. `scripts/searchSweep.js` is the clearest example: you open a search URL such as `x.com/search?q=from:you @someone&f=live`, paste it, and the script renders a floating panel that can delete, like, repost or reply to every result, with a dry run and filters. Because X search returns results in slices, the script supports multiple passes. `scripts/engageProfile.js` does the same for a whole profile, with dry run, resume, undo, and replies drawn from your own templates or from an LLM given a one-line brief.

The split matters operationally. Console scripts run inside a page you already authenticated, so there is no credential handling to reason about. The CLI needs a session, which is why `login` exists as a separate step.

The write path is the design decision worth attention

Most automation toolkits of this type are judged on how much they can do. XActions is more interesting for what it refuses to do immediately.

The comparison table lists two rows that are not features in the usual sense. 'Human approval gate on writes' means every write is held as a draft rather than executed. 'Daily action caps that survive a restart' means the limits are per account and written to disk, so killing the process does not reset your budget for the day. The README attributes both to x-use, a competitor, and says plainly: 'Where a rival led, we built it.'

That is a defensible design for a tool whose primary risk is a banned account. It also means XActions is not a fire-and-forget growth bot, whatever the repository description's talk of a follow bot and a like bot suggests. If you want unattended bulk action, you are fighting the tool's defaults, and the defaults are the part the maintainers thought hardest about.

The same pattern shows up in the scraping side. Resumable long scrapes use cursor checkpoints, so an interrupted run continues rather than restarting. Account pools are stored in SQLite with per-operation windows, which is the twscrape pattern adapted to JavaScript. None of this is glamorous, and all of it is the difference between a demo and something you leave running.

Getting it running: three commands and one login

The README's own quickstart is short enough to quote directly. Profile lookup needs nothing:

npx xactions profile nasa

The README gives the output shape, including the follower count and verification line, and says it returns 'Real data in about a second.' That timing is the README's claim, not a measured result here.

Timeline export writes a CSV:

npx xactions tweets nasa --limit 100 --output nasa.csv

Anything beyond public reads needs a session:

npx xactions login npx xactions search "your brand" --limit 50

The README says login 'unlocks search, followers, DMs.' Two flags appear in the comparison table for sourcing cookies from a browser you already use: `--from-browser` and `--cookies-file`. The README does not document their exact accepted values in the material available, so check docs/getting-started.md before relying on them. There is also an official archive import, `xactions archive`, for loading your own X data export, and a Dockerfile if you would rather not install Node locally. TypeScript types ship in types/index.d.ts.

One inconsistency to note: the README's badge alt text reads '153 MCP Tools' while the surrounding prose and table say 152. Small, but it is the kind of thing that tells you the MCP surface changes faster than the docs around it.

Where XActions is the wrong tool

The whole toolkit rests on browser sessions and logged-in accounts. That is a real constraint, not a footnote.

First, it inherits the fragility of the thing it automates. Any change to X's page structure or search behaviour can break a console script, and the README itself acknowledges that search returns results a slice at a time, which is why searchSweep needs multiple passes. A toolkit built on selectors and session cookies has a maintenance cost that a documented API does not.

Second, the account is the unit of risk. Daily caps and an approval gate reduce the chance of a ban. They do not remove it, and nothing in the material describes what happens when an account is limited or suspended mid-run. If your workflow depends on a specific account continuing to work, that dependency is the exposure.

Third, the licence and the terms are separate questions. Apache-2.0 governs the code. It says nothing about whether automating a given account is permitted by X, and the README's positioning as an API-fee avoidance route is precisely the framing that invites scrutiny. Nothing here is legal advice; the point is that a permissive code licence is not permission to operate.

Finally, if you need guaranteed throughput, documented rate limits, or someone to call when it breaks, this is the wrong category of tool. The comparison table itself lists xmcp (official) as requiring X API keys, and that requirement is what you are buying when you use it.

Alternatives, and what actually differs

The README names its competitors and, unusually, credits them. That table is the most useful document in the repository because it states what each rival does better.

xmcp (official) is the metered, key-based route with 140 tools. The difference is not tool count, it is the contract: you pay, you get documented limits and a sanctioned integration path. XActions trades that for zero marginal cost and no key management.

twikit and twscrape are Python. twikit authenticates with cookies, twscrape runs an account pool. XActions is JavaScript and adopted the account pool idea, storing it in SQLite with per-operation windows. If your stack is Python, there is no reason to cross languages for this.

bird and twitter-cli are TypeScript and Python CLIs respectively that read cookies from your browser. XActions added the same capability via `--from-browser` and `--cookies-file`. The meaningful difference is breadth: 56 CLI commands, 95 console scripts and an MCP server in one package, against single-purpose CLIs.

x-use is the closest in spirit. It runs through a browser, exposes a 33-tool MCP server, and, per the README, originated the human approval gate and restart-surviving daily caps that XActions copied. If you only need agent-facing MCP tools and want the smaller surface, x-use is the more direct comparison and the README does not claim to beat it on that axis.

Agent-Reach is listed as skills rather than MCP, which is a different integration model for the same audience.

Maintenance, versioning and the licence boundary

The repository is not archived, the default branch is main, and the last push recorded in the material is 2026-09-10. No releases were retrieved, which means there is no changelog to read and no tagged version to pin against. For a tool that automates a third-party site, that is the single most important maintenance fact: you cannot tell from a tag what changed or when.

Practically, that pushes you toward pinning the npm package version explicitly rather than relying on `npx xactions` resolving to latest, and toward reading the commit history on main before upgrading. The README references a competitive and structural audit dated 2026-08-27 and a set of docs under docs/, including mcp-setup.md, getting-started.md, api-reference.md and search-sweep.md. Those are the files to check when a command behaves differently from the README.

The licence is Apache-2.0, which permits commercial use and modification and includes a patent grant. It also means there is no warranty, and no maintainer obligation to fix a break caused by a change on x.com. The README's own credits section, where it names x-use, twscrape, Scweet, bird and twitter-cli as the sources of ideas it adopted, is worth reading before you file a feature request: several of the guardrails already exist because a competitor built them first.

Editorial conclusion

Adopt XActions if you need X/Twitter read and write operations from a terminal or an AI agent and you are willing to run it against a logged-in browser session you control. Do not adopt it if you need contractual stability, vendor support, or an automation path that X's terms clearly permit; the README positions the whole toolkit as avoiding the API, and that posture is the risk you are accepting. Verify three things before you commit: whether the 152 or 153 MCP tool count in the badges matches docs/mcp-setup.md, whether the human approval gate actually holds every write as a draft in your configuration, and whether `npx xactions login` stores the session somewhere you are willing to have it stored.

Official sources

1. Issues
2. License: Apache-2.0
3. nirholas/XActions on GitHub
4. Project website
5. README