twitter_api_safe_relay_mcp
Related Servers
Alternatives to twitter_api_safe_relay_mcp
No user-submitted related servers found.
Related Servers
- AlicenseNot gradedqualityCmaintenanceEnables an agent to send arbitrary HTTPS API requests (GET, HEAD, POST, PUT, PATCH, DELETE, uploads) to saved services using stored auth keys, with request previews, idempotent write recording, and built-in Cookiejar site creation and deployment. Requests are pinned to the saved origin and auth header, with the service itself deciding what each request may do.MIT

Alidade MCPofficial
AlicenseAqualityAmaintenanceForwards every tool call to a hosted MCP backend and, when supplied with your own X API bearer token, fills in the text and engagement metrics of X posts returned by mention and semantic searches so agents see readable posts instead of bare IDs. Without a token it behaves exactly like the hosted server.12393 npmMIT- FlicenseNot gradedqualityDmaintenanceExposes provider-specific tools and relays HTTP requests to configured providers like Supabase, Vercel, and Context7, enabling interaction with multiple external APIs through a unified MCP interface with configurable authentication and access controls.-
- AlicenseAqualityAmaintenanceAPI client for coding agents. Sends saved HTTP, GraphQL and gRPC requests, runs collections with their checks, and creates or edits requests over stdio or loopback HTTP, with secret values redacted and calls limited to an allowlist of hosts.1656MIT
- AlicenseNot gradedqualityAmaintenanceEnables AI agents to safely interact with external services (HTTP, GraphQL, gRPC, Bash, SQL) using HCL templates and OS keychain secrets, preventing prompt injection by keeping request details from the LLM.113Apache 2.0
- AlicenseNot gradedqualityCmaintenanceEnables MCP clients to connect once to self-hosted, user-owned upstream accounts and then discover and invoke granted tools through a single authenticated endpoint. Each client receives its own key with deny-by-default tool grants, while sensitive calls require durable human approval and credentials stay encrypted and never forwarded upstream.Apache 2.0
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.