"寻找国内可用的服务器" matching MCP tools:

• zhini_list_tagsA

  知你AI助手｜多平台客户与客服数据 MCPA

  分页获取标签列表，用于在已知标签分组 ID 时列出该分组下的标签，并为客户搜索或历史会话搜索提供 tag_id。page 从 1 开始；page_size 最大 20。前置：可先调用 zhini_list_tag_groups 获取分组；如果用户只提供标签中文名，优先调用 zhini_search_tags 解析 tag_id。后续：拿到 tag_id 后可调用 zhini_search_customers 或 zhini_search_sessions。

  ConnectorOAuth

• zhini_search_customersA

  知你AI助手｜多平台客户与客服数据 MCPA

  搜索客户通讯录，用于根据客户名、手机号、微信号、客服、负责人、明确标签、渠道、性别、联系人类型或时间范围完整召回符合条件的客户 UID。用户只要求查询当天或某个时间范围内咨询过的客户时，默认查询当前授权账号关联的所有渠道范围，不代表当前调用客服本人接待或回复过；除非用户明确说“我处理过、我接待过、我回复过、归属于我”或指定某客服/渠道，否则不要自动传 kfid、pic_kfids 或 channel_id。用户要求查询某天或某段时间内的全部用户、包括会话已经结束/关闭的用户时，应使用本工具分页查询，不能用 zhini_list_active_sessions 代替。重要边界：自然语言中的“XXX 用户/客户”默认是业务语义或筛选条件，不应自动转换为 tag_id。可由名称、时间、渠道、客服等结构化字段表达的条件直接使用本工具；必须根据聊天内容判断的条件，应结合 zhini_search_sessions 和 zhini_fetch_messages 识别。只有用户明确要求某标签或上下文已有 tag_id 时才按标签筛选，且 tag_id 只覆盖已标注客户。用户给客户姓名/手机号/微信号时先用本工具召回候选客户；如果匹配多个客户，应让用户确认。用户明确给出标签名、渠道名、客服名时，应先分别调用 zhini_search_tags、zhini_list_channels、zhini_list_kefu 解析 ID。禁止空条件拉全量；page 从 0 开始；page_size 最大 20。后续：拿到 uid 后通常调用 zhini_get_customer_profile 或 zhini_fetch_messages。

  ConnectorOAuth

• zhini_list_active_sessionsA

  知你AI助手｜多平台客户与客服数据 MCPA

  获取当前授权客服账号所负责渠道下尚未关闭、尚未结束的当前会话队列。用于查看此刻的待接待、我的会话、同事会话、AI 会话状态，或从当前队列选定会话后读取消息/客户资料。重要边界：这是当前队列快照，不是历史查询；当天或更早已经由当前授权账号、其他客服结束/关闭的会话不会返回，不能用本工具汇总某天或某段时间内的全部用户、全部接待或完整会话。需要完整用户范围时调用 zhini_search_customers；需要已结束、已关闭或历史会话时调用 zhini_search_sessions，必要时再用 zhini_fetch_messages 按消息时间验证。范围：只返回当前授权账号负责渠道下的会话，不是全企业所有会话；我的会话全部返回，同事会话最多显示 250 个，排队中/等待接待会话最多显示 100 个，达到上限时摘要应提示可能被截断。前置：需要区分“我的会话/同事会话”时，先调用 zhini_get_current_kefu 获取当前 kfid。

  ConnectorOAuth

