Skip to content
verify mcp Beta VerifyMCP is currently in beta. If you notice any issues, get in touch and we’ll put it right.

com.mcparmory/launchdarkly

OCI · GHCR.IO/MCPARMORY/LAUNCHDARKLY:1.0.4 · 2 COMPONENTS · SCANNED SEP 21

Manage feature flags, segments, projects, environments, and team members

0 this week 49 Trust /100
Trust breakdown (7 categories)

How this component scores in each security and reliability category. Every signal is checked automatically from public evidence about the published package, including repeated runs of it in an isolated sandbox, and we only credit what we can confirm. How we score → Why this is hard to score →

Supply Chain Security0
  • Malware scan not yet available for this package.Unverified
  • Known CVEs could not be checked: this artifact ships no SBOM, so there is no dependency list to read. Publishing one would let us assess it.Unverified
  • Install-script risk not yet assessed.Unverified
  • Dependency health could not be checked: this artifact ships no SBOM, so there is no dependency list to read. Publishing one would let us assess it.Unverified
Provenance & Transparency32
Schema Quality & AI Usability73
  • AI-judged instruction clarity (excellent).Pass
  • Context-footprint check failed: tool/resource definitions use about 36460 tokens (~133/item across 274 items; 274 tools + 0 resources), over budget; trim descriptions and params. See how to fix → Fail
  • Usage-examples check failed: none of the tools include examples. See how to fix → Fail
Stability & Change Management83
  • Stability observed for 25 of 30 days with no destabilising changes; credit accrues until the full window elapses.Partial
Tool Coverage100
  • 100% of tools have a non-trivial description (not blank, and not just the tool's name).Pass
  • 100% of tool parameters carry a description.Pass
Tool Safety100
  • No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.Pass
  • All 43 tool(s) whose name or description implies an irreversible operation declare an MCP destructiveHint annotation.Pass
  • An AI judge read all 274 captured unit(s) of tool text and found none that tries to manipulate the model reading it.Pass
Capabilities100
  • Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28.Pass

Unverified: 1 category

A category scored 0 because we could not verify it: a data source with nothing on this package, evidence we could not reach, or a check we could not run. We only credit what we can confirm.

Install

How do I install the com.mcparmory/launchdarkly MCP server?

com.mcparmory/launchdarkly runs locally as a container image, launched with docker run --rm -i ghcr.io/mcparmory/launchdarkly:1.0.4. Ready-made configuration for Claude, Cursor, VS Code, Codex and 3 more is on this page, copied from each client's own documentation.

oci · ghcr.io/mcparmory/launchdarkly:1.0.4

# add to Claude Code
claude mcp add com-mcparmory-launchdarkly -- docker run --rm -i ghcr.io/mcparmory/launchdarkly:1.0.4
// .cursor/mcp.json
{
  "mcpServers": {
    "com-mcparmory-launchdarkly": {
      "command": "docker",
      "args": [
        "run",
        "--rm",
        "-i",
        "ghcr.io/mcparmory/launchdarkly:1.0.4"
      ]
    }
  }
}
// .vscode/mcp.json
{
  "servers": {
    "com-mcparmory-launchdarkly": {
      "command": "docker",
      "args": [
        "run",
        "--rm",
        "-i",
        "ghcr.io/mcparmory/launchdarkly:1.0.4"
      ]
    }
  }
}
# add to Codex CLI
codex mcp add com-mcparmory-launchdarkly -- docker run --rm -i ghcr.io/mcparmory/launchdarkly:1.0.4
// opencode.json
{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "com-mcparmory-launchdarkly": {
      "type": "local",
      "command": [
        "docker",
        "run",
        "--rm",
        "-i",
        "ghcr.io/mcparmory/launchdarkly:1.0.4"
      ],
      "enabled": true
    }
  }
}
# ~/.hermes/config.yaml
mcp_servers:
  com-mcparmory-launchdarkly:
    command: "docker"
    args: ["run", "--rm", "-i", "ghcr.io/mcparmory/launchdarkly:1.0.4"]
