Proposal: render
method for an MCP server
#1
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.
Currently, the design of the
McpServer
makes it easy to define servers whose resources/tools/prompts are static and known ahead of time:There's nothing stopping you from adding tools/prompts/resources after connecting, but it also doesn't broadcast
list_changed
events if you were to do so. So there's not really a good way to make a "dynamic"McpServer
without dropping down a level and building your own abstraction using aServer
.I've been looking for a neat API which can make these servers dynamic without needing a complete restructure of the class. This is the best I've come up with: adding the concept of a
render
function where the output is diffed to the previous version to emit change events:As written, the
render()
function could observe some external state to choose to hide/show/tweak aspects of the server, but I think it makes more sense ifrender
takes an argument:This feels like the most natural way to take the current API and make it dynamic, though there's plenty of alternatives.
Anyway, I thought I'd raise this as a draft PR to see if there was any interest in the API itself, before I finish it off. Currently it needs a smarter diffing algorithm (currently only looks for things being added/removed, but a change of description should probably fire an event too), as well as some tests.