Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@xtapdown-mcp What's the best time to post for my audience in India?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP (Model Context Protocol) server that gives any LLM client — Claude Desktop, Cursor, Cline, Continue, or your own agent — direct access to the XTapDown X (Twitter) creator toolkit.
Six tools, zero auth, zero rate limits for the data tools, free.
Full coverage of every XTapDown web tool — 4 downloaders (video, GIF, image, full archive) consolidated under a single download_tweet since they share one X syndication endpoint.
Tool | Description |
| Download any X post — video, GIF, image, or article. Returns direct media URLs, author info, engagement stats. Covers /twitter-video-downloader, /twitter-gif-downloader, /twitter-image-downloader and /tweet-downloader. |
| Curated X hashtags for a niche (tech, finance, marketing, politics, sports, business, ai, gaming, writing, fitness, design, general) + strategy tips. |
| Best posting windows on X by country (12 countries) with the reasoning behind each slot. |
| Battle-tested tweet hook formulas across 8 categories (Curiosity, Controversy, Authority, List, Story, Question, Numbers, Reframe). |
| Compute engagement rate using the public follower-based formula, with tier-aware benchmark bands. |
| Estimate monthly Premium creator ads-revenue-share payout from impressions, with eligibility check. |
| Live trending topics on X by country (17 countries) — refreshed roughly hourly. |
| X-weighted character count (CJK ×2, emoji ×2, URLs ×23 t.co) with thread-split warning. |
| Split long text into ≤280-char numbered tweets respecting sentence/word boundaries + t.co URL math. |
| Build an X advanced-search URL from structured filters (from:, since:, min_faves:, lang:, filter:media, etc). |
| Convert ASCII to fancy Unicode (bold, italic, monospace, script, double-struck, small-caps, bold-italic) for bios and tweets. |
| Deep-link to the XTapDown screenshot tool with theme + background presets pre-filled (PNG rendering happens client-side in the browser). |
| Top creators in a niche plus 3 viral tweet templates with explanations of why each one works. |
| Full X advanced-search operator reference, grouped by category, updated for 2026. |
Related MCP server: TwitterAPI MCP Server
Add to your claude_desktop_config.json:
{
"mcpServers": {
"xtapdown": {
"command": "npx",
"args": ["-y", "xtapdown-mcp"]
}
}
}Add a stdio MCP server entry pointing at:
npx -y xtapdown-mcpgit clone https://github.com/farukkolip/xtapdown-mcp
cd xtapdown-mcp
npm install
npm run build
node dist/index.jsSet PORT=3000 (or any port) to start the server in HTTP / SSE mode for
Smithery-style hosted deployments. Endpoint: POST /mcp and GET /mcp
following the MCP Streamable HTTP transport spec.
"Download this tweet for me: https://x.com/.../status/..." →
download_tweetreturns direct MP4, thumbnail, author handle, like count.
"What's the best time to post on X if my audience is in Türkiye?" →
get_best_time_to_post_xreturns day-by-day windows in TRT.
"My 50k-follower account got 1,200 likes, 80 reposts, 150 replies. What's my engagement rate?" →
calculate_x_engagement_ratereturns 2.86% (Good — Mid tier).
"I've been getting 8M impressions a month. Would I qualify for ads revenue share?" →
calculate_x_ads_revenuereturns: projected 24M / 25M threshold = not yet eligible, ~$60/mo estimated payout if you cross.
X's API is largely closed to creators. Most third-party tools require paid subscriptions or scrape with hidden rate limits. This server uses X's own public syndication endpoint (the same one embed widgets use) plus inline curated content data, so it works offline-free, no auth, no quota, no surprises.
Once added to your MCP client, the LLM can autonomously fetch tweet data and apply XTapDown's research data to whatever you're working on — content drafts, social audits, strategy threads, monetization math.
Tweet data: cdn.syndication.twimg.com/tweet-result (public, auth-free)
Hashtags / best times / hooks / benchmarks: XTapDown editorial library, 2026 updated
Engagement math: public follower-based formula (likes + reposts + replies + bookmarks + quotes) / followers × 100
Ads revenue math: X Premium Creator Ads Revenue Sharing documented terms (25M imp/3mo + 500 verified followers + Premium)
tiktapdown-mcp — TikTok equivalent
xtapdown.com — full web toolkit with 17 tools
MIT — © Faruk Kolip
Build an X (Twitter) advanced search URL from structured filters. Returns a clickable URL using X's official advanced search operators (from:, since:, until:, min_faves:, lang:, filter:media etc).
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | Posts replying to a specific username (no @) | |
| from | No | Posts from a specific username (no @) | |
| lang | No | ISO 639-1 language code (e.g. 'en', 'es', 'tr') | |
| query | No | Free-text keywords (e.g. 'AI agents') | |
| mentions | No | Posts mentioning a username (no @) | |
| minFaves | No | Minimum likes | |
| sortMode | No | 'top' (relevance) or 'live' (recent) | top |
| sinceDate | No | YYYY-MM-DD lower bound (inclusive) | |
| untilDate | No | YYYY-MM-DD upper bound (inclusive) | |
| minReplies | No | Minimum replies | |
| mediaFilter | No | Media type filter | |
| minRetweets | No | Minimum reposts | |
| minBookmarks | No | Minimum bookmarks (the strongest save signal in 2026) | |
| verifiedOnly | No | filter:verified — verified accounts only | |
| excludeReplies | No | -filter:replies — exclude replies | |
| excludeRetweets | No | -filter:retweets — exclude reposts |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states that the URL uses X's advanced search operators but does not disclose any behavioral traits such as rate limits, authentication requirements, or error handling. Minimal information is given beyond the basic function.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two sentences, front-loaded with the core purpose, and contains no extraneous information. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a URL-building tool with 16 optional parameters and no output schema, the description covers the essential purpose and output. It could mention that the URL targets X's web UI or that parameters are encoded, but it is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds minor context by mentioning specific operators like from:, since:, etc., but does not significantly enhance understanding beyond the schema's detailed parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it builds an X advanced search URL from structured filters and returns a clickable URL. It specifies the resource (X search URL) and the action (build from filters), and no sibling tool performs the same function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for converting structured filters into a search URL but does not explicitly state when to use this tool vs alternatives, nor does it mention when not to use it. Sibling tools include other X utilities but none are direct alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Estimate monthly X Premium Creator Ads Revenue Share payout from impressions. X pays creators based on ads shown in REPLIES to their posts, not the posts themselves — so reply density is the lever. Requires X Premium + 500 verified followers + 25M impressions over the trailing 3 months for eligibility.
| Name | Required | Description | Default |
|---|---|---|---|
| cpmEstimate | No | Estimated CPM in USD for reply ads (industry estimate $1.50-$4 — default $2.50) | |
| avgRepliesPerPost | No | Average replies per post (drives ad inventory in replies — default 20) | |
| monthlyImpressions | Yes | Total impressions on your posts in the past 30 days |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses the estimation nature and the key driver (reply density), and implies it is a read-only calculation. It does not mention side effects, but for a calculation tool, this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the core purpose, and each sentence adds essential context (mechanism, eligibility). No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple calculation tool, the description covers purpose, mechanism, and eligibility. However, it does not specify the output format (e.g., estimated monthly payout in USD), assuming user inference from parameter defaults. Still, it is mostly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (all three parameters have descriptions in the schema). The tool description adds contextual information about reply density as a lever but does not add new parameter-specific details beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool estimates X Premium Creator Ads Revenue Share payout from impressions, explaining the mechanism (ads in replies) and eligibility. It distinguishes itself from sibling tools, none of which perform revenue estimation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: estimating revenue share with explicit eligibility requirements (X Premium, 500 followers, 25M impressions). However, it does not explicitly mention when not to use this tool or suggest alternative tools, though none exist among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculate X (Twitter) engagement rate using the public follower-based formula: (likes + reposts + replies + bookmarks + quotes) / followers × 100. Returns the percentage and the tier-aware benchmark band (Excellent / Good / Average / Low / Inactive).
| Name | Required | Description | Default |
|---|---|---|---|
| likes | Yes | Likes on the post (or sum across posts) | |
| posts | No | Number of posts the engagement is summed over (default 1) | |
| quotes | No | Quote tweets (optional, default 0) | |
| replies | Yes | Reply count | |
| reposts | Yes | Reposts / retweets | |
| bookmarks | No | Bookmarks (optional, default 0) | |
| followers | Yes | Account follower count |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description discloses the formula and output format (percentage and benchmark band). It does not mention error handling, data sourcing, or restrictions beyond the schema. Adequate for a calculation tool but could elaborate on behavior (e.g., it uses provided numbers, not live data).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence that efficiently conveys the formula, output, and benchmark. No superfluous text; every part earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given full schema coverage and no output schema, the description sufficiently explains the tool's purpose and return value. It could mention that followers must be positive (implied by schema exclusiveMinimum:0) but overall complete for agent usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with each parameter described. The description adds the formula context but does not enhance parameter meaning beyond the schema. Baseline 3 as schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool calculates X engagement rate using a specific formula and returns percentage with benchmark band. Verb 'calculate' and resource 'X engagement rate' are explicit. Distinguishes from siblings like 'build_x_search_url' or 'calculate_x_ads_revenue'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description indicates when to use the tool: when needing to compute engagement rate via the follower-based formula. It does not explicitly state when not to use it or list alternatives, but the context is sufficiently clear given sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Count tweet characters using X's official weighted-length formula. CJK ideographs, fullwidth chars, and most emoji count as 2; URLs always count as 23 (t.co shortening). Returns char count, remaining budget for free + Premium limits, and a warning if a thread split is needed.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Tweet text to measure |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description fully carries the burden. It discloses behavioral traits: uses official weighted-length formula, specific counting rules, and output includes char count, remaining budget, and thread split warning. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, no wasted words. Efficiently conveys all necessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema, no annotations), the description is complete. It covers purpose, how it works, what it returns, and even hints at related functionality (thread split warning).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has one parameter 'text' with 100% coverage. Description adds significant meaning beyond schema: explains that text is measured by weighted-length formula and details character counting rules, augmenting the minimal schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool counts tweet characters using X's official weighted-length formula, specifies character weightings (CJK, emoji, URLs), and mentions return values (char count, remaining budget, thread split warning). It distinguishes well from siblings like split_long_text_into_thread.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly indicates usage for measuring tweet character count respecting X's rules, and hints at integration with thread splitting. However, it lacks explicit when-not-to-use instructions or direct alternatives, though the purpose is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Download an X (Twitter) post — video, GIF, images, or article. Returns direct media URLs, author info, and engagement stats. Uses the public X syndication endpoint, no auth required.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | X / Twitter post URL (e.g. https://x.com/user/status/12345 or twitter.com equivalent) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the full burden. It discloses that the tool uses a public endpoint and requires no auth, and it explains what is returned. It does not mention potential rate limits or destructive behavior, but the read-only nature is implied.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise with two sentences that front-load the action and then provide specifics. No extraneous words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple input (one URL parameter) and no output schema, the description is fairly complete. It covers purpose, return values, and authentication. It could mention that it returns URLs rather than files, but that is clear. It lacks information on limits, but for a basic tool it's adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description does not add extra semantic information about the parameter beyond what the schema provides (URL format). The description focuses on output, not parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool downloads an X post, lists the content types (video, GIF, images, article), and mentions returned data (media URLs, author info, engagement stats). It is distinct from siblings which are for search URLs, calculations, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies that no authentication is required, which guides usage. It does not explicitly state when to use this tool versus alternatives, but the sibling tools do not overlap in functionality, so the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the top X (Twitter) creators in a niche plus 3 viral tweet templates with explanations of why each one works. Pulls from XTapDown's curated viral pattern library.
| Name | Required | Description | Default |
|---|---|---|---|
| niche | Yes | Niche to surface viral patterns for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions a data source (XTapDown library) but does not disclose whether the tool is read-only, data freshness, error handling, or any side effects. The behavioral profile is under-explained.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words. The first sentence front-loads the main action and output, the second provides context. Highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, so description should explain expected return format. It mentions 'top X creators' and '3 viral tweet templates' but not their structure (e.g., creator names, template text). Adequate for a simple tool but could be more explicit.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema describes 'niche' parameter with enum values. The description adds context: 'surface viral patterns for', which clarifies the parameter's role beyond the schema. Schema coverage is 100%, so the description adds value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's specific function: returning top creators and viral tweet templates for a given niche. It distinguishes from siblings by offering a combined output of creators plus templates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives. It does not mention when not to use it or reference sibling tools like generate_tweet_hook or get_x_trends. The context of use is implied but not clarified.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Convert plain ASCII text into a fancy Unicode style suitable for X bios and tweets. 7 styles supported: bold, italic, boldItalic, monospace, script, doubleStruck, smallCaps.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | ASCII text to transform | |
| style | Yes | Style preset |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. It lists supported styles but fails to disclose limitations (e.g., character support, case handling, or potential transformation failures), leaving agents uninformed about edge cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, well-structured sentence front-loads the purpose and immediately lists the styles, making it efficient and easy to parse with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with two straightforward parameters and no output schema, the description covers the core transformation, target platforms, and style options. It lacks behavioral nuances but is largely complete given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds the list of 7 styles, which matches the enum, and restates 'ASCII text to transform', providing no significant extra meaning beyond the schema definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'convert', the resource 'plain ASCII text', and the output 'fancy Unicode style', making the purpose specific and easily distinguishable from sibling tools that focus on X utilities like search, ads, or tweet hooks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions suitability for 'X bios and tweets', implying a use case, but does not explicitly state when to use this tool versus alternatives or provide conditions for avoidance. Given no direct sibling for text styling, the guidance is adequate but minimal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate proven tweet hook formulas for a category. Returns 3 ready-to-use templates with examples and execution tips. Hooks must land in line one because the rest of the post is hidden until tap.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | No | Optional topic (e.g. 'AI agents', 'crypto') to customize the examples | |
| category | Yes | Hook category |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses output format (3 templates, examples, tips) and a behavioral constraint (hooks must land in line one). However, it does not mention auth requirements, rate limits, or side effects, though none are expected.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose. The first sentence states what it does, the second adds a critical usage tip. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, description sufficiently explains returns (3 templates, examples, tips). Both parameters are covered, and the line one constraint is important context. Complete for a simple generation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, both parameters have descriptions in schema. The description adds minimal extra meaning for topic ('to customize the examples'), which is already in schema. No additional semantic value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates tweet hook formulas for a category and returns 3 templates with examples and tips. It distinguishes from sibling tools like 'build_x_search_url' or 'calculate_x_engagement_rate' which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for generating hooks but does not explicitly state when to use or when not to use. It provides a key tip about hooks needing to be in line one, but lacks alternative guidance or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the best times to post on X (Twitter) for a country, with day-by-day windows and the reasoning behind each slot. X engagement curves differ from TikTok — weighted toward morning commute, lunch, and evening news windows.
| Name | Required | Description | Default |
|---|---|---|---|
| country | Yes | Country code |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. It states the output includes 'day-by-day windows and reasoning' but does not disclose any side effects, authentication requirements, rate limits, or other behaviors. The description lacks depth on what the tool does beyond its basic function.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, with the purpose front-loaded. Every sentence adds valuable context: the first states the core functionality, the second provides platform-specific engagement patterns. There is no wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with only one parameter and no output schema, the description is complete enough. It explains what the tool returns (day-by-day windows and reasoning) and provides relevant context about X vs. TikTok. No additional information seems necessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema describes the single parameter 'country' fully (enum values and a brief description 'Country code'). The description does not add any additional meaning or usage guidance for this parameter. With schema coverage at 100%, a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get the best times to post on X (Twitter) for a country, with day-by-day windows and the reasoning behind each slot.' It uses a specific verb ('Get') and resource ('best times to post on X'), and distinguishes it from siblings by targeting platform-specific timing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context for when to use the tool by noting that 'X engagement curves differ from TikTok — weighted toward morning commute, lunch, and evening news windows.' This implies it is suitable for X-specific timing decisions, but it does not explicitly mention when not to use it or list alternative sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a deep-link to XTapDown's tweet screenshot tool with the tweet URL and styling pre-filled. The PNG/JPG rendering happens client-side in the browser — this tool returns a ready-to-open URL plus a checklist of available styles.
| Name | Required | Description | Default |
|---|---|---|---|
| theme | No | Native X theme to render against | light |
| tweetUrl | Yes | X (Twitter) post URL to screenshot | |
| background | No | Decorative background preset | plain |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that rendering is client-side and returns a ready-to-open URL with a checklist. While it doesn't cover error handling or limitations, the transparency is adequate for a simple URL generation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary action, and contains no extraneous words. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given three parameters and no output schema, the description covers the key aspects: what it does, output nature (URL + checklist), and client-side behavior. It could be more specific about the checklist contents but is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for each parameter. The description adds context that styling parameters are pre-filled and mentions a checklist of available styles, which augments the schema meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates a deep-link to XTapDown's tweet screenshot tool with URL and styling pre-filled. It uses a specific verb and resource, and distinguishes itself from sibling tools like download_tweet and build_x_search_url.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the tool returns a URL and checklist, but does not explicitly state when to use it versus alternatives (e.g., download_tweet). No exclusion criteria or when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get curated X (Twitter) hashtags for a niche, plus 3 strategy tips on how to use them. Hashtag rules on X differ sharply from TikTok or Instagram — max 1-3 tags per post.
| Name | Required | Description | Default |
|---|---|---|---|
| niche | Yes | Niche label |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the output is 'curated hashtags plus 3 strategy tips', implying a read-only, non-destructive operation. However, it does not disclose any side effects, authentication needs, or limitations like update frequency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose and output, followed by relevant usage context. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (single enum parameter, no output schema), the description is nearly complete. It specifies the output type (hashtags + tips) and a key usage rule. Minor omission: exact output format is not detailed, but this is acceptable for a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% coverage for the single parameter 'niche' with an enum list. The description adds 'for a niche' but does not elaborate on how to choose or interpret the niche values beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves curated X hashtags for a niche plus strategy tips. It is distinct from sibling tools like 'build_x_search_url' or 'calculate_x_engagement_rate', which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives context about X hashtag rules differing from TikTok/Instagram and recommends 1-3 tags per post, helping agents understand when this tool is relevant. However, it does not explicitly contrast with alternatives like 'get_x_trends' or provide when-not scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the complete X (Twitter) advanced search operators reference, grouped by category, with syntax / example / description for each operator. Updated for 2026.
| Name | Required | Description | Default |
|---|---|---|---|
| category | No | Filter by category — or 'all' for the full sheet | all |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It transparently describes return content (grouped by category, with syntax/example/description) and notes it is updated for 2026. No side effects or limitations are mentioned, but for a read-only reference tool, this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, perfectly concise with no wasted words. Every piece of information earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple optional parameter and no output schema, the description fully explains what the tool returns and how to filter. No additional details needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (one parameter with enum and description). The tool description adds no additional meaning beyond what the schema provides, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Return the complete X (Twitter) advanced search operators reference' with details on grouping, syntax, example, and description. It distinguishes from sibling tools like 'build_x_search_url' which constructs URLs rather than returning a reference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving operators but does not explicitly state when to use this tool versus siblings or provide exclusions. No guidance on when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the current top trending topics on X (Twitter) for a country. Live data refreshed roughly hourly by the XTapDown trends collector.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max trends to return (1-50, default 20) | |
| country | Yes | Country code (ISO 3166-1 alpha-2) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that data is live and refreshed hourly, which is useful. No annotations are present, so description carries full burden. Does not mention rate limits or authentication, but for a read-only trends tool, this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with key action and resource, no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description doesn't indicate return format (e.g., list of strings). For a simple tool, the lack of output structure is a minor gap. Context signals indicate low complexity, so a 3 is appropriate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description does not add extra meaning beyond the schema's parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves current top trending topics on X for a country, using specific verbs and resource. It distinguishes from siblings like get_x_hashtags.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides refresh frequency context but no explicit when-to-use or when-not-to-use guidance relative to siblings. However, the purpose is straightforward and no direct alternative exists among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Split a long text into a numbered tweet thread (each tweet ≤ 280 chars). Uses X's weighted-length formula and t.co URL shortening (URLs always count as 23). Prefers sentence boundaries, then paragraph, then word.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Long text to thread-split | |
| numbered | No | Append ' i/N' numbering to each tweet |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses important behaviors: use of X's weighted-length formula, t.co URL counting (23 chars), and boundary preference hierarchy. This aids the agent in understanding operational nuances.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences efficiently convey the purpose, constraints, and behavior. The first sentence states the primary action and limit; the second adds critical details. No redundant or superfluous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and two simple parameters, the description covers the main aspects: input, output format (implicitly a thread), and splitting logic. It adequately prepares the agent, though it does not specify edge cases like unsplittable text.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear parameter descriptions. The description adds minimal new information beyond the schema—only reinforcing the numbering format. Baseline score of 3 applies since the schema already documents parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'split' and resource 'long text into a numbered tweet thread' with specific constraints (≤280 chars). It distinguishes from sibling tools that address different X tasks, such as character counting or URL building.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
While the description does not explicitly state when not to use it, the context is clear: use it to split a long text into tweets. It provides implicit guidance by mentioning preferences for sentence boundaries, which helps the agent understand splitting behavior.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.2.1build_x_search_urlcalculate_x_ads_revenuecalculate_x_engagement_ratecount_tweet_charactersdownload_tweetfind_viral_tweets_for_nichegenerate_fancy_unicode_textgenerate_tweet_hookget_best_time_to_post_xget_tweet_screenshot_urlget_x_hashtagsget_x_search_operators_cheatsheetget_x_trendssplit_long_text_into_threadScored across 14 tools
Tools are mostly distinct with clear purposes. Minor overlap exists between 'build_x_search_url' and 'get_x_search_operators_cheatsheet' (both about search) and between 'generate_tweet_hook' and 'find_viral_tweets_for_niche' (both about viral content), but descriptions differentiate them adequately.
All tool names use a consistent snake_case verb_noun pattern (e.g., 'build_x_search_url', 'calculate_x_ads_revenue', 'split_long_text_into_thread'). No mixing of styles or vague verbs.
14 tools cover the X/Twitter marketing domain comprehensively without being excessive. Each tool serves a distinct purpose in content creation, analysis, or optimization.
The set covers most key X/Twitter tasks: search, engagement, trends, posting optimization, formatting, and media retrieval. Missing a direct posting tool (create_tweet) but that may be out of scope for an analysis-focused server.
An MCP server that gives any LLM or agent clean YouTube transcripts on demand: a single video, a whole channel, or a playlist, plus AI cleanup of auto-generated captions. API-key auth, credit-based, same backend as the public v1 API. Get a free API key with 25 free credits at youtubetranscriptdownload.com/account.
Twitter/X read-only MCP server — 12 tools: search, users, tweets, followers, timelines, trends.
MCP server providing access to the Scorecard API to evaluate and optimize LLM systems.