// ~/.netclaw/config/netclaw.json
{
  "McpServers": {
    "com-mcparmory-launchdarkly": {
      "Transport": "stdio",
      "Command": "docker",
      "Arguments": [
        "run",
        "--rm",
        "-i",
        "ghcr.io/mcparmory/launchdarkly:1.0.4"
      ]
    }
  }
}
// mcp.json
{
  "mcpServers": {
    "com-mcparmory-launchdarkly": {
      "command": "docker",
      "args": [
        "run",
        "--rm",
        "-i",
        "ghcr.io/mcparmory/launchdarkly:1.0.4"
      ]
    }
  }
}
Changelog

Every change we have recorded for this component, newest first. Security-relevant changes are always shown. ▲ marks a change for the better, ▼ a change for the worse; unmarked changes are neutral.

  • 20 Sept 26 −3
    • Stability: pass → 0.80 functional
  • 19 Sept 26 +1
    • Stability: 0.97 → pass security
  • 17 Sept 26 +1

    No change was recorded against any check on this day. Stability & Change Management went from 90 to 93. That category is still filling its 30-day observation window: 27 days of observed history at the previous scan, 28 at this one. The score rises as the window fills, whether or not the server changes.

  • 15 Sept 26 +1

    No change was recorded against any check on this day. Stability & Change Management went from 83 to 87. That category is still filling its 30-day observation window: 25 days of observed history at the previous scan, 26 at this one. The score rises as the window fills, whether or not the server changes.

  • 13 Sept 26 −3
    • Stability: pass → 0.80 functional
  • 12 Sept 26 +1
    • Stability: 0.97 → pass security
  • 10 Sept 26 +1

    No change was recorded against any check on this day. Stability & Change Management went from 90 to 93. That category is still filling its 30-day observation window: 27 days of observed history at the previous scan, 28 at this one. The score rises as the window fills, whether or not the server changes.

  • 8 Sept 26 +1

    No change was recorded against any check on this day. Stability & Change Management went from 83 to 87. That category is still filling its 30-day observation window: 25 days of observed history at the previous scan, 26 at this one. The score rises as the window fills, whether or not the server changes.

Diagnostics

Diagnostic detail from the automated scan of this channel: what the scanner observed at each step, so you can see exactly where a check passed or failed. It is informational only and never changes the trust score.

Captured 21 Sept 2026 · Analysed oci/ghcr.io/mcparmory/launchdarkly:1.0.4

Provenance No attestation

The registry publishes no build provenance for this version, so there is nothing to verify.

Result No attestation
Ecosystem oci
Reason No attestation published

Background: How many MCP packages publish verified provenance →

MCP tools · 274 exposed · ~36,460 tokens

The tools this component advertises to a client, with an estimated token cost for each. Expand a tool to see its parameters and schema. The per-tool counts are indicative and are not scored directly; the schema's total context footprint is one signal in Schema Quality & AI Usability. A tool's description is untrusted text the model reads on every call, which is what makes this list a security surface and not just an inventory: how tool poisoning works →

Tool Tokens
update_flag_defaults_for_project_partial ~104

Update flag defaults for a project using JSON patch or JSON merge patch operations. This allows you to modify default flag configurations applied across the project.

NameTypeReqDescription
bodyarrayyesAn array of patch operations following RFC 6902 (JSON Patch) or RFC 7386 (JSON Merge Patch) format, specifying the changes to apply to the flag defaults.
projectKeystringyesThe project key that uniquely identifies the project containing the flag defaults to update.

No output schema declared.

No examples provided.

update_flag_setting_for_context ~203

Set or clear a feature flag's variation value for a specific context. Omit or set `setting` to null to erase the current setting; otherwise, provide a variation value matching the flag's type (e.g., boolean, string).

NameTypeReqDescription
contextKeystringyesThe unique identifier for the context within its kind.
contextKindstringyesThe context kind (e.g., 'user', 'organization') that categorizes the context.
environmentKeystringyesThe environment key where the flag setting applies.
featureFlagKeystringyesThe key of the feature flag to update.
projectKeystringyesThe project key that contains the feature flag.
settingThe variation value to assign to this context. Must match the flag's variation type (e.g., true/false for boolean flags, a string value for string flags). Omit or set to null to remove the context's…

