kolsprite-search

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

KOLSprite Search

KOLSprite 搜索

Route a direct TikTok data request to the smallest useful call through the active connection that exposes the compatible KOLSprite tool contract. Use MCP automatically; do not ask whether to use it.
通过当前已启用且暴露兼容 KOLSprite 工具契约的连接,将直接的 TikTok 数据请求路由至最小可用的调用。自动使用 MCP;不要询问是否使用它。

Compatible MCP routing

兼容的 MCP 路由

  • Prefer the SellerSpace Yunya unified MCP when it is available and authenticated.
  • Support direct business tools plus current and legacy Yunya facade entrypoints.
  • In direct mode, resolve and call the required category, creator, product, video, or shop tool by its semantic business name.
  • In Yunya facade mode, when a required business tool is not visible at the host's top level, make at most one host-level discovery attempt and prefer the product-specific
    yunya_search_kolsprite_tools
    . Query the smallest set of tools needed for the lookup; use the exact internal tool names and complete input schemas returned, then invoke them through
    call_read_tool
    .
  • If the product-specific entrypoint is unavailable but the legacy generic
    yunya__search_tools
    is discoverable, use it with provider
    kolsprite
    , operation
    read
    , and the same query. Do not prefer the generic entrypoint when the product-specific one is available.
  • Do not guess a facade namespace, internal tool name, wrapper, category value, or arguments. Reuse discovered names and schemas throughout the lookup.
  • A host-level miss for a business tool does not prove that it is absent from the internal catalogue. Only report a missing dependency after direct exposure and the available current or legacy facade lookup fail. If neither facade entrypoint can be discovered, report a connector-discovery failure and do not switch to an unrelated data source as if it were equivalent.
  • A standalone KOLSprite MCP remains compatible only when it exposes the same required semantic tool names, input schemas, and response shapes.
  • If both connections are enabled, use one connection for the entire lookup, prefer Yunya, and never duplicate a paid call across both services.
  • If a required tool is absent or schema-incompatible, report that dependency gap and narrow or stop the lookup instead of guessing a substitute.
  • 当 SellerSpace Yunya 统一 MCP 可用且已完成身份验证时,优先使用它。
  • 支持直接业务工具,以及当前和旧版 Yunya facade 入口点。
  • 在直接模式下,按语义业务名称解析并调用所需的分类、达人、商品、视频或店铺工具。
  • 在 Yunya facade 模式下,当所需业务工具未在宿主顶层显示时,最多进行一次宿主级发现尝试,并优先使用产品专用的
    yunya_search_kolsprite_tools
    。查询此次查找所需的最小工具集合;使用返回的准确内部工具名称和完整输入 schema,然后通过
    call_read_tool
    调用。
  • 如果产品专用入口点不可用,但可以发现旧版通用
    yunya__search_tools
    ,则使用它,并将 provider 设为
    kolsprite
    、operation 设为
    read
    ,执行相同查询。存在产品专用入口点时,不要优先使用通用入口点。
  • 不要猜测 facade namespace、内部工具名称、wrapper、category 值或参数。在整个查找过程中复用已发现的名称和 schema。
  • 宿主层级的查找未命中,并不能证明该工具不存在于内部目录中。只有在直接暴露以及当前或旧版 facade 查找均失败后,才能报告依赖项缺失。如果两个 facade 入口点都无法被发现,则报告连接器发现失败,并且不要改用不相关的数据源并将其视为等价来源。
  • 只有当独立的 KOLSprite MCP 暴露相同的所需语义工具名称、输入 schema 和响应结构时,才视为兼容。
  • 如果两个连接均已启用,整个查找过程只使用一个连接,优先使用 Yunya,并且绝不跨两个服务重复执行付费调用。
  • 如果所需工具缺失或 schema 不兼容,请报告该依赖项缺口,并缩小查找范围或停止查找,而不是猜测替代方案。

Tool routing

