feat: add bulk registration methods for tools, resources, and prompts #847
+662
−5
Conversation
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
cameroncooke
force-pushed
the
main
branch
2 times, most recently
from
24662c8 to
eb95200
Compare
…ublic methods The _createRegisteredTool() method was calling setToolRequestHandlers() and sendToolListChanged() internally, which caused issues when registering tools after server connection due to capability registration restrictions. This moves the notification responsibility to the public registerTool() and tool() methods, making tool registration consistent and allowing registration after connection when capabilities have already been established. Fixes memory leak warnings caused by rapid tool registration after connection.
- Adds registerTools() method that accepts an array of tools - Registers all tools and sends only one list_changed notification - Prevents memory leak warnings when registering many tools - Uses same pattern as individual registerTool() method - Includes comprehensive test coverage This solves the GitHub issue where registering 80+ tools caused EventEmitter memory leak warnings due to multiple rapid notifications.
- Accepts array of resource configurations - Registers all resources with single notification - Supports both string URIs and ResourceTemplate objects - Consistent with existing registration patterns
- Accepts array of prompt configurations - Registers all prompts with single notification - Follows existing registration patterns - Comprehensive test coverage with notification validation
- Add early return for empty arrays to avoid unnecessary notifications - Add comprehensive tests for empty array edge cases - Addresses O3 feedback from code review
… registerTools Simplifies the registerTools() method signature to prevent TypeScript from attempting complex tuple type inference when registering large numbers of tools with complex Zod schemas. The simplified interface maintains full runtime safety through Zod validation while avoiding compile-time type complexity issues.
|
Would it be better to batch things with something a bit like the dataloader library, so that users don't have to worry about this and it just works if they batch register with the standard endpoints? EDIT: this video has good context about the architecture of dataloader: https://youtu.be/ld2_AS4l19g?si=3fyLtc8xbhreDGZy&t=541 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Adds bulk registration methods (
registerTools,registerResources,registerPrompts) to improve performance andreduce notification spam when registering large numbers of MCP components in a single operation.
Motivation and Context
When MCP servers need to register many components (e.g., 80+ tools), the current API requires individual calls that
each trigger separate
list_changednotifications. This creates performance issues and notification spam forclients.
Problems solved:
How Has This Been Tested?
Breaking Changes
None. This is a purely additive change. All existing
tool(),resource(), andprompt()methods workunchanged. The new bulk methods are optional enhancements.
Types of changes
Checklist
Additional context
Implementation notes:
ToolRegistrationinterface withunknowntypes to prevent TypeScript from attempting deepinference on complex schemas
list_changedevent after all registrations completeDesign decisions:
unknownoveranyto maintain type safety while preventing compilation issuesUse cases: