opentwitter-mcp for Twitter/X data and monitoring

opentwitter-mcp's Twitter/X data surface

opentwitter-mcp addresses a specific integration problem: giving an AI assistant structured access to Twitter/X information without making the assistant itself handle every search and monitoring request. It is intended for MCP clients such as Claude Code and for users who want conversational access to account profiles, recent tweets, keyword searches, engagement filters, follower changes, deleted tweets, quote tweets, retweeters, and monitoring data.

The project does not present itself as a general browser automation system. Its tools are named around Twitter/X entities and discrete data requests. Profile data can be fetched by username or numeric ID. Tweet discovery supports basic and advanced search, while account history includes recent and deleted tweets. A tweet ID can lead to the tweet itself, nested replies or quotes, quote tweets, and the users who retweeted it.

Monitoring is a separate capability from one-off lookup. `get_twitter_watch` lists monitored users, `add_twitter_watch` creates a watch entry with event options, a `remark`, and an optional `group_name`, and `delete_twitter_watch` removes one. Follower and unfollower events can also be requested through `get_twitter_follower_events`. This combination suits account research, change detection, and recurring queries made through an AI client.

Two tools extend beyond ordinary Twitter/X records. `get_meme_token_evidence` returns thesis and callout evidence, while `get_meme_activity` returns statements and buy or sell evidence associated with meme token activity. Their inclusion makes opentwitter-mcp relevant to crypto-oriented monitoring, but it also means the project is broader than a conventional social search connector.

How opentwitter-mcp passes requests to 6551

Based on the repository layout and package metadata, opentwitter-mcp is a Python MCP server with its source under `src/opentwitter_mcp`. `pyproject.toml` registers the `main` function from `opentwitter_mcp.server` under the project script name `opentwitter-mcp`. It requires Python 3.10 or later and depends on `mcp[cli]` and `httpx`, which correspond to the MCP client interface and HTTP transport.

The configuration indicates that tool requests are routed to a 6551 REST API rather than collected directly by a local Twitter/X client. The documented default base URL is `https://ai.6551.io`, and `TWITTER_API_BASE` can replace that URL. Authentication uses the required `OPENNEWS_TOKEN`, described as a 6551 API Bearer Token. `TWITTER_MAX_ROWS` limits the maximum results per query and defaults to 100.

Configuration can also live in `config.json` at the project root. Environment variables take precedence over that file. The documented fields are `api_base_url`, `api_token`, and `max_rows`. This supports local file configuration, environment-based deployment, and a configurable API endpoint, although the README does not document retry policy, rate limits, cache behavior, or the exact error mapping exposed to MCP clients.

The real-time path uses a separate WebSocket endpoint at `wss://ai.6551.io/open/twitter_wss`. Clients send JSON-RPC subscription commands and can send `ping` for a `pong` response. The server pushes `twitter.event` messages for monitored accounts. This creates two access patterns: explicit tool calls for retrieval and search, and a pushed event stream for accounts already placed on the monitoring list.

Installing opentwitter-mcp and querying a profile

The README directs users to `http://app.newsliquid.com/mcp` to obtain an API Token. For Claude Code, its documented registration command injects `OPENNEWS_TOKEN`, selects `uv`, points at the local project directory, and runs the server entry point:

claude mcp add twitter \
  -e OPENNEWS_TOKEN=<your-token> \
  -- uv --directory /path/to/twitter-mcp run twitter-mcp

Replace `/path/to/twitter-mcp` with the local checkout and `<your-token>` with the issued value. The documentation does not state the exact confirmation text shown by Claude Code, so success should be established through a request that uses a registered tool.

There is a concrete packaging mismatch here. The README command ends with `run twitter-mcp`, but `pyproject.toml` names the console script `opentwitter-mcp`. That means the README command may fail if no separate `twitter-mcp` script exists. A developer should inspect the installed command entry before treating the documented command as authoritative.

For the first query, ask the connected assistant for the Twitter profile of a specific account. The README gives this request:

Show @elonmusk's Twitter profile

That should invoke `get_twitter_user`, according to the tool-to-request table. Keep in mind that this example exercises only profile lookup. It does not confirm tweet search, advanced filters, watch-list changes, or WebSocket delivery. Those paths should be checked separately before production use.

Configuration choices and WebSocket event handling

For an environment-based configuration outside the Claude Code registration command, the README documents separate shell syntax for Unix-like systems and Windows PowerShell. The required value is the API token obtained from the project’s token page:

export OPENNEWS_TOKEN="<your-token>"

The equivalent documented PowerShell assignment is:

$env:OPENNEWS_TOKEN = "<your-token>"

A local `config.json` can hold the same connection settings when environment variables are not preferred:

{
  "api_base_url": "https://ai.6551.io",
  "api_token": "<your-token>",
  "max_rows": 100
}

The WebSocket API uses JSON-RPC. Subscription and unsubscription are separate methods, so a client should track whether it has subscribed before interpreting the absence of events as inactivity. The documented subscription payload is:

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "twitter.subscribe"
}

