twitter_api_safe_relay_mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| twitter_api_requestA | Execute one request against the signed-in Twitter/X relay. Get a current template from twitter_request_catalog first: GraphQL query IDs, features, field toggles, and variable names are versioned and operation-specific. Reads and writes use the same relay; confirm before side effects and verify writes with a follow-up read. HTTP 200 responses may still contain GraphQL errors. |
| twitter_request_catalogA | Search the current Twitter/X request catalog by operation name, path, method, or request content. Returns ranked templates already converted to the argument shape accepted by twitter_api_request. Use operation-like terms such as SearchTimeline, UserByScreenName, TweetDetail, CreateTweet, friendships, blocks, or lists. Fetches the upstream NDJSON on every call so query IDs and feature flags stay current. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 2 tools
The two tools have completely distinct purposes: one fetches/curates request templates from the catalog, the other executes a single request against the relay. There is no overlap or ambiguity between them.
Both tools use a similar 'twitter_' prefix, but one uses 'request' and the other 'request_catalog', which is a mild inconsistency in granularity. The names are readable but the pattern isn't perfectly parallel—'twitter_api_request' vs 'twitter_request_catalog' mixes the placement of 'api' and 'request'.
Two tools feels extremely thin for a Twitter/X API surface, which is vast (timelines, tweets, users, friendships, DMs, media, trends). While the catalog tool cleverly bundles the numerous request types into a searchable interface, the overall surface is still very limited given the breadth of the domain.
The two-tool design is a clever pattern: the catalog surfaces templates for any operation and the executor handles them, so in principle the coverage is as deep as the catalog. However, there are no helper tools for authentication setup, session management, or error diagnosis, and the design forces agents to do two calls for every single operation, creating friction.