Doppler MCP Server

by signalford

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation4/5
Tools are largely distinct by resource type (secrets, projects, configs, environments) and action (get, list, set, delete, create). The only minor overlap is doppler_run which touches secrets, but its purpose of injecting into a command is clearly distinct from directly getting secret values.
Naming Consistency5/5
All tools follow a consistent doppler_<resource>_<action> pattern (e.g., doppler_secrets_get, doppler_projects_list, doppler_configs_create). This is uniform and predictable across all 11 tools.
Tool Count4/5
11 tools is within the ideal 3-15 range and covers the core Doppler surface reasonably. A few related actions appear grouped (e.g., get/list/set/delete for secrets) which is appropriate. Not excessive or too thin for a secrets management server.
Completeness3/5
Secrets have full CRUD coverage (get, list, set, delete) which is good. However, there are notable gaps: no ability to update/delete configs or projects, no way to list roles/members, and doppler_run is useful but projects/configs lifecycle is incomplete (create exists but no delete or update).
Average 3/5 across 11 of 11 tools scored. Lowest: 2.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden of behavioral disclosure. It doesn't state whether config/project are required when doppler setup hasn't been run, what happens for missing secrets (error vs empty), or whether the value is sensitive/redacted. This is a secrecy-sensitive read tool with zero behavioral detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no wasted words. It's appropriately brief and front-loaded, but arguably under-specified rather than concisely complete. Not verbose, but also conveys almost nothing beyond the name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a security-sensitive read tool with no output schema and no annotations, the description is incomplete. It doesn't explain return value format, behavior with missing config/project, permission requirements, or error cases. Sibling tools (set/delete) and the secrets-domain context demand more behavioral detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. However, the description adds nothing beyond the schema. The schema documents name/config/project but the description provides no additional context about how project/config interplay works (e.g., when you must supply them vs rely on setup), nor clarifies the required parameter. Slight deduction for adding zero value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get a secret value from Doppler' uses a clear verb (get) and resource (secret value). It distinguishes the read operation from siblings like doppler_secrets_set and doppler_secrets_delete, though it doesn't explicitly name them or contrast. Basic purpose is clear but minimal.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this vs alternatives, no prerequisites mentioned, and the schema hints at optional project/config but no clarity on when setup is needed. The description gives no usage context or exclusions. An agent has to infer from the schema what context is required.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It doesn't mention that listing secrets may expose sensitive values, whether output is masked/redacted, rate limits, or what happens when config/project aren't set. For a security-sensitive secrets tool, the lack of disclosure about sensitive value exposure is a notable gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, zero waste. The description is efficient and front-loaded with the verb. Could arguably add a bit more context but the brevity is appropriate for a simple list operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a list operation with no output schema, no annotations, and 2 optional params. For a secrets-listing tool, the description should clarify whether the output includes secret values (sensitive) or just names, and how config/project resolution works when not set. These gaps matter for an agent deciding whether to call this tool and how to handle the result safely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters are documented in the schema itself. The description doesn't add any parameter-specific meaning beyond what the schema provides. Both params are marked optional with fallback to doppler setup, which is captured in the schema. Baseline 3 is correct when schema does the heavy lifting and description adds no extra context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all secrets in a Doppler config' uses a clear verb (List) and resource (secrets in config). It distinguishes from get/set/delete but is generic about scope—doesn't specify whether it returns all values/keys or requires auth. It's adequate for listing but lacks distinctions like whether this returns secret values vs just names, unlike a sibling comparison.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No indication of when to use this vs doppler_secrets_get specifically. It distinguishes from get/set/delete by being 'all secrets' vs individual, but there's no explicit statement of when to prefer this tool, no alternative naming, and no mention of whether secrets are decrypted or masked. Little guidance beyond the obvious reading.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It says 'Create' which implies mutation, but doesn't state whether this requires authentication, whether it requires the project and environment to exist first, the failure modes (e.g., duplicate config names), or the return value. For a creation tool with zero annotations, more disclosure is warranted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no waste. It's front-loaded and efficient. However, it is somewhat under-specified, which means conciseness is achieved through brevity rather than through rich, well-structured detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a creation tool with no annotations and no output schema, the description does not explain return value, error conditions (like name collisions), or prerequisite state (existing project/environment). The complexity is low (3 plain string params), but the missing behavioral contract for a mutation tool leaves completeness lacking.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and all three parameters (name, project, environment) have descriptive schema entries. The description adds no parameter-specific detail beyond what the schema provides. Baseline 3 is appropriate given the schema fully documents each parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description states a clear verb+resource: 'Create a new config in a Doppler project.' It clearly distinguishes itself from the configs_list sibling (which reads) and the projects_create sibling (which creates a different resource type). However, it could more explicitly note the config is an environment-scoped entity within a project.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as doppler_projects_create (create the project first) or the configs_list tool. No mention of prerequisites like requiring an existing project and environment. The description doesn't specify when creating a config is appropriate or what precedes it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It's a read-only listing operation, but the description doesn't state the return format, whether pagination is involved, whether it requires a prior 'doppler setup' for the optional project parameter, or what happens when no project is provided. The description is too thin to disclose behavioral traits beyond the obvious 'list all' semantics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with zero wasted words. It's appropriately sized for what appears to be a simple list tool. While it could add more detail, the brevity is not a structural flaw given the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with one optional parameter and no output schema, the description is mostly adequate, but it lacks details about return format, behavior when project is not set (relying on doppler setup), and relationship to environments/config types in Doppler. Given the tool has no annotations and no output schema, the description is expected to carry more weight than it does.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single 'project' parameter, so the baseline is 3. The description does mention 'in a Doppler project' which loosely maps to the project parameter, and the sibling tool doppler_configs_create helps infer context. The parameter is optional and the schema already documents it well, so the description adds marginal value but doesn't need to compensate much.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all configs in a Doppler project' has a specific verb+resource (list configs) and clearly identifies the scope (all configs in a project). It distinguishes from siblings like doppler_configs_create and doppler_secrets_list by making clear it's about configs, not secrets. However, it's fairly brief and doesn't specify what a 'config' means in Doppler terminology, though that's a minor gap.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. There's no mention of when listing configs is appropriate, what scenarios call for it, or any exclusions. The sibling list includes similar listing tools like doppler_projects_list and doppler_environments_list, and this description doesn't help the agent distinguish when to choose configs_list over those.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states what the tool does but reveals nothing about output format, pagination, error behavior, auth requirements, or side effects. For a list operation with zero annotation coverage, more behavioral disclosure would be expected.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One concise sentence with zero waste. Front-loaded and direct. Could arguably earn a 5, but the brevity trades away potentially valuable context that a fuller description could provide.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (1 param, 0 required) and the schema covers the parameter fully, which helps. However, the distinction between environments and configs in Doppler's model is non-obvious, and with no output schema and no annotations, a bit more context would make this genuinely complete. The single line leaves meaningful gaps for a tool in a family with several similar list commands.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% — the 'project' parameter is documented as 'The Doppler project name (optional if set via doppler setup)'. The description adds nothing beyond the schema, so baseline of 3 applies since the schema already documents the single parameter fully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb+resource: lists environments in a Doppler project. The scope ('all environments in a project') is specific, though it doesn't distinguish from siblings like configs_list — configs and environments are related Doppler concepts, and the description gives no hint about the difference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this vs alternatives. Among siblings are doppler_configs_list and doppler_projects_list; the description doesn't explain what an 'environment' is relative to a config or when one would need it. No when/when-not guidance provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The description doesn't mention whether project creation requires authentication, whether duplicate names are allowed, whether creation is idempotent, or what the response/return value looks like. As a mutation tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is an efficient single sentence with zero wasted words. It's appropriately minimal, though it could arguably add one sentence of behavioral context without hurting conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a creation/mutation tool with no annotations and no output schema, the description is thin. It doesn't explain outcomes, return format, side effects, or how this relates to other sibling tools. The 100% schema coverage and 2 simple parameters lower the bar, but for a write operation more behavioral context would materially help.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (both name and description parameters are documented in the schema). The description adds no parameter-specific meaning beyond what the schema provides, so the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a new Doppler project' has a clear verb+resource structure and clearly indicates what the tool does. It distinguishes from sibling tools like doppler_projects_list (which lists projects) but doesn't explicitly call out the differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool vs alternatives, such as when to use doppler_configs_create or doppler_environments_list. There are no exclusions, prerequisites, or context about where projects fit in the Doppler hierarchy.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full behavioral disclosure burden. 'Delete' implies mutation/destruction, but the description doesn't state whether deletion is permanent, whether it requires special permissions, what happens on failure (e.g., non-existent secret), or the return format. For a destructive operation with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence with zero waste. It's front-loaded with the action verb and resource. Very concise, though the availability of such brevity comes at the cost of behavioral transparency depth.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a destructive mutation tool with no annotations and no output schema, putting burden on the description. With a 3-parameter tool and mutation semantics, the description should communicate permanence, permission requirements, and error behavior. The current description only states what it does, not what the agent should expect or verify before invoking. Highly incomplete for a destructive operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (all three parameters have descriptions), so the schema already documents the parameters. The description adds no parameter-specific meaning beyond the schema. However, the schema notes project/config are optional 'if set via doppler setup' which provides useful context. Baseline 3 is appropriate since the schema fully covers parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete a secret from Doppler' has a clear verb (delete) and resource (secret in Doppler), which is specific and unambiguous. It doesn't explicitly distinguish from its sibling `doppler_secrets_set` or `doppler_secrets_get`, but the verb 'delete' is self-evident in purpose. A modest improvement would be noting the mutation aspect or scope, but the core purpose is clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like doppler_secrets_set or doppler_secrets_get. The description doesn't mention that deletion is destructive or irreversible, nor does it note the optional project/config context requiring doppler setup. There are no exclusions, prerequisites, or caveats about failed deletions (e.g., deleting a non-existent secret).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The description does not state side effects (overwrites existing secrets?), auth requirements, environment interplay (which config does it target?), or reversibility. For a mutation tool with zero annotations, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single concise sentence with no waste. However, at only 7 words, it borders on under-specification rather than conciseness, though for a simple tool it's acceptable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is thin. It does not explain overwrite behavior, config targeting defaults, post-set verification options, or prerequisites. The 4-parameter schema is fully covered but the tool's operational context is largely unexplained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 4 parameters. The description adds nothing beyond the schema—it doesn't clarify optionality nuances (e.g., what happens if config/project are omitted), value format, or interaction between parameters. Baseline 3 is appropriate when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Set a secret value in Doppler' uses a specific verb (Set) + resource (secret value in Doppler). It clearly distinguishes from siblings like doppler_secrets_get/list/delete, though it doesn't explicitly contrast them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus the alternatives. It doesn't mention prerequisites like doppler setup, whether config/project are required, or any caveats about which config the secret applies to. Some context is implied (it's the write counterpart to get/list), but no explicit guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The description fails to mention that secrets are exposed to the subprocess as environment variables (a security-relevant behavior), how the exit code propagates, whether it streams output, or what happens if secrets/credentials are missing. For a command-execution tool with zero annotation coverage, more behavioral context is expected.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence with zero waste. It is appropriately sized and front-loaded. It could arguably add a bit more behavioral detail, but as written it is efficient and to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
A tool that executes arbitrary commands with injected secrets is high-stakes, yet the description provides minimal context. Given no output schema and no annotations, the description should carry more weight: it doesn't explain what happens on successful/failed runs, exit code semantics, whether output is streamed, key format conventions for env vars, or fallback behavior. This is under-specified for a command execution tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all three parameters. The description adds no additional parameter-level meaning beyond what the schema provides. The command parameter description and config/project descriptions in the schema already cover the semantics, so the description adds little value here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb+resource ('Run a command with Doppler secrets injected as environment variables'). It clearly differentiates this from sibling tools: the secrets_* tools get/list/set/delete secrets, while doppler_run actually executes a command with those secrets as env vars. This is distinct from the rest of the tool family.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies it is used when you want to execute a command with secrets available as environment variables, which distinguishes it from the secrets management tools. However, it does not explicitly state when not to use it, nor mention the dependency on project/config being setup (implied via 'optional if set via doppler setup'), nor alternative non-Doppler approaches.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It doesn't state whether this tool verifies authentication validity, what happens with an invalid/expired token, whether it makes network calls, or what level of detail about the user is returned. For a tool that is effectively an auth-check/identity endpoint, this is thin disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, zero waste. Every word earns its place. For a zero-parameter tool, this is the appropriate length—there is nothing more to say about parameters or invocation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 0 parameters, no output schema, and no annotations, the tool is simple enough that the short description is largely adequate. However, because there's no output schema or annotations, some disclosure about what identity fields are returned (email, name, org roles, etc.) and auth failure behavior would strengthen completeness for a tool serving as an auth-context operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has 0 parameters, and schema description coverage is 100% (the schema has no properties). With no parameters to document, the baseline of 4 applies—there is nothing the description needs to add, and the empty schema is correct. No param semantics gap exists.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clear specific verb (Get) + resource (information about current authenticated Doppler user). Distinguishes itself from siblings which all target specific resources like secrets, projects, configs, and environments. A 'me' pattern is recognizable from similar authed-user endpoints in other APIs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The purpose implies it should be used to identify the current user or verify auth state, but there is no explicit when-to-use guidance. With 10 sibling tools dedicated to specific resources, there's no stated exclusion like 'use this to obtain user identity before calling other tools' or instructions about auth prerequisites for other functions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. However, 'list' is inherently a read-only operation, which is reasonably transparent. The description doesn't clarify whether results are paginated, ordered, or what the response format looks like, but for a simple list operation this is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single concise sentence that fully captures the tool's purpose with zero waste. Highly front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, simple read/list tool with a clear name and no output schema or nested objects, the description is adequately complete. The complexity is low enough that the minimal description suffices. It may not state return format, but for a simple list operation this is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero parameters and schema coverage is 100%, meaning everything about parameters is already fully specified by the absence of parameters. The description adds nothing about parameters, but there are none to document, so the baseline of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb+resource pattern ('List all Doppler projects'). It clearly states the operation (list) and resource (projects). However, it doesn't distinguish from sibling tools that list other resources (configs, environments, secrets) — though the resource names differ and are fairly self-evident from the tool names.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it (when you need a listing of projects), but provides no explicit guidance on when NOT to use it or which alternative tools might fit better. No filtering, pagination, or context hints are mentioned. It's minimally adequate but lacks explicit alternative/exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![mcp-doppler MCP server](https://glama.ai/mcp/servers/signalford/mcp-doppler/badges/card.svg)](https://glama.ai/mcp/servers/signalford/mcp-doppler)

Score Badge

Copy to your README.md:

[![mcp-doppler MCP server](https://glama.ai/mcp/servers/signalford/mcp-doppler/badges/score.svg)](https://glama.ai/mcp/servers/signalford/mcp-doppler)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/signalford/mcp-doppler'

If you have feedback or need assistance with the MCP directory API, please join our Discord server