Skip to main content
Glama

Finewisdom 社媒与电商数据接口

ks_keyword_search

Read-onlyIdempotent

按关键词搜索快手内容。返回视频列表,含每条内容ID与基础互动数据。做关键词监测、内容发现或构建候选集时用,ID可继续调详情与评论接口。单价¥0.3/次,仅成功调用计费,失败或空结果自动退回。

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": {
      "keyword": "<keyword>"
    },
    "name": "ks_keyword_search"
  }
}

Input Schema

NameRequiredDescriptionDefault
_tokenNo备用鉴权:fw_ 开头的 token。推荐改用 HTTP Header X-FW-Token。
cursorNo翻页游标
keywordYes关键词

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/openWorld/non-destructive, so the safety profile is covered. The description adds genuinely non-obvious behavior: per-call pricing of ¥0.3, billing only on success, and automatic refund on failure or empty results — a real cost/retry consideration for an agent. It does not describe pagination behavior of the cursor.

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?

Four short sentences ordered purpose → return value → usage → cost, with nothing redundant. Every sentence carries information the agent needs, and the cost caveat is placed last where it does not obscure the core action.

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 no output schema, the description correctly takes on return-value disclosure (video list with IDs and basic engagement metrics). The main gap is pagination: the cursor parameter exists but the description never indicates whether the result set is paged or capped.

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 description coverage is 100%, so the schema already documents keyword, cursor, and _token; the description adds no per-parameter meaning beyond that. Baseline 3 applies — the description neither compensates for nor undermines 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 states a specific verb and resource ('按关键词搜索快手内容') and adds the return shape ('返回视频列表,含每条内容ID与基础互动数据'), so the agent knows exactly what it gets. It differentiates by platform name against the many other *_keyword_search siblings, though it never names a sibling directly.

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?

It gives concrete usage contexts ('关键词监测、内容发现或构建候选集时用') and an explicit follow-on path ('ID可继续调详情与评论接口'), which tells the agent this is a discovery/entry-point tool. It stops short of naming when NOT to use it (e.g. vs. ks_hot_list, which also surfaces Kuaishou content).

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.