Unofficial TikTok API & scraper: creator analytics, video data, comments, search. x402, no API key.
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.
Average 3.9/5 across 19 of 19 tools scored. Lowest: 3.2/5.
Each tool targets a distinct data type or action (creator, video, comment, sound, hashtag, search, etc.) with no functional overlap. Agents can easily distinguish them based on their clear entity-action pairing.
All tools follow a 'tiktok_' prefix and a consistent noun-first pattern (e.g., 'tiktok_creator_profile', 'tiktok_video_stats'), but there is a minor inconsistency between 'creator' and 'user' for the same entity (e.g., 'tiktok_user_stories' vs 'tiktok_creator_profile').
At 19 tools, the count is slightly high but justified by the breadth of TikTok's public data surface (profiles, videos, comments, sounds, hashtags, searches, etc.). Each tool serves a specific purpose, and the set feels comprehensive rather than bloated.
The tool set covers most read-only operations for TikTok public data, including profiles, videos, comments, sounds, hashtags, and searches. Missing are direct trending feeds or aggregated analytics, but search capabilities compensate. No create/update/delete exists, which is expected for a data extraction server.
tiktok_comment_repliesAInspectList 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) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are empty, so the description carries the full burden. It discloses the operation (list replies), required parameters, and pagination behavior. However, it does not explicitly state that the operation is read-only and non-destructive, though this is implicitly clear. No contradictions exist.
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 with no unnecessary words. It is front-loaded with the purpose, then adds usage context. Every word 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?
The description covers the essential aspects: what it does, required parameters, and pagination. However, since there is no output schema, the description could have added more detail about the return structure (e.g., that it returns a list of replies with cursor fields). Still, for a simple list operation, it is 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 the baseline is 3. The description adds context by restating that video_id and comment_id are required and explaining cursor usage. This provides marginal additional 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 'List replies to a specific comment on a video', using a specific verb and resource. It distinguishes from sibling tools like tiktok_video_comments (which lists top-level comments) by focusing on replies to a specific comment.
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 to drill into a comment thread' and notes the required parameters (comment_id, video_id) and pagination with cursor. It provides clear context for when to use the tool, though it does not explicitly state when not to use it (e.g., for top-level comments), but the sibling tool tiktok_video_comments covers that case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tiktok_creator_followersAInspectList 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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden. It implies a read-only operation ('list'), but does not disclose auth needs, rate limits, or behavior for private creators. Adequate but not detailed.
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, front-loaded with purpose. 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?
Tool is simple; description covers purpose, pagination, and a usage hint. No output schema, but the behavior is straightforward. Could mention return format 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 coverage is 100%, so baseline is 3. The description adds 'Paginate with cursor' which is already in schema. No additional semantic enrichment 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?
The description clearly states 'List a creator's followers (paginated)', providing a specific verb and resource. It distinguishes from siblings like tiktok_creator_following (which lists who the creator follows) and other audience-related 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 usage context: 'Use for audience mapping and finding connected accounts' and mentions pagination with cursor. However, it does not explicitly state when not to use or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tiktok_creator_followingAInspectList 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 |
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 pagination but omits behavioral traits like authentication needs, rate limits, or safety (read-only nature).
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, no waste. First sentence states purpose and pagination; second adds use case and cursor hint. Perfectly front-loaded and 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?
Schema covers all parameters, but with no output schema, the description lacks details on return format or error conditions. Adequate but incomplete for a mutation-free data retrieval tool.
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 description coverage, the schema already explains all four parameters. The description reinforces cursor usage but adds no significant meaning 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 the verb 'List' and the resource 'accounts a creator follows', with pagination. It distinguishes from siblings like tiktok_creator_followers by specifying direction.
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 use cases ('interest-graph and collaboration analysis') and pagination guidance, but does not explicitly exclude alternatives or state when not to use this tool compared to 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_videosAInspectList 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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With empty annotations, the description carries full burden. It mentions pagination via cursor, but does not disclose other behavioral traits like authentication needs, rate limits, or side effects. For a read-only list tool, this is 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?
The description is two sentences, front-loaded with purpose, and contains no fluff. 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?
Given no output schema and 4 parameters, the description is minimally complete. It covers purpose, condition, and pagination, but lacks details about return value structure or what fields are in the response. 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 description coverage is 100%, so baseline is 3. The description does not add meaning beyond what the schema already provides for parameters; it only reinforces cursor usage which is already documented.
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' and resource 'videos a creator has publicly liked', with a condition (only when Likes tab is exposed). It also distinguishes from siblings like tiktok_creator_videos (which lists the creator's own videos) by specifying it's for liked 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 specifies a prerequisite (account exposes Likes tab) and a use case (taste/affinity analysis), but does not explicitly state when not to use it or provide alternatives. This is clear context for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tiktok_creator_profileAInspectFetch 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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits like authentication requirements, rate limits, or error handling. It only describes the returned data but omits any behavioral context, such as what happens if the handle is invalid or if the profile is private.
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 plus a parameter note, all essential and front-loaded. No redundant 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 no output schema, the description lists the key data fields returned (follower/following counts, etc.). For a simple profile endpoint with two parameters, this is sufficient. It could mention response format or pagination, but not critical.
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%, but the description adds value by clarifying that 'handle' accepts '@username or numeric user_id' and explaining the 'expand' parameter: 'Return the full untrimmed payload. Default false = compact JSON.' This goes 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 the tool fetches a TikTok creator's public profile with specific data points (follower/following counts, total videos, likes, etc.). It distinguishes from sibling tools like tiktok_creator_followers or tiktok_creator_videos by focusing on the overall profile.
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 explicit use cases: 'influencer discovery, creator analytics, and audience-size vetting for UGC/brand deals.' It does not explicitly state when not to use it, but the purpose alone implies it's for profile data, not for followers or videos, which are covered by siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tiktok_creator_videosAInspectList 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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so description carries full burden. Discloses return stats and pagination behavior. Does not mention rate limits, data recency, or any other behavioral traits that could affect agent decisions.
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, each serving a distinct purpose: purpose, use cases, param hints. Front-loaded with key information. No redundant or extraneous content.
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 adequately summarizes return content (per-video stats). For a list endpoint with clear sibling differentiation, this is sufficient. Missing details on response structure would be helpful but not critical.
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 already covers all 4 parameters with descriptions (100% coverage). Description adds value by clarifying pagination uses 'max_cursor' and user_id accepts @username or numeric id, going beyond schema details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'List a creator's recent videos with per-video stats', specifying verb and resource. Differentiates from sibling tools like search_videos and hashtag_videos by focusing on a specific creator.
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 suggests use cases: compute engagement rate, spot virality, pull content sample. Provides pagination instruction and parameter format clarification. Lacks explicit when-not-to-use guidance but use cases are sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tiktok_hashtag_videosAInspectList 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` |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full transparency burden. It discloses that `cid` skips resolution for speed and that the default response is compact JSON with an option for full payload via `expand`. However, it does not describe pagination behavior beyond mentioning the cursor parameter, nor does it mention rate limits, error handling, or what happens if both `cid` and `hashtag` are provided.
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, starting with the primary purpose, then providing key usage hints. Every word adds value; no fluff. It is efficiently structured for quick parsing by an AI agent.
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 help the agent understand what the response contains. It mentions pagination (cursor) and compact JSON, but does not describe the structure of returned video objects. While siblings may imply shape, explicit mention of fields like `id`, `url`, or `statistics` would improve completeness. For a list tool, this is a moderate gap.
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 value by explaining the relationship between `cid` and `hashtag` (one resolves to the other) and clarifies that using `cid` is faster. It also contextualizes `expand` by mentioning 'compact JSON' as default. This goes beyond mere 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 lists videos under a hashtag/challenge, with the specific verb 'List' and resource 'videos under a hashtag.' It differentiates from sibling tools like tiktok_search_hashtags (which finds hashtags) and tiktok_search_videos (which searches by query) by focusing on hashtag-based listing.
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 mentions use cases: 'trend tracking and campaign monitoring.' It also provides operational guidance on passing a resolved `cid` for faster execution versus using a `hashtag` name. While it doesn't explicitly state when not to use the tool or list alternatives, the context is clear enough for an AI agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tiktok_resolve_usernameAInspectResolve 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 @) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are empty, so description carries burden; it mentions 'cheap utility' implying low cost but does not explicitly state read-only or other behaviors.
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, 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?
Given simple parameters and no output schema, description covers core behavior and use case. Could mention error handling for unknown usernames, 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%, and description adds minimal nuance beyond what's in schema (e.g., 'with or without @' for username). 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 tool resolves a @username to stable numeric user_id and sec_uid, distinguishing it from sibling tools that likely require an ID.
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 'call this first when you only have a handle and need an id for other tools,' providing clear when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tiktok_search_creatorsAInspectSearch 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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description mentions pagination with 'cursor', which is a useful behavioral trait. With no annotations, the description carries the full burden; it could disclose more about auth needs or rate limits, but the basic pagination behavior is covered.
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 concise sentences with purpose first, no fluff. 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?
The description lacks detail about the response structure (profile fields) and does not explain what 'matching profiles' contains, which would help agents understand return values better, especially without an 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%, so parameters are well-documented in the schema. The description reinforces the cursor parameter's purpose but adds no new meaning beyond what the schema already provides.
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 creators by keyword/name and returns matching profiles, distinguishing it from other TikTok search tools (e.g., search videos, hashtags) and creator-specific tools (e.g., creator profile).
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 recommends use for 'influencer discovery and account lookup', providing clear usage context. However, it does not mention when to avoid using this tool or suggest alternatives like tiktok_resolve_username for exact username resolution.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tiktok_search_hashtagsAInspectSearch 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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so description carries full burden. It correctly implies a read-only search operation and mentions pagination. Discloses return elements (cid, video counts). Could add more about response structure, but adequate.
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 with zero waste. Front-loaded with action and resource, followed by usage and pagination hint. 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 search tool with no output schema, the description adequately explains return items and pagination. Could mention that response includes pagination tokens, but the hint is sufficient.
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 practical context by explaining the cursor parameter usage and the typical workflow, adding 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?
The description uses a specific verb 'Search' and resource 'TikTok hashtags/challenges', clearly stating it returns 'cid and video counts'. It distinguishes from siblings like tiktok_search_videos by focusing on hashtag 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?
Explicitly says 'Use to find the right hashtag before pulling its videos', providing clear context for when to use. Does not mention exclusions or alternatives, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tiktok_search_livesAInspectSearch 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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses pagination behavior with 'Paginate with `cursor`.' No annotations are provided, so description carries full burden. It does not address rate limits, empty results, or authorization requirements, but covers basic behavior.
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, zero waste. Purpose is front-loaded, and key information is presented efficiently.
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 minimal description. Agent lacks information on return format, error handling, and cursor mechanics beyond basic pagination. Incomplete for confident invocation.
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 all 4 parameters with descriptions, achieving 100% coverage. Description adds little beyond schema, such as mentioning count default and cursor usage, but does not significantly enhance 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?
Description clearly states 'Search live TikTok streams by keyword' and 'Use for real-time/live-content discovery', specifying verb, resource, and domain. This distinguishes from sibling tools like 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?
Explicitly states 'Use for real-time/live-content discovery', providing context. Does not mention when not to use or alternatives, but given the sibling list, the intended use is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tiktok_search_soundsAInspectSearch 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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are empty, so description carries full burden. Only mentions pagination with cursor and usage counts; no disclosure of rate limits, auth needs, or read-only nature.
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, front-loaded sentences. Every word adds value; 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?
Adequate for a simple search tool but lacks details on output format, cursor progression, and edge cases. No output schema to compensate.
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 all parameters (100% coverage). Description adds only a pagination hint ('Paginate with `cursor`'), not enough to exceed baseline value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the action (search), resource (sounds/tracks), and return value (matching music with usage counts). Distinguishes from sibling tools by focusing on 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?
Provides usage context ('Use for audio/trend discovery') and pagination hint, but does not specify when not to use or mention alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tiktok_search_videosBInspectSearch 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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It states it searches and returns posts with stats, but lacks information on rate limits, authentication requirements, data recency, or any side effects. The read-only nature is implied but not 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?
The description is concise with three sentences, each adding value. It front-loads the verb and resource, and avoids redundancy. Minor improvement could be to structure usage guidelines and behavioral notes separately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema, the description partially compensates by mentioning 'posts with stats,' but it does not explain the structure of results or error behavior. For a tool with 4 parameters and many siblings, more detail on return values would enhance completeness.
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% and the description adds extra context by reinforcing pagination with `cursor` and mentioning use cases. However, it does not provide deeper semantics beyond what the schema already offers, meeting the baseline for high coverage.
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 videos by keyword and returns matching posts with stats. The name and description distinguish it from sibling search tools (e.g., tiktok_search_creators), though no explicit differentiation is given.
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 (topic/trend discovery, competitive research) and mentions pagination with cursor. However, it does not specify when not to use this tool or mention alternative search tools for other resource types.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tiktok_sound_infoAInspectFetch 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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It states it fetches metadata (read-only), but does not disclose rate limits, auth requirements, or response structure. Adequate 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 sentences with no wasted words. First sentence states purpose and outputs; second sentence gives usage hint. 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?
Given tool simplicity (2 params, no output schema, no annotations), description covers purpose, use case, and key outputs. Lacks response format details but acceptable for a metadata 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 documentation coverage is 100% for both parameters. Description adds no new meaning beyond schema; e.g., 'music_id' is already described as 'Numeric TikTok music_id'. 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 specific verb 'Fetch' and resource 'sound/track metadata', lists returned fields (title, author, duration, usage count), and distinguishes from sibling tiktok_sound_videos by stating 'before pulling its 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 case: 'Use to size a sound's reach before pulling its videos.' Implies when to use this tool vs. tiktok_sound_videos. Lacks explicit exclusion of alternatives but 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_videosAInspectList 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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits. It mentions ordering and pagination but does not state that the operation is read-only, lacks details on rate limits, auth requirements, or any side effects. This is insufficient for a tool with no annotation safety net.
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-load purpose and ordering, followed by use cases and a pagination hint. No wasted 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?
Given no output schema, the description could explain the response format. It mentions cursor-related fields in the parameter description but not in the main text. The use cases are helpful, but missing return structure details makes it somewhat incomplete.
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 schema already documents all parameters. The description adds only the pagination hint ('Paginate with `cursor`') and ordering, providing marginal extra value. 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 'List', the resource 'videos that use a given sound/track', and specifies ordering by most-recent first. It distinguishes from sibling tools like tiktok_hashtag_videos or tiktok_sound_info by focusing on videos using a specific sound.
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 explicit use cases (sound-trend analysis, finding UGC, gauging virality) and mentions pagination with cursor. It does not include when not to use it, but the context is clear enough given sibling tools serve different purposes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tiktok_user_storiesAInspectList 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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that stories expire ~24h, implying a time-sensitive fetch. It does not mention rate limits or side effects, but as a read-only operation, this is acceptable.
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: one for purpose, one for usage, one for parameter. Zero wasted words, front-loaded with essential 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?
No output schema, but the description doesn't detail return format. However, for a list tool with few parameters, the description is sufficiently complete to use effectively.
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 that user_id accepts '@username or numeric id', but does not elaborate on count or expand beyond what the schema already provides.
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 'a creator's active TikTok Stories', and explains what Stories are (ephemeral posts ~24h). This distinguishes it from sibling tools like tiktok_creator_videos which list permanent 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 says 'Use to capture story content before it disappears', giving a clear use case. However, it does not mention when not to use or provide 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_video_commentsAInspectList 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 |
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 discloses pagination, ordering, and the fact that it returns top-level comments. However, it does not mention authentication requirements, rate limits, or the possibility of empty results.
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 that cover purpose, output, usage context, and pagination. Every sentence adds value without 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 tool's low complexity, lack of output schema, and no annotations, the description provides adequate information: what it returns (comments with likes and authors), how to paginate (cursor), and a use case. Missing details about error states or limits, 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?
All four parameters are well-described in the schema (100% coverage). The description adds minimal extra context (e.g., relevance ordering, pagination behavior) but does not significantly enhance understanding 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 action (list), resource (top-level comments), ordering (most-relevant first), and included data (like counts and authors). It effectively distinguishes from the sibling tool tiktok_comment_replies, which handles nested 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 provides explicit use cases (sentiment sampling, audience-response analysis) and mentions pagination via cursor. It does not explicitly state when not to use, but the purpose is clear enough to avoid confusion with siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tiktok_video_download_urlAInspectResolve 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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are empty, so the description must cover behavioral traits. It does not disclose side effects, rate limits, authentication needs, or error handling (e.g., if the video is unavailable). It only covers input formats, leaving the agent uninformed about the tool's safety or mutation behavior.
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, front-loaded with the core purpose, and contains no unnecessary words. Every sentence adds meaning.
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 2 parameters and no output schema, the description adequately explains what it does (resolves a URL) and how to specify the input. No output schema is present, but the description implies the output is a URL, which is sufficient for this simple tool.
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 value by clarifying the video_id parameter accepts both numeric IDs and full URLs, which goes beyond the schema description. For the expand parameter, the schema already explains it well.
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 resolves a watermark-free download URL for a TikTok video, specifying the output as clean MP4 for archival or analysis. It distinguishes this from sibling tools like comments or stats, which serve different purposes.
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 to obtain the clean MP4 for archival or analysis', providing a clear use case. However, it does not explicitly state when not to use this tool or compare it to alternatives, though the context of siblings makes the usage implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tiktok_video_statsAInspectFetch 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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must handle behavioral context. It describes what data is returned and the input format, but lacks details on rate limits, authentication, or error handling (e.g., what if video is private or deleted).
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, front-loading the purpose and then adding usage guidance. Every sentence provides essential information with no verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-video stats tool, the description lists all key return fields, making it complete enough for selection. No output schema exists, so the list compensates. It could mention handling of invalid IDs or missing videos, but overall sufficient.
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% with both parameters documented. The description adds clarity that video_id can be a numeric aweme_id or a full URL, which adds value beyond the schema. However, it does not elaborate on the expand parameter beyond what the schema says.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it fetches a single video's stats and metadata, listing specific metrics. It distinguishes itself from sibling tools like tiktok_video_comments or tiktok_video_download_url by focusing on performance metrics.
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 to measure a specific post's performance,' providing a clear use case. It does not explicitly state when not to use it or mention alternatives, but the sibling context implies that for other data (e.g., comments, creator info) other tools are appropriate.
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.
No comments yet. Be the first to start the discussion!