• zhini_search_sessionsA

  知你AI助手｜多平台客户与客服数据 MCPA

  搜索历史会话，用于按客户名、消息关键词、消息发送时间范围、客服、渠道、明确标签、联系人类型召回包括已结束、已关闭会话在内的历史会话候选。用户只要求查询当天或某个时间范围内的对话、咨询记录时，默认查询当前授权账号关联的所有渠道范围，不代表当前调用客服本人接待或回复过；除非用户明确说“我处理过、我接待过、我回复过、归属于我”或指定某客服/渠道，否则不要自动传 kfid 或 channel_id。用户要求查询某天或某段时间内的全部接待、完整会话或已结束会话时，应使用本工具分页查询，不能只调用 zhini_list_active_sessions。自然语言中的“XXX 用户/客户”默认是业务语义；当 XXX 必须根据聊天判断时，使用 msg 按相关表达召回候选，再用 msg_stime 限定消息发送时间范围，最后用 zhini_fetch_messages 读取完整上下文并由模型分类，不要先把 XXX 当成标签名。只有用户明确提到标签或已有 tag_id 时，标签才作为筛选条件或补充信号。关键词命中只是召回信号，不等于最终分类。条件性限制：仅当 msg 非空时，关键词历史检索只支持最近半年内的记录；msg 未传或为空、仅使用其他筛选条件（包括 msg_stime）时不受这条关键词专属限制。重要时间语义：msg_stime 表示消息发送时间范围，用于筛选时间段内包含消息的会话，不表示对话开启时间；旧字段 stime 已移除，不要传入。禁止空条件拉全量；page 从 0 开始；本工具不接收数量参数，底层查询默认每次返回 30 条，MCP 可全部展示给模型。

  ConnectorOAuth

• zhini_get_current_kefuA

  知你AI助手｜多平台客户与客服数据 MCPA

  获取当前调用者的客服 ID，即 kfid。用于在调用 zhini_list_active_sessions 前识别当前会话列表中哪些是自己正在接待的会话，或在用户明确说“我处理过、我接待过、我回复过、归属于我”等第一人称归属条件时构造 kfid 筛选。重要边界：用户只要求查询当天或某个时间范围内的对话、咨询过的客户时，默认范围是当前授权账号关联的所有渠道，不表示当前调用客服本人处理过，不应调用本工具或自动附加当前 kfid。本工具只输出 kfid，不输出手机号、姓名、团队、企业或负责渠道等身份信息。

  ConnectorOAuth

• zhini_get_customer_profileA

  知你AI助手｜多平台客户与客服数据 MCPA

  按客户 UID 获取客户资料和标签，用于确认客户身份、来源、负责人、联系方式、备注和标签。适用于客服回复前、销售跟进前、复盘客户历史前。边界：只读查询，不修改客户资料、备注、负责人或标签。前置：如果用户只给姓名/手机号/微信号，先用 zhini_search_customers 找 uid；如果已经有 uid，直接调用本工具。后续：需要聊天上下文时调用 zhini_fetch_messages。

  ConnectorOAuth

• zhini_search_tagsA

  知你AI助手｜多平台客户与客服数据 MCPA

  按关键词搜索标签，用于把用户明确提出的标签名解析成稳定 tag_id。典型场景：用户说“查带高意向标签的客户”“按高意向标签筛选”，先调用本工具搜索“高意向”，再用 tag_id 调用 zhini_search_customers 或 zhini_search_sessions。重要边界：自然语言中的“XXX 用户/客户”默认表示业务语义或筛选条件，不表示名为 XXX 的标签；只有用户明确提到“标签、带标签、按标签筛选”，或上下文已给出 tag_id 时才调用本工具。标签只代表已经被人工或系统标注的客户，不等于业务语义上的完整人群。空关键词应返回参数错误。include_grouped=true 时按 tag_group_id 聚合，便于用户确认同名或相似标签。

  ConnectorOAuth

• zhenghe_routeA

  Zhenghe — 正和支付路由与资本保全金库A

  构造一笔正和路由支付（消费入口）。返回签名就绪的 approve+pay calldata，调用方本地签名上链即完成原子正和支付：商户收 USDC + 捐赠注入金库 + 引路人分账 + NAV 抬升。路由决策：USDC 够→直接付；USDC 不足但 LOVE×NAV 够→赎回 LOVE 付；都不够→返回缺口。私钥永不经过服务器。

  ConnectorNo auth

