Skip to main content
Glama
Crawlora-org

Crawlora MCP

Official
by Crawlora-org
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

tiktok_mobile_live_room

Retrieve a TikTok LIVE room's status, viewer count, owner, stream URLs, and cover by room_id for live monitoring and room-detail lookups.

Instructions

LIVE room detail: status, viewers, owner, stream URLs, cover. Returns one LIVE room's detail, keyed by room_id — the numeric id that /api/v1/tiktok/mobile/live/search returns under data[].lives.author.room_id. The upstream is /webcast/room/info/ on the webcast edge host (no origin header), captured from the running 47.4.3 app's LIVE surface and reproduced against the live gateway. The response projects the fields callers key on — title, status (2 = live), user_count (concurrent viewers), create_time, owner (user id, nickname, avatar), stats (cumulative enter_count/total_user, watch_user_count, like_count, comment_count, share_count, follow_count, replay_viewers), stream (playable flv_pull_url per resolution plus default_resolution/candidate_resolution and the HLS/RTMP URLs) and cover — and keeps the upstream room object unmodified in data (it has ~500 keys, so a partial struct would drop fields). Measured 2026-10-22 with the pure-Go (device-free) signer: one room returned 193-198 KB with 1,595-1,600 concurrent viewers, 27,916 cumulative viewers, 27,096 enters and FLV URLs for FULL_HD1/HD1/SD1/SD2. anchor_id is deliberately NOT forwarded: it was measured to suppress the audience-only stats.total_user (27,916 -> 0 on the same room). A missing, non-numeric or unknown room id answers the webcast envelope's status 10011 and is surfaced as a 400; a finished room (status 30003) is a 400 too. The route is not signature-gated, so it does not need the device-backed signer.

Input Schema

NameRequiredDescriptionDefault
room_idYesNumeric LIVE room id from /api/v1/tiktok/mobile/live/search (data[].lives.author.room_id)

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?

No annotations, so the description carries the full burden and does so richly: upstream path, ~500-key payload preserved unmodified, measured payload sizes, the deliberate omission of anchor_id and its rationale (it zeroes stats.total_user), status-code mapping, and the note that the route isn't signature-gated.

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 one-line purpose before detail, and every paragraph is purposeful. Some measured telemetry (193-198 KB, 1,595 viewers, 27,916 cumulative) is arguably more detail than an agent needs, but it is well organized.

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?

With no output schema, the description must explain returns and it does thoroughly (title, status, user_count, stats, stream URLs, cover) plus error semantics and the anchor_id caveat. Nothing an agent needs to call it correctly is missing.

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% and the schema already documents room_id with the exact path, which sets a baseline of 3. The description adds minor value by tying invalid/non-numeric ids to specific error behavior, but mostly restates the schema's identity description.

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?

Opens with a specific verb+resource ('LIVE room detail') and enumerates exactly what it returns (status, viewers, owner, stream URLs, cover). It also names the sibling endpoint (/api/v1/tiktok/mobile/live/search) that supplies the room_id, so an agent can place it in the workflow without opening the schema.

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?

Clear about where the room_id comes from and what happens on errors (invalid/unknown id -> 400, finished room status 30003 -> 400). It stops short of explicitly contrasting with tiktok_mobile_live_room_by_user or stating when to prefer one over the other.

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