Skip to main content
Glama
Crawlora-org

Crawlora MCP

Official

tiktok_mobile_search_effects

Search TikTok effects and stickers by keyword to retrieve full effect objects; paginate results by passing the returned cursor and search_id together.

Instructions

Search TikTok effects/stickers by keyword. Searches TikTok's effect catalogue by keyword, returning the app's full effect objects (name, hint, icon_url, file_url, effect_id, types, tags, parent/children, effect_type, music, source, designer_id, schema). The upstream is /aweme/v1/search/effect/; the page is unfolded to the top level (effects, cursor, has_more, search_id, use_hot, plus bind_effects/collection on some queries). Paging is real but needs BOTH halves of the token: pass the previous response's cursor and search_id together (measured: page 1 cursor: 100, page 2 with cursor=100&search_id=... returned the final effect with has_more: false; a cursor without its search_id returns an empty page, which the service rejects as a 400). count and offset were measured as no-ops. Measured 2026-10-21 with the pure-Go (device-free) signer: keyword=green screen -> 6 effects (11,831 B) + 1 on page 2, green -> 2, 字幕 -> 4; a keyword with no matches is a valid empty page. The route is not signature-gated, so it does not need the device-backed signer.

Input Schema

NameRequiredDescriptionDefault
countNoAccepted for shape parity; the server was measured to ignore it
cursorNoNext-page token from the previous response (0 = first page)
keywordYesEffect name or text, e.g. green screen
search_idNoSearch-session token from the previous response; required together with cursor

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.17.16

TDQS

A4.6/5.0
Behavior5/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 so: it discloses the upstream path, how the envelope is unfolded to the top level, that paging is real but token-paired, that count/offset are ignored, that the endpoint is not signature-gated, and that an empty result set is valid rather than an error. These are measured, non-obvious traits an agent could not infer from the schema.

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?

Purpose is front-loaded in sentence one, and the remaining prose is dense with measured facts (byte sizes, example keywords, page-2 behavior). It is long, but nearly every clause earns its place; the measured example list is the only portion bordering on over-detailed.

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

Completeness5/5

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

There is no output schema, so describing the returned fields, top-level envelope keys, and conditional extras (bind_effects/collection) fills the gap precisely. Combined with the paging and signer notes, an agent has everything needed to call and paginate this tool correctly.

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 already 100%, so the baseline is 3; the description goes beyond it by explaining why cursor and search_id must be passed together and by documenting count/offset as no-ops with measured evidence. It adds real meaning rather than restating the schema.

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 first sentence names a specific verb and resource ('Search TikTok effects/stickers by keyword') and immediately narrows the scope to the effect catalogue. It is clearly distinguishable from siblings like tiktok_mobile_search (general content), tiktok_mobile_search_music, and tiktok_mobile_trending_effects.

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?

Strong operational guidance: it says paging requires BOTH cursor and search_id, that a cursor alone yields an empty page/400, that count/offset are no-ops, and that the route isn't signature-gated. It does not, however, explicitly route the agent away from sibling tools that also search by keyword (e.g. music vs. effect search).

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