Skip to main content
Glama
Crawlora-org

Crawlora MCP

Official
by Crawlora-org
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

tiktok_mobile_live_room_by_user

Retrieves the TikTok LIVE room a user is currently streaming by user_id, returning title, viewer count, owner, stats, and FLV URLs. Use it to check if a user is live and pull their active room data.

Instructions

LIVE room by user: the room a user is currently streaming. Returns the LIVE room a TikTok user is currently streaming, keyed by user_id. The upstream is /webcast/room/info_by_user/ on the webcast edge host (no origin header) and returns the same room payload as /api/v1/tiktok/mobile/live/room (title, status, concurrent viewers, owner, cumulative stats, per-resolution FLV URLs, cover and the ~500-key room object in data), except that the caller addresses a user and the room id is filled from the payload (both user_id and room_id are echoed). Measured 2026-10-22 with the pure-Go (device-free) signer: user_id=6707748031095751686 answered 184,575 B (195,220 B on the second webcast host); anchor_id alone answers a 57-byte empty payload, so user_id is the address. A user with no live room answers status 30003 "room has finished" and is surfaced as a 400; a non-numeric user id is a 400 (status 10011); a bare call answers a 57-byte empty success envelope, which is why this endpoint requires user_id. The route is not signature-gated, so it does not need the device-backed signer.

Input Schema

NameRequiredDescriptionDefault
user_idYesNumeric TikTok user id (e.g. the owner id from a profile, video author or live search row)

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 enumerates the response fields (title, status, viewers, owner, stats, FLV URLs, ~500-key room object), documents the failure modes (30003 'room has finished' surfaced as 400, 10011 for non-numeric id, 57-byte empty envelope on a bare call), and states the route is not signature-gated so no device-backed signer is needed. That is unusually complete behavioral disclosure for a read tool.

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?

The purpose is front-loaded in the first clause and the rest follows logically (payload, error semantics, auth). Some material does not earn its place for an invoking agent — the exact byte measurements (184,575 B / 195,220 B), the measurement date, and the second-host size are provenance rather than decision inputs, which makes the description heavier than it needs to be.

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?

A single-parameter, no-output-schema, no-annotation tool is fully covered: the description supplies what the response contains, what errors mean, and what credentials/signing are unnecessary. Nothing an agent needs in order 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 already 100%, so the baseline is 3; the description earns a point by adding meaning the schema lacks — that `user_id` is the only valid address, that `anchor_id` yields an empty payload, and that a non-numeric id produces a 400. It stops short of format detail such as length or numeric range, but the added constraints are the ones an agent would actually trip on.

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 opening sentence names a specific verb and resource ('Returns the LIVE room a TikTok user is currently streaming') and pins the addressing key to `user_id`. It also implicitly separates itself from the sibling `tiktok_mobile_live_room` by noting 'the caller addresses a user and the room id is filled from the payload', so an agent can tell the two apart without opening either 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?

Usage context is clear: call this when you have a user id and want that user's current live room, and the note that `anchor_id` alone returns an empty payload tells the agent which identifier to supply. It never explicitly routes to a named alternative ('use tiktok_mobile_live_room when you already have a room_id'), so the exclusion is implied rather than stated.

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