Skip to main content
Use this page when an AI agent needs to choose the right Xquik surface, call live X data, hand results to a backend, or recover missed webhook work. Keep live calls narrow, aggregate high-volume pages inside the sandbox, persist cursor state, and move durable jobs to REST, SDKs, or webhooks.

Pick the agent surface

Docs MCP

Use https://docs.xquik.com/mcp when the agent needs public docs, API reference pages, examples, troubleshooting, or type definitions. It is read-only and requires no auth.

API MCP

Use API MCP v2.5.4 at https://xquik.com/mcp for live calls. Full account keys and OAuth tokens expose 118 operations. Guest paid_reads keys expose exactly 33 eligible GET routes.

REST or SDK

Use REST or generated SDKs when a service owns retries, cursor storage, file downloads, queues, or batch jobs outside the chat session.

Webhooks and Replay

Use monitor webhooks for fresh events and GET /api/v1/events when a receiver, queue, warehouse, or agent run needs replay.

Use the default agent route

  1. Search public docs or llms.txt for the workflow before calling live data.
  2. Use explore before xquik.request(...) to confirm the endpoint path, required parameters, costs, and response shape.
  3. Call xquik.request(path, { method?, body?, query? }) with the smallest useful page size.
  4. Continue while has_more is true and next_cursor advances.
  5. Return normalized rows, IDs, counts, samples, and cursors instead of full raw pages.
  6. Hand long-running or replayable work to REST, SDKs, webhooks, or exports.
Credential lifecycle operations and direct saved-payment mutations are not in the MCP catalog. Guest wallet creation, status, and top-up also remain direct REST only. A 402 creates no checkout. Report its payment choices, ask the user to choose an amount and option, then wait for explicit confirmation. A full account session may execute only an advertised account checkout action in its catalog. Never execute guest wallet routes through MCP.

Route guest paid reads

An active guest key gives explore and xquik a 33-operation read-only catalog. Every route appears in the guest paid-read inventory. Batch GET /api/v1/x/tweets accepts up to 100 tweet IDs. The sandbox cannot execute writes, account actions, automations, billing, credential management, or noneligible reads. OAuth and full account behavior remain unchanged. If the guest key needs creation, activation status, or more credits, leave MCP and follow the accountless guest wallet flow through direct REST: Creation and top-up require explicit user confirmation. Status polling does not create payment. Never place the guest key or its creation Idempotency-Key in tool code, chat output, or shared agent state.

Return stored rows

MCP returns normalized snake_case fields, structured errors, and date-time fields as Unix seconds. Keep agents on has_more and next_cursor even when REST or SDK pages show camelCase response fields. Read a REST createdAt field as created in MCP results.

Follow cursor rules

Full account sessions can check GET /api/v1/credits before large reads. Guest sessions receive balance and top-up context in 402, while the direct REST guest status route reports the current balance. Low balances can return smaller pages, and zero affordable rows can return 402 insufficient_credits. For high-volume MCP reads:
  • De-duplicate tweet or user rows by stable id
  • Continue through empty pages when has_more is true
  • Stop at the requested total, page cap, or has_more: false
  • Stop with cursor_stalled when next_cursor is missing or repeats
  • Return counts, aggregates, or a bounded sample within the 24,000-character tool limit

Persist handoff state

Store the values a later agent, service, or workflow needs to resume without reading chat history.
Keep API keys, webhook secrets, raw request bodies, raw signatures, and full headers out of chat transcripts, shared agent memory, spreadsheets, CRM rows, and queue payloads.

Know when to leave MCP

File Exports

Use extraction export endpoints for CSV, JSON, XLSX, Markdown, or PDF files.

Webhook Receivers

Use signed webhooks when downstream systems need fresh monitor events.

Replay Jobs

Use stored events and delivery rows when receivers miss work.

SDK Backends

Use SDKs when a backend owns retries, storage, and batch orchestration.

Continue with focused references

MCP Tools Reference

Review explore, xquik, sandbox inputs, response contracts, and examples.

Docs MCP Server

Connect read-only documentation search beside the API MCP server.

No-Code Handoff

Hand monitor events, exports, and direct reads to workflow platforms.

Webhook Testing

Verify signed receivers before accepting production events.
Last modified on July 16, 2026