User-scoped API tokens for cross-project data access (MCP / agents)

A user in the Langfuse UI can open every project they belong to. The public API cannot do the same thing, because API keys are project-scoped and are not tied to a user.

From the RBAC docs:

API keys are associated with a project … They are not tied to a user.

That isolation is the right model for ingestion SDKs. It is a poor fit for agents, MCP clients, and CLI tools, where one identity should see what the human can see, then pick a project as an argument.

What I am asking for

A credential that represents the user (a personal access token, or equivalent), with these properties:

1. GET /api/public/projects returns every project that identity can access, not only the project the key was created in.
2. Trace, observation, prompt, dataset, and similar data APIs accept a projectId (or equivalent) and enforce that user's project-level RBAC.
3. The token cannot exceed the user's UI permissions. A Viewer token cannot write. A project-level role still applies.
4. Organization API keys stay admin-only. This is not a request to let org keys read traces or prompts.

GitHub's API is the shape I have in mind: one user token, endpoints take owner / repo. GitHub MCP can span orgs in a single stdio process for that reason. Langfuse MCP cannot, because there is no such token to put in the process environment.

What exists today

Public API docs show GET /api/public/projects with a project key returning that project. Org-key routes are provisioning, not observability. The official MCP server is explicit that each API key is scoped to one project, and it rejects org-level keys.

Workaround today: one MCP server entry (or CLI profile) per project, each with its own project key. That works. It does not give an agent a single "list my projects, then read this trace" loop, and the tool list multiplies with every extra server.

Related, but different

• Discussion #10605 already has people asking to switch Langfuse projects inside one agent session. The blocker is the credential, not the MCP tool list.
• Community avivsinai/langfuse-mcp#54 is named --profiles, still N processes. Useful local key store. Does not change Langfuse auth.
• #12738 is SSO / OIDC for MCP transport. Complementary. OIDC without a user-scoped data token still cannot list or read across projects.
• Discussion #16442 is OAuth so a third-party app can provision projects in the user's org. Also complementary. That flow is about creating resources, not about reading traces as the user.

Suggested shape

Not a design I expect you to ship as-is. Just to make the request concrete:

• User / PAT token, created in user settings, optionally limited to selected orgs or projects and to read vs write.
• GET /api/public/projects lists projects visible to that identity.
• Existing project data routes take projectId when auth is user-scoped, and keep today's implicit project when auth is a project key.
• MCP, CLI, and the public API all use the same token.

Happy to help test this against the official MCP server and a local stdio client.