Skip to main content
Glama
Crawlora-org

Crawlora MCP

Official
by Crawlora-org
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

tiktok_mobile_place_photos

Fetch a TikTok place's photo album by poi_id to retrieve categorized images with per-photo author attribution for enriching place listings.

Instructions

Place photo album with per-photo attribution. Returns one place's photo album, keyed by the poi_id that the place search endpoint returns. The upstream is /tiktok/poi/picture_album/v1: categories holds each album tab (name, pic_tab_typecode, pictures of bare image URL lists and pictures_v2, the same photos with author attribution, pic_id, source and origin/compressed URL info), photo_count sums the categories' pictures, and title is the app's own header. Measured 2026-10-21 with the pure-Go (device-free) signer: one place answered 5,368 B, title "Gallery (3)", 1 category with 3 photos whose pictures_v2 entries name the Google-places contributor; another answered 24,196 B with more photos. The album is one-shot: count and pic_tab_typecode were measured and did not change the page. A nonexistent id answers 500 (the upstream answers status 4 "Server is currently unavailable" on this route, unlike the poi-not-exist code the other place routes use). 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.6/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations exist, so the description carries the full burden and does so exceptionally: it discloses the upstream route, the exact return shape (categories, pictures vs pictures_v2 with author attribution, photo_count, title), pagination is a no-op, and error behavior (nonexistent id gives 500/status 4, distinct from other place routes). It even notes the route is not signature-gated so a device-free signer suffices.

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 what the tool returns, then the return structure, then behavioral quirks. It is dense and includes measured byte sizes and a measurement date that are slightly more than strictly necessary, but they concretely illustrate the return shape so they earn most of their space.

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 and no annotations, the description fully compensates: it describes the return fields, the no-pagination behavior, the error mode, and the signing requirement. An agent has everything needed to call it correctly and interpret the response.

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 single poi_id param is self-documenting, so baseline is 3. The description adds value by clarifying that poi_id must come from the place search endpoint rather than anywhere else, giving an agent the correct source.

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?

States a specific verb+resource ('Returns one place's photo album') and immediately scopes it to the poi_id from the place search endpoint. This distinguishes it cleanly from siblings like tiktok_mobile_place_detail, tiktok_mobile_place_info, and tiktok_mobile_place_videos without any ambiguity.

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 context: it takes the poi_id that the place search endpoint yields, and it notes the album is one-shot (count/pic_tab_typecode don't change results). It doesn't explicitly name sibling tools to prefer over this one, so it stops short of full when-to-use-vs-alternative guidance.

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