feat: add useWebMCPTools for tool collections - #7
Open
devteapot wants to merge 1 commit into
Open
Conversation
This was referenced Aug 27, 2026
MrSunshyne
added a commit
to MrSunshyne/vue-webmcp
that referenced
this pull request
Aug 27, 2026
A component that owns a group of tools registers them in one call, with enabled, annotations, exposedTo and onError shared across the group and per-tool options winning. defineWebMCPTool() is a typed identity helper so definitions can live in plain modules and keep their argument types and literal names. byName keeps the per-tool state; the group reports isRegistered when every tool is, and the first error. The plural name follows GoogleChromeLabs/use-webmcp-tool#7.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
useWebMCPTools(tools)hook for registering a collection of toolsuseWebMCP(options)backward compatible by delegating to the collection lifecycleexecute,formatOutput, andonErrorcallbacks without registration churnenabledflags and atomically roll back the batch if any registration failsAPI design and scope
Issue #3 originally suggests overloading
useWebMCPso it can accept either one tool or an array. This PR deliberately adds a dedicated plural hook instead:useWebMCPTools(tools). That keeps the existing single-tool contract unambiguous and backward compatible while avoiding calls to hooks in a loop.This is a hook-level ergonomic collection, not a new coarse-grained WebMCP definition mechanism. Every tool is still registered independently through
document.modelContext.registerTool; the hook only coordinates registration and cleanup for the supplied collection. A Provider is not required becausedocument.modelContextis already page-global.That distinction is intended to let this API coexist with any future coarse-grained tool-definition work. It also responds to the concern raised in the issue that a collection API might otherwise interfere with or become confusing alongside that broader design:
Lifecycle and performance tradeoff
The current implementation treats the supplied collection as one atomic lifecycle. Changing only
execute,formatOutput, oronErrorupdates the callback references without re-registering tools. Changing discoverable metadata for any tool re-registers the whole enabled collection.The atomic behavior keeps rollback and aggregate
registeredstate predictable, but it may introduce avoidable churn for collections of roughly 25–100 tools. A commenter on #3 noted unpublished benchmark findings around a 25-tool case: #3 (comment)If real-world measurements show that whole-collection registration is material, the internal implementation can move to per-tool metadata diffing without changing the public
useWebMCPTools(tools)API. Calling this tradeoff out here is intentional so maintainers can decide whether atomic batches or per-tool diffing better match the package direction before merging.Fixes #3.
Testing
npm test(30 tests passing)npm pack --dry-run