Skip to main content
Glama
TwitterAPIs

twitterapis

twitter_grok_chat

Ask X's Grok a question as your authenticated account and receive a structured reply with cited sources, summaries of tweet URLs, and support for multi-turn conversations.

Instructions

Ask X's own Grok a question AS your authenticated account, and get ONE complete JSON reply with the answer plus the sources it cited. Unlike a general LLM, Grok reads X in real time, so it can answer about what is being said right now, and passing a bare tweet or status URL as the message returns a structured summary of that post. Returns answer text, citations (url, title, snippet) merged and de-duplicated across every search Grok ran, the searches themselves, and the model that ACTUALLY answered (which can differ from the one you asked for). Buffered, not streamed. STATELESS: nothing is stored, so to continue a conversation pass the prior turns back in messages[] along with conversation_id. Requires an authenticated session for the acting account.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
ct0NoOptional. The account's ct0 cookie, paired with auth_token. Sent as the x-ct0 header.
modeNoWhich Grok to use: 'auto' (default, balanced), 'fast' (quicker, less thorough) or 'expert' (slowest, most thorough). The response reports the model that actually answered, which can differ from the mode requested.
messageNoThe prompt, for a single-turn question. A bare tweet or status URL is a first-class input and comes back as a summary of that post. Provide either this or messages[].
messagesNoPrior turns for a multi-turn conversation, oldest first, each { role: 'user' | 'grok', content: '...' }. The endpoint stores nothing, so the full history you want Grok to see must travel in this array. Provide either this or message.
proxy_urlNoOptional. Residential proxy URL to egress this call through. Recommended for writes: X soft-blocks writes from datacenter IPs as automated. Sent as the x-proxy-url header.
auth_tokenNoOptional. The account's auth_token cookie, to act AS that account for this call (must be paired with ct0). Sent as the x-auth-token header; never placed in the URL.
user_agentNoOptional. User-Agent string to send for this session. Sent as the x-user-agent header.
image_countNoHow many images Grok may generate if the prompt calls for one. Defaults to the value X's own client sends. Set 0 for a text-only answer.
conversation_idNoConversation id returned by a previous call. Omit on the first turn and one is created for you.
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond annotations, the description candidly discloses that the tool is stateless, buffered not streamed, requires session auth, and may return a model different from the one requested. It also clarifies that citations are merged/de-duplicated and that full conversation history must be re-sent. This is rich behavioral transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the purpose and remains information-dense without padding. Each sentence gives genuinely new context: realtime Grok behavior, output shape, statelessness, and auth requirements. The formatting with clear term emphasis helps an agent parse key constraints quickly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex tool with 9 optional parameters and no output schema, this description covers the needed operational context: what returns, how citations are merged, how conversation continuity works, proxy/authentication concerns, and how turns are affected by mode. This is sufficient for an agent to invoke it with reasonable expectations.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is already well served. The description adds useful semantics not obvious from the schema, such as treating a bare status URL as a first-class message for post summaries and showing that auth_token is never placed in the URL. Those details are not in the parameter names alone.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states a specific action and resource: ask X's own Grok a question AS an authenticated account. It also describes the key output (single JSON reply with answer and citations) and the bare-tweet-URL summary use case, distinguishing it from the many other tweet/user/social-graph tools in the sibling list.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explains when this is uniquely useful, namely for questions about what is being said on X in real time, and that a bare status URL produces a structured post summary. It does not name sibling tools as alternatives or state explicit when-not-to-use cases, but the realtime Grok framing gives solid practical guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/TwitterAPIs/twitterapis-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server