Skip to main content
Glama

APIClaw

by io.apiclaw.api

openapi_v2_tiktok_videos_search

Tiktok Videos Search

Search daily-updated TikTok videos by engagement, creator, and commerce signals.

Filter by play and like counts, interaction rate, creator follower count, publish date, whether the video carries a shoppable product, and the product's category (by id or path). Each video also returns the primary product's category id and path. Data is from the latest daily video collection within the fallback window. Interaction rate is (likes + comments + shares + saves) / plays, as a decimal; it is computed per video, so filtering by it narrows the result set but does not reduce query time. Related: /tiktok/creators/search and /tiktok/products/search.

Responses:

200: Successful Response (Success Response) Content-Type: application/json

Example Response:

{
  "success": true,
  "meta": {
    "requestId": "Requestid",
    "timestamp": "Timestamp"
  }
}

Output Schema:

{
  "properties": {
    "success": {
      "type": "boolean",
      "title": "Success",
      "description": "Whether the request was successful",
      "default": true
    },
    "data": {
      "title": "Data",
      "description": "Response data payload"
    },
    "error": {
      "description": "Error details if request failed"
    },
    "meta": {
      "description": "Metadata for API responses.\n\nCredit fields follow the ADR-0003 parallel-fields strategy (Option 3):\n- `credits_remaining` / `credits_consumed` (int): legacy fields, rounded\n  to whole credits, kept for zero-breaking-change to existing SDK clients.\n- `credits_remaining_exact` / `credits_consumed_exact` (float): new\n  precision-aware fields for clients that opt in to decimal credits.\n\nSee ADR-0003 decision 5 and the \u00a78 deprecation timeline.\n\nTODO(2026-11, ADR-0003 \u00a78 +6mo): mark `credits_remaining` /\n`credits_consumed` as `deprecated=True` in their Field() definitions\nand announce in customer changelog.\nTODO(2027-05, ADR-0003 \u00a78 +12mo): remove the legacy int fields via a\nmajor-version bump of the OpenAPI surface.",
      "properties": {
        "requestId": {
          "type": "string",
          "title": "Requestid",
          "description": "Unique request identifier"
        },
        "timestamp": {
          "type": "string",
          "title": "Timestamp",
          "description": "Response timestamp in ISO 8601 format"
        },
        "total": {
          "title": "Total",
          "description": "Total number of records"
        },
        "page": {
          "title": "Page",
          "description": "Current page number"
        },
        "pageSize": {
          "title": "Pagesize",
          "description": "Number of records per page"
        },
        "totalPages": {
          "title": "Totalpages",
          "description": "Total number of pages"
        },
        "creditsRemaining": {
          "title": "Creditsremaining",
          "description": "Remaining API credits (rounded to whole credits; see creditsRemainingExact for precise value)"
        },
        "creditsConsumed": {
          "title": "Creditsconsumed",
          "description": "Credits consumed by this request (rounded; see creditsConsumedExact for precise value)"
        },
        "creditsRemainingExact": {
          "title": "Creditsremainingexact",
          "description": "Remaining API credits, precise to 1 decimal place"
        },
        "creditsConsumedExact": {
          "title": "Creditsconsumedexact",
          "description": "Credits consumed by this request, precise to 1 decimal place"
        },
        "tokensUsage": {
          "description": "Provider token-usage block \u2014 populated on terminal video polls only, null on every non-video endpoint. See TokensUsage for its fields."
        }
      },
      "type": "object",
      "required": [
        "requestId",
        "timestamp"
      ],
      "title": "ResponseMeta"
    }
  },
  "type": "object",
  "required": [
    "meta"
  ],
  "title": "OpenApiResponse[list[TikTokVideo]]",
  "examples": []
}

422: Validation Error Content-Type: application/json

Example Response:

{
  "detail": [
    {
      "loc": [],
      "msg": "Message",
      "type": "Error Type",
      "ctx": {}
    }
  ]
}

Output Schema:

{
  "properties": {
    "detail": {
      "items": {
        "properties": {
          "loc": {
            "items": {},
            "type": "array",
            "title": "Location"
          },
          "msg": {
            "type": "string",
            "title": "Message"
          },
          "type": {
            "type": "string",
            "title": "Error Type"
          },
          "input": {
            "title": "Input"
          },
          "ctx": {
            "type": "object",
            "title": "Context"
          }
        },
        "type": "object",
        "required": [
          "loc",
          "msg",
          "type"
        ],
        "title": "ValidationError"
      },
      "type": "array",
      "title": "Detail"
    }
  },
  "type": "object",
  "title": "HTTPValidationError"
}

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pageNo1-indexed page number.
sortByNoSort field for video search.playCount
videoIdNoExact TikTok video ID to look up.
pageSizeNoPage size, 1–100. Default 20.
sortOrderNoSort direction. Default desc.desc
categoryIdNoTikTok category ID — matches videos whose primary product anchor category has this id at any of the 7 hierarchy levels.
hasProductNoFilter by whether the video carries a shoppable product. True: the video has a TikTok Shop product anchor; False: it has none. Omit to include both.
categoryPathNoCategory path names, root → leaf, e.g. ['Home Improvement', 'Bathroom Fixtures']. Subtree match: the video's first N category level names must equal the N supplied segments in order; deeper levels (if any) are unconstrained. A partial path matches the whole subtree below it; supply the full leaf path to narrow to that single node. Must contain 1 to 7 segments (TikTok's max category depth) — deeper paths are rejected.
diggCountMaxNoMaximum like count.
diggCountMinNoMinimum like count.
playCountMaxNoMaximum play (view) count.
playCountMinNoMinimum play (view) count.
shareCountMaxNoMaximum share count.
shareCountMinNoMinimum share count.
publishedAtMaxNoLatest publish date (inclusive), as YYYY-MM-DD in UTC, e.g. 2026-06-30.
publishedAtMinNoEarliest publish date (inclusive), as YYYY-MM-DD in UTC, e.g. 2026-06-01.
repostCountMaxNoMaximum on-platform repost count.
repostCountMinNoMinimum on-platform repost count.
collectCountMaxNoMaximum save/collect count.
collectCountMinNoMinimum save/collect count.
commentCountMaxNoMaximum comment count.
commentCountMinNoMinimum comment count.
interactionRateMaxNoMaximum interaction rate, as a decimal. Interaction rate = (likes + comments + shares + saves) / plays.
interactionRateMinNoMinimum interaction rate, as a decimal. Interaction rate = (likes + comments + shares + saves) / plays.
creatorFollowerCountMaxNoMaximum follower count of the video's creator.
creatorFollowerCountMinNoMinimum follower count of the video's creator.

TDQS

A4.1/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full behavioral burden. It discloses meaningful traits: data is from the latest daily collection within a fallback window, interaction rate is computed per video and filtering does not reduce query time, and each result includes the primary product's category id/path. It doesn't mention auth or rate limits, but for a search tool this is strong behavioral coverage.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The text is front-loaded with the core search purpose, followed by filter capabilities and a behavioral note. The extensive response schemas add length but are justified since no dedicated output schema field exists. Overall it is well-structured and each section earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 26 parameters, no annotations, and no output schema, the description compensates well: it covers data source, filter semantics, interaction rate calculation, related tools, and response formats. It lacks explicit error-handling beyond 422 and auth notes, but those are not essential for a search tool with this level of schema documentation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so every parameter is already documented with meaningful descriptions. The main description adds a high-level summary of filter types and the interaction rate formula, but it restates, rather than extends, what the schema already provides. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with 'Search daily-updated TikTok videos by engagement, creator, and commerce signals', which clearly states a specific verb and resource. It distinguishes itself from sibling tools by listing related searches (/tiktok/creators/search and /tiktok/products/search), making its scope unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context for when to use this tool—when searching TikTok videos with engagement, creator, and commerce filters. It names related tools but does not explicitly state exclusions (e.g., 'for creators, use /tiktok/creators/search instead'), so it stops short of full when/not guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All APIClaw toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

B3.2/5.0
Disambiguation2/5

Several tools have unclear boundaries, most notably openapi_v2_competitor_product_keywords and openapi_v2_product_traffic_terms, which have identical descriptions. The deprecated openapi_v2_realtime_product duplicates openapi_v3_realtime_product, and openapi_v2_image_embedding overlaps heavily with openapi_v2_fashion_image_embedding.

Naming Consistency2/5

Naming is inconsistent: a few tools follow a clean verb_noun pattern (create_video_asset, list_video_assets, poll_video_task), while the vast majority are prefixed with openapi_v2_/openapi_v3_ followed by nouns or mixed verbs. The route-style prefix is not a meaningful verb and creates an arbitrary split across the tool set.

Tool Count2/5

49 tools is far beyond the well-scoped range and spans multiple unrelated domains (Amazon product data, TikTok commerce, fashion vision, web scraping, video generation, billing). The server appears to be an entire REST API surface exposed wholesale rather than a curated set of capabilities.

Completeness3/5

Each domain is individually fairly complete (Amazon search/reviews/keywords/VoC, TikTok search, web tools, video generation), but there are notable gaps: video assets lack update/delete, video tasks lack cancel/list, and there is no singular 'get daily product by ASIN' alongside the realtime variants. The broad scope makes it hard to verify full lifecycle coverage across all domains.

Resources