工具路由

  • Creator-category value resolution: call
    creator_category_list
    before
    creator_search
    when the user requests a creator-content category and no verified accepted value is already available in the current run.
  • Product-category ID resolution: call
    product_category_list
    before a category-filtered creator, product, video, or shop search when no verified accepted ID is already available in the current run.
  • Creator identity, audience scale, engagement, content category, selling activity, contactability, or creator shortlist: call
    creator_search
    .
  • Product identity, price, rating, reviews, listing date, sales, growth, creator count, or video count: call
    product_search
    .
  • Shoppable video identity, creator, product, views, engagement, sales, recency, or duration: call
    video_search
    .
  • Shop identity, type, category, rating, products, sales, creators, or videos: call
    shop_search
    .
Use multiple tools only when the user's direct lookup genuinely needs joined records. Reuse returned IDs when a downstream tool accepts them. Examples include
shop_search
followed by
product_search
with
shop_id
, or
product_search
followed by
video_search
with
product_id
.
Do not claim that
creator_search
identifies the exact creators who promoted a specific product: the public creator tool currently supports category and performance filtering, not a product-ID relationship query.
  • 达人分类值解析:当用户请求达人内容分类,且当前运行中尚无经过验证且受工具接受的值时,在调用
    creator_search
    前调用
    creator_category_list
    。
  • 商品分类 ID 解析:当用户请求按分类筛选达人、商品、视频或店铺,且当前运行中尚无经过验证且受工具接受的 ID 时,在搜索前调用
    product_category_list
    。
  • 达人身份、粉丝规模、互动情况、内容分类、销售活动、可联系性或达人候选名单:调用
    creator_search
    。
  • 商品身份、价格、评分、评论数、上架日期、销量、增长量、达人数或视频数:调用
    product_search
    。
  • 带货视频的身份、达人、商品、播放量、互动情况、销量、近期程度或时长:调用
    video_search
    。
  • 店铺身份、类型、分类、评分、商品、销量、达人或视频:调用
    shop_search
    。
仅当用户的直接查询确实需要关联记录时才使用多个工具。当下游工具接受上游返回的 ID 时,应复用这些 ID。例如,先执行
shop_search
,再使用
shop_id
执行
product_search
;或先执行
product_search
,再使用
product_id
执行
video_search
。
不要声称
creator_search
能识别推广特定商品的确切达人:公开的达人工具目前支持分类和表现筛选,但不支持按 product ID 查询关联关系。

Category resolution

分类解析

  • Treat category-list tools as parameter resolvers, not user-facing search results or required preflight calls. Skip them when no category filter is needed or a valid current-run value has already been returned.
  • Match the user's Chinese or English creator-category wording against
    creator_category_list
    ; pass the returned
    value
    to
    creator_search.category_list
    .
  • Traverse the recursive
    product_category_list
    tree and match
    categoryCn
    or
    categoryEn
    ; pass the returned full
    category
    value to
    product_search.cat_ids
    ,
    shop_search.category
    ,
    video_search.product_category_list
    , or
    creator_search.product_category_list
    as applicable.
  • Interpret content niche or account positioning as a creator category, and selling, promoted-product, or collaboration direction as a product category. Do not set both category filters merely to hedge an ambiguous phrase such as “beauty creator”; use the request context, state a material assumption, or ask once only when the choice would materially change the result.
  • The current search schemas accept an array but support only one category value. Choose the narrowest unambiguous match that preserves the user's intent. If two plausible mappings would materially change the result, ask once; otherwise use the broader valid parent and disclose it.
  • Never pass a display label where an accepted value/ID is required, invent an ID, or freeze the live catalogue in Skill text. Reuse one successful mapping across the current run. If the resolver is unavailable or no safe match exists, omit the category filter, use a clearly labelled keyword-bounded query when useful, and disclose the limitation.
  • Use the semantic tool names above. The MCP host may add a client- or server-specific namespace to the callable name; do not hardcode one agent's prefix.
  • 将分类列表工具视为参数解析器,而不是面向用户的搜索结果或必需的预检调用。不需要分类筛选,或者当前运行中已返回有效值时,应跳过这些调用。
  • 将用户的中文或英文达人分类表述与
    creator_category_list
    进行匹配;将返回的
    value
    传给
    creator_search.category_list
    。
  • 遍历递归的
    product_category_list
    树,并匹配
    categoryCn
    或
    categoryEn
    ;将返回的完整
    category
    值传给
    product_search.cat_ids
    、
    shop_search.category
    、
    video_search.product_category_list
    或
    creator_search.product_category_list
    (视适用情况而定)。
  • 将内容垂直领域或账号定位理解为达人分类,将销售、推广商品或合作方向理解为商品分类。不要仅为了对冲“美妆达人”之类含义模糊的表述而同时设置两个分类筛选器;应结合请求上下文,说明重要假设,或仅在选择会实质改变结果时询问一次。
  • 当前搜索 schema 接受数组,但仅支持一个分类值。选择能够保留用户意图的最窄且无歧义的匹配。如果两个合理映射会实质改变结果,则询问一次;否则使用范围更广的有效父分类并予以说明。
  • 绝不要在需要传入受接受的值或 ID 的位置传入显示标签,绝不要虚构 ID,也绝不要在 Skill 文本中固化实时目录。在当前运行中复用一次成功映射。如果解析器不可用或找不到安全匹配,省略分类筛选;在有用时使用清楚标注为受关键词约束的查询,并说明局限。
  • 使用上述语义工具名称。MCP 宿主可能会为可调用名称添加客户端或服务器特定的 namespace;不要硬编码某个 Agent 的前缀。