No output schema declared.

No examples provided.

update_flag_trigger ~181

Update a flag trigger's configuration using semantic patch instructions. Supports actions like enabling/disabling the trigger, replacing trigger actions, or cycling the trigger URL.

NameTypeReqDescription
environmentKeystringyesThe environment key where the trigger is configured.
featureFlagKeystringyesThe feature flag key associated with this trigger.
idstringyesThe unique identifier of the flag trigger to update.
instructionsarrayAn array of semantic patch instructions to apply. Each instruction is an object with a `kind` field specifying the operation: `replaceTriggerActionInstructions` (with `value` array of actions like `t…
projectKeystringyesThe project key that contains the feature flag.

No output schema declared.

No examples provided.

update_insight_group ~132

Update an insight group using JSON Patch operations. Specify the changes you want to make (such as renaming the group) via a JSON Patch document following RFC 6902 standards.

NameTypeReqDescription
bodyarrayyesA JSON Patch document (RFC 6902) describing the updates to apply. Each operation must include 'op' (the operation type), 'path' (the JSON pointer to the field), and 'value' (the new value for replace…
insightGroupKeystringyesThe unique identifier for the insight group to update.

No output schema declared.

No examples provided.

update_layer ~156

Modify a layer's properties or experiment traffic reservations using semantic patch instructions. Supports updating layer name/description or managing traffic reservations for experiments within the layer.

NameTypeReqDescription
environmentKeystringThe environment key for environment-specific updates, such as modifying experiment traffic reservations. Required when updating experiment reservations.
instructionsarrayyesAn array of semantic patch instructions defining the updates to apply. Each instruction object must include a `kind` field specifying the operation type (updateName, updateDescription, updateExperime…
layerKeystringyesThe unique identifier for the layer to update.
projectKeystringyesThe unique identifier for the project containing the layer.

No output schema declared.

No examples provided.

update_member ~143

Update an account member's role or custom roles using JSON Patch format. Changes are applied to the member object, though IdP-managed accounts may be overridden by the Identity Provider shortly after.

NameTypeReqDescription
bodyarrayyesA JSON Patch array describing the changes to apply. Each patch object must contain an operation (add, remove, replace, etc.), a path (e.g., '/role' or '/customRoles/0'), and a value. Use array index…
idstringyesThe unique identifier of the member to update.

No output schema declared.

No examples provided.

update_members_bulk ~113

Perform bulk updates to member roles and custom roles using semantic patch instructions. Supports targeted updates to specific members or filtered bulk updates across all members (Enterprise feature).

NameTypeReqDescription
instructionsarrayyesArray of semantic patch instructions defining the bulk update operations. Each instruction object must include a `kind` field specifying the operation type (replaceMembersRoles, replaceAllMembersRole…

No output schema declared.

No examples provided.

update_metric ~144

Update a metric using JSON Patch operations. Specify the changes you want to make to the metric's properties such as name, description, or other attributes.

NameTypeReqDescription
bodyarrayyesAn array of JSON Patch operations describing the changes to apply. Each operation must include 'op' (the operation type such as 'replace', 'add', or 'remove'), 'path' (the JSON pointer to the target…
metricKeystringyesThe unique identifier for the metric to update.
projectKeystringyesThe unique identifier for the project containing the metric.

No output schema declared.

No examples provided.

update_metric_group ~157

Update a metric group using JSON Patch operations. Apply one or more changes to a metric group's properties by specifying the operation type, target path, and new value.

NameTypeReqDescription
bodyarrayyesAn array of JSON Patch operations (RFC 6902) specifying the changes to apply. Each operation must include 'op' (the operation type such as 'replace', 'add', or 'remove'), 'path' (the JSON pointer to…
metricGroupKeystringyesThe unique identifier for the metric group to be updated.
projectKeystringyesThe unique identifier for the project containing the metric group.

No output schema declared.

No examples provided.

update_oauth_client ~108

Update an OAuth 2.0 client's configuration using JSON Patch operations. Only the client name, description, and redirect URI can be modified.

NameTypeReqDescription
bodyarrayyesA JSON Patch array describing the changes to apply. Each operation must specify an operation type (op), a JSON pointer path, and a value. Supported paths are /name, /description, and /redirectUri.
clientIdstringyesThe unique identifier of the OAuth 2.0 client to update.

No output schema declared.

No examples provided.

update_project ~125

Update a project using JSON Patch operations. Supports modifying project fields including adding, removing, or replacing values. Array fields like tags are automatically deduplicated and sorted alphabetically.

NameTypeReqDescription
bodyarrayyesAn array of JSON Patch operations describing the changes to apply. Each operation must specify an operation type (add, remove, replace, etc.), a JSON Pointer path to the target field, and a value whe…
projectKeystringyesThe unique identifier for the project to update.

No output schema declared.

No examples provided.

update_prompt_snippet ~112

Update an existing prompt snippet in a project, creating a new version with the modified content or metadata.

NameTypeReqDescription
namestringThe display name for the prompt snippet. If provided, updates the snippet's name.
projectKeystringyesThe unique identifier of the project containing the prompt snippet.
snippetKeystringyesThe unique identifier of the prompt snippet to update.
textstringThe text content of the prompt snippet. If provided, updates the snippet's template text.

No output schema declared.

No examples provided.

update_relay_auto_config ~90

Update a Relay Proxy configuration using JSON patch or JSON merge patch operations. Changes are applied incrementally to the specified configuration.

NameTypeReqDescription
idstringyesThe unique identifier of the Relay Proxy configuration to update.
patcharrayyesAn array of JSON patch operations (RFC 6902) or JSON merge patch operations (RFC 7386) describing the changes to apply to the configuration.

No output schema declared.

No examples provided.

update_release_phase_status ~159

Update the execution status of a specific phase within a feature flag release. Use this to advance phases through their lifecycle and configure audience targeting for phase initialization.

NameTypeReqDescription
audiencesarrayAn ordered list of audience configurations to apply when initializing the phase. Each item specifies targeting rules and rollout parameters for that audience segment.
flagKeystringyesThe unique identifier for the feature flag whose release phase should be updated.
phaseIdstringyesThe unique identifier for the specific phase within the release whose status should be updated.
projectKeystringyesThe unique identifier for the project containing the feature flag release.
statusstringThe new execution status to assign to the phase, controlling its progression through the release lifecycle.

No output schema declared.

No examples provided.

update_release_phase_status_by_flag_key ~173

Update the completion status of a release phase for a flag in a legacy release pipeline. Use JSON patch format to mark specific phases as complete or incomplete by their array index.

NameTypeReqDescription
bodyarrayyesA JSON patch array specifying the phase status changes. Each patch object must contain an 'op' field set to 'replace', a 'path' field pointing to a phase's complete status (e.g., '/phases/0/complete'…
flagKeystringyesThe flag key identifying which flag's release to update. A string identifier for the flag.
projectKeystringyesThe project key that contains the flag. A string identifier for the project.

No output schema declared.

No examples provided.

update_release_pipeline ~183

Updates an existing release pipeline with new configuration, including its name, deployment phases, and optional tags for organization and filtering.

NameTypeReqDescription
namestringyesThe display name for the release pipeline (e.g., 'Standard Pipeline'). Used to identify the pipeline in the UI and reports.
phasesarrayyesAn ordered array of deployment phases, where each phase represents a logical grouping of one or more environments that share attributes for rolling out changes. Phase order determines the sequence of…
pipelineKeystringyesThe unique identifier for the release pipeline to be updated.
projectKeystringyesThe unique identifier for the project containing the release pipeline.
tagsarrayAn optional array of tags for categorizing and filtering the release pipeline (e.g., ['example-tag']). Tags help organize pipelines by team, environment type, or other attributes.

No output schema declared.

No examples provided.

update_release_policy ~406

Update an existing release policy for a project, configuring how feature flags are released across environments with optional metrics-based validation and rollback controls.

NameTypeReqDescription
LD-API-VersionstringyesAPI version specification; must be set to 'beta' for this endpoint.
environmentKeysarrayOptional list of environment keys where this policy applies (e.g., production, staging). If specified, the policy is scoped to these environments only.
flagTagKeysarrayOptional list of flag tag keys to which this policy applies. If specified, the policy only affects flags with these tags.
guardedReleaseConfigStagesarrayOptional array of release stages for guarded-release policies, defining sequential validation gates and approval requirements.
metricGroupKeysarrayOptional list of metric group keys to monitor during release. Groups allow monitoring multiple related metrics together.
metricKeysarrayOptional list of metric keys to monitor during release (e.g., http-errors, latency). These metrics inform release decisions and rollback triggers.
minSampleSizeintegerOptional minimum number of samples (observations) required before the system can make a release decision. Helps ensure statistical significance.
namestringyesA human-readable name for the release policy, up to 256 characters. Used for display and identification in the UI.
policyKeystringyesThe unique human-readable identifier for the release policy to update.
progressiveReleaseConfigStagesarrayOptional array of release stages for progressive-release policies, defining percentage-based rollout increments and timing.
projectKeystringyesThe unique identifier for the project containing the release policy.
releaseMethodstringyesThe release strategy for this policy: 'guarded-release' for controlled rollouts with validation gates, or 'progressive-release' for gradual percentage-based rollouts.
rollbackOnRegressionbooleanOptional flag to automatically roll back the release if a regression is detected in monitored metrics.

No output schema declared.

No examples provided.

update_repository ~116

Update a repository's settings using JSON patch or JSON merge patch operations. Changes are applied according to RFC 6902 or RFC 7386 standards.

NameTypeReqDescription
bodyarrayyesAn array of patch operations describing the changes to apply. Each operation should specify an action (op), a JSON pointer path (path), and the new value (value) where applicable. Operations are proc…
repostringyesThe name of the repository to update. This identifier is used to locate the specific repository in the system.

No output schema declared.

No examples provided.

update_scheduled_flag_change ~216

Update a scheduled flag change by replacing its instructions or execution date using semantic patch operations. Supports deleting the scheduled change, modifying its execution time, or changing the flag actions to be performed.

NameTypeReqDescription
environmentKeystringyesThe environment key where the scheduled change is configured.
featureFlagKeystringyesThe feature flag key for which the scheduled change applies.
idstringyesThe unique identifier of the scheduled change to update.
ignoreConflictsbooleanSet to `true` to allow the update even if new instructions conflict with existing scheduled changes, or `false` to reject conflicting updates. Defaults to `false`.
instructionsarrayyesAn array of semantic patch instructions to apply. Each instruction is an object with a `kind` field specifying the operation (deleteScheduledChange, replaceScheduledChangesInstructions, or updateSche…
projectKeystringyesThe project key that contains the feature flag.

No output schema declared.

No examples provided.

update_segment ~190

Update a segment using semantic patch, JSON patch, or JSON merge patch. Supports modifications to segment metadata, targeting rules, individual targets, and big segment operations.

NameTypeReqDescription
dryRunbooleanWhen true, validates the patch and returns a preview of the updated segment without persisting changes.
environmentKeystringyesThe environment key where the segment exists.
patcharrayyesThe patch instructions as a JSON array. Use semantic patch (with `domain-model=launchdarkly.semanticpatch` header) for segment-specific operations like managing targets and rules, or standard JSON pa…
projectKeystringyesThe project key that contains the segment to update.
segmentKeystringyesThe segment key identifying which segment to update.

No output schema declared.

No examples provided.

update_segment_expiring_targets ~200

Schedule or modify expiration dates for context targets within a segment using semantic patch instructions. Supports adding, updating, or removing scheduled expirations for included or excluded contexts.

NameTypeReqDescription
environmentKeystringyesThe environment key where the segment targeting applies. Specifies which environment's segment expiration rules to update.
instructionsarrayyesArray of semantic patch instructions defining the changes to apply. Each instruction must specify a kind (addExpiringTarget, updateExpiringTarget, or removeExpiringTarget), the target type (included…
projectKeystringyesThe project key that contains the segment. Used to identify which project's segment configuration to modify.
segmentKeystringyesThe segment key identifying which segment's expiring targets to modify.

No output schema declared.

No examples provided.

update_team ~131

Perform a partial update to a team using semantic patch instructions. Supports operations like adding/removing members, updating team metadata, managing custom roles, and configuring permission grants.

NameTypeReqDescription
instructionsarrayyesAn array of semantic patch instruction objects that specify the updates to apply. Each instruction object must include a `kind` field indicating the operation type (e.g., addMembers, updateName, remo…
teamKeystringyesThe unique identifier for the team to update. Use the team key value returned from team listing operations.

No output schema declared.

No examples provided.

update_token ~115

Update an access token's settings using JSON Patch operations. Specify the changes you want to make (such as modifying the role) in RFC 6902 patch format.

NameTypeReqDescription
bodyarrayyesAn array of JSON Patch operations describing the changes to apply. Each operation must include 'op' (the operation type), 'path' (the token property to modify), and 'value' (the new value for replace…
idstringyesThe unique identifier of the access token to update.

No output schema declared.

No examples provided.

update_view ~213

Update an existing view by replacing specified fields. Provide a JSON object containing only the fields you want to modify; unchanged fields retain their current values.

NameTypeReqDescription
LD-API-VersionstringyesAPI version specification. Must be set to 'beta' for this endpoint.
archivedbooleanWhether the view is archived. Set to true to archive the view, or false to unarchive it.
generateSdkKeysbooleanWhether to automatically generate SDK keys for this view. Set to true to enable SDK key generation.
namestringA human-readable name for the view. This is the display name users will see.
projectKeystringyesThe project key that contains the view. Use the project identifier (e.g., 'default').
tagsarrayTags to associate with this view for organization and filtering. Provide as an array of tag strings.
viewKeystringyesThe view key that identifies which view to update (e.g., 'my-view').

No output schema declared.

No examples provided.

update_webhook ~113

Update a webhook's configuration using JSON Patch operations. Specify the changes you want to make (such as enabling/disabling the webhook) as an array of patch operations.

NameTypeReqDescription
bodyarrayyesAn array of JSON Patch operations describing the changes to apply. Each operation must include an 'op' field (e.g., 'replace'), a 'path' field indicating which property to modify, and a 'value' field…
idstringyesThe unique identifier of the webhook to update.

No output schema declared.

No examples provided.

upsert_branch ~195

Create a new branch or update an existing branch in a repository. Use this to sync branch metadata including the current HEAD commit and last sync timestamp.

NameTypeReqDescription
branchstringyesThe branch name as it appears in the URL, URL-encoded if it contains special characters.
headstringyesA commit identifier representing the current HEAD of the branch, typically a commit SHA hash.
namestringyesThe human-readable branch name (e.g., 'main', 'develop'). This is the actual branch identifier.
referencesarrayAn optional array of flag references discovered on this branch. Order and format depend on the flag reference structure used by the system.
repostringyesThe name of the repository where the branch exists or will be created.
syncTimestringyesA Unix timestamp (in milliseconds or seconds as int64) indicating when this branch was last synchronized with the source.

No output schema declared.

No examples provided.

Common questions

What is the com.mcparmory/launchdarkly MCP server?

com.mcparmory/launchdarkly is an MCP server listed in the public MCP registry as com.mcparmory/launchdarkly. Manage feature flags, segments, projects, environments, and team members. This page covers its container image (ghcr.io/mcparmory/launchdarkly:1.0.4).

Is the com.mcparmory/launchdarkly MCP server safe to use?

com.mcparmory/launchdarkly scores 49 out of 100 on VerifyMCP. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm.

What tools does the com.mcparmory/launchdarkly MCP server expose?

com.mcparmory/launchdarkly exposes 274 tools: list_relay_proxy_configs, create_relay_proxy_config, get_relay_proxy_config, update_relay_auto_config, delete_relay_auto_config, and 269 more. Their descriptions and schemas cost roughly 36,460 tokens of context every time the server is loaded.

Is the com.mcparmory/launchdarkly MCP server still maintained?

com.mcparmory/launchdarkly is still listed as active in the MCP registry. We last reached this channel on 21 September 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.