Enables AI agents to access and query KOLSprite's TikTok seller analytics data through structured MCP tools, handling authentication and API complexity.
Scored across 9 tools
Most tools target distinct entities (creators, products, shops, videos) with different entry points, and category lookups are clearly scoped as lookups. Some boundaries blur: creator_search vs product_related_creator both return creator lists, and video_search vs asin_analysis_video both return videos, though their inputs (keyword/product vs ASIN) differentiate them.
A clear noun_action pattern dominates (creator_search, product_search, shop_search, video_search, creator_category_list). A few names deviate (asin_analysis_video, caption_extract_url, product_related_creator) but all remain snake_case and readable.
Nine tools is well-scoped for a TikTok e-commerce analytics platform, covering the four core entities plus supporting lookups and relationship queries without redundancy.
The surface covers search across creators, products, shops, and videos, plus category lookups and cross-entity relationship queries (product_related_creator, asin_analysis_video), so core discovery workflows are covered. The main gap is the absence of dedicated detail/get-by-ID tools, forcing agents to retrieve specific records via search parameters.
ASIN关键词视频分析。根据ASIN和市场区域查找关联的带货视频。
Args:
market (string): 市场(US/GB/...)，必填
asin (string): 亚马逊ASIN标识，必填
region (string): 视频区域，非必传，不传则和market一致
page_num (integer): 页码，默认1
page_size (integer): 每页数量，默认20，最大100
Returns:
object: 分页结果。
外层: {code(string): 状态码, message(string): 提示信息, success(boolean): 是否成功, data(object): 分页数据}
data: {total(integer): 数据总数, pageNum(integer): 当前页码, pageSize(integer): 页容, list(object[]): 结果集}
list元素(视频):
id (string): 视频ID
title (string): 视频标题
cover (string): 视频封面
region (string): 区域
seconds (integer): 视频时长(秒)
pubTime (string): 视频发布时间
playCnt (integer): 播放量
likeCnt (integer): 点赞数
collectCnt (integer): 收藏数
commentCnt (integer): 评论数
forwardCnt (integer): 转发数
interactionRate (number): 互动率
currency (string): 货币
totalSalesVolume (integer): 总销量
salesVolumeLst30d (integer): 近30天销量
salesLst30d (number): 近30天销售额
creator (object): 达人信息
product (object): 商品信息
creator(达人信息):
id (string): 达人ID
name (string): 达人昵称
handleName (string): 达人handle
cover (string): 达人头像
region (string): 达人区域
fansCnt (integer): 粉丝数
categoryList (string[]): 达人分类
enCategoryList (string[]): 达人英文分类
product(商品信息):
id (string): 商品ID
title (string): 商品标题
imageUrl (string): 商品图片
price (number): 现价
originalPrice (number): 原价
currency (string): 货币
region (string): 商品区域
catId (string): 分类ID
catName (string): 分类名称
cnCatName (string): 中文分类名称
salesVolumeLst30d (integer): 近30天销量
totalSales (number): 总销售额
| Name | Required | Description | Default |
|---|---|---|---|
| asin | Yes | 亚马逊ASIN标识，必填 | |
| market | Yes | 市场(US/GB/...)，必填 | |
| region | No | 视频区域，非必传，不传则和market一致 | |
| page_num | No | 页码，默认1 | |
| page_size | No | 每页数量，默认20，最大100 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does disclose the paginated return shape and field semantics. However, it never states that this is a read-only lookup, nor does it mention auth requirements or rate limits, so the operational profile is only inferable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The purpose is front-loaded, which is good, but the Args block is a pure duplicate of the input schema and does not earn its place. The Returns block is long yet justified since there is no output schema; the parameter repetition is the main waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Because no output schema exists, the detailed nested return documentation (pagination wrapper, video fields, creator and product sub-objects) genuinely compensates and lets an agent consume the result. The remaining gap is the absence of any routing context against the sibling video tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 every parameter. The Args block in the description merely restates the same text verbatim (e.g. '市场(US/GB/...)，必填'), adding no syntax, valid-value, or fallback detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The Chinese description states a concrete verb and resource: retrieve sales/带货 videos associated with a given ASIN and market region. This is more specific than a bare resource name, but it never distinguishes itself from siblings such as video_search or product_related_creator, which an agent must disambiguate against.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no when-to-use or when-not-to-use guidance and names no alternative. Nothing tells the agent why it would pick this over video_search or product_related_creator, even though those siblings clearly overlap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
通过视频URL提取字幕内容。
Args:
url (string): 视频URL(必填)
is_southeast_asia (boolean): 是否东南亚视频，默认false
Returns:
object: {code(string): 状态码, message(string): 提示信息, success(boolean): 是否成功, data(string): 字幕内容}
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | 视频URL(必填) | |
| is_southeast_asia | No | 是否东南亚视频，默认false |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden. It usefully discloses the return envelope (code, message, success, data) since there is no output schema, but it says nothing about auth requirements, rate limits, or failure behavior for an invalid/unsupported URL.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded one-line purpose followed by a standard Args/Returns layout. Slightly redundant in echoing the schema, but appropriately sized for a two-parameter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The fabricated Returns section compensates for the absent output schema, and both params are covered. However, with no annotations and no usage guidance, an agent still lacks sufficient context to know when this tool applies versus the video_search family.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters are already documented in the schema. The Args block merely restates them verbatim, adding no syntax, format, or URL-validation detail beyond the structured fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource: extract subtitle/caption content from a video URL. This is clearly distinguishable from all siblings (search/list/analysis tools), so an agent can identify it without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no when-to-use guidance, no prerequisites, and no indication of when an alternative tool might be preferable. The agent must infer that this is the caption-extraction entry point.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取TikTok达人分类列表。creator_search的category_list参数取值来源于此。
Returns:
object: {code(string): 状态码, message(string): 提示信息, success(boolean): 是否成功, data(object[]): 分类列表}
data元素:
value (string): 分类值(用于creator_search的category_list)
categoryCn (string): 分类中文名
categoryEn (string): 分类英文名
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden: it documents the full return envelope (code, message, success, data[]) and the shape of each data element. It does not state read-only/non-mutating behavior or any auth/rate-limit constraints, but as a zero-parameter lookup the disclosed output shape is the substantive behavioral detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the one-sentence purpose and the cross-reference, followed by a structured Returns block. The Returns block is long relative to the single sentence of prose, but it is justified because no output schema exists.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter lookup with no output schema, the description supplies the complete return structure (envelope plus per-element fields) and the downstream consumer of the values. Nothing an agent needs to call it or interpret the result is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so the baseline is 4. The description correctly adds no parameter semantics because none exist, and its return-field descriptions (value/categoryCn/categoryEn) describe outputs rather than inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource (获取TikTok达人分类列表) and immediately ties it to the sibling creator_search, making clear this is the value source for that tool's category_list parameter. An agent can distinguish it from product_category_list purely by the creator-vs-product scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells the agent the returned values are consumed by creator_search's category_list parameter, which implies the call-before-search ordering. It stops short of an explicit when-not or a named alternative for category lookup, so it is clear context but not full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
搜索TikTok达人/创作者。支持按昵称或关键词搜索，可按粉丝数、互动率、带货量等条件筛选。
Args:
keyword (string): 搜索词
search_type (string): 搜索方式 N:昵称，K:关键词，默认K
region (string): 国家/区域，默认US
category_list (string[]): 达人分类列表
product_category_list (string[]): 带货分类列表
fans_cnt_from (integer): 粉丝数量下限
fans_cnt_to (integer): 粉丝数量上限
fans_gr_from (number): 粉丝增长率下限
fans_gr_to (number): 粉丝增长率上限
interact_from (number): 互动率下限
interact_to (number): 互动率上限
avg_like_from (number): 平均点赞量下限
avg_like_to (number): 平均点赞量上限
play_cnt_from (integer): 平均播放量下限
play_cnt_to (integer): 平均播放量上限
video_cnt_from (integer): 视频数量下限
video_cnt_to (integer): 视频数量上限
product_cnt_from (integer): 商品数下限
product_cnt_to (integer): 商品数上限
sales_volume_from (integer): 带货销量下限
sales_volume_to (integer): 带货销量上限
order_field (string): 排序字段
order_type (integer): 排序方向：0降序，1升序，默认0
page_num (integer): 页码，默认1
page_size (integer): 每页数量，默认20，最大100
Returns:
object: 分页结果。
外层: {code(string): 状态码, message(string): 提示信息, success(boolean): 是否成功, data(object): 分页数据}
data: {total(integer): 数据总数, pageNum(integer): 当前页码, pageSize(integer): 页容, list(object[]): 结果集}
list元素(达人):
id (string): 达人ID
name (string): 达人昵称
uniqueId (string): handler_name
cover (string): 头像地址
tiktokUrl (string): tiktok链接
kolspriteUrl (string): kolsprite详情链接
region (string): 面向区域
category (string[]): 达人分类
enCategory (string[]): 达人分类(英文)
goodsCategory (object[]): 带货分类，元素: {catId(string): 分类ID, catName(string): 分类名称(英文), cnCatName(string): 分类名称(中文)}
fansCnt (integer): 粉丝数量
fansGr (number): 粉丝增长率
likeCnt (integer): 点赞数
likeFansRate (number): 赞粉比
interactionRate (number): 互动率
exposure (number): 视频曝光率
videoCompletionRate (number): 完播率
avgLikeCnt (integer): 平均点赞量
avgViewsPerVideo (integer): 平均播放量
videoCnt (integer): 视频数量
lastVideoDate (string): 最后视频发布时间
productCnt (integer): 带货数
salesVolume (integer): 带货销量
gpm (number): 每千次播放销售额
currency (string): 货币
mailAddress (string): 邮箱
contactList (object[]): 联系方式列表，元素: {type(string): 联系方式类型, contactAddress(string): 联系方式地址}
| Name | Required | Description | Default |
|---|---|---|---|
| region | No | 国家/区域，默认US | |
| keyword | No | 搜索词 | |
| page_num | No | 页码，默认1 | |
| page_size | No | 每页数量，默认20，最大100 | |
| fans_gr_to | No | 粉丝增长率上限 | |
| order_type | No | 排序方向：0降序，1升序，默认0 | |
| avg_like_to | No | 平均点赞量上限 | |
| fans_cnt_to | No | 粉丝数量上限 | |
| interact_to | No | 互动率上限 | |
| order_field | No | 排序字段 | |
| play_cnt_to | No | 平均播放量上限 | |
| search_type | No | 搜索方式 N:昵称，K:关键词，默认K | |
| fans_gr_from | No | 粉丝增长率下限 | |
| video_cnt_to | No | 视频数量上限 | |
| avg_like_from | No | 平均点赞量下限 | |
| category_list | No | 达人分类列表，只支持传递一个，可选值通过creator_category_list工具查询 | |
| fans_cnt_from | No | 粉丝数量下限 | |
| interact_from | No | 互动率下限 | |
| play_cnt_from | No | 平均播放量下限 | |
| product_cnt_to | No | 商品数上限 | |
| video_cnt_from | No | 视频数量下限 | |
| sales_volume_to | No | 带货销量上限 | |
| product_cnt_from | No | 商品数下限 | |
| sales_volume_from | No | 带货销量下限 | |
| product_category_list | No | 带货分类列表，只支持传递一个，可选值通过product_category_list工具查询 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden and does a solid job: it documents defaults (region=US, search_type=K, page defaults), a hard pagination cap (page_size max 100), and a non-obvious constraint that category_list accepts only one value. It stops short of stating permissions, rate limits, or that this is a read-only operation, but the disclosed constraints are substantive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The purpose statement is correctly front-loaded and the Returns block earns its place since no output schema exists. However, the 25-line Args section duplicates a schema that is already 100% documented, adding bulk without information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 25-parameter tool with no annotations and no output schema, the description does cover the return structure and cross-references sibling tools for category values. Gaps remain: order_field's accepted values are never specified, and there is no guidance on how filters combine or on required permissions, so an agent can call it but may pick invalid sort fields.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is already 100%, so the baseline is 3. The Args block in the description is essentially a verbatim restatement of the schema descriptions and adds no meaning beyond them (e.g., order_field is left as '排序字段' in both places, with no valid values given).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The opening line gives a specific verb and resource ('搜索TikTok达人/创作者') and names the two search modes (nickname vs keyword) plus the filter dimensions, so the agent knows exactly what it retrieves. It does not, however, differentiate itself from the sibling product_related_creator, which also returns creators, leaving a real routing ambiguity unresolved.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied through the search_type semantics ('N:昵称，K:关键词，默认K') and the filter list, which tells the agent this is the broad discovery tool. There is no explicit when-to-use / when-not-to-use statement and no mention of when to prefer product_related_creator or video_search instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取TikTok商品分类列表(树形)。product_search的cat_ids、shop_search的category、video_search的product_category_list参数取值来源于此。
Returns:
object: {code(string): 状态码, message(string): 提示信息, success(boolean): 是否成功, data(object[]): 分类树}
data元素:
category (string): 分类ID(用于product_search的cat_ids、shop_search的category、video_search的product_category_list)
categoryCn (string): 分类中文名
categoryEn (string): 分类英文名
children (object[]): 子分类，元素: {catId(string): 分类ID, catName(string): 分类名称(英文), cnCatName(string): 分类名称(中文)}
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it discloses the operation's shape: it returns a status envelope (code/message/success) plus a nested category tree with Chinese and English names. That is meaningful behavioral context. It omits auth requirements, rate limits, and whether the tree is cached or static, so it stops short of a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Purpose and the downstream consumer mapping are front-loaded in the first paragraph, and the Returns block is dense but earns its place because no output schema exists. The Chinese/English duplication across nested fields is slightly verbose but reflects the actual payload.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter list tool with no output schema, the description covers everything an agent needs: what it returns, the exact field names in the tree, and which sibling parameters consume them. Nothing material is left unspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero input parameters, so the baseline is 4. There is nothing to disambiguate, and the description correctly focuses on output rather than inventing parameter guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('获取TikTok商品分类列表(树形)') and immediately distinguishes itself from the sibling creator_category_list by specifying it is the TikTok *product* category tree. It also names the exact downstream consumers, so an agent knows what this resource is for without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes the usage context explicit: the values it returns are the source for product_search.cat_ids, shop_search.category, and video_search.product_category_list — effectively 'call this to obtain those IDs.' It does not state exclusions or ordering (e.g., must be fetched before searching), but the context is clear enough to guide selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
搜索TikTok Shop商品。支持按关键词或ID搜索，可按价格、销量、评分等条件筛选。
Args:
keyword (string): 关键词或产品标题
search_type (string): 搜索方式 N:ID，K:关键词
region (string): 国家/区域，默认US
cat_ids (string[]): 类目ID列表
exclude_keyword (string): 排除关键词
ft (string): 履约类型 fbt:全托管 pop:自运营
lt (string): 物流类型 local:本地 crossborder:跨境
shop_id (string): 店铺ID
price_from (number): 价格下限
price_to (number): 价格上限
rating_from (number): 评分下限
rating_to (number): 评分上限
reviews_from (integer): 评论数下限
reviews_to (integer): 评论数上限
sales_volume_from (integer): 总销量下限
sales_volume_to (integer): 总销量上限
sales_volume_lst7d_from (integer): 近7天销量下限
sales_volume_lst7d_to (integer): 近7天销量上限
sales_volume_lst30d_from (integer): 近30天销量下限
sales_volume_lst30d_to (integer): 近30天销量上限
sales_lst30d_from (number): 近30天销售额下限
sales_lst30d_to (number): 近30天销售额上限
sales_volume_gr7d_from (number): 7天增长率下限
sales_volume_gr7d_to (number): 7天增长率上限
sales_volume_gr30d_from (number): 30天增长率下限
sales_volume_gr30d_to (number): 30天增长率上限
influencer_from (integer): 带货达人数下限
influencer_to (integer): 带货达人数上限
videos_from (integer): 带货视频数下限
videos_to (integer): 带货视频数上限
listing_date_from (string): 上架时间起始，格式yyyy-MM-dd(如2024-01-01)
listing_date_to (string): 上架时间截止，格式yyyy-MM-dd(如2024-12-31)
order_field (string): 排序字段
order_type (integer): 排序方向：0降序，1升序，默认0
page_num (integer): 页码，默认1
page_size (integer): 每页数量，默认20，最大100
Returns:
object: 分页结果。
外层: {code(string): 状态码, message(string): 提示信息, success(boolean): 是否成功, data(object): 分页数据}
data: {total(integer): 数据总数, pageNum(integer): 当前页码, pageSize(integer): 页容, list(object[]): 结果集}
list元素(商品):
id (string): 产品ID
title (string): 产品标题
imageUrl (string): 产品图片
link (string): 商品链接
catId (string): 类目ID
catName (string): 类目名称
cnCatName (string): 中文类目名称
price (number): 现价
originalPrice (number): 原价
currency (string): 货币
rating (number): 评分
reviews (integer): 评论数
ft (string): 履约类型
lt (string): 物流类型
region (string): 区域
listingDate (string): 上架时间
totalSalesVolume (integer): 总销量
totalSales (number): 总销售额
salesVolumeLst7d (integer): 近7天销量
salesVolumeLst30d (integer): 近30天销量
salesVolumeGr7d (number): 近7天销量增长率
salesVolumeGr30d (number): 近30天销量增长率
salesLst7d (number): 近7天销售额
salesLst30d (number): 近30天销售额
influencers (integer): 带货达人数
videos (integer): 带货视频数
lives (integer): 带货直播数
shopId (string): 店铺ID
shopName (string): 店铺名称
shopImageUrl (string): 店铺图片
shopProducts (integer): 店铺商品数
shopSalesVolume (integer): 店铺销量
kolspriteUrl (string): kolsprite详情链接
| Name | Required | Description | Default |
|---|---|---|---|
| ft | No | 履约类型 fbt:全托管 pop:自运营 | |
| lt | No | 物流类型 local:本地 crossborder:跨境 | |
| region | No | 国家/区域，默认US | |
| cat_ids | No | 类目ID列表，只支持传递一个，可选值通过product_category_list工具查询 | |
| keyword | No | 关键词或产品标题 | |
| shop_id | No | 店铺ID | |
| page_num | No | 页码，默认1 | |
| price_to | No | 价格上限 | |
| page_size | No | 每页数量，默认20，最大100 | |
| rating_to | No | 评分上限 | |
| videos_to | No | 带货视频数上限 | |
| order_type | No | 排序方向：0降序，1升序，默认0 | |
| price_from | No | 价格下限 | |
| reviews_to | No | 评论数上限 | |
| order_field | No | 排序字段 | |
| rating_from | No | 评分下限 | |
| search_type | No | 搜索方式 N:ID，K:关键词 | |
| videos_from | No | 带货视频数下限 | |
| reviews_from | No | 评论数下限 | |
| influencer_to | No | 带货达人数上限 | |
| exclude_keyword | No | 排除关键词 | |
| influencer_from | No | 带货达人数下限 | |
| listing_date_to | No | 上架时间截止，格式yyyy-MM-dd(如2024-12-31) | |
| sales_lst30d_to | No | 近30天销售额上限 | |
| sales_volume_to | No | 总销量上限 | |
| listing_date_from | No | 上架时间起始，格式yyyy-MM-dd(如2024-01-01) | |
| sales_lst30d_from | No | 近30天销售额下限 | |
| sales_volume_from | No | 总销量下限 | |
| sales_volume_gr7d_to | No | 7天增长率上限 | |
| sales_volume_gr30d_to | No | 30天增长率上限 | |
| sales_volume_lst7d_to | No | 近7天销量上限 | |
| sales_volume_gr7d_from | No | 7天增长率下限 | |
| sales_volume_lst30d_to | No | 近30天销量上限 | |
| sales_volume_gr30d_from | No | 30天增长率下限 | |
| sales_volume_lst7d_from | No | 近7天销量下限 | |
| sales_volume_lst30d_from | No | 近30天销量下限 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are supplied, so the description carries the full behavioral burden. It correctly conveys this is a read-style query with pagination and documents the full response envelope, but omits auth requirements, rate limits, or explicit confirmation that it is side-effect free.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The one-line summary is well front-loaded, and the Returns section earns its place since no output schema exists. But the 36-parameter Args block duplicates a 100%-covered schema almost verbatim, adding substantial bulk without new information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 36-parameter tool with no output schema and no annotations, the description fills the critical gap by documenting the nested return structure (total/pageNum/list and per-product fields). It is largely complete, missing only cross-tool routing guidance and safety/behavioral context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 all 36 parameters. The Args block merely restates them, and in fact the schema adds extra meaning the description lacks (cat_ids limited to one value, queryable via product_category_list). Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('搜索TikTok Shop商品') and immediately bounds the capability ('按关键词或ID搜索', filter by price/sales/rating). The resource '商品' cleanly distinguishes it from siblings shop_search, video_search, and creator_search without needing to name them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description conveys the two search modes (keyword vs ID via search_type) and the available filter dimensions, implying how to use it. However it never states when to prefer product_search over shop_search/video_search or what prerequisites exist, so guidance remains implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
搜索TikTok Shop店铺。支持按关键词或ID搜索，可按评分、销量、商品数等条件筛选。
Args:
keyword (string): 店铺关键词或名称
search_type (string): 搜索方式 N:ID，K:关键词
region (string): 国家/区域，默认US
category (string[]): 店铺类目列表
shop_type (string): 卖家类型
service_type (string): 运营模式
price_from (number): 价格下限
price_to (number): 价格上限
rating_from (number): 评分下限
rating_to (number): 评分上限
products_from (integer): 在售商品数下限
products_to (integer): 在售商品数上限
sales_volume_from (integer): 总销量下限
sales_volume_to (integer): 总销量上限
sales_volume_lst30d_from (integer): 近30天销量下限
sales_volume_lst30d_to (integer): 近30天销量上限
sales_volume_gr30d_from (number): 近30天销量增长率下限
sales_volume_gr30d_to (number): 近30天销量增长率上限
influencer_from (integer): 带货达人数下限
influencer_to (integer): 带货达人数上限
videos_from (integer): 带货视频数下限
videos_to (integer): 带货视频数上限
order_field (string): 排序字段
order_type (integer): 排序方向：0降序，1升序，默认0
page_num (integer): 页码，默认1
page_size (integer): 每页数量，默认20，最大100
Returns:
object: 分页结果。
外层: {code(string): 状态码, message(string): 提示信息, success(boolean): 是否成功, data(object): 分页数据}
data: {total(integer): 数据总数, pageNum(integer): 当前页码, pageSize(integer): 页容, list(object[]): 结果集}
list元素(店铺):
id (string): 店铺ID
shopId (string): 店铺ID
shopName (string): 店铺名称
imageUrl (string): 店铺图片
link (string): 链接
region (string): 地区
shopType (string): 卖家类型
serviceType (string): 运营模式
fulfillmentType (string): 履行模式（自营/全托管）
crossBorder (integer): 是否跨境（0:本地, 1:跨境）
categories (string): 英文类目信息
cnCategories (string): 中文类目信息
rating (number): 评分
ratingRate (number): 4+评分占比
respondRate (number): 24小时回复率
shipRate (number): 2天内发货概率
shopRate (number): 超过的店铺占比
products (integer): 在售商品数
avgPrice (number): 在售商品平均价格
currency (string): 货币单位
totalSalesVolume (integer): 总销量
totalSales (number): 总销售额
salesVolumeLst30d (integer): 近30天销量
salesVolumeGr30d (number): 近30天销量增长率
salesLst30d (number): 近30天销售额
influencers (integer): 带货达人数
videos (integer): 带货视频数
kolspriteUrl (string): kolsprite详情链接
| Name | Required | Description | Default |
|---|---|---|---|
| region | No | 国家/区域，默认US | |
| keyword | No | 店铺关键词或名称 | |
| category | No | 店铺类目列表，只支持传递一个，可选值通过product_category_list工具查询 | |
| page_num | No | 页码，默认1 | |
| price_to | No | 价格上限 | |
| page_size | No | 每页数量，默认20，最大100 | |
| rating_to | No | 评分上限 | |
| shop_type | No | 卖家类型 | |
| videos_to | No | 带货视频数上限 | |
| order_type | No | 排序方向：0降序，1升序，默认0 | |
| price_from | No | 价格下限 | |
| order_field | No | 排序字段 | |
| products_to | No | 在售商品数上限 | |
| rating_from | No | 评分下限 | |
| search_type | No | 搜索方式 N:ID，K:关键词 | |
| videos_from | No | 带货视频数下限 | |
| service_type | No | 运营模式 | |
| influencer_to | No | 带货达人数上限 | |
| products_from | No | 在售商品数下限 | |
| influencer_from | No | 带货达人数下限 | |
| sales_volume_to | No | 总销量上限 | |
| sales_volume_from | No | 总销量下限 | |
| sales_volume_gr30d_to | No | 近30天销量增长率上限 | |
| sales_volume_lst30d_to | No | 近30天销量上限 | |
| sales_volume_gr30d_from | No | 近30天销量增长率下限 | |
| sales_volume_lst30d_from | No | 近30天销量下限 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden. It does disclose defaults (region US, page_size 20/max 100, order_type 0) and a detailed response shape, which is useful. However it says nothing about authorization requirements, rate limits, whether results are capped, or how multiple filters combine – behavior an agent would want 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The opening two sentences are well front-loaded, but the Args section duplicates all 26 schema parameters verbatim, which is pure token waste at 100% coverage. The Returns section is warranted given no output schema, but overall the definition is bloated by redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 26-parameter search tool with no output schema and no annotations, the definition supplies defaults, pagination limits, and a thorough return-field breakdown. Gaps remain around filter combination logic and valid enumerations for string fields, but an agent has enough to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so every parameter is already documented in the schema and the Args block is a near-verbatim restatement. The description adds no extra semantics beyond the schema (e.g. it never explains valid values for shop_type, service_type, or order_field), so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource (搜索TikTok Shop店铺) and clarifies the two search modes (keyword or ID) plus the filterable dimensions. An agent can distinguish it from product_search, creator_search, and video_search siblings without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the tool's nature (searching shops with optional filters), but there is no explicit when-to-use/when-not guidance and no routing to alternatives such as creator_search for people or product_search for items. It also does not say when keyword vs ID search_type should be chosen, only what the codes mean.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
搜索TikTok带货视频。支持按关键词搜索，可按播放量、点赞、销量、时长等条件筛选。
Args:
keyword (string): 搜索词
region (string): 国家/区域，默认US
video_ids (string[]): 视频id查询，最大50
video_type (string): 视频类型
product (boolean): 是否带货视频
product_id (string): 商品id
shop_id (string): 店铺id
product_category_list (string[]): 带货分类列表
play_cnt_from (integer): 播放量下限
play_cnt_to (integer): 播放量上限
like_cnt_from (integer): 点赞量下限
like_cnt_to (integer): 点赞量上限
interact_from (number): 互动率下限
interact_to (number): 互动率上限
price_from (number): 价格下限
price_to (number): 价格上限
sales_volume_from (integer): 销量下限
sales_volume_to (integer): 销量上限
sales_volume_lst30d_from (integer): 近30天销量下限
sales_volume_lst30d_to (integer): 近30天销量上限
sales_lst30d_from (number): 近30天销售额下限
sales_lst30d_to (number): 近30天销售额上限
seconds_from (integer): 时长下限(秒)
seconds_to (integer): 时长上限(秒)
pub_date_from (string): 发布时间起始，格式yyyy-MM-dd(如2024-01-01)
pub_date_to (string): 发布时间截止，格式yyyy-MM-dd(如2024-12-31)
order_field (string): 排序字段
order_type (integer): 排序方向：0降序，1升序，默认0
page_num (integer): 页码，默认1
page_size (integer): 每页数量，默认20，最大100
Returns:
object: 分页结果。
外层: {code(string): 状态码, message(string): 提示信息, success(boolean): 是否成功, data(object): 分页数据}
data: {total(integer): 数据总数, pageNum(integer): 当前页码, pageSize(integer): 页容, list(object[]): 结果集}
list元素(视频):
id (string): 视频ID
title (string): 视频标题
cover (string): 视频封面
region (string): 区域
seconds (integer): 视频时长(秒)
pubTime (string): 视频发布时间
playCnt (integer): 播放量
likeCnt (integer): 点赞数
collectCnt (integer): 收藏数
commentCnt (integer): 评论数
forwardCnt (integer): 转发数
interactionRate (number): 互动率
vqScore (string): 质量得分
currency (string): 货币
totalSalesVolume (integer): 总销量
salesVolumeLst30d (integer): 近30天销量
salesLst30d (number): 近30天销售额
creator (object): 达人信息
product (object): 商品信息
tiktokUrl (string): tiktok链接
kolspriteUrl (string): kolsprite详情链接
creator(达人信息):
id (string): 达人ID
name (string): 达人昵称
handleName (string): 达人handle
cover (string): 达人头像
region (string): 达人区域
fansCnt (integer): 粉丝数
categoryList (string[]): 达人分类
enCategoryList (string[]): 达人英文分类
product(商品信息):
id (string): 商品ID
title (string): 商品标题
imageUrl (string): 商品图片
price (number): 现价
originalPrice (number): 原价
currency (string): 货币
region (string): 商品区域
catId (string): 分类ID
catName (string): 分类名称
cnCatName (string): 中文分类名称
salesVolumeLst30d (integer): 近30天销量
totalSales (number): 总销售额
| Name | Required | Description | Default |
|---|---|---|---|
| region | No | 国家/区域，默认US | |
| keyword | No | 搜索词 | |
| product | No | 是否带货视频 | |
| shop_id | No | 店铺id | |
| page_num | No | 页码，默认1 | |
| price_to | No | 价格上限 | |
| page_size | No | 每页数量，默认20，最大100 | |
| video_ids | No | 视频id查询，最大50 | |
| order_type | No | 排序方向：0降序，1升序，默认0 | |
| price_from | No | 价格下限 | |
| product_id | No | 商品id | |
| seconds_to | No | 时长上限(秒) | |
| video_type | No | 视频类型 | |
| interact_to | No | 互动率上限 | |
| like_cnt_to | No | 点赞量上限 | |
| order_field | No | 排序字段 | |
| play_cnt_to | No | 播放量上限 | |
| pub_date_to | No | 发布时间截止，格式yyyy-MM-dd(如2024-12-31) | |
| seconds_from | No | 时长下限(秒) | |
| interact_from | No | 互动率下限 | |
| like_cnt_from | No | 点赞量下限 | |
| play_cnt_from | No | 播放量下限 | |
| pub_date_from | No | 发布时间起始，格式yyyy-MM-dd(如2024-01-01) | |
| sales_lst30d_to | No | 近30天销售额上限 | |
| sales_volume_to | No | 销量上限 | |
| sales_lst30d_from | No | 近30天销售额下限 | |
| sales_volume_from | No | 销量下限 | |
| product_category_list | No | 带货分类列表，只支持传递一个，可选值通过product_category_list工具查询 | |
| sales_volume_lst30d_to | No | 近30天销量上限 | |
| sales_volume_lst30d_from | No | 近30天销量下限 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full behavioral burden. It does disclose useful limits and defaults (region defaults to US, video_ids max 50, page_size default 20 / max 100, order_type default 0), but says nothing about authentication, rate limits, or whether an empty keyword is allowed. The detailed Returns block adds real value that annotations would otherwise have to supply.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loading the one-sentence purpose is good, and the Returns section is justified because no output schema exists. However, the 30-line Args block duplicates parameters already documented at 100% coverage in the schema, so a large portion of the text does not earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 30-parameter search tool with no output schema, the embedded Returns block fully documents the pagination envelope and nested video/creator/product objects, which is exactly the missing structured data. Gaps remain around auth/permission requirements and the valid values for order_field and video_type, but nothing critical to a correct call is absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is already 100%, so the schema documents all 30 parameters. The Args block largely restates those same descriptions and actually omits the schema-only detail that product_category_list accepts only one value. Baseline 3 applies since the description adds no syntax or format meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The opening sentence gives a specific verb+resource: searching TikTok product-selling videos, with keyword search and metric filters. An agent can tell it is a video-level search distinct from product_search, creator_search and shop_search by resource, though the description never names or contrasts those siblings explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied by the parameter list — it is a filtered search over videos. The only real routing hint is the cross-reference that valid product_category_list values come from the product_category_list tool. There is no when-to-use/when-not guidance against the eight sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
asin_analysis_videocaption_extract_urlcreator_category_listcreator_searchproduct_category_listproduct_related_creatorproduct_searchshop_searchvideo_search
Add one secure layer between your agents and this server.