Query rules

查询规则

  1. Infer explicit filters such as market, keyword, category, price, followers, engagement, sales, growth, date, sort, and page size.
  2. Use tool defaults for optional inputs when the choice does not materially change the answer. State material assumptions.
  3. Ask only for information that is both required and not safely inferable.
  4. Translate a requested result count into the smallest sufficient page plan. When the user asks for “all,” use the maximum supported page size and continue until there is no next page, the requested scope is exhausted, the service limit is reached, or an error stops collection.
  5. Deduplicate paginated records by their stable object ID. Report requested count, page range, raw rows, deduplicated rows, and stop reason.
  6. Apply the user's sort. If the live schema does not confirm a server-side sort value, sort locally only within the disclosed collected scope.
  7. Before encoding a percentage growth filter, inspect the live schema or a verified official example. Never guess whether 50% is represented as
    50
    or
    0.5
    ; if still unresolved, omit that filter and explain the limitation.
  8. If an initial query is empty, relax one nonessential filter or try one close synonym when that still answers the user's intent. Report the relaxation rather than silently changing scope.
  9. Stop after the requested lookup or bounded comparison is answered. Route decision-oriented follow-ups to
    tiktok-shop-growth-research
    .
  1. 推断明确指定的筛选条件,如市场、关键词、分类、价格、粉丝数、互动情况、销量、增长量、日期、排序和页面大小。
  2. 当可选输入的选择不会实质改变答案时,使用工具默认值。说明重要假设。
  3. 仅询问那些既为必需且无法安全推断的信息。
  4. 将用户请求的结果数量转换为足以满足需求的最小分页计划。当用户要求“全部”时,使用支持的最大页面大小,并持续执行,直到没有下一页、请求范围已耗尽、达到服务限制,或错误中止采集。
  5. 按稳定对象 ID 对分页记录去重。报告请求数量、页面范围、原始行数、去重后行数和停止原因。
  6. 应用用户指定的排序。如果实时 schema 未确认服务端排序值,则仅在已披露的采集范围内进行本地排序。
  7. 在编码百分比增长筛选条件之前,检查实时 schema 或已验证的官方示例。绝不要猜测 50% 应表示为
    50
    还是
    0.5
    ;如果仍无法确定,则省略该筛选条件并说明局限。
  8. 如果初始查询为空,放宽一个非必要筛选条件,或尝试一个仍能回答用户意图的近义词。报告所做的放宽,不要在未说明的情况下改变范围。
  9. 完成用户请求的查询或有限比较后立即停止。将决策类后续请求路由至
    tiktok-shop-growth-research
    。

Point-aware execution

积分感知执行

  • Point use follows the actual executed tool under the current account rules; selecting this Skill is not itself a charge record.
  • Use the smallest call/page plan that answers the request, reuse returned records, and do not repeat an identical paid call without a disclosed reason.
  • Do not hardcode or estimate point prices. Report a deduction or remaining balance only when the current MCP response or host client exposes it.
  • Stop on insufficient points and label completed pages/rows plus remaining work. Ask before adding discretionary tools or pages beyond the user's requested scope when that expansion materially increases point use.
  • 积分消耗遵循当前账户规则下实际执行的工具;选择本 Skill 本身并不是扣费记录。
  • 使用能够回答请求的最小调用和分页计划,复用返回记录,并且不要在未说明原因的情况下重复执行相同的付费调用。
  • 不要硬编码或估算积分价格。只有当前 MCP 响应或宿主客户端提供扣减或剩余余额信息时,才可报告。
  • 积分不足时停止,并标明已完成的页面或行数及剩余工作。当在用户请求范围之外添加非必要工具或页面会显著增加积分消耗时,应先征得用户同意。

