Incrementally integrate TinyRobot, GenUI, business WebMCP, and PageTool into an existing Vue 3 + Vite business application. The actual packages installed in the target project, public APIs, and business declarations shall prevail; do not replace real integration with demo components, mock tools, or preset responses.
By default, complete code integration verification; only when the user explicitly requests verification of conversation, services, or end-to-end functionality, execute the corresponding runtime closed loop.
Selection Phase
Implement only the phase requested by the user, and check the existing capabilities it depends on. When the user requests completing the entire process at once, execute in the following dependency order; missing runtime configuration does not block subsequent code integration.
| Phase | Objective | Prerequisite Capabilities | Detailed Reference |
|---|---|---|---|
| 1 | TinyRobot Chat | Vue 3 + Vite Application | TinyRobot Integration |
| 2 | GenUI | The only TinyRobot Chat already integrated | GenUI Integration、Template Adaptation |
| 3 | Business WebMCP and Business Skill | TinyRobot runtime | Business WebMCP |
| 4 | PageTool | WebMCP channel consumable by TinyRobot | PageTool |
If the project already has a certain prerequisite capability, after confirming it through source code, dependency, and build evidence, continue directly without regenerating or rewriting it.
Both the second and third phases will change useLocalChatRuntime request or MCP ownership. Before implementation, you must read
Runtime Ownership, select the sole owner according to the guard in the target version source code, and do not stack two mutually exclusive entries onto the same runtime.
General Working Approach
- Confirm the current application directory, Git and workspace boundaries, package manager, entry files, existing chat implementation, and dirty files. All commands are executed within the target application boundary, and user changes are preserved.
- Check the package version, exports, types, source code, and runtime parameter validation actually resolved by the target project, and then decide the import path and adaptation method; do not implement based only on memory or reference project versions.
- Prioritize reusing the project's existing components, runtime, model strategy, business state, and test entry points. Keep only one chat interface in the entire application.
- When dependency installation, code generation, or build fails, diagnose based on the original output; do not report failed commands, partial file changes, or mock results as success.
- The business tool contract and PageTool operation scope come only from the business party's existing code, business contract, or explicit user instructions. When declarations are missing, general infrastructure can be completed, but you must point out the actual files and fields that the business party needs to modify, and then stop implementing the corresponding business capability.
Four Phases
1. TinyRobot Chat
First look for the existing TinyRobot component and mounting chain in the project. If it does not exist, follow TinyRobot Integration for the currently locked published CLI, first execute add chat --dry-run, confirm the plan before applying, and do not use create. The CLI version only constrains generator invocation and does not replace checking the target project's runtime version and API.
The existence of CLI-generated files or same-named components does not by itself prove that integration is complete. Before continuing, confirm: dependencies and lockfile can be resolved,TrThemeProvider/TrChat uses the valid exports of the current package, the component is mounted only once in the real entry chain, and styles are integrated.
2. GenUI
Add GenUI on the existing TrChat , and do not create a second chat surface. When compatible, reuse assets/genui-v1.3.0/; if the version or host structure differs, adapt item by item.
Keep the normal text path, current model selection, and host model policy. The GenUI switch only changes the declared request routing and schema rendering behavior; streaming content is passed through PatternExtractor parsing, normal text is still rendered by TinyRobot, and only valid schema-card enters GenuiRenderer. The authentication method and prompt structure must come from the service contract.
If GenUI unifies normal requests and GenUI requests through a custom responseProvider , then it is the sole request owner; do not pass useLocalChatRuntime into the same modelProvidersagain. The original provider definition should be migrated into the custom provider runtime and explicitly connected to the current model; model selection capability must not be removed to eliminate conflicts. Before completion, verify that the final runtime call retains only one request owner, and perform a local mount verification that does not send messages.
3. Business WebMCP and Business Skill
Integrate the Next SDK's browser WebMCP initialization, TinyRobot adapter, and src/skills/**/SKILL.md loading chain. The adapter reads from document.modelContext and executes the real descriptor, without maintaining duplicate business schemas. After loading, the business Skill instructions must enter the model request through the current sole request owner; when a custom responseProvider already exists, extend it, and do not bypass the existing model and GenUI routing to create a second request chain.
The business side is responsible for registering tools in the actual page or business module and writing the corresponding business Skill; tool names, parameters, return values, side effects, and confirmation rules are all based on the business declaration. If a business tool produces a page state change that will affect subsequent model decisions, it should be stated in the tool contract; the return result only reflects the observable state that has already been completed. When the dedicated tool result is already sufficient to accomplish the user's goal, do not use PageTool to search or verify repeatedly. Do not generate business tools based on page fields, buttons, routes, or examples.
The tool registration scope is determined by business visibility: capabilities that hold only on the current page are mounted and unmounted with the page, and only capabilities that are truly unrelated to the page should be persistently registered at the application level. Do not change the business tool scope to bypass TinyRobot's per-turn tool snapshot; when the same message continues to call page tools after crossing routes, use the per-model-request tool refresh capability exposed by the target version. TinyRobot Chat 0.5.2-alpha.15 can use the dynamic toolPluginin versioned assets to read the currently registered and enabled descriptor before each model request, while connecting the adapter runtime separately to the MCP panel. For specific rules, see Business WebMCP。
The Next SDK must be a traceable direct dependency of the target application, and the official WebMCP initialization must be completed at the client entry,createApp , and before the business page registers tools. When the custom adapter is the sole owner of MCP, do not pass useLocalChatRuntime into mcpServersat the same time; an existing real MCP server must not be silently deleted; merge or stop and report according to Runtime Ownership .
The adapter must handle asynchronous tool discovery, the model-visible server namespace, execution of the same descriptor, parameter serialization,toolchange refresh, and component unmount cleanup according to the target version's real contract.toolchange only indicates that the directory and UI state have been refreshed; whether subsequent model requests in the current turn re-fetch tools must be guaranteed by native runtime capabilities or a dynamic tool plugin. When a verified exact version is matched, you can use Business WebMCP versioned templates; otherwise, treat the template as a data flow reference and adapt it item by item.
4. PageTool
Use the target project's current Next SDK public PageTool API to integrate registration, the TinyRobot adapter, the general observation flow, and the action policy.
The infrastructure can implement the query channel, but the model can only observe the safe scope declared by the business side; when nothing is declared, do not expose business page content. Page targets, stable identifiers, actionable actions, and excluded regions are declared by the business side; when not declared, do not add actionable semantics to menus, buttons, or blocks on your own. If the SDK itself has no action authorization mechanism, validate actions and targets before the adapter executes them. Side effects such as submission, deletion, publishing, and payment should use dedicated WebMCP tools with business IDs, permissions, and confirmation contracts, and must not be allowed through general PageTool or prompts.
The adapter must both narrow the PageTool action schema visible to the model according to business policy and validate the latest observation, ref, and stable target before execution; tool names cannot be used as PageTool actions. When the target version supports it, enable mask cleanup after tool invocation; unless the user explicitly asks to hide the operation cursor, use the one shown only during the operation actionOnly, do not change it to never. When a verified exact version is matched, it can adapt to the general template in assets/webmcp-next-0.4.11-tinyrobot-0.5.2-alpha.15/pagetool/ ; the business target policy must come from the target project and must not be written into general assets.
When a message needs to continue calling target page tools after PageTool navigation, pass the page readiness condition as project configuration to the adapter: after the PageTool navigation action executes, wait for all descriptors required by the target route to be registered, then return the tool result; the next model request obtains new tools through the dynamic tool refresh integrated in phase three. PageTool remains registered at the application level, while business tools continue to follow the page lifecycle; the two cannot replace each other by migrating scopes.
PageTool only supplements page observation or interaction not yet covered by business tools. When the dedicated business tool result is already sufficient to accomplish the user's goal, the generated business Skill should require the model to answer directly; only when the result is insufficient, the tool reports failure, or the user explicitly requests an additional page check should PageTool continue to be called.
Configuration and secrets
Only in .env.example add empty placeholders for the required variables. Do not read, output, delete, overwrite, commit, or hardcode real .env and secrets. Any VITE_* value will enter the browser artifact; authentication that needs to be kept secret should be handled by the server or a same-origin proxy.
When the model Key, GenUI URL, Prompt ID, or other runtime configuration is missing, keep the related functionality disabled, continue completing the code integration that does not depend on real services, and list the configuration still to be added in the result.
Verification and reporting
Default verification scope:
- dependencies, lockfile, public exports, and the real mount chain;
- verify the parsing, request routing, adapter, Skill loading, and action policy related to this phase according to the project's existing test entry points or temporary checks;
- the project's existing type checking and production build.
The Skill only specifies the production behavior to be verified and does not copy test templates into the target project. Tests, fixtures, and diagnostic code temporarily added for localization or acceptance must be deleted before completion; only important regressions that the target project itself needs to protect long-term should be retained according to its testing specifications.
After phases two and three modify the runtime wiring, by default reuse the existing local service, or start a development service that the Agent can clean up itself, to complete a mount check that does not send model messages:
- In phase two, open the sole chat surface and check the GenUI controls: toggle when configuration is complete, and verify the disabled state when configuration is missing; in both cases, confirm there are no runtime configuration exceptions;
- In phase three, open the MCP panel and confirm that the server and the tools registered by the business side are visible; when there is no business declaration, only confirm initialization and the empty state.
Do not occupy or stop the user's existing processes; only services started by the Agent itself are stopped after verification. By default, do not send model messages, do not call remote services, and do not capture screenshots.
When the user explicitly requests runtime verification, verify only the scope they name, and complete the real user path: user input → actual model or tool call → observable chat, page, or business result → consistent assistant feedback. For screenshots, use the resolution specified by the user, and set the viewport before the page is first loaded.
The final report uses factual descriptions: which files were modified, which checks passed or failed, which configurations are pending, which runtime capabilities were not verified, and what risks remain. Do not replace these facts with custom status codes.
Scope boundaries
This Skill does not include built-in business tools, business page targets, model provider preferences, or demo data. It provides integration channels, general contracts, and security boundaries; business capabilities are still defined by the target application.