一个托管的模型上下文协议（MCP）服务器，为 Claude、Cursor、Windsurf 以及任何其他 MCP 客户端提供四个只读 TikTok 工具。你可以查看公开资料、遍历某个账号的视频、读取视频评论，以及搜索 TikTok 上的视频或创作者，全部以结构化 JSON 返回，无需 TikTok 开发者账号，也无需 OAuth。
它读取的是未登录访客也能看到的公开数据。它不会登录、发布内容，也不会以账号身份进行操作。
https://mcp.hasdata.com/api/mcp?apis=tiktok
Related MCP server: tiktok-mcp
一个 MCP 客户端，以及一个可从控制台免费创建的 HasData API 密钥。这是一个远程服务器，因此最简单的接入方式是使用 URL 和 x-api-key 请求头，无需运行容器，整个流程中也不需要 TikTok 开发者账号。只支持 stdio 的客户端则通过一个轻量启动器连接，该启动器以 @hasdata/tiktok-mcp 发布在 npm 上、以 hasdata-tiktok-mcp 发布在 PyPI 上，如下所示。
服务器 URL 对所有客户端都一样。我们在 Claude Code 和 Claude Desktop 中亲手运行过。其余配置块则遵循各客户端自己文档中规定的远程服务器格式。
字段 | 值 |
URL |
|
传输方式 | HTTP，流式 |
认证请求头 |
|
支持 OAuth 的客户端可以将同一 URL 作为连接器添加，然后直接登录，无需在配置文件中写入密钥。
claude mcp add --transport http tiktok "https://mcp.hasdata.com/api/mcp?apis=tiktok" \
--header "x-api-key: HASDATA_API_KEY"进入“设置”，然后“连接器”，然后点击“添加自定义连接器”，粘贴 https://mcp.hasdata.com/api/mcp?apis=tiktok 并登录。
如果采用配置文件方式，Claude Desktop 只会加载本地（stdio）服务器，因此需要通过 stdio 启动器连接远程服务器。@hasdata/tiktok-mcp 包就是这个启动器，它会从环境中读取密钥。将以下内容添加到 claude_desktop_config.json：
{
"mcpServers": {
"tiktok": {
"command": "npx",
"args": ["-y", "@hasdata/tiktok-mcp"],
"env": { "HASDATA_API_KEY": "YOUR_KEY" }
}
}
}使用 Python 而不是 Node？把启动器换成 PyPI 包即可，uvx 无需手动安装就能运行它：
{
"mcpServers": {
"tiktok": {
"command": "uvx",
"args": ["hasdata-tiktok-mcp"],
"env": { "HASDATA_API_KEY": "YOUR_KEY" }
}
}
}用于所有项目的 ~/.cursor/mcp.json，或用于单个项目的 .cursor/mcp.json：
{
"mcpServers": {
"tiktok": {
"url": "https://mcp.hasdata.com/api/mcp?apis=tiktok",
"headers": { "x-api-key": "HASDATA_API_KEY" }
}
}
}~/.codeium/windsurf/mcp_config.json。Windsurf 将该字段称为 serverUrl，而不是 url：
{
"mcpServers": {
"tiktok": {
"serverUrl": "https://mcp.hasdata.com/api/mcp?apis=tiktok",
"headers": { "x-api-key": "HASDATA_API_KEY" }
}
}
}{
"mcpServers": {
"tiktok": {
"url": "https://mcp.hasdata.com/api/mcp?apis=tiktok",
"type": "streamableHttp",
"headers": { "x-api-key": "HASDATA_API_KEY" },
"disabled": false
}
}
}工作区中的 .vscode/mcp.json：
{
"servers": {
"tiktok": {
"type": "http",
"url": "https://mcp.hasdata.com/api/mcp?apis=tiktok",
"headers": { "x-api-key": "HASDATA_API_KEY" }
}
}
}~/.codex/config.toml：
[mcp_servers.tiktok]
url = "https://mcp.hasdata.com/api/mcp?apis=tiktok"
[mcp_servers.tiktok.headers]
"x-api-key" = "HASDATA_API_KEY"~/.gemini/settings.json：
{
"mcpServers": {
"tiktok": {
"httpUrl": "https://mcp.hasdata.com/api/mcp?apis=tiktok",
"headers": { "x-api-key": "HASDATA_API_KEY" }
}
}
}这些是提示词，不是代码。粘贴其中一条，代理就会自行选择合适的工具。每条都标注了所需调用次数，因为在 MCP 中由模型决定调用多少次，而且每次成功调用都会消耗 10 个积分。
以 @mrbeast 为例。拉取该账号资料，然后遍历前两页视频，并给出这些视频的播放量中位数。
三次调用，30 积分。资料是一次调用，每一页视频又各是一次调用。
在 TikTok 上搜索与“冷萃咖啡”相关的创作者，按粉丝数排出前十名，并列出各自的简介。
一次调用，10 积分。用户搜索的结果已经包含粉丝数和简介，因此无需再逐个获取资料。
这里有一个视频 URL。读取它的热门评论，并告诉我整体情感倾向以及点赞最多的三条回复。
一次调用，10 积分。URL 中的数字 id 就是评论工具所需的全部信息。
以同一个视频为例，展开点赞最多的评论下的回复。
两次调用，20 积分。先获取顶层评论，然后用该评论的 id 进行第二次调用以获取其回复。
搜索“asmr”视频，然后获取播放量最高的三个视频的作者资料。
四次调用，40 积分。一次搜索，然后每个作者各一次资料调用。搜索结果中的每个作者都带有直接指向其资料端点的链接，因此代理无需猜测用户名。
翻页每次都会消耗一次调用。一次创作者审计如果先读取资料、再遍历五页视频，就是六次调用、60 积分。试用额度用在聚焦的问题上，比用在开放式爬取上能走得更远。
四个工具，全部只读。下面的示例来自真实调用并做了删减，其中的数字会随 TikTok 的更新而变化。请把它们当作数据结构样例。每个工具名称都链接到对应的端点文档，那里有完整的字段列表。
这些示例是载荷部分，不是完整响应。一次 tools/call 的结果包含一个文本块，而该文本本身是 JSON，包含 url、status、text 和 json，抓取到的数据位于 json 下。从原始 JSON-RPC 响应中，路径是解析 result.content[0].text 之后的 .json。聊天客户端会为你解开这一层，而直接调用端点的代码则不会。
用户名、视频 id 和评论 id 可以串联起来。资料页链接到其视频列表，每个视频都带有可供评论工具使用的视频 id，评论和搜索结果中的每个作者也都带有指向其资料页的 hasdataLink 和指向其视频列表的 hasdataPostsLink。代理可以从关键词一路走到创作者、视频和评论，全程无需自己构造 URL。
hasdata_tiktok_profile_getTikTokProfile
按用户名获取一个公开账号。
参数 | 类型 | 必填 | 说明 |
| string | 是 | 用户名，可带可不带开头的 |
返回 username、nickname、biography、bioLink、verified、language、createTime、头像 URL，以及作为整数返回的 followers、follows、likes、videos、friends 计数。这些计数已经过解析，因此 followers > 1000000 比较的是数字，而不是显示用的字符串。
不存在的用户名仍然会返回
requestMetadata.status为ok的响应，只是profile对象缺失。在读取username或任何其他字段之前，请先确认该对象存在，否则代理执行profile.username时会因为空值而报错。
{
"username": "mrbeast",
"nickname": "MrBeast",
"verified": true,
"biography": "Checkout My New Book!👇",
"bioLink": "http://themostdangerousgames.com",
"createTime": "2018-10-20T19:26:16.000Z",
"followers": 138387571,
"follows": 354,
"likes": 1427086888,
"videos": 466,
"friends": 285
}hasdata_tiktok_posts_getTikTokPosts
按用户名获取某个账号的一页视频，最新发布的在前。
参数 | 类型 | 必填 | 说明 |
| string | 是 | 用户名，可带可不带开头的 |
| string | 上一次响应中的 |
一次调用返回约三十个视频以及 pagination，其中包含 hasMore 和 nextPageToken，把后者传回即可一页一页地遍历该账号的发布历史。每个视频都带有 id、description、url、duration、封面图和可播放视频的 URL、music，以及作为整数返回的 likes、comments、shares、plays、collects 和 reposts 计数。
hashtags和mentions只出现在使用了它们的视频中。在真实的一页 27 个视频里，4 个带有hashtags数组，10 个带有mentions。在读取之前先检查键是否存在，而不要假设每个视频都有这两者。
{
"id": "7677375185028271391",
"description": "would you take the car or nah?",
"url": "https://www.tiktok.com/@mrbeast/video/7677375185028271391",
"createTime": "2026-08-23T23:36:59.000Z",
"duration": 41,
"likes": 129500,
"comments": 6670,
"shares": 2033,
"plays": 1100000,
"collects": 4986,
"music": { "title": "original sound", "authorName": "MrBeast", "original": true }
}hasdata_tiktok_comments_getTikTokComments
获取公开视频下的评论，或某条评论下的回复。
参数 | 类型 | 必填 | 说明 |
| string | 是 | 数字 id，即 TikTok URL 中 |
| string | 传入它以获取该评论的回复，而不是视频的顶层评论。同样出于 64 位的原因，请使用字符串，与 | |
| string | 上一次响应中的 token。获取第一页时省略 |
每条评论都带有 text、likes、createTime、replyCount 和 author，每位作者也都带有指向其资料页的 hasdataLink 和指向其视频列表的 hasdataPostsLink。pagination.total 报告的是该视频的评论总数，因此你可以在翻页前就知道深度。replyCount 不为零的评论有回复，你可以用它的 id 作为 commentId 再次调用以获取这些回复。
{
"id": "7677377150003053325",
"text": "How could someone turn down a car",
"createTime": "2026-08-23T23:45:06.000Z",
"likes": 3802,
"replyCount": 22,
"author": {
"username": "hohce.verggr",
"nickname": "Sasori",
"hasdataLink": "https://api.hasdata.com/scrape/tiktok/profile?handle=hohce.verggr",
"hasdataPostsLink": "https://api.hasdata.com/scrape/tiktok/posts?handle=hohce.verggr"
}
}hasdata_tiktok_search_getTikTokSearch
在视频或创作者中进行关键词搜索。
参数 | 类型 | 必填 | 说明 |
| string | 是 | 要搜索的短语 |
| string | 默认为 | |
| string | 上一次响应中的 token。获取第一页时省略 |
当 type: video 时，响应中包含的视频与 posts 工具返回的形式相同，每个视频都有其作者。当 type: user 时，响应中包含创作者，每个创作者都有 username、nickname、signature（个人简介）、avatarUrl、followers，以及相同的 hasdataLink 和 hasdataPostsLink，可继续链入个人资料或其视频。带有认证标记的账户会显示 verified 标志。
{
"username": "la.mooncoldbrew",
"nickname": "lamoon cold brew coffee",
"signature": "อยากได้สูตรชงเมนูไหน Comment ไว้เลยน้า",
"followers": 48000,
"hasdataLink": "https://api.hasdata.com/scrape/tiktok/profile?handle=la.mooncoldbrew",
"hasdataPostsLink": "https://api.hasdata.com/scrape/tiktok/posts?handle=la.mooncoldbrew"
}你的客户端几乎不会从工具调用中看到 HTTP 错误码。MCP 层返回 200，并将失败信息放在结果中，isError 设置为 true，原因以文本形式给出。代理读取到的是一条消息，而不是你可能预期的状态行。
错误的密钥会以工具输出的形式暴露，而不是连接失败。 tools/list 接受任何非空密钥并返回全部四个工具，因此客户端完成握手并显示绿色。第一次工具调用随即返回 isError: true 和文本 HasData API error: 401 Unauthorized。请留意该字符串，因为流程中此前没有任何环节报告此问题。
缺少密钥是唯一真正的 HTTP 错误。 授权在任何工具之前执行，连接本身会以 401 失败。CORS 头存在，浏览器客户端读取到的是状态码，而不是一个不透明的网络故障。
破坏工具 schema 的参数会在成为一次抓取之前被拒绝。 服务器返回 isError: true 和文本 MCP error -32602: Input validation error，并指明违规字段。不会抓取任何内容，也不会产生任何费用。
调用成功但未找到任何内容，是最容易让人困惑的情况。 一个不存在的句柄会作为普通结果返回，requestMetadata.status 设置为 ok，而 data 键直接缺失。响应正文中没有任何内容表明结果为空。请测试你需要的字段，而不是测试错误。
平台拒绝的标识符会返回 400，requestMetadata.status 设置为 error。
携带数据的返回结果同时带有 requestMetadata.id，在联系支持时值得引用。
每个 TikTok 工具每次成功调用花费 10 个积分。响应大小不会改变价格。一整页视频与只有一个字段的个人资料花费相同。
免费试用为 30 天内 1,000 个积分，无需绑卡，即 100 次 TikTok 调用。此后，只要活跃账户的余额低于 100，每天都会补充 100 个积分，因此低流量代理可以无限期地在免费套餐上运行。
付费套餐起价为 每月 $49，包含 200,000 个积分，即 20,000 次调用。单价随用量下降，从入门套餐的 每 1,000 次调用 $2.45，到 Business 的 $0.99、Growth 的 $0.83，以及最大 高用量套餐 的 $0.75。
你的套餐还决定了并发数。免费试用允许同时 1 个请求，Startup 为 15，Business 为 30，Growth 为 50，高用量套餐为 200 到 1,500。在任何无人值守的流程中，都要防御性地处理超出上限的情况，因为扇出的代理会比你更早触达上限。
返回非 200 的请求不会计费。成功调用但未找到任何内容，仍然算一次调用。
apis 查询参数决定你的代理能看到哪些工具。工具越少，意味着用于工具定义的上下文越少，模型选错工具的机会也越少。
?apis=tiktok the four tools in this repo
?apis=tiktok,instagram a social bundle
?apis=tiktok,google_serp add Google search该参数接受 tiktok 这样的提供商名称，也接受 tiktok_search 这样的单个 API 名称。拼写错误的名称会被忽略。如果所有名称都错误，请求将失败并返回 400，响应正文会列出它无法识别的名称以及所有有效值。去掉该参数后，同一端点会暴露全部 57 个 HasData 工具。
TikTok 自己的开发者计划并不涵盖对公共内容的一般性读取。Research API 需要申请，并且仅向有限区域内获批的学术和非营利研究人员开放。Display API 只返回通过 OAuth 登录的账户自己的内容。两者都不适合需要读取任意公共个人资料、其视频或视频评论的代理。
官方 TikTok API | 本服务器 | |
访问 | Research API 需申请，或 Display API 用于自己的账户 | 一个密钥和一个 URL |
范围 | 获批的研究人员，或你自己的已认证账户 | 任何公共个人资料、视频或搜索 |
认证 | 应用审核或 OAuth | 一个 |
非自己视频的评论 | 受限 | 可以，包含回复线程 |
设置 | 开发者账户和审批 | 无 |
写入和私有数据 | 通过 OAuth 发帖和访问自己的账户数据 | 只读，仅公共数据 |
大多数其他 TikTok MCP 服务器只封装一个非官方端点。本服务器涵盖了代理实际串联的四种读取操作——个人资料、帖子、评论——以及搜索，因此整个研究流程只需请求一个服务器即可完成。
本服务器不做什么。 不支持发帖、不提供私信、不提供仅粉丝可见或私有内容，也不提供非你所有账户的分析数据。它只读取未登录访客能看到的内容。
TikTok 没有发布官方的。所有选项都是由其他人构建的。本服务器由 HasData 维护，读取的是公共页面，因此不需要 TikTok 开发者账户。
这是一种将 TikTok 数据作为工具暴露给 AI 客户端调用的服务器。客户端通过 Model Context Protocol 发送工具调用，服务器获取数据并返回结构化的 JSON，模型直接使用结果，永远不会看到 HTML 页面。本服务器暴露四个工具，并以远程方式运行。客户端连接到一个 URL，无需启动任何本地进程。
不需要。唯一需要的凭证是你的 HasData 密钥。无需提交开发者申请，也没有 OAuth 授权界面，因为这些工具读取的是 TikTok 公共页面，而非 TikTok 开发者 API。
不需要。这是一个基于 streamable HTTP 的远程 MCP 服务器。无需安装任何东西，无需保持容器运行，也无需重启进程。
实时的。每次调用都会在请求时抓取数据，并带有自己的 requestMetadata.id。播放量和点赞数等计数器跟随页面变动，因此它们会随页面的变化而更新。
不可以。这些工具返回的是未登录访客能看到的内容。私有账户的视频不是公开的，因此不会出现在任何响应中。
可以。调用 comments 工具时，将评论的 id 作为 commentId 传入，它会返回该评论的回复。评论的 replyCount 会告诉你是否有回复。
可以。apis 参数接受一个列表，?apis=tiktok,instagram 会为你的代理提供四个 TikTok 工具以及 Instagram。去掉该参数 即可获得所有工具。
HasData 仅访问公开可用的数据。平台条款可能限制自动化访问，你需要自行负责合规。如果你收集的数据包含个人信息，请确保你根据 GDPR、CCPA 或你所在司法辖区的同等规则拥有合法的处理依据。
产品页面和请求构建器 | |
服务器文档 | |
一个服务器中的全部 57 个工具 | |
客户端教程 | |
我们抓取的其他所有内容 | |
套餐和积分费用 | |
密钥与用量 | |
npm 上的 Node 启动器 | |
PyPI 上的 Python 启动器 |
本仓库是远程服务器的配置和文档。没有构建步骤，也无需容器化。
test/ 中的测试断言的是工具契约，也就是即使本仓库没有提交也可能出问题的部分。它们检查 ?apis=tiktok 是否恰好返回四个工具、每个工具是否仍然声明其必需参数、是否有名称变更，以及正在使用的密钥是否真的被接受。最后一项检查会真实调用一次工具并花费 10 个积分，这正是金丝雀测试为正确原因而失败的代价。
# macOS and Linux
HASDATA_API_KEY=your_key_here npm test
# Windows PowerShell
$env:HASDATA_API_KEY="your_key_here"; npm test同一套测试会在每次推送时以及每周一次的定时任务中于 CI 中运行，因为上游工具列表可能在没有任何人改动本仓库的情况下发生变化。失败意味着工具列表发生了变动、密钥停止工作或端点不可达，断言消息会指明具体是哪一种。
对工具表格和响应示例的修正是最有用的贡献，因为这些是最容易偏离的部分。请附上你发出的调用和收到的响应。来自 fork 的拉取请求会在没有密钥的情况下运行测试套件，实时检查会跳过而不是报红。
MIT。参见 LICENSE。
Get TikTok Comments
Fetches the comments on a public TikTok video by its numeric video id, or the replies to a specific comment when commentId is given. Each comment returns text, like count, timestamp, reply count, and author (username, nickname, avatar, plus hasdataLink to the profile endpoint and hasdataPostsLink to the posts endpoint). Supports token-based pagination via nextPageToken. Use for sentiment analysis, engagement research, or building comment datasets from a video discovered via the posts or search APIs.
| Name | Required | Description | Default |
|---|---|---|---|
| videoId | Yes | The numeric id of the video (the number after `/video/` in a TikTok URL). | |
| commentId | No | When provided, returns the replies to this comment instead of the video's top-level comments. | |
| nextPageToken | No | Defines the next page token. Use the `nextPageToken` value returned by the previous response. Omit it to fetch the first page. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden and explains read-only fetching of public comments, pagination via nextPageToken, and the returned comment fields. It does not mention rate limits or error behavior, but the disclosed behavior is clear.
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 compact, well-organized, and free of filler. Key information about input, output fields, pagination, and use cases is 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?
Although there is no output schema, the description enumerates returned comment fields and pagination behavior, which gives an agent enough context for typical use. It lacks response envelope or error details, but those are not essential for 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?
All parameters have descriptive schema entries, and the description adds practical context: videoId is the number after /video/ in a TikTok URL, commentId selects replies, and nextPageToken uses the previous response value with omission for the first page.
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?
Clearly states it fetches TikTok comments by video ID or replies by comment ID, distinguishing it from sibling TikTok profile, posts, and search tools. The verb 'Fetches' and the resource 'comments on a public TikTok video' make the purpose specific.
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 concrete use cases such as sentiment analysis, engagement research, and building comment datasets, and notes that videos may be discovered via posts or search APIs. It does not explicitly contrast with sibling tools, but the guidance is sufficient for typical selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get TikTok Posts
Fetches a page of videos for a public TikTok account by username (handle) and returns each video with description, hashtags, mentions, like/comment/share/play/collect counts, cover and playable video URLs, music, duration, and timestamp. Returns a page of ~35 videos plus a nextPageToken; pass that token back to walk the account history one page at a time. Use to monitor competitor content, track engagement of creator videos, or build datasets of account content for vetting and analytics.
| Name | Required | Description | Default |
|---|---|---|---|
| handle | Yes | The TikTok username of the account whose videos you want to scrape, with or without the `@` symbol. | |
| nextPageToken | No | Defines the next page token. It is used for retrieving the next page of results. Use the `nextPageToken` value returned by the previous response. Omit it to fetch the first page. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It discloses pagination via nextPageToken, a page size of ~35 videos, and the public-account constraint. It does not mention rate limits or error cases, but the read-only nature is clearly implied by 'Fetches'.
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 dense and front-loaded, with the core behavior stated immediately and use cases at the end. The opening line repeats the title, but the rest of the content 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?
For a simple two-parameter fetch tool with no output schema, the description covers what is returned, pagination, and typical use cases. It is complete enough for correct invocation, though it omits potential failure modes and rate-limit context.
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%, and both parameters are already well-documented in the schema. The description reinforces the handle and pagination concepts but does not add significant meaning 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 the tool fetches a page of videos for a public TikTok account by username, and enumerates the returned fields. This distinguishes it from sibling tools focused on comments, profile, and search.
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?
Explicit use cases are given: monitoring competitors, tracking engagement, and building datasets for analytics. It does not name alternative tools or exclusions, but the context is clear enough for selecting this tool over the siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get TikTok Profile
Fetches a public TikTok profile by username (handle) and returns nickname, biography, bio link, avatar URLs, verified/private flags, account creation time, and followers, follows, likes, videos, and friends counts. Use to enrich CRM/lead records, verify influencer reach before outreach, monitor competitor accounts, or build datasets of creator metadata for vetting and analytics.
| Name | Required | Description | Default |
|---|---|---|---|
| handle | Yes | The TikTok username of the profile you want to scrape, with or without the `@` symbol. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full behavioral burden. It accurately conveys that this is a read operation (fetches) on public profiles, but it does not disclose potential edge cases like errors for non-existent handles, rate limits, or authentication requirements. For a simple GET it is acceptable but not exhaustive.
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 compact, front-loaded with the tool's purpose, and avoids unnecessary fluff. The second sentence adds value by listing return fields and use cases. It is efficiently written without waste.
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 single-parameter tool with no output schema, the description covers the essential information: what it does, what it returns, and typical use cases. It does not discuss error handling or output formatting, but given the simplicity of the operation, it is sufficiently complete for an agent to invoke it.
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 single parameter 'handle' is fully documented in the schema with an explanation of format (with or without '@'). The description adds no additional semantics beyond restating the parameter name. Since schema coverage is 100%, the baseline of 3 applies.
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 fetches a public TikTok profile by username and enumerates the exact data returned (nickname, bio, counts, flags). It is specific about the resource and action, and its distinctness from sibling tools (comments, posts, search) is evident from the resource type.
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 contexts (CRM enrichment, influencer vetting, competitor monitoring) which implicitly distinguish it from siblings that handle posts, comments, or search. It does not explicitly state when not to use it or name alternatives, but the context is unambiguous enough for an agent to select it correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search TikTok
Searches TikTok by keyword and returns either videos (with description, hashtags, mentions, like/comment/share/play counts, cover and playable video URLs, music, and author) or users (nickname, bio, avatar, verified flag, follower count). Each author and each user carries a hasdataLink to their profile endpoint and a hasdataPostsLink to their posts endpoint. Supports token-based pagination via nextPageToken. Use for content discovery, trend research, influencer discovery, or building datasets from a keyword.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | What to search for — videos or users. Defaults to video. | |
| keyword | Yes | The phrase to search for on TikTok. | |
| nextPageToken | No | Defines the next page token. Use the `nextPageToken` value returned by the previous response. Omit it to fetch the first page. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description should carry the full burden of disclosing behavioral traits. It does not state that the operation is read-only, nor does it mention rate limits, data modification, or other side effects. The absence of such details leaves behavioral transparency incomplete.
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 moderately concise and well-structured. It conveys the core functionality and relevant details without unnecessary verbosity, though it could be slightly tighter by removing redundant phrasing like repeating 'hasdataLink' and 'hasdataPostsLink'.
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 absence of an output schema, the description does well to enumerate the return fields (e.g., description, likes, comments, author) and explain pagination. It also gives practical use cases. Minor gaps include not explaining the structure of the nested author/user objects or the exact format of the response envelope.
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 already covers all parameters with descriptions (100% coverage), and the tool description adds some context about pagination usage. However, it largely repeats the schema information without significantly deepening understanding, so it provides marginal added 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 searches TikTok by keyword and returns videos or users, with a list of fields. It also names specific use cases like content discovery and trend research, 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 provides guidance on when to use the tool (content discovery, trend research, etc.) and explains pagination with nextPageToken. However, it does not explicitly contrast with sibling tools, though the distinct focus on search is implicit.
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.
v0.1.0hasdata_tiktok_comments_getTikTokCommentshasdata_tiktok_posts_getTikTokPostshasdata_tiktok_profile_getTikTokProfilehasdata_tiktok_search_getTikTokSearchScored across 4 tools
Each tool targets a distinct data surface: search, profile metadata, account posts, and comments. Even though profile and posts are both keyed by username, their return shapes are clearly different, so an agent should not confuse them.
Every tool follows the same strict pattern: hasdata_tiktok_<resource>_getTikTok<Resource>. The verb-first camelCase naming is applied uniformly across the entire set.
Four tools is a focused, appropriate scope for a read-only TikTok data server. Each tool covers a distinct public-data API surface and none feel redundant.
The set covers the main public TikTok use cases: discovery via search, profile lookup, posts retrieval, and comment fetching. A direct get-video-by-ID tool is missing, but search and posts largely fill that gap.
Unified social scraper MCP — profiles, posts, videos across ~40 platforms via Streamable HTTP.
TikTok videos, profiles, hashtags, search, comments and followers as JSON. No login. $0.35/1k videos
One MCP endpoint for 414 data APIs across 90 platforms, including TikTok, Instagram, YouTube, Amazon, Xiaohongshu (RedNote) and Douyin, plus 17 web search tools and CAPTCHA solving for 52 types. Pay per call from $0.56 per 1,000 calls; failed or empty calls are not charged.
TikTok profiles, video stats and transcripts by handle or URL. No login. Pay per result.