• zhini_get_apikey_usageA

  知你AI助手｜多平台客户与客服数据 MCPA

  查询当前请求 API Key 所属账号的总配额、账号已使用量、账号剩余量，以及当前请求 API Key 的实时已使用量。工具无业务入参；服务端使用当前请求提供的 API Key 调用配额接口，并标准化返回 total、remaining、used、current_api_key_used，其中前三项是账号整体数据，最后一项是当前请求 API Key 数据。安全边界：不允许模型传入 apikey 或内部 api_key 查询参数，也不返回完整 API Key。

  ConnectorOAuth

• filing_routeA

  中国 AI 合规与备案（条文级自查）A

  判断一项 AI 服务要办哪些手续（备案/安全评估/标识），逐条给出法规依据。 Args: public_facing: 是否面向中国境内公众提供服务（仅内部使用请传 false） generates_content: 是否能生成文本/图片/音频/视频等内容 edits_face_or_voice: 是否提供人脸、人声等生物识别信息编辑功能（换脸、AI 配音、数字人） only_internal_use: 是否仅企业内部使用、不对外提供

  ConnectorNo auth

• zhini_list_kefuA

  知你AI助手｜多平台客户与客服数据 MCPA

  获取当前授权范围内的客服列表，用于把客服姓名解析成 kfid。适用于“客服A负责哪些客户”“抽查某客服历史接待”“队列统计时把 kfid 转成人名”等场景。only_active=true 时只返回可用客服；name 为空时可标准化为未命名。前置：无。后续：拿到 kfid 后可调用 zhini_search_customers、zhini_search_sessions，或在 zhini_list_active_sessions 中辅助标记 mine/colleague。

  ConnectorOAuth

• list_questionsA

  AI 客服国标合规知识库 (GB/T 47746—2026)A

  列出全部合规问答的标题清单。 Args: cluster: 可选，按集群过滤。可选值 ai-service-standard(AI客服国标) / enterprise-knowledge-base(企业知识库)

  ConnectorNo auth

• search_complianceA

  中国 AI 合规与备案（条文级自查）A

  按关键词检索中国 AI 合规条目，返回最相关的若干条（含结论与条文依据）。 Args: query: 检索词，如「AI 客服 备案」「AI 生成内容 标注」「训练数据 合法来源」「大数据杀熟」 top_k: 返回条数，默认 5

  ConnectorNo auth

• list_talentA

  独行录 / opcmenuB

  【何时用】用户要的是**某一类人本人**而不是某个产品/服务时用：「帮我找个能写代码的」「有没有做出海的人」「找几个律师/财税顾问聊聊」。和 list_service_products 的区别：那边是「他卖什么」（产品目录），这边是「他本人是干什么的」（人的目录）；和 search_people 的区别：那边是语义搜，这边是结构化职业筛选，适合按类目扫一遍。 【组合链】items[].user.id → get_creator 看完整主页 → start_conversation 开聊（开聊走每日额度，撞 429 会直接返回「怎么办」的出口，别重试）；user.id → follow_creator 先关注不打扰；items[].company.slug → get_company。人卡唯一动作就是进个人主页，没有别的落点。 【口径/坑】 · 职业（items[].professions）是**机判闭集**：由资料/名片/自述跑分类器写入，不是本人勾选；一人最多两个主职业。没被判出职业的人不进这个目录，想找他走 search_people。 · chip 是职业的合并桶（比如律师/财税/HR 都并在「咨询·顾问」里），卡片上的职业胶囊是细粒度标签，两者不是一回事。 · **此刻真正有人的 chip 用 get_talent_chips 查**（服务端按真实人数 ≥ 阈值才下发，并带每个 chip 的人数）；这里的枚举只是合法值集合，不代表此刻每个都有人。传了没下发的 chip 会拿到很少甚至 0 条，不是报错。不传 chip 或传 all = 全部；传不认识的 key 按全部处理（不 400）。 · 只回真人（在册、已入驻、非测试号、非运营机构号）；返回里没有手机/邮箱/外链，要联系只能开聊。 · 规模小（百级），分页是 offset（nextCursor 就是下一次的 offset）。

  ConnectorNo auth

