Update to LaunchDarkly

{
  "name": "create-graph",
  "description": "Creates observability dashboards and graphs from logs, traces, errors, sessions, metrics, and events data by previewing charts inline and saving them to a dashboard.",
  "included_files": [
    {
      "relative_path": "enums.md",
      "size_in_bytes": 2268
    }
  ],
  "skill_md_contents": "---\nname: create-graph\ndescription: \"Creates observability dashboards and graphs from logs, traces, errors, sessions, metrics, and events data by previewing charts inline and saving them to a dashboard.\"\nlicense: Apache-2.0\ncompatibility: Requires the remotely hosted LaunchDarkly MCP server\nmetadata:\n  author: launchdarkly\n  version: \"0.1.0\"\n---\n\n# Create graphs and dashboards\n\n## Prerequisites\n\nThis skill uses the following LaunchDarkly MCP tools:\n\n- `preview-graph` — render a chart preview inline without saving it\n- `create-graph` — add a chart to an existing dashboard\n- `create-dashboard` — create a new empty dashboard\n- `list-dashboards` — list existing dashboards\n- `get-dashboard` — get the full config of a dashboard, including its graphs\n- `get-keys` — discover available metrics, attributes, and keys for a product type\n\nAll of these tools require a `projectKey` (e.g. `\"default\"`).\n\n## Overview\n\nYou are building observability graphs. Your tools are precise — get the enum values wrong and the API rejects the call. Always use `get-keys` before building a query to confirm the dimension names are real.\n\n## Capabilities\n\n- `list-dashboards` — list existing dashboards to check for duplicates or find a target\n- `get-dashboard` — get the full config of an existing dashboard, including its graphs\n- `create-dashboard` — create a new dashboard\n- `preview-graph` — render a chart preview inline\n- `create-graph` — add a chart to a dashboard\n- `get-keys` — discover available metrics, attributes, and keys for a product type\n\nWhen the user's request is purely about visualizing data, stay on task — don't reach for unrelated tools.\n\n## Workflow\n\n1. **Identify the target dashboard.** If the user already has a specific dashboard in mind (by ID or name), add graphs to it directly. Otherwise, call `list-dashboards` and offer to target an existing one or create a new one with `create-dashboard`.\n2. **Discover the data shape.** Call `get-keys` for the relevant product type before building a query. Attribute names vary across services — `service_name` vs `service.name` vs `serviceName`. Guessing wastes tool calls.\n3. **For ambiguous requests, ask a brief clarifying question** as regular text. Example: \"I found several latency-related keys. Would you like P50 or P95 latency, and should I group by service name?\" Keep clarifications short — one or two questions max. For minor ambiguity (chart type preference), make a reasonable default and note your assumption.\n4. **Preview before committing.** Call `preview-graph` first, show the user an inline preview, and confirm before calling `create-graph`. For multiple graphs, preview and confirm each one individually.\n5. **Create the graph** with `create-graph`. Use exact enum casing from `enums.md`.\n6. **Confirm what was created** — provide the dashboard URL and a one-line description of what the graph shows.\n\n## Duplicating existing graphs\n\nWhen asked to duplicate or copy a graph, call `get-dashboard` to retrieve the full configuration (expressions, product type, query, groupBy, display settings), then replicate those values in `create-graph`. Do not guess from the graph title alone — titles drift from the underlying config.\n\n## Guidelines\n\n- **Be concise — don't narrate intermediate tool calls.** Skip prefaces like \"First, let me discover the keys\" or \"Now I'll build the chart.\" One short sentence at the start of the reply is enough if needed (e.g. \"Building a chart of recent logs by level.\"); after that, just call the tools.\n- **Prefer multiple focused graphs over one complex graph.** A dashboard with 3 clean graphs beats one graph with 5 overlapping expressions.\n- **Always call `get-keys` before building a query.** Prevents silent empty results from wrong field names.\n\n## Chart-type picks\n\n- **`Line chart`** — time-series trends. Error rates over time, latency percentiles, request volume.\n- **`Bar chart`** (or histogram) — comparisons across a dimension. Errors by service, requests by endpoint.\n- **`Table`** — detailed breakdowns with multiple dimensions where a chart wouldn't convey the detail.\n\n## Aggregators\n\n- `Count` — total events (most common). Requires `column=\"\"` (empty string).\n- `CountDistinct` — unique values. Users, sessions, flag keys.\n- `Avg`, `P50`, `P90`, `P95`, `P99` — latency distributions.\n- `Sum` — numeric totals (payload size, revenue).\n\n## Common mistakes\n\n- Using lowercase `sessions` for `productType`. It's `Sessions` — PascalCase. See `enums.md`.\n- Omitting `column` on a `Count` expression. The API requires it; pass empty string `\"\"`.\n- Using `count_distinct` or `Count_distinct`. It's `CountDistinct` — PascalCase, no underscore.\n- Building a query without `get-keys` first and getting empty results because the attribute name was wrong.\n- Using date-only format (`2026-03-04`) for `get-keys`. Needs full ISO with time: `2026-03-04T00:00:00Z`.\n"
}