Skip to main content
Glama

product_related_creator

查询商品关联的带货达人列表。按商品ID查询该商品的带货达人,可筛选是否有联系方式。

Args:
    product_id (string): 商品ID
    region (string): 国家/区域,默认US
    contact_exist (integer): 是否有联系方式 1表示有 0表示没有
    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元素(达人):
            creatorId (string): 达人ID
            name (string): 用户昵称
            uniqueId (string): handler_name
            cover (string): 头像地址
            region (string): 面向区域
            category (string[]): 达人分类
            goodsCategory (string[]): 带货分类
            enGoodsCategory (string[]): 带货分类(英文)
            fansCnt (integer): 粉丝数量
            interactionRate (number): 互动率
            avgViewsPerVideo (integer): 平均播放量
            videos (integer): 视频数量
            lastVideoDate (string): 最后视频发布时间
            productCnt (integer): 带货数
            salesVolume (integer): 带货销量
            sales (number): 带货销售额
            tiktokUrl (string): tiktok链接
            kolspriteUrl (string): kolsprite详情链接
            contactList (object[]): 联系方式列表,元素: {type(string): 联系方式类型, contactAddress(string): 联系方式地址}

Input Schema

NameRequiredDescriptionDefault
regionNo国家/区域,默认US
page_numNo页码,默认1
page_sizeNo每页数量,默认20,最大100
order_typeNo排序方向:0降序,1升序,默认0
product_idYes商品ID
order_fieldNo排序字段
contact_existNo是否有联系方式 1表示有 0表示没有

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

B3.4/5.0
Behavior3/5

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

With no annotations, the description carries the full behavioral burden. It implies a read-only query and discloses pagination defaults plus a hard cap (page_size max 100), which is genuinely useful. It says nothing about auth/permission requirements, rate limits, or how the contactList field behaves, so meaningful gaps remain.

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

Conciseness3/5

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

Purpose is correctly front-loaded in the first sentence. However, the Args section duplicates the input schema wholesale, and the Returns block is long, so the description carries noticeable redundancy even though the return-shape detail has some value absent an output schema.

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?

There is no output schema, so documenting the response envelope (code/message/success/data with total/pageNum/pageSize/list and per-creator fields) is genuinely necessary and is done thoroughly. Parameters are fully covered; only auth/error semantics are missing, keeping it just short of a 5.

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 all 7 parameters. The Args block in the description is essentially a verbatim restatement of that schema and adds no syntax, format, or constraint information beyond it; baseline 3 is appropriate.

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+resource: query the list of creators (带货达人) associated with a given product, keyed by product_id with an optional contact-info filter. This implicitly separates it from sibling 'creator_search', but it never names or contrasts that sibling explicitly, so it stops short of a 5.

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?

Usage is implied by the product-scoped framing ('按商品ID查询该商品的带货达人'), so an agent can infer it is the product-centric lookup rather than a general creator search. However, no when-to-use/when-not conditions or alternative tools (e.g. creator_search, asin_analysis_video) are named, leaving routing to inference.

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