TikTok MCP Server
TikTok MCP Server
Размещённый сервер Model Context Protocol (MCP), который даёт Claude, Cursor, Windsurf и любому другому MCP-клиенту четыре инструмента TikTok только для чтения. Находите публичный профиль, проходите по страницам видео аккаунта, читайте комментарии к видео и ищите в TikTok видео или авторов — всё в виде структурированного JSON, без аккаунта разработчика TikTok и без OAuth.
Он читает публичные данные, которые видит посетитель, не вошедший в аккаунт. Он не входит в аккаунт, не публикует записи и не действует от имени аккаунта.
https://mcp.hasdata.com/api/mcp?apis=tiktok
Содержание
Related MCP server: tiktok-mcp
Что вам нужно
Нужны MCP-клиент и API-ключ HasData из панели управления — его можно создать бесплатно. Это удалённый сервер, поэтому самый простой путь — URL и заголовок x-api-key: никакого контейнера для запуска и никакого аккаунта разработчика TikTok во всей цепочке. Клиент, который поддерживает только stdio, подключается к нему через тонкий лаунчер, опубликованный как @hasdata/tiktok-mcp на npm и hasdata-tiktok-mcp на PyPI, показанный ниже.
Быстрый старт
URL сервера одинаков для всех клиентов. Мы запускаем его на практике в Claude Code и Claude Desktop. Остальные блоки следуют собственному документированному формату каждого клиента для удалённого сервера.
Поле | Значение |
URL |
|
Транспорт | HTTP, streamable |
Заголовок авторизации |
|
Клиенты с поддержкой 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" }
}
}
}Вместо Node нужен Python? Замените лаунчер на пакет 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 авторов по запросу "cold brew coffee" и отсортируй лучших десять по числу подписчиков, с био каждого.
Один вызов, 10 кредитов. Поиск по пользователям уже содержит число подписчиков и био, поэтому отдельный запрос по каждому профилю не нужен.
Вот URL видео. Прочитай его топ-комментарии и скажи общую тональность и три ответа с наибольшим числом лайков.
Один вызов, 10 кредитов. Числовой id из URL — всё, что нужно инструменту комментариев.
Возьми то же видео и разверни ответы под его комментарием с наибольшим числом лайков.
Два вызова, 20 кредитов. Сначала верхнеуровневые комментарии, затем второй вызов с id этого комментария для его ответов.
Найди видео по запросу "asmr", затем загрузи профили авторов трёх видео с наибольшим числом просмотров.
Четыре вызова, 40 кредитов. Один поиск, затем по одному профилю на каждого. Каждый автор в результатах поиска несёт ссылку прямо на endpoint своего профиля, поэтому агенту не приходится угадывать хэндл.
Каждая страница стоит один вызов. Аудит автора, читающий профиль и проходящий пять страниц видео, — это шесть вызовов и 60 кредитов. Пробный период позволяет зайти дальше на узких вопросах, чем на открытых обходах.
Инструменты
Четыре инструмента, все только для чтения. Примеры ниже урезаны из реальных вызовов, и числа в них меняются по мере обновления TikTok. Воспринимайте их как структуру. Каждое имя инструмента ведёт на справочник endpoint'а, где приведён полный список полей.
Примеры — это полезная нагрузка, а не весь ответ. Результат tools/call содержит один текстовый блок, и этот текст сам является JSON с полями url, status, text и json, а собранные данные находятся в json. В сыром JSON-RPC ответе путь — result.content[0].text; распарсив его, получаете .json. Чат-клиент разворачивает это за вас, а код, обращающийся к endpoint напрямую, — нет.
Хэндлы, id видео и id комментариев соединяются в цепочку. Профиль ссылается на свои посты, каждый пост несёт собственный id видео для инструмента комментариев, а каждый автор в комментариях и результатах поиска несёт hasdataLink на свой профиль и hasdataPostsLink на свои видео. Агент проходит путь от ключевого слова к автору, затем к видео и его комментариям, ни разу не конструируя URL.
Получить профиль TikTok
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
}Получить посты TikTok
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 }
}Получить комментарии TikTok
hasdata_tiktok_comments_getTikTokComments
Комментарии к публичному видео или ответы под одним комментарием.
Параметр | Тип | Обязателен | Примечания |
| string | да | Числовой id — часть после |
| string | Передайте его, чтобы получить ответы на этот комментарий вместо верхнеуровневых комментариев видео. Строка, по той же 64-битной причине, что и | |
| string | Токен из предыдущего ответа. Опустите для первой страницы |
Каждый комментарий содержит 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"
}
}Поиск в TikTok
hasdata_tiktok_search_getTikTokSearch
Поиск по ключевому слову среди видео или авторов.
Параметр | Тип | Обязателен | Примечания |
| string | да | Фраза для поиска |
| string | По умолчанию | |
| string | Токен из предыдущего ответа. Опустите для первой страницы |
При 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 присутствуют, и браузерный клиент читает статус, а не непрозрачный сетевой сбой.
Аргумент, нарушающий схему инструмента, отклоняется до того, как превратится в парсинг. Сервер отвечает с isError: true и текстом MCP error -32602: Input validation error, указывая на проблемное поле. Ничего не загружается и ничего не списывается.
Успешный вызов, который ничего не находит, — вот случай, на котором спотыкаются. Несуществующий handle возвращается как обычный результат со requestMetadata.status, установленным в ok, а ключ данных просто отсутствует. Ничто в теле не говорит, что результат пуст. Проверяйте наличие нужного поля, а не наличие ошибки.
Идентификатор, отклонённый платформой, возвращает 400 со requestMetadata.status, установленным в error.
Результаты с данными также содержат requestMetadata.id, который стоит указывать в обращении в поддержку.
Цены, бесплатный тариф и лимиты
Каждый инструмент TikTok стоит 10 кредитов за успешный вызов. Размер ответа не меняет цену. Полная страница видео стоит столько же, сколько профиль с одним полем.
Бесплатная пробная версия — 1000 кредитов на 30 дней без карты, это 100 вызовов TikTok. После этого активный аккаунт продолжает получать пополнение на 100 кредитов каждый день, когда его баланс опускается ниже 100, так что агент с небольшим объёмом работает на бесплатном тарифе бессрочно.
Платные тарифы начинаются от $49 в месяц за 200 000 кредитов, то есть 20 000 вызовов. Цена за единицу снижается с объёмом: от $2.45 за 1000 вызовов на начальном тарифе до $0.99 на Business, $0.83 на Growth и $0.75 на самых крупных high-volume тарифах.
Ваш тариф также задаёт параллельность. Бесплатная пробная версия разрешает 1 запрос одновременно, Startup — 15, Business — 30, Growth — 50, а high-volume тарифы — от 200 до 1500. Обрабатывайте переполнение защитно во всём, что работает без присмотра, потому что агент, рассылающий запросы, упрётся в потолок раньше вас.
Запрос, вернувшийся не с кодом 200, не тарифицируется. Успешный вызов, который ничего не нашёл, всё равно считается вызовом.
Выбор инструментов
Параметр запроса apis определяет, какие инструменты видит ваш агент. Меньше инструментов — меньше контекста тратится на определения инструментов и меньше шансов, что модель потянется не к тому.
?apis=tiktok the four tools in this repo
?apis=tiktok,instagram a social bundle
?apis=tiktok,google_serp add Google searchПараметр принимает имена провайдеров, такие как tiktok, и отдельные имена API, такие как tiktok_search. Имена с опечатками игнорируются. Если каждое имя неверно, запрос завершается ошибкой 400, и тело перечисляет и то, что не было распознано, и все допустимые значения. Уберите параметр — и тот же endpoint откроет все 57 инструментов HasData.
Сравнение
Собственная программа разработчиков TikTok не покрывает обычное чтение публичного контента. Research API доступен только после подачи заявки и открыт для одобренных академических и некоммерческих исследователей в ограниченном наборе регионов. Display API возвращает только контент аккаунта, который входит через OAuth. Ни один из них не подходит агенту, которому нужно читать произвольный публичный профиль, его видео или комментарии к видео.
Official TikTok APIs | Этот сервер | |
Доступ | Research API по заявке или Display API для своего аккаунта | Один ключ и один URL |
Область действия | Одобренные исследователи или ваш собственный авторизованный аккаунт | Любой публичный профиль, видео или поиск |
Авторизация | Рассмотрение заявки или OAuth | Заголовок |
Комментарии к чужим видео | Ограничено | Да, с ветками ответов |
Настройка | Аккаунт разработчика и одобрение | Ничего |
Запись и приватные данные | Публикация и данные собственного аккаунта через OAuth | Только чтение, только публичные данные |
Большинство других MCP-серверов TikTok оборачивают один неофициальный endpoint. Этот покрывает четыре операции чтения, которые агент реально выстраивает в цепочку, — профиль, посты, комментарии — плюс поиск, так что весь исследовательский проход выполняется против одного сервера.
Чего этот сервер не делает. Никаких публикаций, никаких личных сообщений, никакого контента только для подписчиков или приватного контента, никакой аналитики для чужих аккаунтов. Он читает только то, что видит посетитель без входа.
FAQ
Существует ли официальный TikTok MCP-сервер?
TikTok не публикует такой. Каждый вариант создан кем-то другим. Этот поддерживается HasData и читает публичные страницы, поэтому ему не нужен аккаунт разработчика TikTok.
Что такое TikTok MCP-сервер?
Это сервер, который предоставляет данные TikTok в виде инструментов, которые может вызывать AI-клиент. Клиент отправляет вызов инструмента по Model Context Protocol, сервер загружает данные и возвращает структурированный JSON, а модель работает с результатом и никогда не видит страницу HTML. Этот сервер предоставляет четыре инструмента и работает удалённо. Клиент подключается по URL и не запускает локальных процессов.
Нужен ли мне API-ключ TikTok или аккаунт разработчика?
Нет. Единственные учётные данные — ваш ключ HasData. Не нужно подавать заявку разработчика и нет экрана согласия OAuth, потому что инструменты читают публичные страницы TikTok, а не API разработчиков TikTok.
Нужно ли мне что-то хостить или запускать?
Нет. Это удалённый MCP-сервер на streamable HTTP. Ничего устанавливать не нужно, контейнер держать тёплым не нужно, процесс перезапускать не нужно.
Данные живые или кэшированные?
Живые. Каждый вызов загружает данные в момент запроса и несёт собственный requestMetadata.id. Счётчики вроде просмотров и лайков отслеживают страницу, поэтому они меняются вместе со страницей.
Могу ли я читать приватный аккаунт?
Нет. Инструменты возвращают то, что видит посетитель без входа. Видео приватного аккаунта не являются публичными, поэтому их нет ни в одном ответе.
Могу ли я читать ответы на комментарии, а не только комментарии верхнего уровня?
Да. Вызовите инструмент comments, передав id комментария как commentId, и он вернёт ответы на этот комментарий. Значение replyCount комментария показывает, есть ли они.
Можно ли использовать это вместе с другими API HasData?
Да. Параметр apis принимает список, а ?apis=tiktok,instagram даёт вашему агенту четыре инструмента TikTok плюс Instagram. Уберите параметр — и получите всё.
Соответствие требованиям и персональные данные
HasData получает доступ только к общедоступным данным. Условия платформы могут ограничивать автоматический доступ, и вы сами отвечаете за соблюдение требований. Если собираемые вами данные включают персональную информацию, убедитесь, что у вас есть законное основание для этого по GDPR, CCPA или эквивалентным правилам вашей юрисдикции.
Ссылки HasData
Страница продукта и конструктор запросов | |
Документация сервера | |
Все 57 инструментов в одном сервере | |
Пошаговые руководства по клиентам | |
Всё остальное, что мы парсим | |
Тарифы и стоимость кредитов | |
Ключи и использование | |
Node-лаунчер на npm | |
Python-лаунчер на PyPI |
Разработка
Этот репозиторий — конфигурация и документация для удалённого сервера. Здесь нет этапа сборки и нечего помещать в контейнер.
Тесты в 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 при каждом push и раз в неделю по расписанию, потому что внешний список инструментов может измениться без какого-либо вмешательства в этот репозиторий. Сбой означает, что список инструментов сдвинулся, ключ перестал работать или endpoint был недоступен, и сообщение проверки говорит, что именно.
Участие в разработке
Наиболее полезный вклад — исправления таблиц инструментов и примеров ответов, потому что именно эти части расходятся с реальностью. Приложите выполненный вызов и полученный ответ. Pull request из форков запускает набор тестов без ключа, а «живые» проверки пропускаются, а не становятся красными.
Лицензия
MIT. См. LICENSE.
Available Tools
4 toolshasdata_tiktok_comments_getTikTokCommentstiktok_comments: GET /AInspect
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. |
TDQS
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.
hasdata_tiktok_posts_getTikTokPoststiktok_posts: GET /AInspect
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. |
TDQS
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.
hasdata_tiktok_profile_getTikTokProfiletiktok_profile: GET /AInspect
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. |
TDQS
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.
hasdata_tiktok_search_getTikTokSearchtiktok_search: GET /AInspect
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. |
TDQS
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.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
4 tool updates
v0.1.0- First observed
hasdata_tiktok_comments_getTikTokComments - First observed
hasdata_tiktok_posts_getTikTokPosts - First observed
hasdata_tiktok_profile_getTikTokProfile - First observed
hasdata_tiktok_search_getTikTokSearch
TDQS
Scored 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.
Maintenance
Related MCP Connectors
Unified social scraper MCP — profiles, posts, videos across ~40 platforms via Streamable HTTP.
TikTok profiles, video stats and transcripts by handle or URL. No login. Pay per result.
TikTok search demand, videos, creators, comments and captions for AI agents. OAuth or API key.
Hosted MCP server for DataLikers — Instagram & TikTok data API. 51 tools: Instagram user search by demographics (gender/age/race/country/city), profiles, bulk lookup, engagement, posts & reels, comments, hashtags, locations, stories, highlights, music, business accounts, top users; TikTok users, videos, comments, hashtags, playlists and top charts. Streamable HTTP, Bearer API key. Free tier: 100 requests on signup at https://datalikers.com/p/1by27bwg
Related MCP Servers
- AlicenseCqualityDmaintenanceEnables access to TikTok data without watermarks, including trending users, hashtags, post analytics, user profiles, and download links for specific countries. Supports searching by username, user ID, or post links.10MIT
- FlicenseBqualityDmaintenanceMCP server for TikTok that enables searching videos, users, hashtags, and fetching trending content, user profiles, and video details via official API or public scraping.8-
- AlicenseAqualityBmaintenanceEnables downloading TikTok videos and photos without watermarks, extracting metadata and analytics, and performing bulk downloads of user profiles via CLI or as an MCP server for AI assistants.512 npm1MIT
- AlicenseAqualityAmaintenanceA hosted Model Context Protocol server providing read-only YouTube tools for search, video/channel data, and transcripts, with no Google Cloud project or API key required.450 npm67 PyPI6MIT