Your agent needs to create flags, flip targeting, and gate a rollout in LaunchDarkly. LaunchDarkly gives you two ways in: a hosted MCP server and a REST API. They are not the same object. Different capability coverage, different auth, different operational surface once you are past the demo. This is how to choose for a production agent, not a laptop experiment.
You have almost certainly called the REST API before. The MCP server is the newer object, so it is worth being precise about what each one is and how an agent connects to it.
LaunchDarkly runs a hosted MCP server that covers feature management, AgentControl configs, observability, and metrics, with a dedicated observability endpoint alongside the main one. An agent connects over OAuth: the first tool call triggers a browser authorization, and the member's existing LaunchDarkly permissions apply automatically. There is no API key to mint or store. The tools it exposes are the same REST endpoints, wrapped as MCP tools with schemas the model can read directly.
For LaunchDarkly federal and EU instances, the hosted server is not available. There, you run the local MCP server, distributed as an npm package and started with npx. It authenticates with an API access token passed as --api-key, and LaunchDarkly recommends a token with a Writer base role or the Developer preset. This is the stdio path for restricted environments, not the default for a cloud agent.
The REST API is the full surface. Every LaunchDarkly feature begins as an endpoint under the /api/v2 base path, so anything the product can do, the API can do. You authenticate by sending an Authorization header with an API access token. That includes creating and searching members, teams, projects, environments, and flags, toggling flags, querying context data, and building integrations. It is not for evaluating flags in your app; that is what the SDKs are for.
Scalekit's LaunchDarkly connector wraps the hosted MCP server behind per-user OAuth, so the choice below does not change your auth plumbing. The rest of this article is about which path gives your agent the right capabilities and the right auth model.
Both paths cover the day-to-day of feature management well. The difference shows up at the edges: the MCP is a curated tool set, and the REST API is the whole product. Name the gap precisely before you build against either one.
The table below covers the actions most agents reach for. "Limited" means the capability exists but you assemble it yourself or reach for a different surface.
The curated MCP tool set stops at the boundary of account administration. If your agent needs to create a team, edit a custom role, mint or rotate an API access token, or wire up a webhook, those actions live only on the REST API. The MCP can invite and look up members, but it will not restructure your org. For most flag and rollout agents that boundary never bites. For a platform-administration agent, it is the whole job.
The MCP also ships convenience tools the raw API does not hand you in one call. launchdarklymcp_find_stale_flags returns a prioritized cleanup list, and launchdarklymcp_check_removal_readiness classifies a flag as safe, caution, or not-ready from live evaluation data. On the REST API you would query flag status and evaluation counts and compute that yourself. Observability querying is the same story: it is native on the MCP and awkward on the v2 REST surface. Understanding the difference between MCP and APIs at an architectural level helps clarify why these convenience tools exist on one side but not the other.
Capability is only half the decision. The bigger question for a production agent is what credential model each path forces on you, because that is what you will maintain at scale.
The hosted MCP authenticates with OAuth and nothing else. The consent flow runs in a browser, and the resulting token carries the authorizing member's LaunchDarkly permissions. This is a clean fit for the least-privilege rule: what the user cannot do in LaunchDarkly, the agent cannot do either. It is a poor fit for a headless worker with no human present to click through consent.
The REST API gives you options the MCP does not. Personal tokens are tied to a member and inherit that member's scope, so they deactivate if the member is removed. Service tokens are independent of any member, hold fixed permissions set at creation, and are available on select plans. Both can be scoped by base role, custom role, or an inline policy. LaunchDarkly also supports registered OAuth applications for integrations that act on behalf of LaunchDarkly users.
Reduced to essentials: the MCP path gives you an OAuth token per user, and the REST path gives you an access token per user. In a single-tenant internal tool, either is fine. In a multi-tenant B2B agent, both leave you holding one credential per user, with no vault and no rotation logic in the box. How tool calling auth changes when you move from single-tenant to multi-tenant is a problem that neither path solves on its own, and it is covered in its own section below.
The MCP path manages more for you on day one. The REST path gives you more control and more to maintain. The honest tradeoff is about who owns the moving parts when something changes.
The MCP server owns tool schemas, endpoint normalization, and the OAuth handshake. You still own token storage, refresh, revocation, and tenant isolation once real users are behind it. You also inherit the provider's release cadence: when LaunchDarkly updates the server, the tool set and schemas can change under you, which is a feature for freshness and a risk for determinism.
With the direct API you own everything: request construction, error handling, retries, pagination, and the full token lifecycle. Nothing changes unless you change it, which is exactly what a deterministic pipeline wants. The cost is that there is no schema layer between your code and the endpoints, so your agent's tool definitions are yours to write and keep current.
The REST API is versioned with a date-based LD-API-Version header; the current version is 20240415, and each access token pins a version. Some endpoints require semantic patch, which means appending domain-model=launchdarkly.semanticpatch to the Content-Type, and beta resources return 403 without an explicit beta header. Version 20220603 reaches end of life on December 31, 2026, which forces a migration you have to plan. The MCP abstracts all of that away, and takes the control with it.
Neither path is the default. The right one depends on whether a human is in the loop, how deterministic the workflow must be, and which surfaces your agent needs to touch.
Here is the part that survives whichever way you go. Both paths give your agent a token or a credential per user. Neither gives you a place to keep it, a way to rotate it, or a way to revoke it when a user leaves.
In a multi-tenant B2B agent, every user has their own LaunchDarkly credential. The MCP path makes that an OAuth token; the direct API makes it an access token. The token type differs, but the infrastructure required is identical: N credentials to encrypt, refresh, and revoke at scale. The tempting shortcut — a single service token shared across all users — collapses least privilege and inflates the blast radius, since every agent action then attributes to one over-scoped credential rather than the person who triggered it. A token vault is critical for AI agent workflows precisely because this problem compounds as your user base grows.
Scalekit's LaunchDarkly connector handles the OAuth flow, token storage, and rotation for the hosted MCP, so the MCP-versus-API decision does not change your auth infrastructure. Credentials sit in a token vault and never touch the agent runtime. If you need REST-only surfaces the MCP does not cover, the bring-your-own-connector model and connected accounts let you manage those credentials the same way.
The connector exposes LaunchDarkly's hosted MCP through Scalekit's per-user auth model. The example below uses Python and LangChain; the same connector works with the Claude SDK, Google ADK, CrewAI, and others.
Install the SDK, initialize the client, and generate a per-user authorization link. The connection_name string must match the connection name configured in your Scalekit dashboard; a mismatch here is the single most common integration error.
Before the agent runs, it loads the tools the current user's connected account is authorized to call, not a flat catalog. This is the line between a per-user agent and a shared-credential one. LaunchDarkly's hosted MCP surfaces 136 tools through the connector, so the default page will miss some; raise page_size, or scope the surface with a virtual MCP server (covered below) so the model only ever sees what it needs. This is one of the core tool calling auth patterns that separates production agents from demos.
Bind the tools to your model and run the loop. Each tool call executes against LaunchDarkly with the current user's credential, which Scalekit injects at call time.
When the workflow is fixed, skip the model and call the tool directly. execute_tool takes the exact tool name and runs it under the same per-user credential. Use the exact names from the connector's tool list, such as launchdarklymcp_find_stale_flags or launchdarklymcp_get_flag_status_across_envs.
The connector removes the auth work. The pieces below are why that matters at production scale, especially for multi-tool and multi-tenant agents.
A virtual MCP server declares exactly which tools an agent can see. At roughly 200 tokens per tool, LaunchDarkly's 136-tool surface is well over 25,000 tokens loaded into every context window before the agent does any work. Scope it to the five or ten flag tools your agent uses, and you cut that overhead sharply while enforcing least privilege at the tool level. A flag-cleanup agent never needs the ability to delete a project. This cost differential is part of why MCP can be significantly more expensive than CLI when tool surfaces are not scoped properly.
Each agent run receives a short-lived session token scoped to one user's connected accounts. Credentials live in a token vault, so they never sit in the agent runtime or leak into logs. One server definition serves every user, and no credential is shared across tenants.
Because every call runs under a specific user's connected account, Scalekit can record which user's credential executed which tool. That gives you audit trails for agent auth for observability and accountability, rather than a single service-account identity smeared across every action your agent takes.
The same model extends past LaunchDarkly. Add GitHub, Slack, or an incident tool from the connector catalog, and each connection keeps its own per-user scope. For patterns that pair feature control with the rest of the release toolchain, see the DevOps assistant, incident response, and auto release notes templates.
If your agent is interactive and a user is present to authorize, build against the hosted MCP and let per-user OAuth do the scoping. If your agent is headless, deterministic, or needs account-administration surfaces the curated tool set skips, build against the REST API with scoped tokens. Most teams end up with both over time — a chat assistant on the MCP and a background pipeline on the API.
The decision that outlasts either one is the credential layer: per-user isolation, rotation, and revocation are the same problem on both paths. Who holds the token matters at every layer of the stack, and that is the part worth building on production-grade infrastructure rather than rebuilding twice. Pricing for that layer is on the Scalekit pricing page.
Building a LaunchDarkly agent and want another set of eyes on the auth model? Join the Scalekit Slack community or talk to us for immediate help. Start from the LaunchDarkly connector docs or the connector overview.
