v0.9.1 - 91 tools (57 reads, 34 writes)

First tagged release. The repository carried 0 tags and 0 releases until now, which is the most likely reason directories were pinning an old snapshot: Glama was still serving 0.3.0 and the superseded "71 tools: 44 reads and 27 write actions" README while npm had been serving 0.9.1.

This tag points at 05af7b8, the commit where package.json became 0.9.1, which is the exact tree published to npm as @twitterapis/mcp@0.9.1. It deliberately does NOT point at the branch head: main has since gained the MCPB bundle manifest (#34), which is not part of the published 0.9.1 tarball, and tagging the head would have made this release claim content npm does not ship.

The catalog

91 tools: 57 reads and 34 write actions.

What landed in 0.9.x

0.9.1 adds mcpName to package.json and pins it in test/registry-manifests.mjs, which now requires the field to exist and to equal server.json's name. This is the field the official MCP registry reads out of the npm tarball to prove package ownership, and 0.9.0 shipped without it.

0.9.0 adds the X List operation family, five tools.

Two reads that look like two spellings of one capability and are not:

• twitter_list_tweets — posts written by the members of a public List, newest first, read through X's search index. The filterable half: it takes since and until date bounds (until is EXCLUSIVE, matching X's own until: operator) and an include_replies toggle. It carries no retweets, and search-index lag applies, so a very recent post can be briefly missing.
• twitter_list_timeline — the same List as X's own native feed, carrying members' retweets and X's List ordering. It takes only list_id, count and cursor, because a native timeline cannot honour search operators, so no date range and no reply filter exist on it.

The two are separated by their PARAMETER SETS rather than by their names. Each tool description says so and names the other, so a model choosing between them cannot silently answer a different question than the one asked, and a regression check pins the difference so a later edit cannot harmonise it away.

Three writes that run on the customer's registered X session rather than a pooled account, because a List belongs to a specific account:

• twitter_list_create — create a List with a name and optional description and is_private. A List is public unless you ask otherwise, and a private List is not readable by the public List read tools.
• twitter_list_add_member and twitter_list_remove_member — add or remove one account on a List you own.

Both writes return the List's member_count read back from X after the write. Check that field rather than ok alone: X returns a populated errors[] on 100% of successful calls to these operations, so the error array cannot tell you whether your write applied, while the count can. A null member_count means X returned no list object at all, which is itself the not-applied signal. A write that does not apply comes back with the same field layout plus a 422 and a machine-readable reason, and is not billed.

All five cost $0.0008 per call. Register a session once with twitter_customer_session, or pass auth_token and ct0 per call, for the three writes.

Install

npm install @twitterapis/mcp

The unscoped name twitterapis-mcp on npm is a name reservation only. Install the scoped package above.