MCP agent provisioning and dynamic clients

Standing up a project and an OIDC client by hand blocks agent-driven setup. Agents can now provision and inspect Authdog projects directly, and MCP servers register OIDC clients dynamically instead of waiting for a console click.

This is the longer note behind the July 19 changelog entry.

How it works

The first provisioning tools are intentionally small:

• whoami — inspect the authenticated caller
• list_tenants — see workspaces the caller can reach
• list_projects — list projects in those workspaces
• create_project — provision a project from the agent session

MCP servers can register OIDC clients dynamically, so a new server does not require a separate manual client create step before it can talk OIDC. The MCP OIDC flow and the playground used to test connections were hardened at the same time.

The playground still lives under MCP Auth for MCP project types: connect with SSO to mint a short-lived bearer for the environment, then import tools. Tokens stay scoped to the selected environment — use dev while iterating.

Later management tools (user search, environment CRUD, get_public_key) build on this provisioning set. They are a separate release.

Set it up

1. Authenticate the agent and call whoami. Confirm tenant scope before you create anything.
2. Call list_tenants and list_projects to see what already exists.
3. Use create_project when you need a new project rather than reusing one.
4. Let the MCP server register its OIDC client dynamically instead of creating a client by hand.
5. Open MCP Auth playground on that project and test the connection in a non-production environment.

Create MCP projects from the console as well: Projects → MCP server. After registration, clients and scopes still appear under Authentication, and allowed agents under Agents.

Trust boundaries

create_project is a write. list_tenants and list_projects expose workspace layout. Scope the agent to the tenants it should see, and keep unverified agent identities out of production.

Dynamic client registration removes a manual step. It does not remove redirect, secret, and grant review. Treat a newly registered client as untrusted until you have checked its redirect URIs and scopes.

Playground tokens are short-lived bearers for testing. Do not reuse them as long-lived automation credentials. Hardened OIDC on the MCP path is still OIDC: validate issuer, audience, and expiry on the server.

Try it

Call whoami, list projects, then create one in a development tenant and test it in the MCP playground. Background: MCP security and MCP servers. The original release note is in the changelog.