Provides tools for downloading TikTok videos, retrieving viral hashtags by niche, best posting times by country, and generating hook formulas.
Give Claude, Cursor, Windsurf and any MCP-compatible AI assistant the power to download TikTok videos, find viral hashtags by niche, get best posting times by country, and generate hook formulas — all in one MCP server. Free, no API keys required.
Companion web app → tiktapdown.com
If you're a TikTok creator, marketer, or social media agency using Claude or any MCP client, you can now:
Pull a watermark-free MP4 of any TikTok directly into your AI conversation
Get curated hashtag sets your AI can use when drafting captions
Ask "when should I post in Germany?" and get a concrete answer
Generate scroll-stopping opening lines without leaving Claude
No browser, no copy-paste, no third-party watermarks.
Related MCP server: TikTok Complete MCP Server
10 tools covering downloading, sound discovery, monetization analysis, and content planning.
Tool | What it does |
| Download any TikTok video. Returns no-watermark + watermark MP4 links and full metadata. |
| Extract audio (MP3) from a TikTok video for sound discovery and trend research. |
| Top 15 hashtags for 15 niches with strategy tips per niche. |
| Best posting windows for 12 countries with reasoning. |
| 8 hook categories × 3 formulas with concrete examples. |
| Estimate Creator Rewards revenue per niche × country × views. 16 niches, 16 countries. |
| Compute engagement rate from views/likes/comments/shares and benchmark against tiers. |
| Convert text to 7 Unicode font styles (bold, italic, cursive, monospace, double-struck, fraktur) for bios and captions. |
| Live snapshot of trending music, hashtags, and videos for 16 countries. |
| TikTok-specific keyword intent classification with related keywords and content angles. |
Add to your claude_desktop_config.json:
{
"mcpServers": {
"tiktapdown": {
"command": "npx",
"args": ["-y", "tiktapdown-mcp"]
}
}
}git clone https://github.com/farukkolip/tiktapdown-mcp
cd tiktapdown-mcp
npm install && npm run buildThen add to claude_desktop_config.json:
{
"mcpServers": {
"tiktapdown": {
"command": "node",
"args": ["/ABSOLUTE/PATH/TO/tiktapdown-mcp/dist/index.js"]
}
}
}Config file location:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
Restart Claude Desktop after editing the config.
Add to ~/.cursor/mcp.json:
{
"mcpServers": {
"tiktapdown": {
"command": "npx",
"args": ["-y", "tiktapdown-mcp"]
}
}
}Add to ~/.codeium/windsurf/mcp_config.json:
{
"mcpServers": {
"tiktapdown": {
"command": "npx",
"args": ["-y", "tiktapdown-mcp"]
}
}
}Once installed, you can ask Claude:
"Download this TikTok for me: https://www.tiktok.com/@user/video/123"
"What are the best hashtags for my fitness TikToks?"
"When should I post on TikTok if my audience is in Germany?"
"Write me a curiosity hook for my finance content"
"Save this TikTok and write a caption with hashtags for fitness niche"
US 🇺🇸 · GB 🇬🇧 · AU 🇦🇺 · CA 🇨🇦 · TR 🇹🇷 · DE 🇩🇪 · FR 🇫🇷 · BR 🇧🇷 · MX 🇲🇽 · JP 🇯🇵 · SA 🇸🇦 · AE 🇦🇪
Fitness · Beauty · Food · Travel · Tech · Education · Finance · Fashion · Lifestyle · Gaming · Motivation · Business · Pets · Music · Comedy
Curiosity · Contrarian · Listicle · How-To · Story · Question · Stat-Drop · Pattern-Interrupt
Web app: tiktapdown.com — same toolset in the browser
MCP spec: modelcontextprotocol.io
TikTapDown is the first tool in a family of focused creator utilities, one platform at a time.
🎵 TikTapDown (TikTok) — live
📷 Instapdown (Instagram) — coming
🐦 XTapdown (X) — coming
📺 YouTapDown (YouTube) — coming
📌 PinTapdown (Pinterest) — coming
Each tool: simple, free, no fluff. Follow the build at @tapdown_ on X or u/tapdown_ on Reddit.
MIT — built by farukkolip. Web companion: tiktapdown.com
Calculate a TikTok video or account engagement rate and benchmark it against tier averages. Inputs are raw counts; output includes ER percentage, tier classification, and improvement tips.
| Name | Required | Description | Default |
|---|---|---|---|
| likes | Yes | Total likes | |
| saves | No | Optional: saves (TikTok counts these as bookmarks) | |
| views | Yes | Total views | |
| shares | Yes | Total shares | |
| comments | Yes | Total comments |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose side effects. It describes inputs and outputs but does not explicitly state that the tool is read-only or has no side effects. However, the nature of calculation implies no data modification, which is conveyed indirectly. Could be more explicit.
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 effectively communicate purpose and scope, with no redundant information. Well front-loaded.
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 lack of output schema, the description provides a reasonable overview of outputs. However, it could include more detail on how tier averages are determined or the improvement tips, but it is sufficient for most use cases.
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 covers 100% of parameters with descriptions. The description adds value by stating the output components (ER percentage, tier, tips) and that inputs are raw counts, which enhances understanding beyond the 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 it 'Calculates a TikTok video or account engagement rate and benchmark it against tier averages.' The verb 'calculate' specifies the action, and 'engagement rate' distinguishes from sibling tools like RPM calculation or extraction tools.
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 does not explicitly state when to use this tool over alternatives, but the purpose is distinct from siblings which handle different TikTok metrics. The context of 'raw counts' implies use when raw data is available, but no explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Estimate TikTok Creator Rewards revenue for a given niche, audience country, and view count. Returns RPM range, per-video estimate, and monthly projection. Based on 2026 Creator Rewards benchmarks.
| Name | Required | Description | Default |
|---|---|---|---|
| niche | Yes | Content niche | |
| views | Yes | Total views per video (or campaign) | |
| country | Yes | Primary audience country | |
| videosPerMonth | No | Optional: videos per month for monthly projection |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It describes the outputs (RPM range, per-video estimate, monthly projection) but does not explicitly state that it is a safe, read-only operation or disclose any side effects. The behavior is implied as a calculator, but more explicit transparency would improve the score.
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 with no unnecessary words. It front-loads the main purpose and output, then adds a single detail about the data source. 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 the complexity (4 parameters, no output schema), the description covers the main purpose, inputs, and outputs. It lacks detail on the exact format of the returned values (e.g., whether RPM range is a string or structured object), but it is still generally complete for a straightforward estimation 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% with each parameter having a description. The description adds context about the output and that 'videosPerMonth' is optional for monthly projection, but does not significantly enhance parameter understanding 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 TikTok Creator Rewards revenue, specifying the verb 'estimate' and the resource (revenue for a given niche, audience country, and view count). It distinguishes itself from sibling tools like calculate_tiktok_engagement_rate by focusing on 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 context on usage (estimating RPM for a niche, country, and view count) but does not explicitly state when not to use it or contrast with alternatives. However, given the niche focus, it is adequately clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Convert plain text to Unicode font styles for TikTok bios, captions, and on-screen text. Supports bold, italic, boldItalic, cursive, monospace, doubleStruck, and fraktur.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Text to convert (max 280 characters, like a tweet) | |
| style | Yes | Font style to apply |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It describes the transformation from plain text to Unicode font styles, which is a simple and non-destructive operation. However, it does not explicitly state that the tool is safe, read-only, or has no side effects. For a straightforward conversion tool, this is adequate but lacks proactive behavioral disclosure.
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: the first states the action and context, the second lists the supported styles. It is concise, front-loaded, and contains no unnecessary information. Every sentence serves a purpose.
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?
The tool is simple with two parameters and a straightforward transformation. The description provides sufficient context for using it on TikTok. However, it does not mention the output format or return value, which might be assumed to be the converted text. For a tool of this complexity, this minor gap does not significantly impair completeness.
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%, with both parameters (text and style) documented in the input schema. The description adds minimal extra value beyond the schema, essentially reiterating the supported font styles. Given high schema coverage, 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 converts plain text to Unicode font styles specifically for TikTok bios, captions, and on-screen text. It lists all seven supported styles, making the action and resource unambiguous. The purpose is distinct from sibling tools which are all about TikTok analytics and content generation.
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 the context of use (TikTok bios, captions, on-screen text) and implicitly indicates this tool is for formatting text, not for analytics like sibling tools. However, it does not explicitly state when not to use it or mention any prerequisites or alternatives outside this tool set.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Download a TikTok video without watermark. Returns direct download links (no-watermark + with-watermark), video title, author info, and stats.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The TikTok video URL (e.g. https://www.tiktok.com/@user/video/123456789) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses return values (download links, title, author, stats) but omits behavioral traits like rate limits, required authentication, or whether the download is permanent. Moderate transparency but missing operational details.
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 sentence that packs essential information: action, output specifics, and result format. No filler, logically structured, and front-loaded with the core action.
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?
Without an output schema, the description compensates by listing return values (links, title, author, stats). This is sufficient for a simple download tool with one input. However, missing details like file quality or size would improve completeness for production use.
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 a single parameter. The description adds an example URL pattern in the schema, matching the baseline expectation. No additional parameter meaning beyond what the schema provides, leading to a midpoint score.
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 a TikTok video without watermark, distinguishing it from siblings like extract_tiktok_audio_mp3 or calculate_tiktok_engagement_rate. The verb 'download' and resource 'TikTok video' are specific and unambiguous.
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 guidance on when to use this tool versus alternatives. For example, it does not mention that extract_tiktok_audio_mp3 is for audio-only downloads or that other tools cover analytics. The agent must infer usage context from sibling names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extract the audio (MP3) from a TikTok video. Returns the original sound title, artist, and a direct audio download link useful for sound discovery, music analysis, and trend research.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The TikTok video URL |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must cover behavioral traits. It lists outputs (title, artist, download link) and use cases, which provides moderate transparency. However, it does not disclose potential risks, authentication needs, or link expiration.
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 with no wasted words. The first sentence states the core action, and the second adds return details and use cases. It is well-structured and front-loaded.
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 one parameter and no output schema, the description adequately covers purpose, return values, and use cases. It lacks only minor details like error handling or link validity, which are not critical for a typical agent.
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 'url' with a clear description. The tool description adds no additional constraints or format details beyond what the schema provides, so score is at baseline.
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 extracts audio (MP3) from a TikTok video, specifying the exact resource and action. It distinguishes itself from siblings like download_tiktok_video by focusing on audio extraction, making the purpose unambiguous.
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 hints at use cases (sound discovery, music analysis, trend research) but does not explicitly guide when to use this tool over alternatives like download_tiktok_video or get_tiktok_hashtags. No when-not-to-use instructions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate proven viral TikTok hook formulas for a specific category. Returns 3 ready-to-use hook templates with examples and tips.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | No | Optional: your specific topic to customize examples (e.g. 'fitness', 'investing', 'cooking') | |
| category | Yes | The hook category/type that fits your content |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries burden. States it 'returns' templates (read behavior). Does not disclose authentication needs, rate limits, or what happens with invalid input (though enum prevents invalid category). Adequate for a generation tool, but could note that it is a safe, stateless operation.
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, no extra words. Key info (purpose, category constraint, output quantity) is front-loaded. Every element 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 two parameters (one optional, one enum) and no output schema, the description sufficiently covers what is needed. It states return format (3 templates with examples and tips). Minor gap: no detail on whether 'topic' modifies examples, but schema description covers it. Slightly above baseline.
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 both parameters. Description adds no additional semantics beyond the schema's own descriptions of 'category' and 'topic'. 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?
Description uses specific verb 'generate' and resource 'viral TikTok hook formulas' with clear scope: 'for a specific category'. It specifies output quantity (3 templates). Distinct from all sibling tools which deal with analytics, formatting, or downloads.
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?
Implied usage context for content creation, but no when-not or alternative tool guidance. Since siblings are unrelated, the tool is self-contained, but explicit usage instructions are missing.
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 TikTok for a specific country, with day-by-day recommendations and the reasoning behind each time slot.
| Name | Required | Description | Default |
|---|---|---|---|
| country | Yes | Country code (US, GB, AU, CA, TR, DE, FR, BR, MX, JP, SA, AE) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description mentions output details (day-by-day recommendations and reasoning), which offers some behavioral insight beyond a simple 'get'. However, with no annotations provided, it lacks disclosure on authentication, rate limits, or whether the operation is read-only, leaving the agent with minimal safety cues.
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, front-loaded with verb and resource, no wasted words. Every part of the description adds value to the agent's understanding.
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 one parameter and no output schema, the description covers the main purpose and output structure (recommendations with reasoning). It lacks detail on the exact format of recommendations or any prerequisites, but it is largely complete for basic selection.
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% for the single parameter 'country', which already defines the enum and purpose. The description adds no new semantic information for the parameter beyond restating its role, so it meets the baseline for high coverage without adding 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 'Get the best times to post on TikTok for a specific country' with specific verb and resource, and adds 'day-by-day recommendations and reasoning', making it distinct from sibling tools like engagement rate, RPM, fonts, downloads, hooks, hashtags, keyword research, and trends.
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 the tool is for determining optimal posting times per country but provides no explicit guidance on when to use versus alternatives or when not to use it. With siblings like 'get_tiktok_trends_by_country', more contextual differentiation would be helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the top 15 TikTok hashtags for a specific niche, plus 3 expert strategy tips on how to use them effectively.
| Name | Required | Description | Default |
|---|---|---|---|
| niche | Yes | The content niche to get hashtags for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that it returns top 15 hashtags and tips, but does not elaborate on potential behavioral aspects such as authentication requirements, rate limits, or output format. With no annotations provided, the description must carry the full burden, and while it gives some useful detail, it lacks comprehensive behavioral disclosure.
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 a single sentence that concisely communicates the tool's primary function and output. No redundant or unnecessary words are present.
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 one parameter and no output schema, the description adequately covers what the tool does and what it returns. It is complete enough for an agent to select and invoke the tool correctly, though it could mention more about the output structure.
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 has 100% coverage with a clear description for the 'niche' parameter. The tool description does not add new semantic meaning beyond what the schema provides, so it meets the baseline expectation.
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 retrieves the top 15 TikTok hashtags for a specific niche and provides 3 strategy tips. This is a specific verb+resource combination that distinguishes it from siblings like 'get_tiktok_keyword_research' or 'get_tiktok_trends_by_country'.
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 when hashtags for a niche are needed, but it does not provide explicit guidance on when to use this tool versus alternatives. No mention of prerequisites, exclusion criteria, or comparison with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get TikTok-specific keyword research data: search intent type, suggested related keywords, and content angle ideas. Useful for planning a TikTok content calendar.
| Name | Required | Description | Default |
|---|---|---|---|
| keyword | Yes | Seed keyword to research (e.g. 'meal prep', 'productivity hacks', 'iPhone tips') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states the output types but does not mention side effects, rate limits, authentication needs, or whether it is a read-only operation. For a tool that likely performs a read query, more transparency is needed.
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 first sentence stating the purpose and outputs, and the second providing a use case. Every part is useful and 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?
Given no output schema, the description sufficiently explains the types of data returned (search intent, related keywords, content angle ideas). For a research tool with a single parameter, this is adequate, though an indication of return format or pagination would improve completeness.
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?
With 100% schema description coverage, the input schema already explains the 'keyword' parameter with examples. The tool description does not add additional semantic context beyond what the schema provides, so 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 verb 'Get' and the resource 'TikTok-specific keyword research data' and lists specific outputs: search intent type, suggested related keywords, and content angle ideas. It distinguishes well from sibling tools which cover engagement rate, RPM, hashtags, 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 offers a concrete use case ('planning a TikTok content calendar'), which helps the agent decide when to use this tool. However, it does not explicitly mention when not to use or compare with alternatives; though siblings are clearly different, so the context is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the current trending TikTok music, hashtags, and videos for a specific country. Returns a snapshot of what is climbing right now. Data is refreshed daily.
| Name | Required | Description | Default |
|---|---|---|---|
| country | Yes | Country code |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that the tool returns a snapshot of trending content and that data is refreshed daily, indicating it is read-only and not real-time. This is transparent enough for a simple read operation.
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 purpose, and contains no fluff. 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 the single required parameter and lack of output schema, the description sufficiently covers purpose, data refresh, and scope. No missing information is critical for tool invocation.
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 the country parameter fully described in the schema (enum and description 'Country code'). The description adds no new meaning beyond context, so 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 uses the specific verb 'Get' and clearly identifies the resource as 'current trending TikTok music, hashtags, and videos for a specific country.' This distinguishes it from sibling tools like calculate_tiktok_engagement_rate or generate_tiktok_hook.
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 states it is for a specific country and that data is refreshed daily, providing clear context. However, it does not explicitly state when not to use this tool or suggest alternatives, though sibling tools are listed for differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool targets a distinct TikTok-related function: engagement calculation, revenue estimation, font conversion, video downloading, audio extraction, hook generation, best time to post, hashtags, keyword research, and trends. No overlap in purpose.
Most tools follow a consistent verb_noun pattern in snake_case (e.g., calculate_tiktok_engagement_rate, download_tiktok_video). Minor deviation: 'get_best_time_to_post' uses a different structure (verb_adjective_noun_to_verb), and 'convert_tiktok_unicode_font' includes the domain in the middle rather than at the end.
With 10 tools covering analytics, content creation, and media handling, the count is well-scoped for a TikTok utility server. Each tool earns its place without redundancy or omission.
The set covers major TikTok analytics and content optimization needs (engagement, revenue, trends, hashtags, hooks, best time to post, keyword research) plus media extraction. Minor gaps exist (e.g., no tool for competitor analysis or scheduling), but these are beyond the apparent scope.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Free public MCP for AI agents — 193 tools, 44 workflows. No API key.
Public TikTok profiles, videos, comments and keyword search as JSON. No developer account.
Hosted MCP with 91 agent tools: X, domains, SEO, Maps, Trends, Search, YouTube, TikTok, and more.
Unofficial TikTok API & scraper: creator analytics, video data, comments, search. x402, no API key.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/farukkolip/tiktapdown-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
