Skip to main content
Glama
Crawlora-org

Crawlora MCP

Official
by Crawlora-org
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

tiktok_mobile_place_info

Fetch a compact TikTok place (POI) record by poi_id to get address, coordinates, rating, hours, and counters without loading the full detail page.

Instructions

Compact place (POI) record: address, coordinates, rating, hours, counters. Returns one place's compact record, keyed by the poi_id that the place search endpoint returns. The upstream is TikTok's POI read (/tiktok/poi/get/v1), the record behind a place card: name, address, category, average_price, latitude/longitude, city_code/region_code, review_score with review_count/no_rating, video_count, favorite_count, opening_hours/opening_status, cover, share_url/share_desc and parent_poi, plus the upstream POI object unmodified in place so a richer field is never lost. This is the cheap lookup to use instead of the ~1 MB slash detail page when only the place record is needed. A nonexistent id answers 400 (the upstream business status 3009009 "poi not exist" is a caller error, not an outage). Measured 2026-10-21 with the pure-Go (device-free) signer: 4,594 B for a coffee shop (score 4.7 / 2 reviews, price "$", hours "8:00 AM – 5:00 PM", 11 videos), 4,623 B for a second location (score 4.8 / 13 reviews). The route is not signature-gated, so it does not need the device-backed signer.

Input Schema

NameRequiredDescriptionDefault
poi_idYesPlace id from the place search endpoint

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.17.16

TDQS

A4.5/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 return fields, gives measured payload sizes (~4.6 KB), discloses the 400 / upstream status 3009009 error semantics ('a caller error, not an outage'), and notes the route is not signature-gated so the device-backed signer isn't needed. That is exactly the operational context an agent needs before calling.

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

Conciseness3/5

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

Front-loading is good: the first two sentences establish scope and key. But the closing measurement paragraph is bloated with two byte-count anecdotes, per-example ratings, prices, hours and video counts that do not change how the agent calls the tool; the second measurement adds essentially nothing over the first.

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 the description must describe the return shape, and it does: named field list plus a note that the raw upstream POI object is preserved in `place`. Error behavior and auth requirements are also covered, so nothing material is missing for a single-parameter read.

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% and the schema already says 'Place id from the place search endpoint', so the description's restatement of the same key adds little. The only extra signal is the 400 behavior on a nonexistent id, which is behavioral rather than semantic. Baseline 3 is appropriate.

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 concrete verb+resource ('Returns one place's compact record') and names the exact key (`poi_id`), the upstream endpoint, and the record contents. It explicitly contrasts itself with the place search endpoint that produces the id and with the heavier detail page, so an agent can distinguish it from tiktok_mobile_place_detail and tiktok_mobile_search_place without reading 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 Guidelines5/5

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

Explicitly states the selection rule: 'This is the cheap lookup to use instead of the ~1 MB slash detail page when only the place record is needed.' It also tells the agent where the id must come from (the place search endpoint) and what happens on a bad id, leaving no inference required.

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