Choose a query and a sample boundary

Use search_videos to retrieve ordinary TikTok video search results. Give the tool a specific keyword. Set count from 1 to 20. Add a supported sort and date filter only when the decision needs them.

Write the sample plan before the call: “Inspect the first two pages of relevance results for ‘standing desk treadmill’ and code the opening claim.” The plan tells you where to stop and keeps a later summary tied to the result set you inspected.

The saved two-page search returned four videos, then three. Follow the returned continuation values.
The saved two-page search returned four videos, then three. Follow the returned continuation values.

Call the first page through the MCP connection

Configure the MCP client with https://mcp.tokconnect.com/mcp and a bearer key. TokConnect does not provide public per-tool REST endpoints. The following object is a tools/call fragment for a connected MCP client:

{
  "method": "tools/call",
  "params": {
    "name": "search_videos",
    "arguments": {
      "keyword": "standing desk treadmill",
      "count": 5,
      "sort": "relevance"
    }
  }
}

The result includes video records with author and engagement fields, plus the paging information used for continuation. Inspect returned media URLs and descriptions as source material; the service does not watch videos or extract transcripts for you.

Inspect a two-page result

A fresh 18 September 2026 search for standing desk treadmill requested five relevance results. Page one returned four records, nextOffset: 5, and searchId 202609190144479A810E0F85177E8E1548. The second call used that exact search ID with offset 5 and returned three records. It returned its own next search ID, which the evidence file preserves.

PageReturned recordsExample recordContinuation value
Offset 04alyssasanddd, 847,815 viewsnextOffset 5 and first searchId
Offset 53ccupp4, 18,322 viewsnextOffset 10 and second searchId

Record the page’s returned count rather than treating the requested count as a guarantee. The page-one and page-two records support a review of seven returned videos. They do not represent the complete TikTok result set.

Read every paging field

count asks for a maximum of one to 20 results. nextOffset is the value the next request must use. hasMore says that the upstream response advertises another page. searchId is the continuation token from the first response. Keep the first page’s query, sort, date, count, and search ID together. A later offset without that search context can return an empty-session error.

FieldPage one value in the saved runUse on the next call
keywordstanding desk treadmillRepeat unchanged
sortrelevanceRepeat unchanged
count5 requested; 4 returnedKeep the request size explicit
nextOffset5Send as offset: 5
searchId202609190144479A810E0F85177E8E1548Send as search_id

Write a paged client loop

This is pseudocode for a wrapper that has already decoded the MCP tool payload into videos, searchId, nextOffset, hasMore, and is_error. An SDK may expose those values under different names.

page = call_and_decode("search_videos", first_arguments)
if page.is_error: stop_and_save(page.error)
save_redacted_page(page)
records = unique_by_id(page.videos)
search_id = page.searchId
previous_offset = first_arguments.get("offset", 0)
offset = page.nextOffset
pages = 1

while page.hasMore and pages < 2 and len(records) < 10:
    if not search_id or offset <= previous_offset: break
    page = call_and_decode("search_videos", {
      **first_arguments, "offset": offset, "search_id": search_id
    })
    if page.is_error: stop_and_save(page.error)
    records = unique_by_id(records + page.videos)
    previous_offset, offset = offset, page.nextOffset
    pages += 1
    save_redacted_page(page)

Set the page cap from the research plan. This example stops after two pages, an error, a missing session ID, a non-advancing offset, ten unique records, or an upstream end signal. Preserve the first page’s searchId because the local tool schema requires it for later offsets; save any changed ID returned on later pages as response evidence rather than assuming a replacement rule. A queryId from topic search cannot continue a video search.

Recover from search errors

The local implementation accepts relevance, most_liked, and newest as sort values; it accepts any, day, week, month, and half_year for the date filter. Reject unknown values before a costly research run. A blank keyword is an input error. A missing continuation token on a later offset is a paging error.

An empty result can be genuine, but an empty response with the upstream search_nil_item signal is handled as a search limit or block by the local backend. Record the provider error and stop treating the empty list as market evidence. A new first-page request is a new sample, so save it separately instead of appending it to a failed page sequence.

Turn the pages into a reviewable memo

Search: [exact keyword]. Filters: [sort and date]. Pages inspected: [offsets]. Retrieval: [date and time]. Selected videos: [URLs]. Observed pattern: [specific description]. Proposed test: [one production change]. Boundary: this finding covers the retrieved result pages only.

Use video_detail for a selected record and video_comments for audience language. The comment workflow covers a clear denominator. Compare topic data in Creator Search Insights through MCP, or review the broader connection choice in TikTok MCP vs TikTok APIs.

Sources and further reading