| name | xquik-social-data |
| description | Use Xquik for X and Twitter social data workflows through its public API, SDKs, MCP server, webhooks, and installable agent skill. |
| version | 0.1.0 |
| author | kriptoburak |
| tags | ["xquik","twitter","x","social-data","api","mcp"] |
Xquik Social Data
Use this skill when a user needs to collect, normalize, monitor, or automate X and Twitter data with Xquik. Xquik provides a public REST API, generated SDKs, an HTTP MCP server, webhooks, and an installable agent skill for common social data workflows.
When to Use
- Search tweets, inspect tweet details, or collect account timelines
- Fetch user profile data, followers, following, mentions, media, or engagement data
- Run bulk extraction jobs for replies, quotes, posts, media, lists, communities, or people search
- Set up monitors and webhook delivery for new social events
- Use Xquik from an AI agent through the public MCP server or installable skill
- Draft, schedule, or confirm write actions only when the user explicitly asks
Required Inputs
XQUIK_API_KEY for API, SDK, or MCP calls
- The target endpoint, task type, username, tweet URL, tweet ID, query, or extraction type
- The desired output shape, such as JSON, CSV, summary, dashboard table, or webhook payload
- User confirmation before private reads, write actions, monitor creation, webhook delivery, or bulk jobs
Workflow
-
Read the public Xquik docs before selecting endpoints. Start with the API reference for REST routes and the MCP guide for agent setup.
-
Use the installable skill when the agent supports Skills:
npx skills@1.5.3 add Xquik-dev/x-twitter-scraper
-
For JavaScript or TypeScript helpers, pin the validated package version:
npm install x-developer@2.4.16
-
Keep credentials in environment variables or the host secret store. Never paste API keys into prompts, logs, source files, PRs, or issue text.
-
Choose the narrowest endpoint or extraction type that satisfies the task. Do not fetch extra pages, private data, or write-capable resources without user approval.
-
Preserve pagination metadata such as next_cursor and has_more. For long jobs, estimate first, start the job, then poll the documented job endpoint until it finishes or fails.
-
Normalize outputs before analysis. Keep raw IDs, source URL, collected-at time, query parameters, and pagination state so results can be audited later.
-
For monitors and webhooks, confirm the target account or keyword, event types, destination URL, and ongoing behavior before creating resources.
Output Shape
Return structured results unless the user asks for prose only:
{
"source": "xquik",
"task": "tweet-search",
"query": "from:example launch",
"items": [],
"has_more": false,
"next_cursor": null,
"notes": []
}
For summaries, include the query, time window, result count, missing fields, and any follow-up cursor or job ID.
Safety Checks
- Stop when the task needs an unsupported endpoint or unavailable data. Do not guess response fields.
- Ask for explicit confirmation before write actions, private reads, monitor creation, webhook delivery, or large extraction jobs.
- Do not log, echo, or commit
XQUIK_API_KEY.
- Do not present internal implementation details. Describe the public API, SDKs, MCP server, webhooks, and documented workflows only.
- Check public links and package availability before adding install snippets to docs or generated output.
References