TikTok MCP Server
TikTok MCP Server
Un servidor alojado del Model Context Protocol (MCP) que ofrece a Claude, Cursor, Windsurf y a cualquier otro cliente MCP cuatro herramientas de solo lectura para TikTok. Consulta un perfil público, recorre los vídeos de una cuenta, lee los comentarios de un vídeo y busca en TikTok vídeos o creadores, todo como JSON estructurado, sin cuenta de desarrollador de TikTok y sin OAuth.
Lee datos públicos que puede ver un visitante sin sesión iniciada. No inicia sesión, no publica ni actúa como una cuenta.
https://mcp.hasdata.com/api/mcp?apis=tiktok
Contenido
Related MCP server: tiktok-mcp
Lo que necesitas
Un cliente MCP y una clave de API de HasData del panel de control, que se crea de forma gratuita. Este es un servidor remoto, así que la vía más sencilla es una URL y una cabecera x-api-key, sin contenedor que ejecutar y sin cuenta de desarrollador de TikTok en ningún paso del flujo. Un cliente que solo hable stdio llega a él mediante un lanzador ligero, publicado como @hasdata/tiktok-mcp en npm y hasdata-tiktok-mcp en PyPI, que se muestra a continuación.
Inicio rápido
La URL del servidor es la misma para todos los clientes. Lo probamos de primera mano en Claude Code y Claude Desktop. Los demás bloques siguen el formato documentado de cada cliente para un servidor remoto.
Campo | Valor |
URL |
|
Transporte | HTTP, streamable |
Cabecera de autenticación |
|
Los clientes con soporte OAuth pueden añadir la misma URL como conector e iniciar sesión sin poner una clave en un archivo de configuración.
claude mcp add --transport http tiktok "https://mcp.hasdata.com/api/mcp?apis=tiktok" \
--header "x-api-key: HASDATA_API_KEY"Ajustes, luego Conectores, luego Añadir conector personalizado, y pega https://mcp.hasdata.com/api/mcp?apis=tiktok e inicia sesión.
Para la vía del archivo de configuración, Claude Desktop solo carga servidores locales (stdio), así que llega a un servidor remoto mediante un lanzador stdio. El paquete @hasdata/tiktok-mcp es ese lanzador, y lee la clave del entorno. Añade esto a claude_desktop_config.json:
{
"mcpServers": {
"tiktok": {
"command": "npx",
"args": ["-y", "@hasdata/tiktok-mcp"],
"env": { "HASDATA_API_KEY": "YOUR_KEY" }
}
}
}¿Python en lugar de Node? Cambia el lanzador por el paquete de PyPI, que uvx ejecuta sin instalación manual:
{
"mcpServers": {
"tiktok": {
"command": "uvx",
"args": ["hasdata-tiktok-mcp"],
"env": { "HASDATA_API_KEY": "YOUR_KEY" }
}
}
}~/.cursor/mcp.json para cada proyecto, o .cursor/mcp.json para uno solo:
{
"mcpServers": {
"tiktok": {
"url": "https://mcp.hasdata.com/api/mcp?apis=tiktok",
"headers": { "x-api-key": "HASDATA_API_KEY" }
}
}
}~/.codeium/windsurf/mcp_config.json. Windsurf llama al campo serverUrl, no 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 en el espacio de trabajo:
{
"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" }
}
}
}Ejemplos de prompts
Son prompts, no código. Pega uno y el agente elige la herramienta por sí mismo. Cada uno está anotado con las llamadas que requiere, porque en MCP el modelo decide cuántas llamadas hacer y cada llamada exitosa cuesta 10 créditos.
Toma @mrbeast. Obtén el perfil y luego recorre las dos primeras páginas de vídeos y dame la mediana del número de reproducciones entre ellos.
Tres llamadas, 30 créditos. El perfil es una llamada, y cada página de vídeos es otra.
Busca en TikTok creadores sobre «café cold brew» y clasifica los diez primeros por seguidores, cada uno con su biografía.
Una llamada, 10 créditos. Una búsqueda de usuarios ya trae el número de seguidores y la biografía, así que no hace falta consultar cada perfil después.
Aquí tienes una URL de vídeo. Lee sus comentarios principales y dime el sentimiento general y las tres respuestas con más me gusta.
Una llamada, 10 créditos. El id numérico de la URL es todo lo que necesita la herramienta de comentarios.
Toma ese mismo vídeo y expande las respuestas bajo su comentario con más me gusta.
Dos llamadas, 20 créditos. Primero los comentarios principales, y luego una segunda llamada con el id de ese comentario para sus respuestas.
Busca vídeos de «asmr» y luego obtén el perfil del autor de los tres vídeos con más reproducciones.
Cuatro llamadas, 40 créditos. Una búsqueda, y luego un perfil por cada uno. Cada autor en un resultado de búsqueda lleva un enlace directo al endpoint de su perfil, así que el agente nunca tiene que adivinar un handle.
Cada paginación cuesta una llamada. Una auditoría de creador que lee un perfil y luego recorre cinco páginas de vídeos son seis llamadas y 60 créditos. La prueba llega más lejos con preguntas concretas que con rastreos abiertos.
Herramientas
Cuatro herramientas, todas de solo lectura. Los ejemplos de abajo están recortados de llamadas reales, y los números que contienen cambian a medida que TikTok se actualiza. Léelos como formas. El nombre de cada herramienta enlaza a la referencia de su endpoint, que incluye la lista completa de campos.
Los ejemplos son la carga útil, no la respuesta completa. Un resultado de tools/call contiene un bloque de texto, y ese texto es a su vez JSON con url, status, text y json, con los datos extraídos bajo json. Desde una respuesta JSON-RPC en bruto, la ruta es result.content[0].text, parseado, y luego .json. Un cliente de chat lo desempaqueta por ti, y el código que se comunica directamente con el endpoint no.
Los handles, los ids de vídeo y los ids de comentario se encadenan. Un perfil enlaza a sus publicaciones, cada publicación lleva su propio id de vídeo para la herramienta de comentarios, y cada autor en los comentarios y resultados de búsqueda lleva un hasdataLink a su perfil y un hasdataPostsLink a sus vídeos. Un agente va de una palabra clave a un creador, a un vídeo y a sus comentarios sin construir nunca una URL.
Obtener perfil de TikTok
hasdata_tiktok_profile_getTikTokProfile
Una cuenta pública por handle.
Parámetro | Tipo | Obligatorio | Notas |
| string | sí | El nombre de usuario, con o sin la |
Devuelve username, nickname, biography, bioLink, verified, language, createTime, las URL del avatar y los recuentos de followers, follows, likes, videos y friends como enteros. Los recuentos ya están parseados, así que followers > 1000000 compara números, no cadenas mostradas.
Un handle que no existe sigue devolviendo
requestMetadata.statuscon valorok, simplemente el objetoprofileestá ausente. Comprueba que el objeto está presente antes de leerusernameo cualquier otro campo, o un agente que hagaprofile.usernamelanzará un error sobre nada.
{
"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
}Obtener publicaciones de TikTok
hasdata_tiktok_posts_getTikTokPosts
Una página de los vídeos de una cuenta por handle, de más reciente a más antiguo.
Parámetro | Tipo | Obligatorio | Notas |
| string | sí | El nombre de usuario, con o sin la |
| string | El |
Una llamada devuelve unos treinta vídeos más pagination, que trae hasMore y el nextPageToken que vuelves a pasar para recorrer el historial de la cuenta página a página. Cada vídeo incluye id, description, url, duration, las URL de la portada y del vídeo reproducible, music, y los recuentos de likes, comments, shares, plays, collects y reposts como enteros.
hashtagsymentionssolo están presentes en los vídeos que los usan. En una página real de 27 vídeos, 4 traían un arrayhashtagsy 10 traíanmentions. Comprueba si existe la clave antes de leerla, en lugar de asumir que todos los vídeos tienen ambas.
{
"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 }
}Obtener comentarios de TikTok
hasdata_tiktok_comments_getTikTokComments
Los comentarios de un vídeo público, o las respuestas bajo un comentario.
Parámetro | Tipo | Obligatorio | Notas |
| string | sí | El id numérico, la parte después de |
| string | Pásalo para obtener las respuestas a ese comentario en lugar de los comentarios principales del vídeo. Una cadena, por la misma razón de 64 bits que | |
| string | Token de la respuesta anterior. Omítelo en la primera página |
Cada comentario incluye text, likes, createTime, replyCount y un author, y cada autor lleva un hasdataLink a su perfil y un hasdataPostsLink a sus vídeos. pagination.total informa del recuento total de comentarios del vídeo, así que conoces la profundidad antes de paginar. Un comentario con replyCount distinto de cero tiene respuestas a las que llegas llamando de nuevo con su id como 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"
}
}Buscar en TikTok
hasdata_tiktok_search_getTikTokSearch
Una búsqueda por palabra clave sobre vídeos o creadores.
Parámetro | Tipo | Obligatorio | Notas |
| string | sí | La frase a buscar |
| string |
| |
| string | Token de la respuesta anterior. Omítelo en la primera página |
Con type: video, la respuesta contiene videos con la misma forma que devuelve la herramienta posts, cada uno con su autor. Con type: user contiene creadores, cada uno con username, nickname, signature (la biografía), avatarUrl, followers, y los mismos hasdataLink y hasdataPostsLink para encadenar hacia un perfil o sus videos. Un indicador verified está presente en las cuentas que lo tienen.
{
"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"
}Errores y modos de fallo
Tu cliente casi nunca ve un código de error HTTP en una llamada a una herramienta. La capa MCP responde con 200 y coloca el fallo dentro del resultado, con isError establecido en true y el motivo como texto. El agente lee un mensaje donde podrías esperar una línea de estado.
Una clave incorrecta aparece como salida de la herramienta, no como una conexión fallida. tools/list acepta cualquier clave no vacía y devuelve las cuatro herramientas, así que el cliente completa su protocolo de enlace y se muestra en verde. La primera llamada a una herramienta devuelve isError: true y el texto HasData API error: 401 Unauthorized. Presta atención a esa cadena, porque nada anterior en el flujo informa del problema.
Una clave ausente es el único error HTTP real. La autorización se ejecuta antes que cualquier herramienta, y la propia conexión falla con 401. Las cabeceras CORS están presentes, y un cliente de navegador lee el estado y no un fallo de red opaco.
Un argumento que rompe el esquema de una herramienta se rechaza antes de convertirse en un raspado. El servidor responde con isError: true y el texto MCP error -32602: Input validation error, señalando el campo infractor. No se obtiene nada y no se cobra nada.
Una llamada correcta que no encuentra nada es el caso que despista a la gente. Un identificador que no existe devuelve un resultado ordinario con requestMetadata.status establecido en ok y la clave data simplemente ausente. Nada en el cuerpo indica que el resultado estaba vacío. Comprueba el campo que necesitas, no un error.
Un identificador que la plataforma rechaza devuelve 400 con requestMetadata.status establecido en error.
Los resultados que contienen datos también incluyen un requestMetadata.id que vale la pena citar en soporte.
Precios, plan gratuito y límites
Cada herramienta de TikTok cuesta 10 créditos por llamada correcta. El tamaño de la respuesta no cambia el precio. Una página completa de videos cuesta lo mismo que un perfil con un solo campo.
La prueba gratuita es de 1.000 créditos durante 30 días sin tarjeta, lo que equivale a 100 llamadas de TikTok. Después, una cuenta activa sigue recibiendo una recarga de 100 créditos cada día siempre que su saldo baje de 100, así que un agente de bajo volumen se mantiene en el plan gratuito indefinidamente.
Los planes de pago empiezan en $49 al mes por 200.000 créditos, es decir, 20.000 llamadas. El precio unitario baja con el volumen, desde $2,45 por 1.000 llamadas en el plan inicial hasta $0,99 en Business, $0,83 en Growth y $0,75 en los planes de alto volumen más grandes.
Tu plan también fija la concurrencia. La prueba gratuita permite 1 solicitud a la vez, Startup 15, Business 30, Growth 50, y los planes de alto volumen van de 200 a 1.500. Gestiona el caso de desbordamiento de forma defensiva en cualquier proceso no supervisado, porque un agente que se expande alcanzará el límite antes que tú.
Una solicitud que devuelve un código distinto de 200 no se factura. Una llamada correcta que no encuentra nada sigue siendo una llamada.
Selección de herramientas
El parámetro de consulta apis decide qué herramientas ve tu agente. Menos herramientas significa menos contexto dedicado a las definiciones de herramientas, y menos oportunidades de que el modelo elija la equivocada.
?apis=tiktok the four tools in this repo
?apis=tiktok,instagram a social bundle
?apis=tiktok,google_serp add Google searchEl parámetro acepta nombres de proveedores como tiktok y nombres de API individuales como tiktok_search. Los nombres mal escritos se ignoran. Si todos los nombres son incorrectos, la solicitud falla con 400, y el cuerpo enumera tanto lo que no reconoció como todos los valores válidos. Si omites el parámetro, el mismo endpoint expone las 57 herramientas de HasData.
Comparativa
El propio programa de desarrolladores de TikTok no cubre la lectura general de contenido público. La Research API está sujeta a una solicitud de aprobación y abierta a investigadores académicos y sin ánimo de lucro aprobados en un conjunto limitado de regiones. La Display API devuelve solo el contenido de la cuenta que inicia sesión mediante OAuth. Ninguna de las dos sirve para un agente que necesite leer un perfil público arbitrario, sus videos o los comentarios de un video.
APIs oficiales de TikTok | Este servidor | |
Acceso | Research API mediante solicitud, o Display API para tu propia cuenta | Una clave y una URL |
Alcance | Investigadores aprobados, o tu propia cuenta autenticada | Cualquier perfil público, video o búsqueda |
Autenticación | Revisión de la solicitud u OAuth | Una cabecera |
Comentarios de videos que no son tuyos | Restringido | Sí, con hilos de respuestas |
Configuración | Cuenta de desarrollador y aprobación | Ninguna |
Escritura y datos privados | Publicación y datos de tu propia cuenta mediante OAuth | Solo lectura, únicamente datos públicos |
La mayoría de los otros servidores MCP de TikTok envuelven un único endpoint no oficial. Este cubre las cuatro lecturas que un agente encadena de verdad —de profile a posts a comments, además de search—, de modo que un ciclo completo de investigación se ejecuta contra un solo servidor.
Lo que este servidor no hace. No publica, no envía mensajes directos, no accede a contenido solo para seguidores ni privado, y no ofrece analíticas de cuentas que no sean tuyas. Lee lo que un visitante sin sesión puede ver.
Preguntas frecuentes
¿Existe un servidor MCP oficial de TikTok?
TikTok no publica ninguno. Todas las opciones las construye otra persona. Este está mantenido por HasData y lee páginas públicas, por lo que no necesita una cuenta de desarrollador de TikTok.
¿Qué es un servidor MCP de TikTok?
Un servidor que expone datos de TikTok como herramientas que un cliente de IA puede llamar. El cliente envía una llamada de herramienta a través del Model Context Protocol, el servidor obtiene los datos y devuelve JSON estructurado, y el modelo trabaja con el resultado sin ver nunca una página de HTML. Este expone cuatro herramientas y se ejecuta de forma remota. El cliente se conecta a una URL y no inicia ningún proceso local.
¿Necesito una clave de API de TikTok o una cuenta de desarrollador?
No. La única credencial es tu clave de HasData. No hay ninguna solicitud de desarrollador que presentar ni pantalla de consentimiento de OAuth, porque las herramientas leen páginas públicas de TikTok y no las API de desarrollo de TikTok.
¿Necesito alojar o ejecutar algo?
No. Es un servidor MCP remoto sobre HTTP streamable. Nada que instalar, ningún contenedor que mantener caliente, ningún proceso que reiniciar.
¿Los datos son en vivo o están en caché?
En vivo. Cada llamada obtiene los datos en el momento de la solicitud y lleva su propio requestMetadata.id. Contadores como reproducciones y me gusta siguen a la página, así que se mueven a medida que se mueve la página.
¿Puedo leer una cuenta privada?
No. Las herramientas devuelven lo que un visitante sin sesión ve. Los videos de una cuenta privada no son públicos, por lo que no aparecen en ninguna respuesta.
¿Puedo leer las respuestas a los comentarios, no solo los comentarios de primer nivel?
Sí. Llama a la herramienta comments con el id de un comentario como commentId y devolverá las respuestas de ese comentario. El replyCount de un comentario te indica si hay alguna.
¿Puedo usar esto junto con otras API de HasData?
Sí. El parámetro apis acepta una lista, y ?apis=tiktok,instagram le da a tu agente las cuatro herramientas de TikTok más Instagram. Omite el parámetro y lo tienes todo.
Cumplimiento y datos personales
HasData accede únicamente a datos disponibles públicamente. Los términos de una plataforma pueden restringir el acceso automatizado, y tú eres responsable de tu propio cumplimiento. Cuando los datos que recopiles incluyan información personal, asegúrate de tener una base jurídica para ello conforme al GDPR, la CCPA o las normas equivalentes de tu jurisdicción.
Enlaces de HasData
Página del producto y generador de solicitudes | |
Documentación del servidor | |
Las 57 herramientas en un solo servidor | |
Guías para clientes | |
Todo lo demás que raspamos | |
Planes y costes de créditos | |
Claves y uso | |
Lanzador de Node en npm | |
Lanzador de Python en PyPI |
Desarrollo
Este repositorio es configuración y documentación para un servidor remoto. No hay paso de compilación ni nada que contenerizar.
Las pruebas en test/ verifican el contrato de las herramientas, la parte que puede romperse sin que haya un commit aquí. Comprueban que ?apis=tiktok devuelve exactamente cuatro herramientas, que cada herramienta sigue declarando su parámetro obligatorio, que ningún nombre ha cambiado y que la clave en uso es realmente aceptada. Esa última comprobación llama de verdad a una herramienta y cuesta 10 créditos, que es el precio de una prueba canaria que puede fallar por la razón correcta.
# macOS and Linux
HASDATA_API_KEY=your_key_here npm test
# Windows PowerShell
$env:HASDATA_API_KEY="your_key_here"; npm testLa misma suite se ejecuta en CI en cada push y una vez a la semana de forma programada, porque la lista de herramientas upstream puede cambiar sin que nadie toque este repositorio. Un fallo significa que la lista de herramientas se ha movido, que la clave ha dejado de funcionar o que el endpoint era inalcanzable, y el mensaje de la aserción indica cuál.
Contribuciones
Las correcciones de las tablas de herramientas y de los ejemplos de respuesta son la contribución más útil, porque son las partes que se desactualizan. Incluye la llamada que hiciste y la respuesta que obtuviste. Las pull requests desde forks ejecutan la suite sin una clave, y las comprobaciones en vivo se omiten en lugar de ponerse en rojo.
Licencia
MIT. Consulta 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