tiktok
Server Details
Unofficial TikTok API & scraper: creator analytics, video data, comments, search. x402, no API key.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4/5 across 19 of 19 tools scored. Lowest: 3.3/5.
Each tool targets a distinct entity or action (creators, videos, comments, hashtags, sounds, search, etc.) with clear descriptions that differentiate them. Even tools that return videos (by creator, hashtag, sound, keyword) have unambiguous use cases.
All tools share the 'tiktok_' prefix. Most follow a resource-based pattern (e.g., tiktok_creator_followers, tiktok_video_comments) or action-based (e.g., tiktok_resolve_username, tiktok_search_creators), but there is minor mixing between these conventions. Overall, naming is predictable and readable.
With 19 tools covering creator profiles, videos, comments, replies, followers, following, liked videos, stories, hashtags, sounds, search, and metadata resolution, the scope is well-aligned with TikTok's data surface. Each tool serves a clear purpose without bloat.
The tool set covers the main read-only operations for TikTok data: profiles, videos, comments, searches, sounds, and stories. Minor gaps exist (e.g., no direct tool for trending feeds or comment counts), but the core analytics workflow is well-supported.
Available Tools
19 toolstiktok_comment_repliesAInspect
List replies to a specific comment on a video. Use to drill into a comment thread. Requires both comment_id and the parent video_id. Paginate with cursor.
| Name | Required | Description | Default |
|---|---|---|---|
| count | No | Number of items to return, <=50 | |
| cursor | No | Pagination cursor — pass the `cursor`/`max_cursor`/`has_more` value from a prior response. | |
| expand | No | Return the full untrimmed payload. Default false = compact JSON. | |
| video_id | Yes | aweme_id or a /video/<id> URL of the parent video | |
| comment_id | Yes | Numeric comment id (from tiktok_video_comments) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description carries full burden. It indicates a read operation and pagination, but lacks details on auth, rate limits, or return format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, every sentence adds value, no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequately covers invocation parameters and pagination, but missing description of return values/response structure since no output schema.
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%, description reinforces required IDs and pagination cursor usage, but adds no new meaning beyond 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?
Description clearly states verb 'list' and resource 'replies to a specific comment', distinguishing from siblings like tiktok_video_comments.
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?
Explicitly says when to use ('drill into a comment thread') and mentions required parameters (comment_id, video_id), though no explicit exclusions or alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tiktok_creator_followersBInspect
List a creator's followers (paginated). Use for audience mapping and finding connected accounts. Paginate with cursor.
| Name | Required | Description | Default |
|---|---|---|---|
| count | No | Number of items to return, <=50 | |
| cursor | No | Pagination cursor — pass the `cursor`/`max_cursor`/`has_more` value from a prior response. | |
| expand | No | Return the full untrimmed payload. Default false = compact JSON. | |
| user_id | Yes | @username or numeric user_id |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description mentions pagination behavior but lacks other critical behavioral details such as authentication requirements, rate limits, error handling, or what happens if the user doesn't exist. With no annotations, this is insufficient.
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 concise (two sentences) and front-loaded with the primary action. Every sentence is meaningful and without unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lacks information about the return value format, required authentication, or prerequisites. Given no output schema and no annotations, more context is needed for an agent to use the tool correctly.
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%, so the baseline is 3. The description adds no additional meaning beyond what the schema already provides (e.g., cursor for pagination is already described).
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 'List a creator's followers (paginated)' with a specific verb and resource. It also provides usage context ('audience mapping and finding connected accounts'), which differentiates it from siblings like tiktok_creator_following.
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 a use case ('audience mapping') but does not explicitly state when to use this tool versus alternatives (e.g., tiktok_creator_following). No exclusion or comparison is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tiktok_creator_followingAInspect
List the accounts a creator follows (paginated). Use for interest-graph and collaboration analysis. Paginate with cursor.
| Name | Required | Description | Default |
|---|---|---|---|
| count | No | Number of items to return, <=50 | |
| cursor | No | Pagination cursor — pass the `cursor`/`max_cursor`/`has_more` value from a prior response. | |
| expand | No | Return the full untrimmed payload. Default false = compact JSON. | |
| user_id | Yes | @username or numeric user_id |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses pagination behavior and cursor usage but omits details like authentication, rate limits, or privacy considerations. Adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with front-loaded purpose and no superfluous words. Efficient and easy to parse.
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?
No output schema and no annotations; description could better set expectations for response format, error handling, or interpretation of cursor. Current text is minimal but functional.
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 description adds only marginal value. The mention of pagination with cursor aligns with schema but does not provide deeper semantic meaning beyond what schema already offers.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description states 'List the accounts a creator follows' with specific verb and resource, mentions pagination, and clearly distinguishes from sibling tools like tiktok_creator_followers and tiktok_creator_videos.
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?
Explicitly states use cases ('interest-graph and collaboration analysis'), providing clear context. However, it does not mention when not to use or provide alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tiktok_creator_liked_videosAInspect
List videos a creator has publicly liked (only available when the account exposes its Likes tab). Use for taste/affinity analysis. Paginate with cursor.
| Name | Required | Description | Default |
|---|---|---|---|
| count | No | Number of items to return, <=35 | |
| cursor | No | Pagination cursor — pass the `cursor`/`max_cursor`/`has_more` value from a prior response. | |
| expand | No | Return the full untrimmed payload. Default false = compact JSON. | |
| user_id | Yes | @username or numeric user_id |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must fully cover behavior. It discloses the condition (exposed Likes tab) and pagination mechanism, but lacks details on authentication, rate limits, or potential side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no filler. Front-loaded with action, follows with condition and use case, then pagination note.
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 listing tool with 4 parameters and no output schema, description covers essential context (prerequisite, use case, pagination). Lacks mention of default count or response structure, but adequate.
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 each parameter is already documented. Description adds minimal value by reinforcing pagination with `cursor`. 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?
Clear verb 'List' and specific resource 'videos a creator has publicly liked'. Differentiates from sibling tools like tiktok_creator_videos by noting it's the creator's liked videos, not their own uploads.
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?
Explicitly states prerequisite (account must expose Likes tab) and use case (taste/affinity analysis). However, no direct comparison to alternative tools or when-not-to-use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tiktok_creator_profileAInspect
Fetch a TikTok creator's public profile: follower/following counts, total videos and likes, verification status, bio, region, and avatar. Use for influencer discovery, creator analytics, and audience-size vetting for UGC/brand deals. handle accepts an @username (e.g. @charlidamelio) or a numeric user_id.
| Name | Required | Description | Default |
|---|---|---|---|
| expand | No | Return the full untrimmed payload. Default false = compact JSON. | |
| handle | Yes | @username or numeric user_id |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are empty, so the description carries the burden. It states the profile is 'public' but does not disclose any access requirements, rate limits, or response size details. It implies read-only behavior indirectly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, each sentence provides essential information without fluff. The description is well-structured and front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 2 parameters and no output schema, the description covers the tool's purpose and parameter usage adequately. It does not mention error handling or rate limits, but it is sufficient for a simple profile fetch.
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 both parameters are already documented. The description adds value by specifying that 'handle' accepts '@username or numeric user_id', which extends the schema. No additional parameter info beyond that.
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 'Fetch a TikTok creator's public profile' and lists specific data fields. It distinguishes from sibling tools by focusing on profile metrics (followers, following, likes) rather than videos or comments.
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 usage context: 'Use for influencer discovery, creator analytics, and audience-size vetting for UGC/brand deals.' It lacks explicit when-not-to-use or alternatives, but the sibling list gives context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tiktok_creator_videosAInspect
List a creator's recent videos with per-video stats (views, likes, comments, shares). Use to compute engagement rate, spot recent virality, or pull a content sample. Paginate with cursor (the max_cursor from the response). user_id accepts an @username or numeric id.
| Name | Required | Description | Default |
|---|---|---|---|
| count | No | Number of items to return, <=35 | |
| cursor | No | Pagination cursor — pass the `cursor`/`max_cursor`/`has_more` value from a prior response. | |
| expand | No | Return the full untrimmed payload. Default false = compact JSON. | |
| user_id | Yes | @username or numeric user_id |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, but description clarifies it's a read operation ('List'), mentions pagination behavior, and explains the 'expand' parameter effect. Does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences. First sentence states purpose and output. Second sentence adds pagination and parameter details. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description mentions per-video stats (views, likes, comments, shares) — sufficient. Covers pagination and key parameters. Could mention that response is a paginated list, but adequate.
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%, baseline 3. Description adds context: cursor pagination (pass prior response value), user_id accepts @username or numeric, count defaults to 20 with max 35, expand returns full payload. Adds value beyond 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?
States 'List a creator's recent videos with per-video stats' — specific verb and resource. Clearly distinguishes from sibling tools like tiktok_search_videos (search) or tiktok_hashtag_videos (hashtag-based).
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?
Explicitly says 'Use to compute engagement rate, spot recent virality, or pull a content sample.' Also gives pagination guidance with cursor. No explicit when-not-to-use or alternatives, but overall clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tiktok_hashtag_videosAInspect
List videos under a hashtag/challenge. Pass a resolved numeric cid, or a hashtag name (e.g. booktok) which is resolved to a cid first. Use for trend tracking and campaign monitoring. Passing cid directly skips the resolution lookup and is slightly faster.
| Name | Required | Description | Default |
|---|---|---|---|
| cid | No | Numeric challenge id (preferred; skips resolution) | |
| count | No | Number of items to return, <=35 | |
| cursor | No | Pagination cursor — pass the `cursor`/`max_cursor`/`has_more` value from a prior response. | |
| expand | No | Return the full untrimmed payload. Default false = compact JSON. | |
| hashtag | No | Hashtag name without #, e.g. `booktok` |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With empty annotations, the description bears full responsibility for behavioral disclosure. It explains the resolution behavior and speed difference between passing cid and hashtag, but does not mention rate limits, authentication requirements, error handling, or side effects. The description provides useful but incomplete transparency.
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 concise, consisting of two sentences that front-load the core purpose. Every sentence adds value without redundancy or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description should ideally outline the return structure but does not. It covers pagination via the cursor parameter but omits what the response contains (e.g., video list, metadata). The description is adequate for basic usage but could be more complete for an API endpoint that returns data.
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?
Input schema covers 100% of parameters with descriptions. The tool description adds meaningful context: explains the resolution process for hashtag, notes that passing cid skips resolution for speed, and clarifies that `expand` returns full untrimmed payload. This enriches the schema's baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose ('List videos under a hashtag/challenge') and specifies two input modes (resolved cid or hashtag name). It also mentions use cases for trend tracking and campaign monitoring, effectively distinguishing it from sibling 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 provides clear guidance on when to use the resolved cid (faster) vs hashtag name (requires resolution). It also suggests appropriate contexts (trend tracking, campaign monitoring). However, it does not explicitly state when not to use this tool or compare it to search alternatives, slightly limiting differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tiktok_resolve_usernameAInspect
Resolve a TikTok @username to its stable numeric user_id and sec_uid. Cheap utility — call this first when you only have a handle and need an id for other tools.
| Name | Required | Description | Default |
|---|---|---|---|
| expand | No | Return the full untrimmed payload. Default false = compact JSON. | |
| username | Yes | @username (with or without the @) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are empty, so description carries full burden. It notes the tool is cheap and resolves to IDs, but doesn't disclose error handling, rate limits, or existence checks. Adequate for a simple lookup but could be more explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with core purpose. No superfluous words. 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?
Simple tool with 2 params and no output schema. Description covers purpose, usage guidance, and parameter details. Missing return format details, but 'user_id and sec_uid' suffices.
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%. Description adds practical detail: username accepts '@' prefix, and 'expand' parameter defaults to false for compact JSON. This adds meaning beyond schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description states a specific verb-resource pair: 'Resolve a TikTok @username to its stable numeric user_id and sec_uid.' It clearly distinguishes from sibling tools that require user_id as input.
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?
Explicitly says 'Cheap utility — call this first when you only have a handle and need an id for other tools,' indicating when to use and positioning it as a preliminary step.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tiktok_search_creatorsAInspect
Search TikTok creators by keyword/name, returning matching profiles. Use for influencer discovery and account lookup. Paginate with cursor.
| Name | Required | Description | Default |
|---|---|---|---|
| count | No | Number of items to return, <=30 | |
| cursor | No | Pagination cursor — pass the `cursor`/`max_cursor`/`has_more` value from a prior response. | |
| expand | No | Return the full untrimmed payload. Default false = compact JSON. | |
| keyword | Yes | Search query text |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description carries burden. It states the tool searches and returns profiles, and mentions pagination. However, it lacks disclosure of side effects or rate limits, though it is a read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two efficient sentences: first states purpose, second a usage hint. No 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?
Adequate for a search tool with 4 parameters all documented in schema. Description adds usage context. Could mention output type (profiles) but not essential.
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 covers 100% of parameters with clear descriptions. Description adds minimal value beyond schema, only mentioning pagination with cursor. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (Search), resource (TikTok creators), and purpose (influencer discovery, account lookup). It effectively distinguishes from sibling tools like tiktok_search_hashtags or tiktok_search_videos.
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 explicit use cases ('influencer discovery and account lookup') and mentions pagination with cursor. Does not explicitly state when not to use, but context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tiktok_search_hashtagsAInspect
Search TikTok hashtags/challenges by keyword, returning matching challenges with their cid and video counts. Use to find the right hashtag before pulling its videos. Paginate with cursor.
| Name | Required | Description | Default |
|---|---|---|---|
| count | No | Number of items to return, <=30 | |
| cursor | No | Pagination cursor — pass the `cursor`/`max_cursor`/`has_more` value from a prior response. | |
| expand | No | Return the full untrimmed payload. Default false = compact JSON. | |
| keyword | Yes | Search query text |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It describes return data (challenges, cid, video counts) and pagination. However, it doesn't mention read-only nature, rate limits, or authentication requirements. Adequate but not rich.
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?
Three sentences, no fluff. Front-loaded with the main action and purpose. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, description partially explains return values but omits structure (e.g., pagination fields like has_more). Does not cover errors or limitations. Adequate for a simple search tool but could be more complete.
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 baseline 3. Description adds context that cursor is for pagination and that results include cid and video counts, but doesn't elaborate on parameter details beyond 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?
Description clearly states it searches TikTok hashtags/challenges by keyword and returns matching challenges with cid and video counts. It distinguishes from sibling search tools like tiktok_search_creators and tiktok_search_videos by specifying 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?
Explicitly advises to use this tool to find the right hashtag before pulling its videos, implying a workflow. Mentions pagination with cursor. Does not state when not to use, but context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tiktok_search_livesAInspect
Search live TikTok streams by keyword. Use for real-time/live-content discovery. Paginate with cursor.
| Name | Required | Description | Default |
|---|---|---|---|
| count | No | Number of items to return, <=30 | |
| cursor | No | Pagination cursor — pass the `cursor`/`max_cursor`/`has_more` value from a prior response. | |
| expand | No | Return the full untrimmed payload. Default false = compact JSON. | |
| keyword | Yes | Search query text |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description indicates a search (read) operation and mentions pagination with cursor, adding some behavioral context beyond empty annotations. But it lacks details on auth requirements, rate limits, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose and usage, no unnecessary words. Highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains pagination and mentions the expand parameter's effect, but does not describe the response format or structure (no output schema provided). This leaves some uncertainty for the agent regarding what data will be returned.
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 baseline is 3. The description adds only a note about paginating with cursor, which reinforces the cursor parameter but does not add new semantic meaning beyond the schema descriptions.
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 'Search live TikTok streams by keyword', specifying a specific verb and resource, and distinguishes from sibling tools that search other content types (videos, creators, hashtags).
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 provides a usage hint: 'Use for real-time/live-content discovery', which clarifies context. However, it does not explicitly state when not to use or mention alternatives among sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tiktok_search_soundsAInspect
Search TikTok sounds/tracks by keyword, returning matching music with usage counts. Use for audio/trend discovery. Paginate with cursor.
| Name | Required | Description | Default |
|---|---|---|---|
| count | No | Number of items to return, <=30 | |
| cursor | No | Pagination cursor — pass the `cursor`/`max_cursor`/`has_more` value from a prior response. | |
| expand | No | Return the full untrimmed payload. Default false = compact JSON. | |
| keyword | Yes | Search query text |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It states the tool returns matching music with usage counts and supports pagination, but does not disclose read-only nature, authentication needs, or side effects. It adds some value beyond the schema by mentioning 'usage counts', but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the primary action and result, no wasted words. Efficiently communicates the core functionality and pagination.
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 4 parameters and no output schema, the description covers the main purpose and pagination but omits return structure, error handling, or rate limits. It is sufficient for a basic search tool but lacks completeness for robust agent usage.
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 baseline is 3. The description adds no additional meaning beyond the schema; it only reiterates 'keyword' and 'cursor' context. It does not elaborate on usage counts or expand behavior beyond schema descriptions.
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 sounds/tracks by keyword and returns matching music with usage counts. It effectively distinguishes from siblings like tiktok_search_creators and tiktok_search_hashtags by specifying 'sounds/tracks' and 'audio/trend discovery'.
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 says 'Use for audio/trend discovery' and mentions pagination with cursor. However, it does not provide when-not-to-use guidance or alternatives, but the context is clear enough for sound-specific searches.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tiktok_search_videosBInspect
Search TikTok videos by keyword, returning matching posts with stats. Use for topic/trend discovery and competitive research. Paginate with cursor.
| Name | Required | Description | Default |
|---|---|---|---|
| count | No | Number of items to return, <=30 | |
| cursor | No | Pagination cursor — pass the `cursor`/`max_cursor`/`has_more` value from a prior response. | |
| expand | No | Return the full untrimmed payload. Default false = compact JSON. | |
| keyword | Yes | Search query text |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions pagination via cursor but omits critical details like rate limits, authentication requirements, response structure (no output schema), and what 'stats' entails. The lack of transparency for a data-fetching tool is a significant gap.
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 concise with three short sentences that front-load the main purpose. Every sentence adds value: action, usage context, and pagination hint. No redundant or wasteful text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description should explain return values more thoroughly. It vaguely states 'matching posts with stats' but lacks detail on structure or field meaning. Pagination handling is mentioned, which is good. However, for a search tool with 4 parameters, it is minimally adequate but not comprehensive.
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 baseline 3 is appropriate. The description adds no additional meaning beyond the schema for parameters (e.g., keyword, count, expand are already described in schema). Only cursor is contextualized with 'pass from prior response', but this is minimal. Overall, the description does not significantly enhance parameter understanding.
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 searches TikTok videos by keyword and returns matching posts with stats. The verb 'Search' and resource 'videos' are specific, and the context of returning posts with stats distinguishes it from sibling tools that focus on creators, hashtags, or sounds, though explicit differentiation is lacking.
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 a usage context ('Use for topic/trend discovery and competitive research') which implies when to use, but it does not specify when not to use or provide alternatives. The pagination hint is useful but more behavioral than usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tiktok_sound_infoAInspect
Fetch metadata for a sound/track: title, author, duration, and how many videos use it. Use to size a sound's reach before pulling its videos.
| Name | Required | Description | Default |
|---|---|---|---|
| expand | No | Return the full untrimmed payload. Default false = compact JSON. | |
| music_id | Yes | Numeric TikTok music_id |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses read-only metadata fetching behavior. Without annotations, it adequately explains the operation and what is returned. Minor omission: no mention of rate limits or auth, but acceptable for a simple fetch.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two focused sentences: first describes what it does, second tells when to use. No wasted words, front-loaded with key information.
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 tool simplicity (two params, no output schema, no annotations), the description provides sufficient purpose, usage, and key outputs. It meets the needs for an agent to select and invoke correctly.
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 covers both parameters with descriptions. The description adds context about metadata fields, but does not add meaning to the parameters themselves beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies 'Fetch metadata for a sound/track' and lists exact fields (title, author, duration, video count). It clearly distinguishes from sibling tools like tiktok_sound_videos (which pulls videos) 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?
Explicitly states when to use: 'Use to size a sound's reach before pulling its videos.' This tells the agent to use this tool before tiktok_sound_videos, providing clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tiktok_sound_videosAInspect
List videos that use a given sound/track, most-recent first. Use for sound-trend analysis, finding UGC around a track, or gauging a sound's virality. Paginate with cursor.
| Name | Required | Description | Default |
|---|---|---|---|
| count | No | Number of items to return, <=35 | |
| cursor | No | Pagination cursor — pass the `cursor`/`max_cursor`/`has_more` value from a prior response. | |
| expand | No | Return the full untrimmed payload. Default false = compact JSON. | |
| music_id | Yes | Numeric TikTok music_id |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are empty, so the description carries full burden. It discloses that results are sorted most-recent first and that pagination is supported via `cursor`. However, it does not mention rate limits, authentication, data shape, or potential errors. The disclosure is adequate for a straightforward listing 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 two sentences long, with the core action and ordering stated first, followed by use cases and pagination note. Every sentence provides essential information with no redundancy.
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 4 parameters and no output schema, the description is reasonably complete. It explains the listing operation, ordering, use cases, and pagination. While it could optionally detail response fields, the core functionality is well covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with descriptions for all parameters. The description adds value by reinforcing the pagination pattern and context for `cursor`. However, it does not add significant meaning beyond the schema, warranting the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'list', the resource 'videos', and the filtering condition 'that use a given sound/track'. It also provides specific use cases (sound-trend analysis, finding UGC, gauging virality), which differentiates it from sibling tools like tiktok_hashtag_videos or tiktok_creator_videos.
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 states when to use the tool (sound-trend analysis, UGC discovery, virality gauge) and mentions pagination with `cursor`. It does not specify exclusions or alternatives, but the purpose is clear enough to guide appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tiktok_user_storiesAInspect
List a creator's active TikTok Stories (ephemeral posts that expire ~24h). Use to capture story content before it disappears. user_id accepts an @username or numeric id.
| Name | Required | Description | Default |
|---|---|---|---|
| count | No | Number of items to return, <=35 | |
| expand | No | Return the full untrimmed payload. Default false = compact JSON. | |
| user_id | Yes | @username or numeric user_id |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. It discloses that stories expire ~24h and user_id accepts two formats, but doesn't mention read-only nature, rate limits, or error handling (e.g., no stories found). Adequate 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?
Two sentences, front-loaded with purpose, then usage and parameter info. No unnecessary words, every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with 3 parameters and no output schema, the description covers purpose, usage context, and a parameter hint. Lacks mention of pagination or empty results, but acceptable.
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 baseline is 3. The description adds how user_id works ('@username or numeric id'), but this is already in the schema. No extra semantics for count or expand.
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 'List a creator's active TikTok Stories', specifying a distinct resource (Stories) with a clear verb (List). It distinguishes from sibling tools like tiktok_creator_videos by mentioning ephemeral nature.
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 advises to 'use to capture story content before it disappears', providing a clear context for when this tool is appropriate. While it doesn't explicitly exclude other scenarios, the ephemeral hint naturally differentiates from permanent content tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tiktok_video_commentsAInspect
List top-level comments on a video, most-relevant first, with like counts and authors. Use for sentiment sampling and audience-response analysis. Paginate with cursor.
| Name | Required | Description | Default |
|---|---|---|---|
| count | No | Number of items to return, <=50 | |
| cursor | No | Pagination cursor — pass the `cursor`/`max_cursor`/`has_more` value from a prior response. | |
| expand | No | Return the full untrimmed payload. Default false = compact JSON. | |
| video_id | Yes | aweme_id or a /video/<id> URL |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It clarifies that the tool returns top-level comments (not replies), orders them by most-relevant, and includes like counts and authors. While it does not explicitly state read-only or idempotent behavior, 'list' implies a safe operation. The description adequately conveys key behavioral traits without contradictions.
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 extremely concise—only two sentences. It is front-loaded with the verb 'List' and the resource 'top-level comments on a video', immediately conveying the action. Every piece of information is relevant and there is no wasted text.
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 tool has 4 parameters, no output schema, and no annotations, the description is fairly complete. It explains what the tool returns (top-level comments with like counts and authors), the order (most-relevant first), and how to paginate. It could mention the default `count` value or that it requires authentication, but overall it provides sufficient context for an AI agent to use the tool correctly.
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%, so the baseline is 3. The description adds some context for the `cursor` parameter by specifying how to pass values from a prior response. However, it does not add much beyond what the schema already provides for `video_id`, `count`, or `expand`. The description's additional value is marginal, keeping the score at baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists top-level comments on a video, ordered by most-relevant, and includes like counts and authors. It distinguishes itself from the sibling tool 'tiktok_comment_replies' by specifying 'top-level' and focusing on video comments rather than replies.
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 says 'Use for sentiment sampling and audience-response analysis,' providing clear context for when to use the tool. It also mentions pagination with `cursor`. However, it does not explicitly state when not to use it or directly compare to alternatives like tiktok_comment_replies, though the sibling list provides implicit differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tiktok_video_download_urlAInspect
Resolve a watermark-free download URL for a TikTok video. Use to obtain the clean MP4 for archival or analysis. Accepts a numeric video_id or a full TikTok video URL.
| Name | Required | Description | Default |
|---|---|---|---|
| expand | No | Return the full untrimmed payload. Default false = compact JSON. | |
| video_id | Yes | aweme_id or a /video/<id> URL |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are empty, so the description bears the full burden for behavioral transparency. It states 'watermark-free' and 'clean MP4,' but provides no information about error handling (e.g., if video is private or deleted), rate limits, authentication requirements, or side effects. This is a significant gap for a tool that presumably makes network requests.
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 extremely concise, consisting of two sentences. The first sentence states the core purpose, and the second adds usage scope and input format. Every word serves a purpose with no redundancy.
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 simplicity of the tool (2 parameters, no nested objects, no output schema), the description provides the essential context: what the tool does, its input format, and a typical use case. It lacks details about the return value (presumably a URL) but for a straightforward download tool, this is acceptable. Some might argue it needs error behavior, but overall it's fairly complete.
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 both parameters are documented in the schema. The description adds a useful clarification for video_id ('numeric `video_id` or a full TikTok video URL'), which mirrors the schema's description. However, the expand parameter is not mentioned in the description; the schema already explains it. Overall, the description adds marginal value 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's purpose with a specific verb ('Resolve') and resource ('watermark-free download URL for a TikTok video'). It explicitly mentions the output ('clean MP4') and use case ('archival or analysis'). This distinguishes it from sibling tools that handle comments, profiles, hashtags, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates when to use the tool ('obtain the clean MP4 for archival or analysis'), which is clear and context-aware. However, it does not explicitly state when not to use it or mention any alternatives among siblings, though no sibling appears to provide download URLs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tiktok_video_statsAInspect
Fetch a single TikTok video's stats and metadata: play/like/comment/share/save counts, author, sound, duration, description, hashtags, and create time. Use to measure a specific post's performance. Accepts a numeric video_id (aweme_id) or a full TikTok video URL.
| Name | Required | Description | Default |
|---|---|---|---|
| expand | No | Return the full untrimmed payload. Default false = compact JSON. | |
| video_id | Yes | aweme_id or a tiktok.com/.../video/<id> URL |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions that the tool fetches stats and metadata, but does not disclose any behavioral traits such as authentication requirements, rate limits, or whether it modifies any state. For a read-only fetch tool, the transparency is adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loading the core purpose and data returned. The second sentence adds usage guidance and parameter clarification. Every sentence serves a purpose with no fluff.
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 explicitly lists the types of data returned (counts, author, sound, etc.), which is sufficient for an AI agent to understand the output. The tool complexity is low, and the description is complete enough for its purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage, baseline is 3. The description adds value by explaining that `video_id` accepts either a numeric aweme_id or a full TikTok URL, and that `expand` returns the full untrimmed payload. This goes beyond the schema's basic descriptions.
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 explicitly states 'Fetch a single TikTok video's stats and metadata', with a specific list of included data (play/like/comment/share/save counts, author, sound, etc.). This clearly distinguishes it from sibling tools that handle comments, profiles, or searches.
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 a clear use case: 'Use to measure a specific post's performance.' It does not explicitly exclude other tools or state when not to use, but the context of siblings and the focused purpose make the intent clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!