Skip to main content
Glama

SocialDataX 抖音 Douyin MCP

douyin_get_video_statistics

Read-only

按单个作品 ID 查询视频或图文播放量、点赞数、评论数和下载数,每次仅传一个 ID;未提供的互动指标为 null,未返回统计的 ID 单独列出。

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "aweme_id": "<aweme_id>"
    },
    "name": "douyin_get_video_statistics"
  }
}

Input Schema

NameRequiredDescriptionDefault
aweme_idYes单个抖音视频或图文作品 ID,1–32 位数字字符串。可复用搜索或详情结果中的 aweme_id,不传链接或分享文案。

Output Schema

NameRequiredDescriptionDefault
itemsYes取得播放量的作品,按请求 ID 顺序排列
pointsYes本次成功调用的积分消耗与账户积分余额。
missing_aweme_idsYes本次未返回统计的作品 ID;不代表作品已删除,也不表示播放量为零

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • addedInput schema / properties / aweme_id
      Added value: +{
      +  "description": "单个抖音视频或图文作品 ID,1–32 位数字字符串。可复用搜索或详情结果中的 aweme_id,不传链接或分享文案。",
      +  "maxLength": 32,
      +  "minLength": 1,
      +  "type": "string"
      +}
    • removedInput schema / properties / aweme_ids
      Removed value: -{
      -  "description": "抖音视频或图文作品 ID 数组,1–50 个不重复的数字字符串;单条查询传一个元素。可复用搜索或详情结果中的 aweme_id,不传链接或分享文案。",
      -  "items": {
      -    "type": "string"
      -  },
      -  "maxItems": 50,
      -  "minItems": 1,
      -  "type": "array"
      -}
    • changedInput schema / required
      Previous value: -[
      -  "aweme_ids"
      -]New value: +[
      +  "aweme_id"
      +]
  2. Changed1 schema field changed
    • removedOutput schema / properties / items / items / properties / share_count
      Removed value: -{
      -  "anyOf": [
      -    {
      -      "minimum": 0,
      -      "type": "integer"
      -    },
      -    {
      -      "type": "null"
      -    }
      -  ],
      -  "default": null,
      -  "description": "本次查询返回的分享数;未提供时为 null",
      -  "title": "Share Count"
      -}
  3. Added

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already cover safety (readOnlyHint) and open-world reach, and the description adds genuinely new behavioral facts: missing interaction metrics come back as null, and IDs with no statistics are reported separately. That partial-result semantics is exactly the kind of thing an agent cannot get from the annotations, though rate limits or auth needs are unmentioned.

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?

A single dense sentence front-loads the resource and metrics, then appends the two behavioral caveats. Every clause carries information, though the semicolon chain makes it slightly harder to scan than a two-sentence split would.

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?

With an output schema present, the description does not need to explain return shapes, yet it still clarifies null handling and the separately-listed missing IDs. For a one-parameter read tool this is close to complete; only the relationship to the detail/URL siblings is left implicit.

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%, so the single aweme_id parameter is already well documented including the 1–32 digit format and the 'no links or share text' rule. The description adds the non-obvious constraint that only one ID may be supplied per call, i.e. no batching, which is meaning beyond the schema.

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 names a specific verb (查询) and a concrete resource set (播放量、点赞数、评论数、下载数) scoped to a single work ID, which cleanly separates it from detail-oriented siblings like douyin_get_video_detail_by_aweme_id. It never names a sibling explicitly, so it falls just short of the top band.

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

Usage Guidelines3/5

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

The 'each call takes only one ID' constraint is a real usage rule, but there is no statement of when to pick this over douyin_get_video_detail_by_aweme_id or the URL-based variant, and no prerequisites or exclusions. Usage must be inferred from the metric list.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources