TikTok MCP Server
This server provides four read-only TikTok tools that return public data as structured JSON, so an MCP client (Claude, Cursor, Windsurf, etc.) can look up profiles, browse videos, read comments and replies, and search TikTok without a TikTok developer account or OAuth.
Get a TikTok profile by handle: username, nickname, bio, verified status, avatar, creation time, and follower/following/like/video/friend counts.
Get an account's videos by handle, newest first, with description, engagement counts (likes, comments, shares, plays, collects), duration, music, and pagination via nextPageToken.
Get comments on a video by numeric videoId, or replies to a specific comment by commentId, including author info and reply counts, with pagination.
Search TikTok by keyword for videos (with author details) or users (with bio, follower count, verified flag), with pagination.
Chain results together: profiles link to posts, videos carry ids for comments, and authors/users carry hasdataLink/hasdataPostsLink for follow-up calls.
Works remotely over streamable HTTP with just a HasData API key; no local hosting or TikTok credentials required.
Provides read-only access to public TikTok data, including profile lookup, account video listing with pagination, video comments retrieval, and searching for videos or creators.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@TikTok MCP ServerLook up the public profile for @charlidamelio and list their recent videos"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
TikTok MCP Server
A hosted Model Context Protocol (MCP) server that gives Claude, Cursor, Windsurf and any other MCP client four read-only TikTok tools. Look up a public profile, walk an account's videos, read the comments on a video, and search TikTok for videos or creators, all as structured JSON, with no TikTok developer account and no OAuth.
It reads public data that a signed-out visitor can see. It does not sign in, post, or act as an account.
https://mcp.hasdata.com/api/mcp?apis=tiktok
Contents
Related MCP server: tiktok-mcp
What you need
An MCP client and a HasData API key from the dashboard, free to create. This is a remote server, so the simplest path is a URL and an x-api-key header, with no container to run and no TikTok developer account anywhere in the flow. A client that only speaks stdio reaches it through a thin launcher, published as @hasdata/tiktok-mcp on npm and hasdata-tiktok-mcp on PyPI, shown below.
Quick start
The server URL is the same for every client. We run it hands-on in Claude Code and Claude Desktop. The other blocks follow each client's own documented format for a remote server.
Field | Value |
URL |
|
Transport | HTTP, streamable |
Auth header |
|
Clients with OAuth support can add the same URL as a connector and sign in without putting a key in a config file.
claude mcp add --transport http tiktok "https://mcp.hasdata.com/api/mcp?apis=tiktok" \
--header "x-api-key: HASDATA_API_KEY"Settings, then Connectors, then Add custom connector, then paste https://mcp.hasdata.com/api/mcp?apis=tiktok and sign in.
For the config-file route, Claude Desktop loads only local (stdio) servers, so it reaches a remote server through a stdio launcher. The @hasdata/tiktok-mcp package is that launcher, and it reads the key from the environment. Add this to claude_desktop_config.json:
{
"mcpServers": {
"tiktok": {
"command": "npx",
"args": ["-y", "@hasdata/tiktok-mcp"],
"env": { "HASDATA_API_KEY": "YOUR_KEY" }
}
}
}Python instead of Node? Swap the launcher for the PyPI package, which uvx runs without a manual install:
{
"mcpServers": {
"tiktok": {
"command": "uvx",
"args": ["hasdata-tiktok-mcp"],
"env": { "HASDATA_API_KEY": "YOUR_KEY" }
}
}
}~/.cursor/mcp.json for every project, or .cursor/mcp.json for one:
{
"mcpServers": {
"tiktok": {
"url": "https://mcp.hasdata.com/api/mcp?apis=tiktok",
"headers": { "x-api-key": "HASDATA_API_KEY" }
}
}
}~/.codeium/windsurf/mcp_config.json. Windsurf calls the field serverUrl, not 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 in the workspace:
{
"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" }
}
}
}Example prompts
Prompts, not code. Paste one in and the agent picks the tool itself. Each is annotated with the calls it takes, because in MCP the model decides how many calls to make and every successful call costs 10 credits.
Take @mrbeast. Pull the profile, then walk the first two pages of videos and give me the median play count across them.
Three calls, 30 credits. The profile is one call, and each page of videos is another.
Search TikTok for creators around "cold brew coffee" and rank the top ten by followers, each with their bio.
One call, 10 credits. A user search already carries follower count and bio, so no per-profile follow-up is needed.
Here is a video URL. Read its top comments and tell me the overall sentiment and the three most-liked replies.
One call, 10 credits. The numeric id in the URL is all the comments tool needs.
Take that same video, then expand the replies under its most-liked comment.
Two calls, 20 credits. Top-level comments first, then a second call with that comment's id for its replies.
Search "asmr" videos, then pull the author profile of the three with the highest play counts.
Four calls, 40 credits. One search, then one profile each. Every author in a search result carries a link straight to its profile endpoint, so the agent never has to guess a handle.
Paging costs a call each time. A creator audit that reads a profile then walks five pages of videos is six calls and 60 credits. The trial goes further on narrow questions than on open-ended crawls.
Tools
Four tools, all read-only. Samples below are trimmed from real calls, and the numbers in them move as TikTok updates. Read them as shapes. Each tool name links to its endpoint reference, which carries the full field list.
The samples are the payload, not the whole response. A tools/call result carries one text block, and that text is itself JSON holding url, status, text and json, with the scraped data under json. From a raw JSON-RPC response the path is result.content[0].text, parsed, then .json. A chat client unwraps that for you and code talking to the endpoint directly does not.
Handles, video ids and comment ids chain together. A profile links to its posts, every post carries its own video id for the comments tool, and every author in comments and search results carries a hasdataLink to its profile and a hasdataPostsLink to its videos. An agent walks from a keyword to a creator to a video to its comments without ever constructing a URL.
Get TikTok profile
hasdata_tiktok_profile_getTikTokProfile
One public account by handle.
Parameter | Type | Required | Notes |
| string | yes | The username, with or without the leading |
Returns username, nickname, biography, bioLink, verified, language, createTime, the avatar URLs, and the followers, follows, likes, videos and friends counts as integers. The counts are already parsed, so followers > 1000000 compares numbers, not display strings.
A handle that does not exist still comes back with
requestMetadata.statusset took, theprofileobject simply absent. Check that the object is there before readingusernameor any other field, or an agent doingprofile.usernamethrows on nothing.
{
"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
}Get TikTok posts
hasdata_tiktok_posts_getTikTokPosts
A page of an account's videos by handle, newest first.
Parameter | Type | Required | Notes |
| string | yes | The username, with or without the leading |
| string | The |
One call returns about thirty videos plus pagination, which carries hasMore and the nextPageToken you feed back to walk the account history one page at a time. Each video carries id, description, url, duration, the cover and playable video URLs, music, and the likes, comments, shares, plays, collects and reposts counts as integers.
hashtagsandmentionsare present only on videos that use them. In one real page of 27 videos, 4 carried ahashtagsarray and 10 carriedmentions. Test for the key before you read it, rather than assuming every video has both.
{
"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 }
}Get TikTok comments
hasdata_tiktok_comments_getTikTokComments
The comments on a public video, or the replies under one comment.
Parameter | Type | Required | Notes |
| string | yes | The numeric id, the part after |
| string | Pass it to get the replies to that comment instead of the video's top-level comments. A string, for the same 64-bit reason as | |
| string | Token from the previous response. Omit it for the first page |
Each comment carries text, likes, createTime, replyCount and an author, and every author carries a hasdataLink to its profile and a hasdataPostsLink to its videos. pagination.total reports the video's whole comment count, so you know the depth before you page. A comment with a non-zero replyCount has replies you reach by calling again with its id as 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"
}
}Search TikTok
hasdata_tiktok_search_getTikTokSearch
A keyword search over videos or creators.
Parameter | Type | Required | Notes |
| string | yes | The phrase to search for |
| string |
| |
| string | Token from the previous response. Omit it for the first page |
With type: video the response holds videos in the same shape the posts tool returns, each with its author. With type: user it holds creators, each with username, nickname, signature (the bio), avatarUrl, followers, and the same hasdataLink and hasdataPostsLink to chain into a profile or its videos. A verified flag is present on accounts that carry one.
{
"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"
}Errors and failure paths
Your client almost never sees an HTTP error code from a tool call. The MCP layer answers 200 and puts the failure inside the result, with isError set to true and the reason as text. The agent reads a message where you might expect a status line.
A wrong key surfaces as tool output, not as a failed connection. tools/list accepts any non-empty key and returns all four tools, so the client completes its handshake and shows green. The first tool call then comes back with isError: true and the text HasData API error: 401 Unauthorized. Watch for that string, because nothing earlier in the flow reports the problem.
A missing key is the one real HTTP error. Authorization runs before any tool, and the connection itself fails with 401. CORS headers are present, and a browser client reads the status and not an opaque network failure.
An argument that breaks a tool's schema is rejected before it becomes a scrape. The server answers with isError: true and the text MCP error -32602: Input validation error, naming the offending field. Nothing is fetched and nothing is charged.
A call that succeeds and finds nothing is the case that trips people up. A handle that does not exist comes back as an ordinary result with requestMetadata.status set to ok and the data key simply missing. Nothing in the body says the result was empty. Test for the field you need, not for an error.
An identifier the platform rejects returns 400 with requestMetadata.status set to error.
Results that carry data also carry a requestMetadata.id worth quoting in support.
Pricing, free tier and limits
Every TikTok tool costs 10 credits per successful call. Response size does not change the price. A full page of videos costs the same as a profile with one field.
The free trial is 1,000 credits over 30 days with no card, which is 100 TikTok calls. After that an active account keeps getting 100 credits topped up each day whenever its balance drops below 100, so a low-volume agent runs on the free tier indefinitely.
Paid plans start at $49 a month for 200,000 credits, which is 20,000 calls. The unit price falls with volume, from $2.45 per 1,000 calls on the entry plan to $0.99 on Business, $0.83 on Growth and $0.75 on the largest high-volume plans.
Your plan also sets concurrency. The free trial allows 1 request at a time, Startup 15, Business 30, Growth 50, and the high-volume plans run from 200 to 1,500. Handle the overflow case defensively in anything unattended, because an agent that fans out will reach the ceiling before you do.
A request that comes back non-200 is not billed. A successful call that finds nothing is still a call.
Tool selection
The apis query parameter decides which tools your agent sees. Fewer tools means less context spent on tool definitions, and fewer chances for the model to reach for the wrong one.
?apis=tiktok the four tools in this repo
?apis=tiktok,instagram a social bundle
?apis=tiktok,google_serp add Google searchThe parameter takes provider names like tiktok and individual API names like tiktok_search. Misspelled names are ignored. If every name is wrong the request fails with 400, and the body lists both what it did not recognise and every valid value. Drop the parameter and the same endpoint exposes all 57 HasData tools.
How it compares
TikTok's own developer program does not cover general reading of public content. The Research API is gated behind an application and open to approved academic and nonprofit researchers in a limited set of regions. The Display API returns only the content of the account that signs in over OAuth. Neither fits an agent that needs to read an arbitrary public profile, its videos, or a video's comments.
Official TikTok APIs | This server | |
Access | Research API by application, or Display API for your own account | One key and one URL |
Scope | Approved researchers, or your own authenticated account | Any public profile, video or search |
Auth | Application review or OAuth | An |
Comments of videos you do not own | Restricted | Yes, with reply threads |
Setup | Developer account and approval | None |
Writes and private data | Posting and your own account data over OAuth | Read-only, public data only |
Most other TikTok MCP servers wrap a single unofficial endpoint. This one covers the four reads an agent actually chains, profile to posts to comments, plus search, so a whole research pass runs against one server.
What this server does not do. No posting, no direct messages, no follower-only or private content, no analytics for accounts you do not own. It reads what a signed-out visitor can see.
FAQ
Is there an official TikTok MCP server?
TikTok does not publish one. Every option is built by somebody else. This one is maintained by HasData and reads public pages, which is why it needs no TikTok developer account.
What is a TikTok MCP server?
A server that exposes TikTok data as tools an AI client can call. The client sends a tool call over the Model Context Protocol, the server fetches the data and returns structured JSON, and the model works with the result and never sees a page of HTML. This one exposes four tools and runs remotely. The client connects to a URL and starts no local process.
Do I need a TikTok API key or a developer account?
No. The only credential is your HasData key. There is no developer application to file and no OAuth consent screen, because the tools read public TikTok pages and not the TikTok developer APIs.
Do I need to host or run anything?
No. This is a remote MCP server on streamable HTTP. Nothing to install, no container to keep warm, no process to restart.
Is the data live or cached?
Live. Each call fetches at request time and carries its own requestMetadata.id. Counters like plays and likes track the page, so they move as the page moves.
Can I read a private account?
No. The tools return what a signed-out visitor sees. A private account's videos are not public, so they are not in any response.
Can I read comment replies, not just top-level comments?
Yes. Call the comments tool with a comment's id as commentId and it returns that comment's replies. A comment's replyCount tells you whether there are any.
Can I use this together with other HasData APIs?
Yes. The apis parameter takes a list, and ?apis=tiktok,instagram gives your agent the four TikTok tools plus Instagram. Drop the parameter and you get everything.
Compliance and personal data
HasData accesses publicly available data only. A platform's terms may restrict automated access, and you are responsible for your own compliance. Where the data you collect includes personal information, make sure you have a lawful basis for it under GDPR, CCPA or the equivalent rules in your jurisdiction.
HasData links
Product page and request builder | |
Server documentation | |
All 57 tools in one server | |
Client walkthroughs | |
Everything else we scrape | |
Plans and credit costs | |
Keys and usage | |
Node launcher on npm | |
Python launcher on PyPI |
Development
This repository is configuration and documentation for a remote server. There is no build step and nothing to containerize.
The tests in test/ assert the tool contract, the part that can break without a commit here. They check that ?apis=tiktok returns exactly four tools, that every tool still declares its required parameter, that no name changed, and that the key in use is actually accepted. That last check calls a tool for real and costs 10 credits, which is the price of a canary that can fail for the right reason.
# macOS and Linux
HASDATA_API_KEY=your_key_here npm test
# Windows PowerShell
$env:HASDATA_API_KEY="your_key_here"; npm testThe same suite runs in CI on every push and once a week on a schedule, because the upstream tool list can change without anyone touching this repository. A failure means the tool list moved, the key stopped working, or the endpoint was unreachable, and the assertion message says which.
Contributing
Corrections to the tool tables and the response samples are the most useful contribution, because those are the parts that drift. Include the call you made and the response you got. Pull requests from forks run the suite without a key, and the live checks skip instead of going red.
License
MIT. See 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, the description carries more behavioral burden. It discloses that the video must be public, describes what each returned comment contains, and mentions nextPageToken-based pagination. It could additionally mention rate limits, auth requirements, or error behavior, but it is already substantially transparent for a GET tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded and each sentence contributes something useful: scope, return fields, pagination, or intended use. It is slightly longer than minimal, but the extra detail is justified because there is no output schema to explain return values.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with three parameters and a meaningful output shape, the description covers request behavior, both comment modes, pagination, and the main response fields. The main gap is operational detail such as rate limits, response envelope, and failure modes, but the available context is already strong.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents all three parameters at 100% coverage, including commentId's reply-switching behavior and nextPageToken's purpose. The description reinforces but does not meaningfully extend the schema, so the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Fetches') with a clear resource: TikTok video comments. It distinguishes two distinct modes — top-level comments by videoId and replies by commentId — and clearly separates this from the sibling profile, posts, and search tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives concrete use cases ('sentiment analysis, engagement research, building comment datasets') and situates the tool in a workflow ('a video discovered via the posts or search APIs'). It does not explicitly say 'when not to use', but the context is sufficient for an agent to select it correctly among siblings.
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 available, the description carries the behavioral disclosure burden. It accurately conveys read-only intent, reports the approximate page size, and clearly explains pagination via nextPageToken to walk the account history. It does not mention credential boundaries or rate limits, but those are not central to this read-only API.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only three sentences and is front-loaded with the main action, followed by return fields, pagination, and use cases. The returned-field enumeration is slightly long, but each clause adds factual value, making the description efficient rather than padded.
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 small parameter count and the absence of an output schema, the description provides a strong, actionable mental model of the tool's behavior: input handle, page size, returned video fields, and pagination. It does not show an explicit response example or error conditions, but those are not necessary for a basic fetch-and-paginate workflow.
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 documents both parameters completely (100% coverage), so the description does not need to add detailed parameter semantics. It does add the useful note about passing the nextPageToken back for pagination, but this is a modest enrichment rather than a fundamental explanation.
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 action and resource: fetching a page of videos for a public TikTok account by username, then enumerates the returned content fields. This distinguishing account-scoped focus separates it from the sibling tools focused on comments, profile info, or 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?
The description explicitly names intended use cases, such as monitoring competitor content, tracking creator engagement, and building datasets for analytics. It does not explicitly state when not to use it or how it compares to the sibling tools, so it misses out on the top score.
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 carries the full burden of behavioral disclosure. It clearly states the operation is a fetch of public data and enumerates the response fields, but it does not mention behavior around errors, non-existent handles, rate limits, or data freshness. For a benign read operation this is acceptable but has gaps.
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 core behavior and return fields are packed into a single dense sentence, followed by a concise list of use cases. The opening line 'Get TikTok Profile' is somewhat redundant with the title, but the overall description is lean, informative, and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a single well-documented parameter and no output schema, the description compensates by listing the contained fields. It gives enough context for an agent to construct a correct call and interpret the result. It could optionally cover failure cases or input validity expectations, but the essentials are present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the sole required parameter 'handle' is fully documented in the schema, including the '@' detail. The description repeats 'username (handle)' without adding significant new meaning. Baseline 3 is appropriate when the schema already carries the weight.
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 states a specific verb ('Fetches'), resource ('public TikTok profile'), and identifier ('username (handle)'). It also explicitly lists the returned fields, making the tool's function unmistakable. Sibling names like comments/posts/search make this profile-focused tool clearly distinct.
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 concrete use cases: enriching CRM/lead records, verifying influencer reach, watching competitor accounts, and building metadata datasets. It clearly implies this tool is for profile-level lookups, though it does not explicitly state when to use alternative sibling tools.
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 carries the behavioral transparency burden. It fully explains what the search returns, mentions pagination via nextPageToken, and even notes that authors and users carry links to profile and posts endpoints. It does not mention rate limits or auth, but it clearly establishes a read-oriented search behavior and pagination model.
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 organized and front-loaded with the main purpose: Search TikTok. The following sentences add necessary details about return fields, linked data, pagination, and intended use cases without excessive filler. It could be slightly tighter, but every sentence 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 three-parameter tool with no output schema, the description covers the result shape, pagination behavior, and use cases well. It gives enough information for an agent to invoke the tool with a keyword and interpret the response, though it does not cover edge cases or error conditions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents all three parameters with 100% coverage. The description adds some context around pagination and result types, but it does not significantly enrich parameter meaning beyond what the schema already provides. Therefore, the baseline 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 that this tool searches TikTok by keyword and returns either videos or users, enumerating the key result fields for both. This is a specific verb+resource description and is easily distinguished from the sibling profile, posts, and comments tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit context for when to use it: content discovery, trend research, influencer discovery, or building datasets from a keyword. It does not explicitly list when-not-to-use scenarios or name alternative tools, but it provides enough usage context to guide selection.
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. Dates show when Glama detected each change.
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
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
Hosted TikTok ads MCP with OAuth, bounded reads, and prepare/confirm writes.
All HasData scraping tools in one MCP server: Google, TikTok, Instagram, maps, e-commerce and more.
Unofficial TikTok API & scraper: creator analytics, video data, comments, search. x402, no API key.
TikTok profiles (followers, bio) and per-video stats by handle or URL. No login. Pay per result.
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-
- FlicenseNot gradedqualityCmaintenanceA remote MCP server that provides tools to query live Meta (Facebook+Instagram) and TikTok organic social data, such as follower counts, insights, recent posts, and aggregated overviews.-
- FlicenseNot gradedqualityCmaintenanceProvides unified access to social media data across nine networks (Instagram, TikTok, YouTube, etc.) through a set of MCP tools for profiles, posts, search, and comments, backed by the SocialBridge API.-
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/HasData/tiktok-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server