Repository navigation
Feature request: community projects section and guidance on identity/authorization for application-level servers #1313
Description
Is your feature request related to a problem? Please describe.
I maintain Foundgine, an open-source semantic execution layer with a Java version(the core is on Maven Central as io.github.cristianbarragan:foundgine-core). I looked for a place in this repo or its docs where JVM community projects around MCP are listed, and couldn't find one, so developers have no obvious way to discover existing servers, adapters and tools. I'm also unsure what the recommended approach is for servers that expose application-level capabilities, where authorization and caller identity come from the host application rather than from the MCP layer.
Describe the solution you'd like
- A "Community projects" section in the README or docs, where JVM servers, adapters and tools can be listed with a short description and link.
- A short documentation page on conventions for identity and authorization when a server exposes application capabilities, for example how the host application's identity should flow into tool calls, and where authorization should be enforced.
Describe alternatives you've considered
- Listing projects only in the official MCP Registry. That helps discovery across languages, but not for people browsing the Java SDK repo.
- Using GitHub Discussions on this repo for community showcases, if that is preferred over a docs page.
- Documenting the approach only on each project's own docs site, which doesn't help people who never find it.
Additional context
Foundgine lets an application define its entities, fields, relationships and capabilities once. Every request is resolved against the semantic model, authorized using the identity supplied by the host application, bound into a provider-independent execution plan, and executed. The same rules apply to every caller, including AI agents, so authorization logic isn't duplicated per entry point.
Activity
media-ctrl commentedon Nov 5, 2026
Both asks are reasonable and the second one is worth more than the first.
On the docs page: the gap is real because MCP defines transport-level authorization (OAuth on the HTTP transports) and says nothing about application identity. A tool call arrives as
params.argumentsplusparams._metawith no principal attached, so a server fronting a business system has to answer two questions itself: who is calling, and where authorization is enforced.A structure that covers the cases I have seen in production:
_meta, not at initialize, so one session can serve more than one user and a long-lived session does not pin the identity of whoever connected first._metais client-supplied and therefore unverified. A server either verifies it (signed assertion, or a lookup against the host's session store) or treats it as a hint and authorizes from a server-side mapping between the transport credential and the principal. Writing down which of those the SDK expects is the missing page.On the community list: the official registry solves cross-language discovery but not "what exists in this SDK's ecosystem". A
COMMUNITY.mdlinked from the README is enough for that, needs no per-entry review, and keeps the README short. The failure mode to avoid is a list with an inclusion bar that no maintainer has time to apply, because it then goes stale and stops being trusted.One addition worth considering while the docs are open: a short section on why a server should not accept an identity claim that travels through tool arguments. It is the obvious shortcut and it is indistinguishable from a client with a bug.
Kehrlann commentedon Nov 5, 2026
I agree that authorization should probably be improved, opened a targeted issue for: #1315
Other than that, we don't plan on promoting community projects.