MCP uses the same project model

MCP servers used to sit beside the rest of the console instead of inside the project and environment you already use for OIDC clients and hosted auth. Servers and tools now follow that same hierarchy, so navigation, client config, and the playground share one environment.

This is the longer note behind the March 29 changelog entry.

How it works

An MCP server is scoped to a project environment, not a parallel tree. Console navigation lists MCP next to the other environment modules. OIDC client and environment session settings used by authenticated tool calls are the same records other applications already use.

The playground is environment-bound: you pick a server and tool in the current project environment, attach the authenticated session for that environment, and inspect the request and result. It is a control-plane lab, not a public MCP endpoint.

MCP runtime events (MCP_TOOL_INVOKED, MCP_TOOL_DENIED, and related types) stay a different category from console-plane server CRUD.

Set it up

In the console, open a project environment that should host MCP:

1. Create or select the MCP server under that environment.
2. Confirm the OIDC client and environment config match the app that will call tools.
3. Open the playground, authenticate, and invoke a tool.

Do not point the playground at a different environment's issuer and expect the same client to work.

Trust boundaries

Sharing a project model does not share user stores across environments. Each environment keeps its own users, keys, and MCP servers. A playground call uses the credentials you attached in that environment.

A published MCP server is not the same object as an agent identity in the trust store.

Try it

Open MCP on an environment you already use for hosted auth and run one authenticated tool call. Background is on AI / MCP security. The original release note is in the changelog.