@tencent-rtc/mcp 1.6.8 → 1.7.0

package/resource/knowledge/roomkit/best-practice/common/room-limit-and-multi.md

@@ -0,0 +1,83 @@
+---
+title: "TUIRoomKit Concurrent Room Limits and Multi-Room Support（TUIRoomKit / 并发房间 / 房间上限 / 同时进多个房间 / 单房间人数）"
+product: room
+frameworks: [react, vue, web, android, ios, flutter]
+scope: platform_common
+tags: [TUIRoomKit, concurrent rooms, room limit, joining multiple rooms, single room capacity, peak group count, TUIRoomTypeConference, useRoomState, multi-device login, mutual kick, conference, room management]
+version_range: ">=2.0.0"
+---
+
+# TUIRoomKit Concurrent Room Limits and Multi-Room Support
+
+## 1. Key Takeaways
+
+- The number of concurrent rooms has an upper limit, determined by the **TUIRoomKit (multi-party audio/video) plan version + IM capabilities**.
+- **A single client / single SDK instance cannot be in multiple conference rooms simultaneously**: for conference-type rooms, the per-device concurrent room limit is 1. Exceeding this causes the earliest joined room to be exited.
+- **The same userId on multiple devices joining the same room results in mutual kick by default** (later entry kicks earlier entry). To have multi-device access to the same meeting, configure "multi-device login" according to your plan, or assign different userIds to different devices.
+
+## 2. Field / API Reference
+
+| Field / Capability | Purpose | Notes |
+|---|---|---|
+| `TUIRoomTypeConference` | Conference-type room | Per-device concurrent room limit is 1 |
+| `useRoomState` | Room state (Atomicx no-UI path) | Singleton; a user can only be in one room at a time |
+| Room count limit | Room/group resource peak | Billed by natural month peak, not unlimited room creation |
+| Single room capacity | Max participants per meeting | Hard limit by plan (20/50/200/300) |
+| Multi-device login | Same userId on multiple devices | Only supported in higher-tier plans |
+
+## 3. Mechanism & Sequence
+
+### Concurrent Room Limit
+
+After activating a TUIRoomKit (multi-party audio/video) plan, the number of concurrent meetings is constrained by **room count limit + single room capacity**:
+
+| Capability Dimension | Trial | Basic Interactive | Advanced Interactive | Ultra-Large Room Interactive |
+|---|---|---|---|---|
+| **Room count limit** (billing metric) | Follows IM version | 100,000/month | 100,000/month | 100,000/month |
+| **Single room participant capacity** | 20 | 50 | 200 | 300 (submit ticket for expansion) |
+
+- Single room capacity is the hard upper limit on "max participants per meeting."
+- Room count limit (peak group count) is the IM-side group/room resource peak included in the plan (billed by natural month peak), not "unlimited rooms at any moment."
+- The actual number of simultaneous meetings also depends on IM plan, TRTC resources, and business architecture. Ultra-large rooms have an expansion channel.
+- Multi-device login to meetings / same-platform multi-device login requires a higher-tier plan.
+
+### Same User Joining Multiple Rooms
+
+When a single client / single SDK instance calls `joinRoom` to enter a new room while already in a conference-type room, the earliest joined room is exited (per-device concurrent room limit is 1).
+
+## 4. Standard Usage
+
+When evaluating concurrent room requirements, follow these steps:
+
+1. Confirm your TUIRoomKit plan version and check the room count limit and single room capacity in the [Features & Billing Documentation](https://cloud.tencent.com/document/product/269/104946).
+2. Evaluate whether the per-meeting participant count exceeds the plan limit; submit a ticket for ultra-large room expansion.
+3. When the business needs to host multiple meetings simultaneously, evaluate whether the room count limit (peak group count) is sufficient, combined with IM plan and TRTC resources.
+4. When the business needs the same user on multiple devices in the same meeting, confirm the plan supports multi-device login; otherwise assign different userIds to different devices.
+
+## 5. Expected Results
+
+- Concurrent meeting count is constrained by plan room count limit and single room capacity.
+- When a single SDK instance joins multiple conference rooms, exceeding 1 causes the earliest joined room to be exited.
+- The same userId on multiple devices joining the same room results in mutual kick (later kicks earlier).
+- Multi-device access to the same meeting requires plan support for multi-device login, or assigning different userIds to different devices.
+
+## 6. Common Pitfalls
+
+- Pitfall 1: Assuming room count limit (peak group count) means "unlimited rooms at any time" (billed by natural month peak, not unlimited concurrency).
+- Pitfall 2: Assuming a single SDK instance can be in multiple conference rooms simultaneously (per-device limit is 1).
+- Pitfall 3: Assuming the same userId on multiple devices can join the same room simultaneously (mutual kick by default).
+- Pitfall 4: Ignoring plan version differences (multi-device login only supported in higher-tier plans).
+
+## 7. Problem Definition (retrieval hint)
+
+Whether TUIRoomKit has an upper limit on the number of concurrent meetings, and whether a single user can join multiple rooms simultaneously.
+
+## 8. Alternative Queries (retrieval recall)
+
+- What is the TUIRoomKit concurrent room limit?
+- How many meetings can run simultaneously?
+- Can the same user join two rooms at the same time?
+- What is the maximum number of participants per room?
+- Does TUIRoomKit support multi-device login?
+- Will the same userId on multiple devices cause mutual kick?
+- How to expand the meeting room capacity?

package/resource/knowledge/roomkit/best-practice/common/room-screen-share-preview.md

@@ -0,0 +1,83 @@
+---
+title: "TUIRoomKit Screen Sharing Local Preview and Avoiding Infinite Mirroring（TUIRoomKit / 屏幕共享 / 本地预览 / 无限套娃）"
+product: room
+frameworks: [react, vue, web]
+scope: platform_common
+tags: [TUIRoomKit, screen sharing, local preview, startScreenSharing, startScreenShare, full-screen sharing, infinite mirroring, infinite recursion, window sharing, external monitor, useDeviceState, view parameter]
+version_range: ">=2.0.0"
+---
+
+# TUIRoomKit Screen Sharing Local Preview and Avoiding Infinite Mirroring
+
+## 1. Key Takeaways
+
+- The `view` parameter enables local display of the shared content: passing a valid `view` renders the shared screen in a local container (local preview); omitting it or passing `null` skips local preview rendering.
+- Full-screen sharing with local preview causes "infinite mirroring/recursion": the local preview area is within the captured full screen/current page, so the preview image re-enters the capture, creating recursive mirroring.
+- **Preferred solution: share a "window" instead of the full screen**, preventing the meeting page from being captured and causing recursion.
+  - **Note for sharing WPS**: typically you cannot capture the "slideshow window" independently (the slideshow window and editor window behave inconsistently in the capture list). In this case, have the user connect an **external monitor**: place the slideshow on the external screen, then share that monitor/corresponding window. The main meeting screen continues operating, and the preview is less likely to recurse.
+- **Fallback solution**: when window sharing is not possible and no external monitor is available, make the local preview container as small as possible (shrink the `view` container) to significantly reduce the recursive mirroring impact; or do not pass `view` / pass `null` for local preview, using only a "sharing in progress" status indicator.
+
+## 2. Field / API Reference
+
+| Field / Capability | Purpose | Notes |
+|---|---|---|
+| `view` | Local screen share preview container | Pass a valid DOM element or id to render local preview; pass `null` to skip |
+| `startScreenSharing` | Screen sharing API | TRTC Web / Room screen sharing; `view` specifies local preview |
+| `startScreenShare` | Underlying screen sharing | TRTC `startScreenShare`, consistent with Atomicx |
+| `useDeviceState().startScreenShare` | Atomicx no-UI path | Screen sharing entry; local preview determined by preview view/container |
+
+## 3. Mechanism & Sequence
+
+### Local Preview
+
+Call screen sharing API with a valid `view` -> local container renders the shared screen (local preview) -> omitting `view` or passing `null` skips local preview rendering.
+
+## 4. Standard Usage
+
+### Screen Sharing with Local Preview
+
+```javascript
+// TRTC Web / Room screen sharing, view specifies local preview container (element or id)
+startScreenShare({
+  view: 'local-preview-container',   // 传入有效 view，本地渲染分享画面
+  // 传 null 则不渲染本地预览
+});
+```
+
+### Avoiding Infinite Mirroring
+
+```javascript
+// 方案 1：优先分享窗口而非整屏，从源头避免套娃
+startScreenShare({ view: 'local-preview-container' });  // 选择窗口采集源
+
+// 方案 2（兜底）：无法分享窗口时，缩小本地预览容器或本地不传 view
+startScreenShare({ view: null });  // 不渲染本地预览，仅用"正在共享"状态提示
+```
+
+## 5. Expected Results
+
+- Passing a valid `view`: local container renders the shared screen, enabling local preview.
+- Omitting / passing `null`: no local preview rendering; only remote participants see the shared screen.
+- Full-screen sharing + local preview: may cause infinite mirroring; switch to window sharing or shrink the preview.
+- Sharing WPS slideshow: use the external monitor approach to avoid mirroring.
+
+## 6. Common Pitfalls
+
+- Pitfall 1: Assuming `view` is a remote rendering parameter (`view` specifies the local screen share preview).
+- Pitfall 2: Giving up local preview entirely because full-screen sharing causes mirroring (switch to window sharing or shrink the preview instead).
+- Pitfall 3: Assuming you can capture the WPS slideshow window independently (typically not possible; use an external monitor).
+- Pitfall 4: Confusing `startScreenSharing` with `startScreenShare` (they are consistent at the underlying level; both use `view` for local preview).
+
+## 7. Problem Definition (retrieval hint)
+
+Whether the `view` parameter in TUIRoomKit screen sharing enables local preview of the shared content, and how to avoid infinite mirroring/recursion when sharing the full screen with local preview enabled.
+
+## 8. Alternative Queries (retrieval recall)
+
+- Can screen sharing show a local preview?
+- What is the TUIRoomKit screen sharing startScreenShare view parameter?
+- How to avoid infinite mirroring when sharing full screen?
+- What to do about recursive mirroring in screen sharing?
+- Is it better to share a window or the full screen?
+- How to shrink the local preview window?
+- How to hide local preview for screen sharing?

package/resource/knowledge/roomkit/best-practice/common/room-status-after-all-leave.md

@@ -0,0 +1,69 @@
+---
+title: "TUIRoomKit Room Status and Billing After All Members Leave（TUIRoomKit / 所有人离开 / 房间销毁 / 回收房间 / 解散房间）"
+product: room
+frameworks: [react, vue, web, android, ios, flutter]
+scope: platform_common
+tags: [TUIRoomKit, all members leave, room destruction, room reclaim, dismiss room, billing, meeting end, room existence, room count]
+version_range: ">=2.0.0"
+---
+
+# TUIRoomKit Room Status and Billing After All Members Leave
+
+## 1. Key Takeaways
+
+- A room is **not** automatically destroyed immediately when "all members leave."
+- After a meeting ends, the business side should **proactively call the dismiss room API** to end the meeting.
+- If not manually dismissed: the backend attempts to reclaim the room **6 hours after** the meeting end time, provided the **member count is 0**.
+- Billing is based on actual push/pull stream and call consumption. After all members leave and there is no media usage, audio/video duration charges generally stop; however, the room object still occupies room count quota until dismissed or reclaimed.
+
+## 2. Field / API Reference
+
+| Field / Capability | Purpose | Notes |
+|---|---|---|
+| Dismiss room API | Proactively end a meeting | Business side calls after meeting ends |
+| Backend reclaim | Automatic room cleanup | Attempted 6 hours after meeting end; condition: member count is 0 |
+| Room member count | Room member statistics | Reclaim condition: member count is 0 |
+| Audio/video duration billing | Call consumption billing | Billed by actual push/pull stream and call consumption |
+| Room count occupation | Room object occupation | Still occupies room count quota until dismissed or reclaimed |
+
+## 3. Mechanism & Sequence
+
+All members leave room -> Room is not destroyed immediately -> Business side proactively calls dismiss room API (recommended), or waits for backend automatic reclaim -> Backend attempts reclaim 6 hours after meeting end (condition: member count is 0) -> Room is reclaimed.
+
+Billing dimensions:
+
+- Audio/video duration is billed by actual push/pull stream and call consumption.
+- After all members leave and there is no media usage, audio/video duration charges for that room generally stop.
+- The room object still occupies room count quota until dismissed or reclaimed.
+
+## 4. Standard Usage
+
+1. After the meeting ends, the business side proactively calls the dismiss room API to end the meeting, avoiding lingering rooms.
+2. If manual dismissal is forgotten, the backend automatically reclaims the room after 6 hours (when member count is 0).
+3. When evaluating room count occupation, note that undismissed and unreclaimed room objects still consume quota.
+
+## 5. Expected Results
+
+- After proactive dismissal, the room ends immediately.
+- Without proactive dismissal, the backend reclaims the room 6 hours after meeting end when member count is 0.
+- After all members leave and there is no media usage, audio/video duration charges stop.
+- Undismissed and unreclaimed room objects still occupy room count quota.
+
+## 6. Common Pitfalls
+
+- Pitfall 1: Assuming rooms are automatically destroyed after all members leave (requires proactive dismissal or waiting 6 hours for backend reclaim).
+- Pitfall 2: Assuming undismissed rooms incur no cost (room objects still occupy room count quota, potentially affecting concurrent capacity).
+- Pitfall 3: Neglecting proactive dismissal by the business side (recommended to call the dismiss API rather than relying on backend reclaim).
+
+## 7. Problem Definition (retrieval hint)
+
+Whether a TUIRoomKit room still exists after all members leave, whether billing continues, and how to proactively dismiss a room.
+
+## 8. Alternative Queries (retrieval recall)
+
+- Does the room auto-destroy after everyone leaves?
+- Does an empty TUIRoomKit room still incur charges?
+- How to dismiss a room after a meeting ends?
+- How long does room reclaim take?
+- What happens when room member count is 0?
+- Does the room object still occupy room count quota?

package/resource/knowledge/roomkit/best-practice/vue/room-uikit-vs-atomicx.md

@@ -0,0 +1,111 @@
+---
+title: "Comparison of tuikit-atomicx-vue3/room vs roomkit-web-vue3（roomkit-web-vue3 vs tuikit-atomicx-vue3/room 的区别）"
+product: room
+frameworks: [vue, web]
+scope: platform_specific
+tags: [TUIRoomKit, Atomicx, UIKit, tuikit-atomicx-vue3, roomkit-web-vue3, useRoomState, conference, layer comparison, no-UI, pre-built UI, custom integration, dependency, vue3]
+version_range: ">=2.0.0"
+---
+
+# Comparison of tuikit-atomicx-vue3/room vs roomkit-web-vue3
+
+## 1. Key Takeaways
+
+- `tuikit-atomicx-vue3/room` (Atomicx) is the **atomic capability layer**: the primary path for no-UI / highly customized integration, decomposing room, device, and member states into reactive State Hooks.
+- `@tencentcloud/roomkit-web-vue3` (RoomKit / UIKit) is the **pre-built UI low-code layer**: an out-of-the-box meeting suite with page-level components.
+- Dependency: **RoomKit (pre-built UI) is a productized wrapper built on top of Atomicx/Room capabilities**. From a business perspective, RoomKit reuses/interfaces with Atomicx capabilities rather than being two independent room protocols.
+- API entry points: Atomicx uses `useRoomState()`, UIKit uses `conference`.
+
+## 2. Field / API Reference
+
+| Field / Capability | Purpose | Notes |
+|---|---|---|
+| `useRoomState` | Atomicx room state entry | `createAndJoinRoom` / `joinRoom` / `leaveRoom` / `endRoom` / `currentRoom` |
+| `useDeviceState` | Atomicx device state | Device toggles, screen sharing, etc. |
+| `useRoomParticipantState` | Atomicx participant state | Member management, event subscriptions |
+| `useLoginState` | Atomicx login state | Login capability, reusable within UIKit sessions |
+| `conference` | UIKit meeting facade API | Recommended: `createAndJoinRoom` / `joinRoom` / `leaveRoom` / `endRoom` |
+| `ConferenceMainView` | UIKit pre-built view | Complete meeting UI: login, join room, meeting controls, layout, seat management |
+
+## 3. Mechanism & Sequence
+
+### Layer Comparison
+
+| Comparison | `tuikit-atomicx-vue3/room` (Atomicx) | `@tencentcloud/roomkit-web-vue3` (RoomKit / UIKit) |
+|---|---|---|
+| **Layer** | Atomicx (atomic capability layer): State Hooks + optional atomic UI components | UIKit / pre-built UI low-code layer: out-of-the-box meeting suite with page-level components |
+| **Package positioning** | No-UI / highly customized integration path; decomposes room, device, and member into reactive State | Pre-built UI rapid integration path; provides complete meeting UI and `conference` facade API |
+| **Core capabilities** | `useRoomState` / `useDeviceState` / `useRoomParticipantState` / `useLoginState`: create room, join meeting, device control, screen sharing, member management, event subscription; compose your own UI | `conference` + pre-built views (e.g. `ConferenceMainView`): login, join room, meeting controls, layout, seat management; supports selective component visibility / custom Widgets |
+| **Use cases** | Embedding audio/video into your own business UI (telemedicine, OA, education dashboards, etc.) with 100% control over interaction and branding | Fastest path to launch a standard meeting/webinar with minimal UI coding, accepting the official meeting interaction |
+| **Dependency** | Built on RoomEngine / TRTC / IM; an atomic integration approach | Pre-built UI reuses/interfaces with Atomicx capabilities (e.g. login uses `useLoginState`, in-meeting logic uses Room capabilities); RoomKit (pre-built UI) is a productized wrapper on top of Atomicx/Room |
+| **API entry** | `useRoomState()`: `createAndJoinRoom` / `joinRoom` / `leaveRoom` / `endRoom`, `currentRoom`, event subscriptions, etc. | `conference`: recommended `createAndJoinRoom` / `joinRoom` / `leaveRoom` / `endRoom` |
+| **UI form** | Optional pre-built atomic components + primarily self-composed custom modules | Primarily pre-built complete meeting UI, with limited customization via Widget / visibility configuration |
+
+## 4. Standard Usage
+
+### Atomicx Approach (no-UI, custom integration)
+
+```javascript
+import { useRoomState } from 'tuikit-atomicx-vue3/room';
+
+const { createAndJoinRoom } = useRoomState();
+
+createAndJoinRoom({
+  roomId: 'YOUR_ROOM_ID', // 必填：建议由业务后台生成的唯一标识
+  options: {
+    roomName: '项目进度周会',
+  },
+});
+// 通过 useDeviceState / useRoomParticipantState 等获取响应式状态自拼 UI
+```
+
+### UIKit Approach (pre-built UI, rapid integration)
+
+```javascript
+import { conference, ConferenceMainView, ConferenceMainViewH5, RoomEvent, genTestUserSig } from '@tencentcloud/roomkit-web-vue3';
+const SDKAppID = 0; // 替换为您在开通服务阶段获取的 SDKAppID
+const SDKSecretKey = ''; // 替换为您在开通服务阶段获取的 SDKSecretKey
+const handleEnterRoom = async () => {
+  if (!SDKAppID || !SDKSecretKey) {
+    return;
+  }
+  try {
+    const { userSig } = genTestUserSig({ userId: 'test01', sdkAppId: SDKAppID, secretKey: SDKSecretKey });
+    await conference.login({ sdkAppId: SDKAppID, userId: 'test01', userSig });
+    await conference.setSelfInfo({ userName: 'test', avatarUrl: '' });
+    await conference.createAndJoinRoom({ roomId: '123456', options: { roomName: `test01 的会议` } });
+    inRoom.value = true;
+  } catch (error) {
+    console.error('进入会议失败:', error);
+  }
+};
+// 使用预制 ConferenceMainView 渲染完整会议 UI
+```
+
+## 5. Expected Results
+
+- No-UI / highly customized needs: choose Atomicx, use `useRoomState()` + State Hooks to compose your own UI.
+- Fastest path to a standard meeting: choose UIKit, use `conference` + `ConferenceMainView`.
+- Dependency: UIKit reuses Atomicx capabilities; they are not two independent protocols.
+- API entry: Atomicx uses `useRoomState()`, UIKit uses `conference`.
+
+## 6. Common Pitfalls
+
+- Pitfall 1: Assuming Atomicx and UIKit are two independent room protocols (UIKit is built on top of Atomicx/Room capabilities).
+- Pitfall 2: Assuming Atomicx includes a complete meeting UI (Atomicx provides State Hooks + optional atomic components; UI must be self-composed).
+- Pitfall 3: Assuming UIKit cannot be customized (it supports selective component visibility / custom Widgets).
+- Pitfall 4: Confusing the API entry points of the two approaches (Atomicx uses `useRoomState()`, UIKit uses `conference`).
+
+## 7. Problem Definition (retrieval hint)
+
+Comparing the positioning differences between two TUIRoomKit Vue3 integration approaches: `tuikit-atomicx-vue3/room` (Atomicx Core SDK, no-UI, State Hooks self-composed) vs `@tencentcloud/roomkit-web-vue3` (RoomKit UIKit, pre-built UI, conference low-code) in terms of layer, capabilities, use cases, dependency, and API entry (useRoomState vs conference).
+
+## 8. Alternative Queries (retrieval recall)
+
+- What is the difference between Atomicx and RoomKit?
+- How to choose between `tuikit-atomicx-vue3/room` and `roomkit-web-vue3`?
+- How to choose between TUIRoomKit no-UI and pre-built UI approaches?
+- What is the difference between `useRoomState` and `conference`?
+- Is RoomKit based on Atomicx?
+- Which package for custom meeting room UI?
+- Use Atomicx or UIKit for rapid meeting integration?

package/resource/knowledge/rtcengine/web/plugin/30-advanced-cross-room-link.md

@@ -8,6 +8,8 @@ Cross-room connections support two modes:
 - **Room-level connection**: Connect with all anchors in the target room.
 - **User-level connection**: Connect with a specific anchor in the target room.
 
+> **Note**: Room-level and user-level connections cannot be used simultaneously.
+
 ## How It Works
 
 - **Room-level connection**: Push the audio and video streams of all anchors in the current room to the target room, and push the audio and video streams of all anchors in the target room to the current room.

package/resource/knowledge/rtcengine/web/plugin/39-advanced-video-decoder.md

@@ -6,6 +6,8 @@ This document introduces how to use the TRTCVideoDecoder plugin to enable video
 
 - TRTC Web SDK version >= 5.9.0
 
+- Browser version: Chrome 141+, Edge 141+, and other Chromium-based browsers 141+ (Safari and Firefox are not supported)
+
 ## Implementation Steps
 
 ### Deploy Static Resources

package/server.js

@@ -3,40 +3,45 @@ import { registryTools } from './tools/index.js';
 const SERVER_INSTRUCTIONS = `
 You are using Tencent RTC MCP Server for SDK documentation retrieval.
 
-- search_trtc_knowledge: Primary tool for searching Tencent RTC / Chat(IM) / Push(TIMPush) product documentation.
+- search_trtc_knowledge: Primary tool for searching Tencent RTC / Chat (IM) / Push (TIMPush) documentation.
   Covers: Chat UIKit, CallKit, LiveKit, RoomKit, TRTC Native SDK, WebRTC/rtcEngine, TIMPush.
-  Use this tool FIRST for all technical documentation / FAQ / error code / integration guide lookups.
-  Do NOT use web_search for questions that can be answered via this knowledge base.
+  Use this tool FIRST for technical docs / FAQ / error codes / integration guide lookups.
+  Do NOT use web_search for questions answerable by this knowledge base.
 
-**Product routing（调用 search_trtc_knowledge 前 MUST 推断 product 数组）**：
-- TIMPush / 推送 / 厂商通道 / FCM / APNs / 华为 / 小米 / OPPO / vivo → product=["push"]（独立产品，禁止误归 chat）
-- 会话 / TUIKit / ChatKit / IM 组件 / 主题定制 → ["chat"]
-- CallKit / 通话 → ["call"]；直播 / 语聊房 / LiveKit → ["live"]；RoomKit / 会议 → ["room"]
-- TRTC Web SDK / rtcengine / WebRTC 插件 → ["rtcengine"]
-- TRTCCloud / Native SDK（客户端）→ ["native_trtc_sdk"]
-- 推送 + IM 同时涉及 → 可传 ["push","chat"]
-- 无法从 prompt 唯一判断 product → 先向用户确认，不要无 product 硬搜，也不要 web_search
+**Product routing (MUST infer product[] before calling search_trtc_knowledge):**
+- TIMPush / push / vendor channel / FCM / APNs / Huawei / Xiaomi / OPPO / vivo -> product=["push"] (independent product; do not misroute to chat)
+- conversation / TUIKit / ChatKit / Chat component / theme customization -> ["chat"]
+- CallKit / call -> ["call"]; live streaming / voice room / LiveKit -> ["live"]; RoomKit / conference -> ["room"]
+- TRTC Web SDK / rtcengine / WebRTC plugin -> ["rtcengine"]
+- TRTCCloud / Native SDK (client side) -> ["native_trtc_sdk"]
+- If both push and Chat are involved -> ["push","chat"]
+- If product cannot be uniquely inferred from prompt -> ask user to clarify first; do NOT hard-search with empty product; do NOT use web_search.
 
-**Frameworks**：返回 needs_framework 时 MUST 先 present_framework_choice；详见 search_trtc_knowledge 工具 description 决策表。
-**When in doubt**：仍优先调用 search_trtc_knowledge（带最佳猜测 product）；status=empty 或 low_confidence 时再澄清或重搜。
+**Frameworks:** If status=needs_framework, MUST call present_framework_choice first. See search_trtc_knowledge tool description decision table.
+**When in doubt:** still prefer search_trtc_knowledge with best-guess product; if status is empty or low_confidence, then clarify or retry.
 
-**queryID 传递规则（硬规则，违反会导致 CLS 数据断裂）**：
-- 首次调用 search_trtc_knowledge：无需传 queryID（默认空串），响应 JSON 中会有 server 生成的 queryID 字段
-- 后续每一次 search_trtc_knowledge / finalize_answer / submit_feedback 调用：**MUST** 携带首次响应中的 queryID
-- 不传 queryID = 视为全新咨询（CLS 数据无法串联）
-- 多 sub-question 迭代搜索时，每次都要带相同的 queryID
+**queryID passing rules (hard rule; violation breaks CLS trace continuity):**
+- First search_trtc_knowledge call: no queryID required (defaults to empty); response JSON will include server-generated queryID.
+- Every subsequent call to search_trtc_knowledge / finalize_answer / submit_feedback: MUST carry the first returned queryID.
+- Missing queryID means a brand-new consultation (CLS data cannot be linked).
+- For multi-sub-question iterative searches, always reuse the same queryID.
 
 Workflow:
 1. Call search_trtc_knowledge. Reuse the same queryID for all retries/searches in this consultation.
 2. Draft the final answer from fragments. Include References from meta.references/doc_urls when available.
-3. MUST call finalize_answer with the same prompt + queryID before replying.
-4. Reply with: answer + finalize_answer follow-up text.
-5. After finalize_answer follow-up, check the next user reply before any normal response. If it means Yes/已解决/thanks/OK, MUST call submit_feedback(resolved="1") before replying. If it means No/未解决/still not working, MUST call submit_feedback(resolved="0") before replying. Never say feedback was submitted unless submit_feedback was called.
+3. MUST call finalize_answer with the same prompt + queryID before replying (pass an audit digest in "answer", not necessarily full long-form text).
+4. Reply with: full user-visible answer + finalize_answer follow-up text.
+5. After finalize_answer follow-up, inspect the next user reply before any normal response. If it means Yes/resolved/thanks/OK, MUST call submit_feedback(resolved="1") before replying. If it means No/unresolved/still not working, MUST call submit_feedback(resolved="0") before replying. Never claim feedback was submitted unless submit_feedback was actually called.
+
+User-visible output rules (MUST):
+- Internal routing/tool decisions are NEVER user-facing text.
+- Before calling any tool, do NOT output prefacing planning text such as “should call... / call ... first / let me search first / this is a consultation task / not codegen”.
+- If a tool call is needed, call it directly and then provide user-visible results only.
 `.trim();
 export function createServer() {
     const server = new McpServer({
         name: "Tencent RTC MCP Server",
-        version: "1.6.8",
+        version: "1.7.0",
     }, {
         instructions: SERVER_INSTRUCTIONS,
     });

package/tools/common/finalize_answer.js

@@ -1,6 +1,14 @@
 import { z } from 'zod';
 import { FINALIZE_ANSWER_DEFINITION, FOLLOWUP_QUESTION } from '../definitions/finalize_answer_def.js';
 import { reportCLSClient } from '../../utils/report-cls-client.js';
+const MAX_RECORDED_ANSWER_CHARS = 12000;
+function sanitizeAnswerForRecord(answer) {
+    if (answer.length <= MAX_RECORDED_ANSWER_CHARS)
+        return answer;
+    const head = answer.slice(0, 9000);
+    const tail = answer.slice(-2500);
+    return `${head}\n\n[...truncated_for_record:${answer.length - (9000 + 2500)} chars omitted...]\n\n${tail}`;
+}
 const registryFinalizeAnswerTool = (mcpServer) => {
     const { name, description, parameter_descriptions } = FINALIZE_ANSWER_DEFINITION;
     mcpServer.registerTool(name, {
@@ -16,7 +24,7 @@ const registryFinalizeAnswerTool = (mcpServer) => {
         reportCLSClient({
             method: 'record_answer',
             queryID: params.queryID,
-            answer: params.answer,
+            answer: sanitizeAnswerForRecord(params.answer),
             prompt: params.prompt,
             product: params.product ? params.product.join(',') : '',
             framework: params.framework ?? '',

package/tools/common/search_trtc_knowledge.js

@@ -10,7 +10,7 @@ const registrySearchTRTCKnowledgeTool = (mcpServer) => {
         inputSchema: {
             prompt: z.string().describe(parameter_descriptions.prompt),
             product: z.array(z.enum(['chat', 'call', 'live', 'room', 'push', 'rtcengine', 'native_trtc_sdk'])).min(1).max(4).optional().describe(parameter_descriptions.product),
-            frameworks: z.array(z.enum(['react', 'vue', 'web', 'miniprogram', 'android', 'ios', 'flutter', 'c++', 'uni-app', 'harmonyos', 'react-native', 'unity', 'unreal-engine', 'donut'])).min(1).optional().describe(parameter_descriptions.frameworks),
+            frameworks: z.array(z.enum(['react', 'vue', 'web', 'miniprogram', 'android', 'ios', 'flutter', 'c++', 'uni-app', 'harmonyos', 'react-native', 'unity', 'unreal-engine', 'donut'])).default([]).describe(parameter_descriptions.frameworks),
             queryID: z.string().describe(parameter_descriptions.queryID),
             ide: z.string().describe(parameter_descriptions.ide),
             types: z.array(z.enum([

package/tools/definitions/finalize_answer_def.js

@@ -9,7 +9,7 @@ When to call:
 
 Input:
 - prompt: Original user question. Must match the search_trtc_knowledge prompt.
-- answer: Complete final answer text, excluding the follow-up text. Do not summarize or truncate.
+- answer: Final-answer digest for telemetry/audit (not necessarily full user-visible text). Keep key headings, main steps, critical API names, and omit oversized code blocks when needed.
 - queryID: REQUIRED. Must match the non-empty queryID returned by search_trtc_knowledge.
 - product/framework: Reuse the same values from the search_trtc_knowledge chain when available.
 
@@ -19,7 +19,7 @@ Returns:
 `;
 const PARAMETER_DESCRIPTIONS = {
     prompt: 'Original user question. Must match search_trtc_knowledge.',
-    answer: 'Complete final answer text, excluding the follow-up text. Do not summarize or truncate.',
+    answer: 'Final-answer digest for telemetry/audit. Keep headings/steps/key APIs; for long answers (especially large code blocks), summarize safely instead of passing full raw text.',
     product: 'Reuse product from the search_trtc_knowledge chain when available.',
     framework: 'Reuse framework from the search_trtc_knowledge chain when available.',
     queryID: 'REQUIRED. Non-empty queryID returned by search_trtc_knowledge.',

package/tools/definitions/integration-boundary.js

@@ -2,4 +2,5 @@
 export const INTEGRATION_BOUNDARY_SUFFIX = `
 - **Codegen only**: Call this tool only when the user explicitly wants integration code added into a project, wants you to implement the integration, or wants generated starter code.
 - **Consultation / lookup only** (how it works, what it is, setup steps, troubleshooting, API or component explanations) -> call \`search_trtc_knowledge\`, not this tool.
-- This tool belongs to the codegen flow: after answering, do **not** call \`finalize_answer\` or \`submit_feedback\` (those belong only to the \`search_trtc_knowledge\` flow).`;
+- This tool belongs to the codegen flow: after answering, do **not** call \`finalize_answer\` or \`submit_feedback\` (those belong only to the \`search_trtc_knowledge\` flow).
+- **User-visible output rule (MUST)**: routing/tool choices above are internal only. Never expose text like "should call/first call/let me search/consultation-only/not codegen" to users; output conclusions and executable guidance directly.`;

package/tools/definitions/search_trtc_knowledge_def.js

@@ -26,7 +26,7 @@ if types include api / component / feature / plugin / sdk / integration -> frame
 const PARAMETER_DESCRIPTIONS = {
     prompt: "The user's original question in full. Keep the full context. Do not compress it into keywords or a short summary.",
     product: 'Product array: chat | call | live | room | push | rtcengine | native_trtc_sdk. If inferable, MUST pass it. Push takes priority for TIMPush / push topics and must not be misrouted to chat. Common live keywords: LiveKit / live streaming / voice room / TUILiveKit / AtomicXCore / host streaming / watch live. If uncertain, ask the user first.',
-    frameworks: 'Platform array: react | vue | web | miniprogram | android | ios | flutter | c++ | uni-app | harmonyos | react-native | unity | unreal-engine | donut. Multiple platforms can be passed for cross-platform lookup. For CallKit, TUICallKit is best searched separately by react/vue, while TUICallEngine/TUICallEvent still map to web; use miniprogram for Mini Program. harmonyos / react-native / unity / unreal-engine / donut are only valid for push.',
+    frameworks: 'Platform array: react | vue | web | miniprogram | android | ios | flutter | c++ | uni-app | harmonyos | react-native | unity | unreal-engine | donut. Multiple platforms can be passed for cross-platform lookup. For CallKit, TUICallKit is best searched separately by react/vue, while TUICallEngine/TUICallEvent still map to web; use miniprogram for Mini Program. harmonyos / react-native / unity / unreal-engine / donut are only valid for push. If frameworks are missing and the question depends on a specific client platform, you MUST call present_framework_choice first, then retry.',
     types: 'Usually omit. Allowed values: integration | component | feature | api | plugin | sdk | faq | error_code | product | server_api | webhook. component and feature are equivalent (match both). Discovery/listing questions ("what components are available") MUST omit types. Console/billing/product-capability config -> product (not feature). Do not proactively over-narrow.',
     scenario: 'live | voice. Only valid for the live product.',
     queryID: "First call: ''. Follow-up calls in the same consultation MUST pass through the original queryID returned by the server.",

package/utils/report-cls-client.js

@@ -28,7 +28,7 @@ function sendCLSReport(reportData) {
     const time = Date.now();
     const data = {
         platform: 'mcp',
-        verison: '1.6.8',
+        verison: '1.7.0',
         sdkappid: `${SDKAppID}`,
         method: method,
         userid: queryID || userID,

package/utils/report-es-client.js

@@ -7,7 +7,7 @@ function reportESClient(reportData) {
         report: [
             {
                 platform: 'mcp',
-                version: '1.6.8',
+                version: '1.7.0',
                 sdkappid: `${SDKAppID}`,
                 method: method,
                 userID: `${userID}`,

package/resource/knowledge/callkit/best-practice/web/callengine-invitation.md

@@ -1,80 +0,0 @@
----
-product: 'Call'
-tech_stack: 'callengine'
-framework: 'web'
-doc_kind: 'best_practice'
-title: 'TUICallEngine call invitation handling and signaling (Web)'
-keywords: ['ON_CALL_RECEIVED', 'call invitation', '@trtc/call-engine-lite-js', 'TUICallEngine.calls', 'userData', 'callMediaType', 'accept', 'reject', 'TIM.EVENT.MESSAGE_RECEIVED', 'custom signaling message']
----
-
-# TUICallEngine Web: call invitation reception and signaling notes
-
-Applicable package: **`@trtc/call-engine-lite-js`** (TUICallEngine Web SDK).
-
-## 1) How do I receive an incoming call invitation?
-
-**At the application layer, listen to `TUICallEvent.ON_CALL_RECEIVED` instead of parsing TRTC signaling or IM custom messages yourself.**
-
-```javascript
-import { TUICallEngine, TUICallEvent } from '@trtc/call-engine-lite-js';
-
-const tuiCallEngine = TUICallEngine.createInstance({ SDKAppID: xxx, tim: timInstance });
-await tuiCallEngine.login({ userID, userSig });
-
-tuiCallEngine.on(TUICallEvent.ON_CALL_RECEIVED, (event) => {
-  console.log('Incoming call', event);
-  // Show your incoming-call UI, then call accept() or reject()
-});
-```
-
-### `ON_CALL_RECEIVED` event fields
-
-| Field | Type | Description |
-|---------|---------|---------|
-| callerId | String | The inviter (caller) user ID. |
-| calleeIdList | Array<String> | Other invited users in the same invitation. |
-| isFromGroup | Boolean | Whether this invitation is from a group call. |
-| inviteData | Object | Invitation payload object. |
-| inviteID | String | Invitation ID for this invitation session. |
-| userData | String | Extension string passed through invitation signaling. |
-| callId | String | Unique call ID of this session. |
-| roomID | Number | Audio/video room ID used by this call. |
-| callMediaType | Number | Call media type (audio or video). |
-| callRole | String | Role enum (caller or callee). |
-
-## 2) Which parameters are used when sending an invitation with `calls`?
-
-The caller starts an invitation via **`TUICallEngine.calls()`**:
-
-```javascript
-await tuiCallEngine.calls({
-  userIDList: ['user_bob'],
-  type: 2,                    // 1 = audio, 2 = video (CallMediaType)
-  userData: '{"ext":"info"}', // Optional string extension
-  timeout: 30,                // Seconds, default is 30
-  roomID: 123456,             // Numeric room ID, range [1, 2147483647]
-  strRoomID: '',              // String room ID
-  chatGroupID: '',            // Required for multi-user calls in a Chat group
-  offlinePushInfo: { /* ... */ },
-});
-```
-
-## 3) In Chat-integrated audio/video calls, how do I interpret custom message fields for call status rendering?
-
-| **Question** | **Rule** |
-|---------|---------|
-| How to detect “call initiated” | `actionType = 1` and `cmd = 'videoCall'` or `'audioCall'` |
-| How to detect “call answered” | `actionType = 3` |
-| How to detect “call ended” and get call duration | `actionType = 1` and `cmd = 'hangup'`; read duration from `call_end` (seconds) |
-| How to detect “call canceled” | `actionType = 2` |
-| How to detect “call rejected” | `actionType = 4` |
-| How to detect “rejected due to callee busy” | `actionType = 4` and `cmd = 'line_busy'` |
-| How callee detects “timeout with no answer” | `actionType = 5` |
-
-## 4) Best-practice summary
-
-1. **Only** listen to `TUICallEvent.ON_CALL_RECEIVED`, then respond with `accept()` or `reject()`.
-2. **Do not** parse call invitations from `TIM.EVENT.MESSAGE_RECEIVED` manually.
-3. Use **`userData` (string)** for extension data: caller writes it, callee reads it from event payload.
-4. **`businessID` and low-level payload format** are internal SDK details; do not invent undocumented structures.
-5. In **`@trtc/call-engine-lite-js` 4.x+**, pass custom content via `userData`; there is **no `customData` field**.