A fuller MCP playground

Testing an authenticated MCP server used to mean wiring a client outside the console. The playground now covers server and tool navigation, request configuration, and result inspection inside the project environment you already selected.

This is the longer note behind the January 30 changelog entry.

How it works

McpPlayground is the unified auth-lab layout. You stay in the current project environment:

1. Pick a server, then a tool.
2. Configure the request (arguments, connection, subject).
3. Run the call with the environment's OIDC session.
4. Inspect the result, including errors from the server or auth probes.

Connection state, PKCE, and the stored MCP access header are environment-local. Unsaved playground config can be kept in console draft state (mcp-playground-config) so a refresh does not wipe the request you were editing.

The playground is not a substitute for the MCP runtime. Tool-call telemetry still lands as MCP_TOOL_* events when the SDK emits them.

Set it up

In the console, open the environment MCP playground:

1. Select a server that belongs to this environment.
2. Authenticate if the connection bar requires it.
3. Choose a tool, fill arguments, and run.

If the server lives in another environment, switch environment first. Do not paste an access token from a different issuer.

Trust boundaries

A successful playground call proves that this console session can invoke that tool on that server. It does not grant the same access to every agent identity in the trust store.

Do not point the playground at an arbitrary remote issuer. Authdog MCP probes stay on Authdog-owned OIDC discovery for the selected environment.

Try it

Run one tool against a non-production server and read the result panel. Background is on AI / MCP security. The original release note is in the changelog.