Skip to main content
Glama
hhy5562877

Douyin MCP

by hhy5562877

get_user_posts

Fetch video posts from a Douyin user by supplying their security ID. Returns the video list and pagination data for browsing content.

Instructions

Get videos posted by a Douyin user.

Args: sec_user_id: The user's security ID max_cursor: Pagination cursor (default "0") count: Number of videos per page (default 18)

Returns: dict containing video list and pagination info

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
countNo
max_cursorNo0
sec_user_idYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.5/5.0
Behavior3/5

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

With no annotations provided, the description carries the burden, and it does disclose the return shape ('dict containing video list and pagination info') plus pagination parameters. It does not mention authentication requirements, rate limits, or whether only public videos are returned, but for a read-only getter the stated behavior is minimally transparent.

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

Conciseness5/5

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

The description is compact and well-structured, with a single-purpose opening line followed by args and returns sections. There is no filler or repetition of the schema beyond useful defaults.

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

Completeness4/5

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

For a simple paginated read operation, all parameters are documented and the return type is summarized while an output schema provides further detail. The main missing context is when to choose this versus sibling search/feed tools, and how to advance pagination.

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 description coverage is 0%, yet the description documents all three parameters with meaningful one-line explanations: sec_user_id, max_cursor as pagination cursor, and count as page size. The semantics are clear, though max_cursor could explain that it comes from the previous response.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a clear verb and resource: 'Get videos posted by a Douyin user,' so an agent knows the tool lists a user's videos. It doesn't explicitly compare against siblings like get_homefeed or search_videos, but the user-scoped wording makes its job identifiable.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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

There is no guidance about when to prefer this tool over alternatives, nor any exclusions. Given siblings such as get_homefeed and search_videos that could also return video lists, an agent is left to infer the appropriate selection context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.