connect-existing-tools

WebMCP Kit — connect-existing-tools

Mission

• The site already has working agent tools. This skill does not design, expand, or rebuild them. It moves their registration onto @nekuda/webmcp-sdk so they keep behaving exactly as they do today, and connects the site so their activity is visible in AgentLane.
• Preserved, always: wire name, input schema, handler body, business logic, visible effect, and the pages and auth states each tool is available on. Changed: the registration layer only — defineTool + registerTools — plus the single tracking field Connect writes at the entry-module seam.
• The developer's repo is the source of truth. Every tool this skill connects is derived from what is already in that repo or already registered in the running site; nothing is invented from an idea of what the tools should be.
• Connecting is not what starts network activity. The SDK's anonymous observations are on by default once it is installed; connecting is what makes those observations attributed to this site's account.

Hard rules

• Registration layer only. Never edit a handler, schema, endpoint, or UI effect to make a tool connectable. A tool that cannot be connected without changing its behavior is reported as such, not rewritten.
• Read-only until approved. Phases A–C touch no source file, add no dependency, and create no branch. The migration plan presented in Phase C is approved by the developer before any of the developer's files is written. That gate is the product, not a formality. Two named exceptions, and only these: the Phase-B baseline is written to .webmcp/connect-existing-tools/baseline.json — agent state, never the developer's code, and never part of the migration commit (the same .webmcp/ carve-out the implement skill takes); and Phase B invokes tools to capture samples — read-only ones freely, state-changing ones only against a positively confirmed isolated environment, per references/inventory.md. Phase A's browser pass inspects and never invokes.
• Byte-for-byte rollback. On skip or on any failure, every entry module and every tool module is left exactly as it was found. A half-migrated tree is never a terminal state.
• Named set, honest fallback. Automated migration covers native document.modelContext / navigator.modelContext registrations and @nekuda/webmcp-sdk — including its legacy aliases @agentlane/webmcp and @nekuda/webmcp, which are the same SDK. Any other SDK, and any tool whose defining source cannot be located, is inventoried and reported as needs manual migration. Never guess a rewrite.
• Identity is durable. A stableKey already present in source is immutable — a re-run adopts what it finds and never renames it. A derived key follows references/stable-keys.md, and anything ambiguous is put to the developer as an explicit decision recorded in source, never silently picked.
• Behavior is proven, not assumed. A tool is connected only when the post-migration inventory matches the pre-migration one on names, schemas, invocation results, errors, availability, and visible effects — and when a real invocation is observed arriving attributed. A connection-only tool (already on this SDK, nothing to migrate) has no before/after diff; it needs its route × auth-state registration matrix and one safe attributed call per recorded entry module. Default anonymous traffic is not proof.
• Local only. Source analysis stays on this machine. Never send the developer's code or routes to an external service, and never send anything to an unauthenticated tool. The optional Connect step sends only the CLI's structured project/account request; the separately approved publish step that follows it sends the approved tool descriptions and input schemas, and no handler body or credential.
• Developer-facing wording. In anything shown to the developer, never use the words mint, token, scope, telemetry, API key, or origin, and never echo CLI fields, error codes, or raw error prose. The banned scope is the OAuth sense; registration scope — this skill's own term for one entry module and the batches it registers — is the one carve-out, because the per-scope result this skill owes the developer (migrated, not attributed, per references/migration.md) cannot be stated without it; keep it out of progress messages and decision summaries. On a failure, say only that the connection did not finish, that the existing tools are unchanged, and that they may retry or skip. Beyond those words, lead with what the developer is trying to achieve, not implementation terms. Explain the SDK once as “the library that connects your tools to AgentLane.” Say “saved test results” for baseline, “checking that rerunning makes no extra changes” for idempotency, and “confirming activity appears in your account” for attribution. File paths, stableKey values, and other technical identifiers belong in the separate code-review details. Never expose sensitive values.