面料标签列表接口

解决的问题

海外运营平台的面料后台维护中，面料标签列表是一个高频查询入口。它通常不是孤立的前端请求，而是嵌在多步链路里：先校验登录态与租户权限，再拉取列表，最后把关键字段交给后续 skill 做二次加工。如果每次都手写一遍地址拼接、鉴权头和参数归一化，重复成本高且容易出错。

这个 skill 把 fabric_label 这一个接口动作拆成最小颗粒度。它只负责一件事：向固定正式环境地址发 GET 请求，拿回面料标签列表的原始响应。

核心能力

• 固定正式环境地址：base_url 写在 frontmatter 里，调用时不接受用户输入覆盖，避免误打到其他环境。
• 统一参数结构：tool arguments 只放一个嵌套的 params 对象，不用 params.xxx 这类点号顶层 key。
• 鉴权处理：读取 params.accessToken 生成 Authorization: Bearer；如果传入值已经包含 Bearer，不会重复拼接。
• 参数分类落位：Path 参数写 params.path，Query 写 params.query，JSON Body 写 params.body，额外 Header 写 params.headers。POST/PUT 默认发 JSON body。
• 接口契约：GET /fabric/label/label，Query 为 LabelRequest。

适用边界

这是查询或计算类接口，调用仍需遵守当前登录态、租户和用户权限。返回结果以接口响应为唯一事实来源，不补造库存、价格、订单号、优惠金额或物流状态。如果接口返回认证、权限、参数或业务错误，会把原始错误码和错误信息原样传给上层 agent，不做吞掉或改写。

需要组合成完整业务链路时，本 skill 只完成本接口调用，并把关键返回字段交给后续 skill，由上层 agent 按聚合 skill 或计划文档编排多个原子 skill。