jerryshao opened a new issue, #12953:
URL: https://github.com/apache/gravitino/issues/12953

   **What would you like to be improved?**
   
   The MCP server takes a single metalake at startup (`--metalake`, a required 
field on `Setting.metalake`) and every tool call resolves against that one 
metalake for the lifetime of the process. An installation with more than one 
metalake needs one MCP server process per metalake, or has to accept that 
agents can reach only one of them.
   
   This is inconsistent with the rest of Gravitino: the REST API takes the 
metalake per request in the path, and authorization filters what the caller may 
see there. The MCP server is the only interface that fixes it at startup.
   
   **How should we improve?**
   
   Resolve the metalake per request instead of once at startup, without 
introducing a session/connection-level "declare and remember" mechanism — that 
would only be safe for a single-process deployment and wouldn't extend cleanly 
to running the server as multiple replicas.
   
   Concretely:
   - For HTTP transport, resolve the metalake from a request header (e.g. 
`X-Gravitino-Metalake`), the same way the server already resolves the caller's 
identity per request from the `Authorization` header (see 
`_get_request_authorization()` / `rest_client()` in 
`mcp_server/core/context.py`). This needs no server-side state — any process 
can resolve any request independently, so it stays correct regardless of how 
many replicas the server runs as.
   - For stdio transport, keep today's behavior: one process is one client, so 
`--metalake` at startup remains the source of truth; switching metalake means 
starting another process with a different `--metalake`.
   - Fall back to the configured startup default when no header is present; 
return an error naming the missing argument when neither is available.
   - Authorization is unchanged — the caller's token already determines what 
they may see, so a metalake selected via the header is authorized exactly as 
the same request would be through the REST API.
   
   A tool that returns the metalakes the caller is authorized to use would help 
agents discover what's available rather than being told out of band, but that's 
a separate, independent addition.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to