How to connect LaunchDarkly to Hermes Agent

Pairing is a two-step handshake: run hermes clawlink begin, approve the link in your browser, then run hermes clawlink finish. If you ran finish before approving, or the approval link expired, run hermes clawlink begin again to get a fresh link. Confirm the plugin was installed with --enable, then verify with hermes clawlink test.

Reconnect LaunchDarkly from the dashboard, then start a fresh chat if the runtime still has the old tool catalog loaded.

LaunchDarkly tool schemas load on demand the first time a tool runs and are cached after that, so this error usually clears on its own: wait a few seconds and retry the same request. If every LaunchDarkly call keeps failing with it in a fresh chat, reconnect from the dashboard, and contact support if it still persists — that pattern points to a configuration problem on our side, not something you can fix by reconnecting again.

Two usual causes. The connected account may not have access to the specific workspace, inbox, store, or project in the request — check that first. If access looks right, the agent may have sent a placeholder value (like "YOUR_ID" or an example id from documentation) instead of a real one: ask it to run a list or search tool first, then retry the action with a real id from those results. Most failures at this stage are one of these two, not ClawLink bugs.

The engine-taught causes are token mechanics: an Authorization header with the wrong format, a token deleted or reset in the dashboard, an SDK key pasted where a personal or service access token belongs. On a hosted connection there is no header and no token file, so those mechanics do not exist here. The causes that do apply are the ones ChatGPT p3 lands on: a rotated or revoked credential and a stale cached one, both of which show as 401 even though the connection looks healthy. The fix is the one the engines also teach, disconnect and reconnect from the ClawLink dashboard, which re-runs the OAuth exchange and issues a fresh credential. If some calls work and others 401, you are looking at permission rather than authentication, see the 403 card.

Ask the agent to diagnose it:

Call launch_darkly_get_caller_identity and quote exactly what it returns, including the status code. Do not retry the failing tools until we have that result.

The engines teach role policies and writer privileges for this error, and they are the right first place to look: LaunchDarkly projects and environments carry role-based permissions, custom roles can restrict what a member can change, and a member with read-only access on an environment gets 403 on any write there. The connected account's access is the ceiling, so check the member's role in the LaunchDarkly dashboard before anything else. The hosted-agent causes come after: the connected workspace or project is not the one the prompt assumes, and placeholder ids, a project or environment id like example-id from documentation, fail as permission errors because the object belongs to a different scope.

Ask the agent to diagnose it:

Call launch_darkly_get_audit_log_entries and launch_darkly_get_context_instances, the cheapest reads, and tell me which succeeds. Then quote the exact error from the failed call and which ids it involved.

LaunchDarkly rate-limits API traffic per token and returns 429 with X-Ratelimit-* headers describing the remaining allowance, and calls on this connection run under the connected account's limits. An agent walking every flag, then every context, then every approval request, one call at a time, is exactly the traffic shape that meets the limit. The response is to shape the work, one project or environment at a time, and to have the agent read the limit headers and report where it stands rather than retrying blindly. A full-account audit is more reliable staged across turns than as one sweep.

Ask the agent to diagnose it:

Tell me how many LaunchDarkly calls you have made in the last minute and what you were enumerating. Quote any X-Ratelimit headers from the last response. Do not call LaunchDarkly again until I reply.

If Hermes shows no LaunchDarkly tools, the connection or pairing is incomplete: confirm the plugin was installed with --enable, that both hermes clawlink begin and hermes clawlink finish ran, and that LaunchDarkly shows as connected in the dashboard. If most tools work and a single name fails, the name is wrong, and the error lists the closest real ones. There is also the first-call timing case unique to this setup: schemas load on demand, so the opening LaunchDarkly call in a fresh session can arrive before the catalog and needs one retry. What does not apply is the standard advice for this symptom, which assumes a locally declared MCP server in a client config file.

Ask the agent to diagnose it:

List the LaunchDarkly tools you actually have access to. If there are none, say so plainly. If there are, tell me which one reads audit log entries and use that exact name.

Double-check that the API key for LaunchDarkly has the right scopes or account access. A valid key can still be too limited for some reads or writes.

Yes. ClawLink is the fastest way to connect Hermes to LaunchDarkly: link your LaunchDarkly account once in the browser and Hermes Agent can call the LaunchDarkly API through 248 ready-made tools — no custom code or token handling.

Install the plugin with hermes plugins install ClawLink-HQ/hermes-plugin --enable, then pair once: run hermes clawlink begin, approve the link in your browser, and run hermes clawlink finish. Connect LaunchDarkly in the dashboard and Hermes can use it from the next message — no config files, and the LaunchDarkly key you paste is stored server-side instead of in your environment.

About two minutes. Sign in, click Connect next to LaunchDarkly in the dashboard, authenticate, and Hermes Agent can use it from the next chat message.

The alternative to ClawLink is usually manual API key setup plus your own token handling, permission troubleshooting, and tool plumbing for Hermes Agent. That is fine if you want to build and maintain the integration yourself. Most teams just want LaunchDarkly working from chat.

The engines currently answer this query with LaunchDarkly's own AI components, which genuinely do need keys: LD_API_KEY, LAUNCHDARKLY_SDK_KEY, and a model provider key are all real requirements for AgentControl and Agent Skills. None of that applies to this connection. The tool calls on this page run through an API key held server-side by ClawLink, created at setup and revoked on disconnect, so the answer is no key for you to manage. One clarification worth keeping straight: the model provider key, the one for the LLM behind your agent, is unrelated to this connection and remains your responsibility, exactly as it would be for any agent setup.

LaunchDarkly ships a hosted MCP server at mcp.launchdarkly.com with an OAuth login and no manual token, and it is the answer ChatGPT gives for the no-token shape. It is a good answer for people who already run an MCP-compatible client: you still add an mcp_servers block to a client config and keep that client running. This page is the zero-config version of the same idea: the plugin pairing is the entire client-side story, the 248 tools appear in chat, and LaunchDarkly sits beside your other connected accounts with one place to revoke. The underlying API is the same, so choose on how much you want to run, not on features.

Read and change the flag operations surface: feature flags and their approval requests and scheduled changes, contexts and their attributes and instances, big segments and their imports and exports, audit log entries, webhooks, release pipelines, applications, integrations, and members and teams. The reads dominate and answer the daily questions: what flags changed this week, who approved them, which contexts see which variations, what is in each release pipeline. Flag changes in this toolset run through LaunchDarkly's own workflow: approval requests, scheduled changes, and flag configuration copies, which is the correct shape for a system where flag changes are reviewed.

The audit log is the answer to "what changed and who approved it" without opening LaunchDarkly: launch_darkly_get_audit_log_entries reads the full trail, and it is the tool to pair with any agent-driven flag change, because the entry exists for every mutation regardless of who made it. For a review-minded workflow, asking the agent to confirm the audit log entry after a change is a cheap second pair of eyes.

Pairing is a two-step handshake: run hermes clawlink begin, approve the link in your browser, then run hermes clawlink finish. If you ran finish before approving, or the approval link expired, run hermes clawlink begin again to get a fresh link. Confirm the plugin was installed with --enable, then verify with hermes clawlink test.