Problem
Server#resources_read_handler lets an application take over resources/read, but there is no equivalent for resources/list — the dispatch table binds it to the internal list_resources which paginates the constructor-provided @resources array (lib/mcp/server.rb:205-206, :1091-1095 at ref f0c9665).
This matters when the resource list depends on request context. In our production server the visible resources differ per request:
- authenticated vs anonymous sessions see different sets (real resources vs demo resources)
- OAuth-scoped connector sessions must see a scope-filtered list
Since the constructor array is fixed per Server instance, the workarounds are (a) construct a new Server per request (what we do — works, but makes servers non-reusable), or (b) subclass and override the private list_resources while temporarily swapping @tools-style state, which reaches into internals and is fragile across upgrades.
Proposal
A resources_list_handler(&block) symmetric to resources_read_handler, receiving server_context: (like the read handler does via handler_declares_server_context?), returning the resource array to paginate. Default behavior unchanged.
Context
We run the gem behind a Rails controller serving a production MCP surface (migrated from a hand-rolled implementation; the gem path is now live). Happy to contribute a PR if the direction is acceptable — related prior contribution: #493.
Problem
Server#resources_read_handlerlets an application take overresources/read, but there is no equivalent forresources/list— the dispatch table binds it to the internallist_resourceswhich paginates the constructor-provided@resourcesarray (lib/mcp/server.rb:205-206,:1091-1095at ref f0c9665).This matters when the resource list depends on request context. In our production server the visible resources differ per request:
Since the constructor array is fixed per
Serverinstance, the workarounds are (a) construct a newServerper request (what we do — works, but makes servers non-reusable), or (b) subclass and override the privatelist_resourceswhile temporarily swapping@tools-style state, which reaches into internals and is fragile across upgrades.Proposal
A
resources_list_handler(&block)symmetric toresources_read_handler, receivingserver_context:(like the read handler does viahandler_declares_server_context?), returning the resource array to paginate. Default behavior unchanged.Context
We run the gem behind a Rails controller serving a production MCP surface (migrated from a hand-rolled implementation; the gem path is now live). Happy to contribute a PR if the direction is acceptable — related prior contribution: #493.