Errors and incomplete collection

错误与不完整采集

  • Stop the affected chain on authentication failure, unavailable tools, insufficient points/entitlement, rate-limit errors, or repeated server failure.
  • Never retry a point, entitlement, rate-limit, or authentication error by changing credentials, evading limits, or shrinking requests to conceal the interruption.
  • Label an interrupted collection incomplete and state completed pages/rows, remaining requested work, and which conclusions apply only to the collected sample.
  • Never call the first page or a rate-limited collection “all results.”
  • When a current server error, schema mismatch, empty category result, or suspiciously repeated stable-ID page occurs, consult the dated known-issues ledger. Treat it as a retest guide, not proof that a historical issue is still active.
  • 遇到身份验证失败、工具不可用、积分或权益不足、速率限制错误或重复的服务端故障时,停止受影响的调用链。
  • 对于积分、权益、速率限制或身份验证错误,绝不要通过更改凭据、规避限制或缩小请求来掩盖中断并进行重试。
  • 将中断的采集标记为 不完整,并说明已完成的页面或行数、剩余请求工作,以及哪些结论仅适用于已采集的样本。
  • 绝不要把第一页或因速率限制而中断的采集称为“全部结果”。
  • 当出现当前服务端错误、schema 不匹配、分类结果为空,或稳定 ID 页面出现可疑重复时,查阅带日期的 已知问题台账。将其视为复测指南,而不是历史问题仍在发生的证明。

Evidence and response rules

证据与响应规则

  • Base TikTok facts only on current MCP output. Never fabricate missing records or metrics.
  • Label the source, market, filters, sort, period basis, page, and returned sample size when they affect interpretation.
  • Preserve the field's actual time window. Do not relabel total or unspecified sales as 7-day or 30-day sales.
  • Distinguish MCP fields from client calculations. Show a formula or plain-language method for any calculated rate, rank, or concentration.
  • Treat keyword matches as candidates until product/category relevance is checked.
  • Treat an empty result as “no records returned under these conditions,” not proof that the object or market does not exist.
  • Use a returned object link when useful. Do not invent TikTok or KOLSprite URLs.
  • Lead with the result or shortlist; keep secondary dimensions out unless they change the user's decision.
  • For analytical requests, end with a prioritized action, the evidence supporting it, the metric to observe, and a review or stop condition. Do not append an action plan to a simple lookup when the user did not ask for one.
  • For a reusable analytical run or partner-facing example, apply the shared run evidence display and do not describe query execution as a measured customer outcome.
  • TikTok 事实只能基于当前 MCP 输出。绝不要虚构缺失记录或指标。
  • 当来源、市场、筛选条件、排序、周期口径、页码和返回样本量影响解读时,应明确标注这些信息。
  • 保留字段的实际时间窗口。不要把总计或未指明周期的销量重新标记为 7 天或 30 天销量。
  • 区分 MCP 字段与客户端计算结果。对于任何计算得出的比率、排名或集中度,展示公式或通俗易懂的方法。
  • 在核实商品或分类相关性之前,关键词匹配只能视为候选对象。
  • 将空结果表述为“在这些条件下未返回记录”,而不是证明该对象或市场不存在。
  • 在有帮助时使用返回的对象链接。不要虚构 TikTok 或 KOLSprite URL。
  • 先给出结果或候选名单;除非次要维度会改变用户决策,否则不要纳入。
  • 对于分析类请求,最后给出优先级行动、支持该行动的证据、需要观察的指标,以及复核或停止条件。对于简单查询,如果用户没有要求,不要附加行动计划。
  • 对于可复用的分析运行或面向合作伙伴的示例,应用共享的 运行证据展示规范,并且不要把查询执行描述为已测量的客户结果。