Skip to content

Beans for mcplog, roots and others / need for session context? #205

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
maxandersen opened this issue Apr 10, 2025 · 2 comments
Open

Beans for mcplog, roots and others / need for session context? #205

maxandersen opened this issue Apr 10, 2025 · 2 comments
Labels
enhancement New feature or request

Comments

@maxandersen
Copy link
Member

currently I have to add McpLog on every method - couldn't that be field or constructor injected?

how about Roots (#204) could it be an injected bean which is kept uptodate based on events.

would be useful to have some client info available - have a session/request scope notion for MCP?

@mkouba
Copy link
Contributor

mkouba commented Apr 10, 2025

currently I have to add McpLog on every method - couldn't that be field or constructor injected?

Well, currently the MCP logger name (sent back to the client) is derived from the feature name, i.e. tool:myToolMethod. We could make the logger a @Dependent bean and derive the logger name from the declaring class but that's IMO less useful (esp. if you combine different features on one class). Also the internals would have to be rewritten a bit (not everything is now CDI bean).

how about Roots (#204) could it be an injected bean which is kept uptodate based on events.

I don't know about roots - need to read the spec first.

would be useful to have some client info available - have a session/request scope notion for MCP?

Yes, we could introduce the session context. However, for stdio a singleton/application scope serves the same purpose.

@maxandersen
Copy link
Member Author

Yes, we could introduce the session context. However, for stdio a singleton/application scope serves the same purpose.

yes sure, but the hope is that the same code can work equally well independent of the protocol used.

@mkouba mkouba added the enhancement New feature or request label Apr 10, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants