# Doppler MCP MCP

> Doppler MCP handles secrets management and environment variables directly from your AI agent. It lets you audit project structures, view current config settings (dev, staging, prod), read specific secret values with fallbacks, and track every change that happens in a secure conversation. Manage all your sensitive data without opening the Doppler dashboard.

## Overview
- **Category:** loved-by-devs
- **Price:** Free
- **Tags:** secrets-management, environment-variables, doppler, api-keys, config-management

## Description

You connect your secrets management system to your AI agent and manage everything through natural language. Instead of navigating dashboards and clicking through dozens of tabs just to check an API key or see who changed the database URL, you talk to your agent. Your agent handles all the heavy lifting: listing every project workspace, viewing environment templates for a specific config, and even showing you the full audit log of who read which secret last week. Because sensitive credentials pass through Vinkius's zero-trust proxy, your keys never sit on disk; they are only used in transit during the call. This means you get to manage complex environments—from listing all workspaces down to updating a single secret value—with full conversational control and high security.

It’s about treating your AI agent like a dedicated secrets engineer. You ask it to list all configs for `backend-api`, then ask for the `DATABASE_URL` in the 'prod' environment, and finally ask who changed that credential last month. The whole process is handled without you ever touching the UI.

## Tools

### change_secrets
Adds or updates secret values for a specific project configuration.

### delete_secrets
Removes defined secrets from a specified project configuration.

### get_account
Verifies the current Doppler account details, including token scope and permissions.

### get_config
Retrieves metadata for a specific deployment environment configuration.

### get_project
Fetches general details about an entire Doppler project, given its slug.

### get_secret
Reads and returns the computed value of a specific secret name from an environment.

### list_activity_logs
Shows a detailed, auditable history of all secret reads, writes, and configuration changes.

### list_configs
Returns a list of all environment configurations (like dev or prod) for an entire project.

### list_environments
Lists the available types of deployment environments in your account.

### list_projects
Retrieves a list of all projects and their creation dates across workspaces.

### list_secrets
Lists the names, computed values, and visibility status of all secrets within a config.

### list_workspaces
Provides a list of top-level organizational workspaces that contain multiple projects.

## Prompt Examples

**Prompt:** 
```
Show me all configs for my 'backend-api' project.
```

**Response:** 
```
I found 3 configs for 'backend-api': 'dev' (development, root config), 'staging' (staging, inherits from dev) and 'prod' (production, inherits from staging). Each has its own set of secrets.
```

**Prompt:** 
```
Update the DATABASE_URL secret in my prod config to point to the new database.
```

**Response:** 
```
Done! I've updated the `DATABASE_URL` secret in the prod config of your backend-api project. The new value has been applied and will be available to all services using this environment.
```

**Prompt:** 
```
Who changed secrets in my project in the last week?
```

**Response:** 
```
I found 14 activity events in the last 7 days: 3 secret updates by alice@company.com, 8 secret reads by the CI/CD service account, 2 config changes by bob@company.com and 1 new secret added by admin@company.com.
```

## Capabilities

### List organizational units
Retrieves a list of all workspaces and projects grouped by those workspaces.

### Audit environment configurations
Lists all available environments (like development, staging, or production) for a given project.

### Review secret values
Fetches the current value of any specific secret, automatically resolving fallbacks from parent environments.

### Manage environment secrets
Adds, updates, or deletes credentials across defined project configurations in an atomic request.

### Track activity logs
Generates a detailed audit trail showing exactly who performed which action and when it happened.

## Use Cases

### Auditing credential access
A security auditor needs to know if the CI/CD service account read the payment gateway key last night. They run `list_activity_logs` and immediately see a record showing the exact time, who accessed it, and what config was affected.

### Verifying deployment setup
A developer is setting up a new service and needs to know if the production environment has all the required API keys. They run `list_secrets` for 'prod' and verify that every necessary credential, like the Stripe key, exists.

### Onboarding a new team member
A manager needs to show a new hire the full organizational structure of services. They ask the agent to run `list_workspaces` and then drill down using `list_projects` to map out all active components.

### Emergency credential rotation
A secret is compromised, and it needs immediate updating. The engineer uses `change_secrets` to push the new value for the master API key into the production config across all necessary environments.

## Benefits

- Eliminate manual lookups: Use `get_secret` to pull a specific credential value—like the database URL—and see it instantly, including fallbacks from parent configs.
- Maintain compliance records: Run `list_activity_logs` whenever you need proof of who read or modified a secret and when. This is essential for security audits.
- Structure verification: Use `list_projects` and `list_workspaces` to quickly map out your entire credential topology, seeing which projects belong where.
- Control changes: Need to update an API key? You can use `change_secrets` to add or modify a secret in a specific environment without touching the UI.
- Clean up resources: If a project is deprecated, you can run `delete_secrets` to remove credentials and prevent orphaned data.

## How It Works

The bottom line is that your AI agent uses your credentials through Vinkius's secure layer to perform complex operations across multiple resource types without needing any UI interaction from you.

1. Subscribe to this MCP and provide your Doppler Service or Personal Token.
2. Tell your AI agent what you need—for example, 'List all projects in the billing service.'
3. Your agent executes the necessary calls, returns the requested data (like a list of project slugs), and presents it back to you in conversation.

## Frequently Asked Questions

**How do I create a Doppler Service Token?**
Log in to the [**Doppler Dashboard**](https://dashboard.doppler.com), select your project, go to **Settings** > **Tokens** and click **Generate Token**. Choose the scope (project + config/environment), set the access level (Read or Read+Write) and copy the token immediately — it won't be shown again.

**Can I update multiple secrets at once?**
Yes! Use the `change_secrets` tool with a JSON object mapping names to values, e.g. `{"DATABASE_URL":"postgres://new-host","API_KEY":"sk-new"}`. This creates or updates all specified secrets in a single atomic operation.

**What is the difference between a Personal Token and a Service Token?**
A **Personal Token** is scoped to your user account and can access all workspaces and projects you have permission for. A **Service Token** is scoped to a specific project and config, with either read-only or read+write access. Service tokens are recommended for CI/CD and automated integrations, while personal tokens are better for development and admin tasks.

**Can I view the activity history for a project?**
Yes! Use the `list_activity_logs` tool with the project_slug to see all audit events (secret reads, writes, config changes, user additions). Optionally filter by config_name to see activity for a specific environment only. Each log entry shows who performed the action, when, and what was affected.

**When should I use `list_projects` versus `get_project`?**
Use `list_projects` to see all available projects within a workspace. If you already know the project slug, then using `get_project` provides instant details on that specific container. This helps your agent scope down immediately before querying internal configs or secrets.

**How does the `get_secret` tool handle environment fallbacks?**
The agent automatically resolves secret values using defined environment fallbacks. If a required secret value is missing in the current config, it checks parent environments until a value appears or confirms that no value exists anywhere.

**What information do I get from `list_environments`?**
This tool returns a list of all configured deployment environments, such as development, staging, and production. It's key for your agent to confirm the exact scope you need before running operations like viewing secrets or making changes.

**What is the critical warning when using `delete_secrets`?**
Deleted secrets cannot be recovered, so always verify the names first. Furthermore, if a secret inherits its value from a parent environment, deleting it will make the current config revert to that parent's inherited state.