Skip to main content
Glama
Crawlora-org

Crawlora MCP

Official
by Crawlora-org
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

tiktok_mobile_music_posts

Fetches the videos that use a given TikTok sound, returning full video objects with author, statistics and sound info plus cursor pagination.

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

TableJSON Schema
NameRequiredDescriptionDefault
countNoAccepted for compatibility; the server ignores it (max 50)
cursorNoPagination cursor
music_idYesSound (music) id

Schema Changelog

Changes observed during successful MCP inspections.

  1. 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 disclose real behavioral traits: the return shape (aweme_list of full video objects with author/statistics/added_sound_music_info, plus cursor and has_more) and the non-obvious quirk that count is ignored upstream so paging must be done with cursor. It omits auth/permission needs and rate-limit behavior.

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?

Front-loaded with the purpose, then return shape, then the required-param and pagination caveats. Dense but each clause earns its place; only mild redundancy with the schema's note about count.

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?

For a 3-param, no-output-schema, no-annotation tool, the description is largely self-sufficient: it explains what is returned and how to paginate. Missing only edge behavior such as error/empty cases and any auth requirements.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, but the description adds actionable meaning beyond the schema: it reinforces that count is disregarded and instructs the agent to advance via cursor, which is the key invocation detail.

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'. The resource (a sound/music_id) clearly separates it from sibling post-list tools like tiktok_mobile_hashtag_posts, though no sibling is named explicitly.

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?

Usage is implied by the required music_id and the stated pagination flow ('page with cursor'), but there is no explicit when-to-use/when-not guidance and no alternatives named among the many music-related siblings (music_beats, music_related, music_trending).

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