Skip to main content
Glama
Sign In
Crawlora MCP

Crawlora MCP

Official
by Crawlora-org
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

tiktok_mobile_music_posts

Retrieve TikTok videos that use a specific sound, including full video objects, author and stats, with cursor-based pagination. Pass the sound music_id to list fresh or popular posts.

Instructions

Retrieve videos for a TikTok sound. Lists the videos that use one sound, as the mobile app returns them: aweme_list of full video objects (with author, statistics and added_sound_music_info), plus cursor and has_more. music_id is required. count is accepted but ignored upstream - the server returns its own default page, so page with cursor.

Input Schema

NameRequiredDescriptionDefault
sortNoListing: fresh (newest, default) or popular (app canonical music.posts list)
countNoAccepted for compatibility; the server ignores it (max 50)
cursorNoPagination cursor
music_idYesSound (music) id

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.17.18
    • changedInput schema / properties / sort / description
      Previous value: -"Listing: fresh (newest, default) or popular (app canonical music.posts list; requires the device-backed signer)"New value: +"Listing: fresh (newest, default) or popular (app canonical music.posts list)"
  2. Changed1 schema field changedv1.17.16
    • addedInput schema / properties / sort
      Added value: +{
+  "description": "Listing: fresh (newest, default) or popular (app canonical music.posts list; requires the device-backed signer)",
+  "enum": [
+    "fresh",
+    "popular"
+  ],
+  "type": "string"
+}
  3. Addedv1.17.13

TDQS

A3.8/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 burden and does well: it discloses the response shape (`aweme_list` of full video objects with `author`, `statistics`, `added_sound_music_info`, plus `cursor` and `has_more`) and warns that `count` is ignored upstream in favor of a server default page. Read-only nature is implied by 'Retrieve'/'Lists' but not stated outright, and rate limits or auth needs are absent.

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

Conciseness5/5

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

Three tight sentences ordered by importance: what it returns, what the payload contains, then the parameter gotcha. Nothing is repeated and no filler appears — the pagination caveat is exactly the kind of detail that prevents a mis-called tool.

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?

No output schema exists, so describing the returned `aweme_list` fields and cursor/has_more is necessary and delivered. Parameter behavior and pagination are both covered, leaving only minor gaps like what `sort` does to results, which the schema already handles.

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 coverage is 100%, so every parameter including the `sort` enum is already documented in structured fields, which sets the baseline at 3. The description reinforces the `music_id` requirement and the ignored-`count` quirk but adds no new semantics for `sort` or `cursor` beyond what the schema already says.

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

Purpose4/5

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

States a specific verb and resource: 'Retrieve videos for a TikTok sound. Lists the videos that use one sound.' That clearly separates it from related music tools conceptually, but it never names the adjacent siblings (tiktok_mobile_music_pick, tiktok_mobile_music_related, tiktok_mobile_music_trending, tiktok_mobile_search_music), so the agent must infer the distinction from the name alone.

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

Usage Guidelines3/5

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

Use is only implied: you call it when you already have a `music_id` and want that sound's video list. There is no explicit when-to-use, when-not-to-use, or named alternative such as tiktok_mobile_music_trending for discovering sounds. The practical paging advice ('page with `cursor`') is the only operational guidance offered.

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

Deploy Server

Other Tools