A successful response includes `result.success` set to `true`. Event delivery then arrives through `twitter.event`. Documented event types include `NEW_TWEET`, `NEW_TWEET_REPLY`, `NEW_TWEET_QUOTE`, `NEW_RETWEET`, and `CA`. The common event object includes account information, an event type, a remark, a timestamp, and variable content data.

This design is convenient for account monitoring, but it also concentrates operational risk in the remote endpoint and token. The README does not document reconnect behavior, token rotation during a live WebSocket session, delivery guarantees, historical backfill, or duplicate-event handling. Those are material constraints for any workflow that treats follower events as a complete audit log.

Limits of opentwitter-mcp for Twitter/X research

The strongest limitation is that opentwitter-mcp is an API-backed connector rather than a self-contained Twitter/X data source. A valid `OPENNEWS_TOKEN` and access to the configured 6551 service are required. The README does not publish token pricing, quota, request limits, or service-level commitments, so a prospective user cannot determine throughput or availability guarantees from the project documentation alone.

Result volume is also bounded by `TWITTER_MAX_ROWS`, whose documented default is 100 per query. The repository does not state whether advanced searches expose pagination, how cursors work, or whether all supported filters can be combined. Requests that require complete historical coverage should not assume that a single tool result is exhaustive.

The WebSocket layer adds another boundary. It reports activity for monitored accounts, but the documentation does not explain what happens after a disconnect, whether missed events can be recovered, or whether at-least-once delivery is attempted. It should not be treated as a durable event store without separate evidence from the service.

There is also the executable-name discrepancy between the README and `pyproject.toml`. That is more than a cosmetic documentation issue because it can prevent the documented launch command from resolving. The mismatch also highlights why the package metadata should be treated as the primary source for installed script names. Finally, the meme evidence tools may be appropriate for crypto monitoring, but they do not make opentwitter-mcp a general market-data system or a source that can be evaluated independently without understanding what the remote service returns.

OpenAI API workflows versus opentwitter-mcp tools

A custom integration would require its own authentication, request construction, response validation, storage, retries, and operational logs. The difference is architectural rather than cosmetic.

opentwitter-mcp reduces that application work by packaging a defined set of Twitter/X operations as MCP tools. An AI client can select those tools conversationally, while the server handles the call through the configured 6551 API. This is useful when the primary requirement is rapid assistant integration rather than ownership of the data pipeline. It also provides account watches and a WebSocket event protocol that a minimal direct script would need to implement separately.

The trade-off is reduced visibility and direct control. opentwitter-mcp requires an external token and service, and its README does not disclose rate limits, retention rules, raw response schemas, retry behavior, or pricing. A custom integration gives the developer finer control over requests and fields, but it creates more client code and does not automatically provide opentwitter-mcp’s KOL, meme evidence, or watch-list abstractions.

For an engineer deciding between them, choose opentwitter-mcp if MCP tool discovery and its prebuilt monitoring operations matter more than direct control over every API call. Choose the direct approach if data provenance, custom persistence, predictable request handling, or independent credential management are primary requirements.

Maintenance, packaging, and MIT licence considerations

The repository is not archived, and its last push was on 2026-09-22. There are no GitHub releases, so the repository has no published release history to compare against `pyproject.toml`. The package version there is `0.1.0`, while the README demonstrates a different executable name. This combination suggests that installation should be checked against the package metadata rather than inferred from release numbering.

The build system uses Hatchling and packages code from `src/opentwitter_mcp`. Its runtime dependency set is limited in the documented metadata to `mcp[cli]>=1.25,<2` and `httpx>=0.27`. Python `>=3.10` is required. These declarations make environment preparation straightforward, but they do not by themselves confirm the contents or security properties of the hosted 6551 service.

The project uses the MIT licence. That licence governs the repository code and provides the permissions and conditions stated in its text. It does not automatically determine the rights or availability of Twitter/X records, KOL classifications, follower events, or meme evidence delivered by the external API. This distinction matters because opentwitter-mcp is a client and tool layer for data whose upstream terms are outside the repository.

Upgrade planning should therefore include the package version, the `mcp[cli]` version range, the `httpx` dependency, the command-name mismatch, and changes to the 6551 token or endpoint. The repository has no GitHub releases to serve as upgrade notes, and the README does not document a rollback procedure.

Editorial conclusion

Adopt opentwitter-mcp when an AI assistant needs query-based Twitter/X profiles, search, follower monitoring, and related 6551 data through MCP. Do not adopt it for offline analysis, unrestricted Twitter/X access, or deployments that cannot depend on an external token and service. Verify the executable name first, because the README runs twitter-mcp while pyproject.toml registers opentwitter-mcp.

Frequently asked questions

Official sources

1. 6551Team/opentwitter-mcp on GitHub
2. Issues
3. License: MIT
4. Project website
5. README