• get_my_positioningA

  独行录 / opcmenuB

  【需要登录】【何时用】用户问「我现在到哪一步了」「接下来该干嘛」「帮我把这周能做的都做了」。返回阶段台阶（主线五级 + 融资阶段）上的当前等级、六维画像、称号与总分，以及全部任务的完成态与 nextUp（最该做的三件事）。 【组合链·代办】nextUp 里每条任务都带 suggestedTool——**这是 agent 面相对 App 的关键差别：App 的 CTA 只能把人跳到那一屏让他自己动手，你能直接把这件事做完。** 对照表： · 写「我能提供什么」/ 一句话说清项目 → update_my_profile(canOffer)（partner.can_offer 与 funding.one_liner 两条任务判的就是 User.canOffer 的字数，分别 ≥30 / ≥20 字，写虚了过不了） · 融资资料、轮次金额、传 BP → set_my_role_profile(fundraising) · 邀请同行 → get_my_invite · 发需求（招兼职 / 找合伙人 / 找资源）→ create_need · 发布产品 → create_product · 归位产业链 → set_my_chain_position · 看看我的名片长什么样 → get_my_card；去回消息 → list_my_conversations 用户说「把这周能做的都做了」就真的一条条做完再汇报，别只念清单。 【口径/坑】 · **本工具会刷新你的定位快照**（写 PositioningState：算分快照 + auto 任务的完成戳），所以它不是纯读工具，别当免费接口循环调。只想看个大概用 get_my_brief。 · level.source='declared'（用户自报）**永远优先**于 inferred（LLM 读证据判的）/ observed（确定性兜底）。要改自报值走 set_my_role_profile(venture.stage)。 · basis / signals / confidence 是 LLM 给的判词，**转述它，别自己另判一个等级**，更别说「我觉得你其实已经到 XX 了」。 · 任务只增不减：达标那刻盖戳，之后数据回落也不打回未完成（用户不会莫名其妙掉级）。 · 默认**裁掉全部任务的培训正文（guide）**，否则一次调用几万 token。要正文：includeGuides=true + taskKeys 指定 1~5 条（「证照与备案那几项怎么办」就一次要 5 条，别发 5 次往返）。 · defaultSection 是服务端按段位给的分流建议：'chain'=这人该先去归位产业链（list_my_chain_anchors / set_my_chain_position），'self'=先补自我定位。**别自己另判一套。** · 任务带 group（如「证照与备案」），这一组的进度直接读返回体的 compliance{group,total,done}，别自己数也别手抄条数。 · verify='manual' 的任务平台观测不到，要用 mark_positioning_task 自报打勾（一次可以打一批）。

  ConnectorNo auth

• update_collaboration_taskA

  独行录 / opcmenuB

  【需要登录】更新任务标题、描述、截止；换被指派人需要指派权限且可能通知新负责人。权限由服务校验，省略保留，detail/dueAt=null 清空。状态用 set_collaboration_task_status。结果不明或超时后先查询现值，不要自动重发；服务没有持久请求去重键。 用 get_collaboration_goal 核对任务。

  Connector

  Destructive

  No auth

• zhini_list_tagsA

  知你客服A

  分页获取标签列表，用于在已知标签分组 ID 时列出该分组下的标签，并为客户搜索或历史会话搜索提供 tag_id。page 从 1 开始；page_size 最大 20。前置：可先调用 zhini_list_tag_groups 获取分组；如果用户只提供标签中文名，优先调用 zhini_search_tags 解析 tag_id。后续：拿到 tag_id 后可调用 zhini_search_customers 或 zhini_search_sessions。

  ConnectorOAuth

• zhini_search_customersA

  知你客服A

  搜索客户通讯录，用于根据客户名、手机号、微信号、客服、负责人、明确标签、渠道、性别、联系人类型或时间范围完整召回符合条件的客户 UID。用户只要求查询当天或某个时间范围内咨询过的客户时，默认查询当前授权账号关联的所有渠道范围，不代表当前调用客服本人接待或回复过；除非用户明确说“我处理过、我接待过、我回复过、归属于我”或指定某客服/渠道，否则不要自动传 kfid、pic_kfids 或 channel_id。用户要求查询某天或某段时间内的全部用户、包括会话已经结束/关闭的用户时，应使用本工具分页查询，不能用 zhini_list_active_sessions 代替。重要边界：自然语言中的“XXX 用户/客户”默认是业务语义或筛选条件，不应自动转换为 tag_id。可由名称、时间、渠道、客服等结构化字段表达的条件直接使用本工具；必须根据聊天内容判断的条件，应结合 zhini_search_sessions 和 zhini_fetch_messages 识别。只有用户明确要求某标签或上下文已有 tag_id 时才按标签筛选，且 tag_id 只覆盖已标注客户。用户给客户姓名/手机号/微信号时先用本工具召回候选客户；如果匹配多个客户，应让用户确认。用户明确给出标签名、渠道名、客服名时，应先分别调用 zhini_search_tags、zhini_list_channels、zhini_list_kefu 解析 ID。禁止空条件拉全量；page 从 0 开始；page_size 最大 20。后续：拿到 uid 后通常调用 zhini_get_customer_profile 或 zhini_fetch_messages。

  ConnectorOAuth

• update_broker_leadA

  独行录 / opcmenuB

  【需要登录】给一批线索打同一个 patch（补标签、补「在找什么」、批量归档）。逐条执行逐条回结果，单条失败不中断整批——批量清洗正是这条的全部意义。 【组合链】list_broker_leads(q=…) 挑出要清洗的 → update_broker_lead(leadIds, patch) → scan_broker_matches。 【口径】① patch.archived=true 是归档不是删除：记录与归因凭据都留着，也是撞线索池上限时腾额度的正路。② ⚠ patch 里带 phone 会让这条线索**当场绑上一个站内用户**，归因先到先得且不可撤——改手机号之前把改前改后念给用户确认。③ 只传想改的字段，不传的保持原值。

  ConnectorNo auth

• collect_broker_leadsA

  独行录 / opcmenuB

  【需要登录】把一批站内用户一次收进线索池，最多 20 人。幂等：已收过的原样返回，之前归档过的会复活。 【组合链】search_people / list_talent / list_broker_fresh_joiners 找人 → collect_broker_leads(userIds, tags=['0921活动']) → scan_broker_matches。 【报名单这条链只有 agent 能走】list_signup_submissions(slug, reviewStatus='ACCEPTED') → 取有 userId 的那些（匿名投递没有，跳过并如实告诉用户跳了几条）→ collect_broker_leads(userIds, tags=['<活动名>'])。⚠ **不要把报名答案抄进 note**——答卷原文不出撮合台，tags 里只放活动标识。 【口径】收自己会被拒、账号不可用的会被拒，这两种落成 skipped 不中断整批。

  ConnectorNo auth

• set_guest_invite_planA

  独行录 / opcmenuB

  【需要登录·主办方】【何时用】定这场活动怎么邀人：邀几位（targetCount）、备选几位、每隔多少分钟邀一位（intervalMinutes）、邀请多久过期、给模型的选人 brief。 【组合链】本工具建计划（SPEAKER 首次建会后台找一批候选，十几秒）→ get_activity_invites 看候选 → update_guest_candidates 定顺序 → set_guest_invite_plan_status(start) 才真开始发。 【口径】① autoStart 只对 ATTENDEE 生效，且等于系统开始按算法给**陌生人**逐个发私信（不是发给报名者）——用户没明说「观众也自动邀」就别传，发起前必须把「邀谁、每隔多久一位、共几位」念给用户确认。② SPEAKER 计划无论如何都要人工 start，autoStart 对它无效。③ brief 不传服务端会再调一次 LLM 归纳（多花钱多等十几秒）；你手上有活动全文，直接给 600 字以内的 brief。改 brief 只作废**还在跑**的那次候选生成，并把 SPEAKER 计划暂停待复核；**已在册的旧候选一条都不会被清掉**，也不会自动再找一批（要新的调 add_guest_candidates，新人追加在旧人后面）。起跑前用返回体里的 speakers 复核整张名单，不要的用 update_guest_candidates 显式剔掉。

  Connector

  Destructive

  No auth