Repository navigation
Add Primitive repository APIs (ResourceRepository, ToolsRepository, ... ) #578
Description
Currently, McpStatelessAsyncServer and McpAsyncServer save resources, tools, prompts, and completionswithCopyOnWriteArrayList`.
I want to provide an API (for example, ResourcesRepository) that, by default, uses the current in-memory strategy but can be replaced, for example, by a dynamic implementation that returns a different list of resources depending on the currently authenticated user.
Reacted by Nick Caballero
Activity
chemicL commentedon Oct 2, 2025
I believe the repository-oriented design should be able to address the needs expressed in #593 (comment). If we can unify these ideas in this issue we could close #593 and make progress designing a comprehensive solution with this issue. @tzolov, @sdelamo WDYT?
hbsjz-swl commentedon Oct 9, 2025
@sdelamo @chemicL
hi, I think these problems are essentially the same type of problems that the org.springframework.ai.mcp.McpToolUtils.prefixedToolName(String prefix, String title, String toolName) method in the SpringAI project solves. They are all about how to manage tools by grouping them so that the MCP client can more intelligently heuristically call tools among a large number of tools, first calling the tool group and then calling the specific tool.
https://github.com/spring-projects/spring-ai/blob/main/mcp/common/src/main/java/org/springframework/ai/mcp/McpToolUtils.java
ultramancode commentedon Jan 13, 2026
Hi! @sdelamo @chemicL Could you take a look at my pr (#747)? I think it’s closely related to this issue, and I’d really appreciate any feedback.
chemicL commentedon Feb 20, 2026
More requirements are described in #746, which I closed as a duplicate but should keep in mind when implementing this.
bcersows commentedon Feb 23, 2026
As all the related tickets seem to have been closed, I want to throw in one requirement that we at our company need; we've implemented a dynamic tool approach depending on some header field in the
tools/listrequest. So a repository-based approach would be great, but also on a per-request basis.ultramancode commentedon Feb 24, 2026
@chemicL
Hi! After #746 was closed as a duplicate of this issue, I’d like to confirm the direction.
I put together PR #747 as an early attempt at the ToolsRepository portion (repository abstraction, per-request filtering, and cursor pagination).
Does this approach align with the direction you’re aiming for here? If not, I’m happy to adjust it accordingly.
If it does, I’d be glad to help with the remaining work via follow-up PRs.
tim-schneider-elo commentedon Mar 23, 2026
Any updates on when this feature will be addressed and will be available?
15 remaining items
ultramancode commentedon Aug 26, 2026
I’ve closed #953 and #1034 in line with the updated direction here.
If there’s a useful piece I can contribute to when the 3.x repository work starts, I’d be glad to help.
Add ttlMs and cacheScope to cacheable result records (SEP-2549)
Add ttlMs and cacheScope to cacheable result records (SEP-2549)
Add ttlMs and cacheScope to cacheable result records (SEP-2549)
ujibang commentedon Sep 8, 2026
A concrete case for the per-client half of this, from a server built on the SDK.
RESTHeart derives MCP resources from MongoDB collections and GraphQL applications. Two things we wanted to do turned out not to be expressible against a server-wide registry:
A schema that differs per caller. We added a
@visible(roles: [...])directive to our GraphQL apps: a field the caller's roles do not name is removed from the schema they see, so introspection does not reveal it exists. We wanted the resource description in the catalog to carry the same role-filtered schema. It cannot:resourcesis one registry for the whole server, so the description we register is the one every client gets. Publishing the unfiltered schema there would have revealed exactly what the directive removes, so we left the schema out of the catalog entirely and point clients at GraphQL introspection instead — which does answer per caller.A catalog that reflects what the caller may read. Reads are authorized per principal (a resource read is checked as the equivalent REST
GET), so a client can see catalog entries it will be refused. That is a deliberate trade on our side, not a complaint — but with a repository API it would be a choice rather than a constraint.Both would be covered by the interface proposed here, provided the lookup receives the exchange (i.e. the authenticated identity), not just a key.
One adjacent note, since it comes up in the same place: #746 was closed as a duplicate of this issue, but it also asked for cursor-based pagination, which this issue does not cover — the server-side list handlers ignore
cursorand never setnextCursor. Filed separately as #1128, so it does not get lost again.Add a stateless server for MCP 2026-07-28
Add a stateless server for MCP 2026-07-28
Modern stateless server for MCP 2026-07-28 (#1170)
Kehrlann commentedon Nov 12, 2026
Covered by #1170 ; we'll improve this with #1200