Honeycomb MCP logo

Integrate Honeycomb MCP with your AI CRM

Honeycomb is an observability platform for high-cardinality event data. The Honeycomb MCP server lets agents query datasets, run analyses and inspect telemetry.

Explore Triggers and Actions

Canvas agent invoke

Kick off a single-turn run of the Honeycomb Canvas agent. Pass investigation_id to extend an existing investigation visible to the caller's team. Omit investigation_id to create a new investigation for this prompt; the new ID is returned in the response so the caller can reuse it on follow-up calls. Returns one of: status='running' with a session_id (call canvas_agent_poll_response next); status='busy' with a message (the user is mid-turn — wait at least 30 seconds, then retry, do NOT loop). Both responses also include investigation_url, a direct browser link to the canvas. On 'running', poll repeatedly until poll returns status='completed' or 'error'. Each poll waits up to 50 seconds. Best for asking the agent to summarize findings, run additional analysis, or kick off a new investigation.

ActionTry it

Canvas agent poll response

Poll for the result of a previously-issued canvas_agent_invoke call. Pass the investigation_id and session_id returned from canvas_agent_invoke. Each call waits up to wait_seconds (default 30, max 50) for a terminal event, then returns either status='completed' with the agent's chat reply, status='error' with a message, status='busy' if another invocation is contending for the same agent (retry canvas_agent_invoke), or status='running' if the agent is still working — in which case call this tool again with the same parameters. Cap on wait_seconds is intentional: longer single waits get killed by network infrastructure.

ActionTry it

Create board

Create a board (dashboard) with query, SLO, and text panels. When to use: - "Create a dashboard for service X" / "build a board with latency and error queries" — primary creation path. - After running queries and collecting their run IDs, assembling them into a board for sharing. - When a user wants an overview with both SLOs and queries side by side. - Before creating, call list_boards to check whether a similar board already exists. Pairs with: list_boards (discover existing boards and tag conventions), get_slos (get SLO IDs for panels), find_queries (locate saved query IDs). Panel type discriminator: each panel's "type" field determines which other fields are required. - type="query": id (query run PK) is required; name/description/chart_type/display_style are optional. - type="slo": id (SLO PK) is required. - type="text": content (Markdown string, max 10 000 chars) is required; id must be omitted. Panels render in the order you specify in the array. Size is optional (width 1-12, height in rows); omit size for auto-layout. Preset filters (max 5) add filterable column dropdowns to the board — each needs column + alias.

ActionTry it

Create marker

Creates a marker (a vertical annotation on charts) to mark a point or window in time, such as a deploy, incident, or config change. Scope it to one dataset or, with dataset_slug='__all__', the whole environment.

ActionTry it

Create recipient

Create a notification recipient (email, Slack, PagerDuty, or webhook) so it can be attached to triggers and SLO burn alerts. When to use: - "Alert the on-call channel when this trigger fires" — create a Slack recipient first, then pass its ID to create_trigger. - "Page the on-call team via PagerDuty" — create a pagerduty recipient with the integration key. - "Send a webhook when an SLO burns" — create a webhook recipient with optional custom headers and payload templates. - Before calling create_trigger or update_trigger when no suitable recipient exists in list_recipients. Required fields per type: - type="email": email_address - type="slack": slack_channel (team must have Slack OAuth configured) - type="pagerduty": pagerduty_integration_key - type="webhook": webhook_url + webhook_name Pairs with: create_trigger, update_trigger (consume the returned recipient ID), list_recipients (check existing recipients before creating). <gotchas> - Slack recipients require your Honeycomb team to have Slack OAuth already configured; the call will fail with an error if it is not. - Webhook custom headers cannot override Content-Type, User-Agent, or X-Honeycomb-Webhook-Token (max 5 headers). - Webhook payload template variables: names must start with a lowercase letter; subsequent characters can be letters (upper or lower) or digits (max 10 variables, max 64 chars per name). </gotchas>

ActionTry it

Create slo

Create an SLO (Service Level Objective) backed by an auto-created SLI derived column. When to use: - "Create an SLO for API latency" / "set a 99.9% availability target" — primary creation path. - When a user asks to track reliability for a service over a rolling time window. - After creating an SLO, call create_trigger with a baseline or threshold to alert on SLO burn. Pairs with: get_slos (list existing SLOs before creating), update_slo (adjust target or window after creation), create_trigger (fire a burn alert when error budget is draining fast). SLI expression syntax: Boolean derived-column expressions referencing span fields with a $ prefix. - LT($duration_ms, 1000) — true when latency < 1 000 ms - EQUALS($http.status_code, 200) — true when status is 200 - EQUALS($error, false) — true when no error flag is set target_per_million encoding: multiply the percentage by 10 000. - 99.9% → 999000 - 99.5% → 995000 - 99.0% → 990000 Derived column auto-create behavior: the tool validates the SLI expression before persisting the derived column. Invalid SLI expressions are rejected without creating the derived column. If a matching SLI derived column already exists, it is reused rather than duplicated. Multi-dataset SLOs: when dataset_slugs contains more than one slug, the SLI must be an environment-wide (shared) derived column — the tool handles this automatically, but both datasets must exist.

ActionTry it

Create trigger

Create a trigger that fires alerts when a query result crosses a threshold. When to use: - "Alert me when error rate exceeds 5%" / "page on-call when request count drops below 100" — primary alerting path. - "Create a trigger that only fires during business hours" — use evaluation_schedule with type=window. - "Alert when traffic is 50% above last week's baseline" — use baseline_details. - After creating an SLO, create a paired trigger with baseline_details to detect accelerating budget burn. Pairs with: list_recipients / create_recipient (obtain recipient IDs before creating the trigger), find_queries (locate a saved query to reference by query_id), get_triggers (verify after creation). Query source — mutually exclusive, exactly one required: - query: inline query spec (calculations required; filters, breakdowns, formulas optional). - query_id: ID of a saved query (from find_queries). Cannot provide both. Frequency encoding: frequency is in seconds (e.g. 900 = 15 min evaluation cycle). <gotchas> - query and query_id are mutually exclusive. Providing both returns an error. - Baseline triggers: threshold.op must be '>=' or '<=' (not '>' or '<'). The comparison is at the boundary because the baseline value is a ratio, and strict inequality against a ratio wouldn't resolve reliably. - Evaluation window vs frequency: when evaluation_schedule.type='window', the window duration must be at least 2x the trigger frequency. - formula passthrough pattern: when your inline query has formulas, add a passthrough formula (not calculation) — e.g. {"name":"volume","expression":"$all_requests"} — that aliases an existing calculation by name so it is directly addressable in ordering or threshold expressions. - frequency must be 60-86400 seconds and a multiple of 60. </gotchas>

ActionTry it

Feedback

Submit feedback about Honeycomb's MCP server to the agentic-intelligence team. When to use: - A tool returned unexpected, wrong, or confusing data. - You wanted a capability that no tool in this server provides. - A workflow felt unnecessarily clunky or required too many tool calls. - A tool description was misleading and caused you to use the wrong tool. Be specific: name the tool you used, what you tried, what you expected, and what you observed. Vague feedback is hard to act on. Pairs with: any tool — call this after completing (or failing) a task to report quality issues.

ActionTry it

Find columns

Search for columns and calculated fields by intent across one or all datasets in an environment. When to use: - "What column has the error rate?" / "Find columns related to duration or latency" — intent-based discovery. - Before composing a run_query, to confirm that columns with the right names exist. - When you are not sure which dataset contains the column you need (omit dataset_slug to search all). - After get_dataset_columns returns too many results to scan, use this to narrow by semantic relevance. Difference from get_dataset_columns: this tool ranks results by relevance to your search input across all datasets; get_dataset_columns returns the complete schema for one specific dataset. Pairs with: get_dataset_columns (full schema once you know the right dataset); run_query (use validated column names here); get_dataset (confirm dataset exists before scoping search).

ActionTry it

Find queries

Search query history and saved queries by intent; returns matching queries with their run PKs. When to use: - "Has anyone queried the error rate for checkout?" — check existing work before composing a new query. - Before calling run_query, verify a semantically similar query does not already exist. - "Show me recent queries for service X" — surface what the team has been investigating. - When the user pastes a query name or description and wants to find the underlying spec. Returns query specifications and run_pks. Pass a run_pk to get_query_results to retrieve the full results from that specific execution. Pairs with: get_query_results (fetch results from a returned run_pk); run_query (run a new query once you've confirmed no similar one exists); create_board (add a found query_id as a panel).

ActionTry it

Get aiconversation

Fetch the full event timeline for a single AI conversation, identified by its OpenTelemetry gen_ai.conversation.id attribute value. Prefer this over ad-hoc run_query filtered by conversation ID — it returns every LLM call, tool call, and related agent/task event (with span name, operation/category, agent name, model, tool name, duration, and error detail per event) plus an aggregate summary (LLM call count, tool call count, failure count, total tokens, total duration) in one call. Use it to debug or analyze one specific AI conversation end-to-end. PERFORMANCE: If you already know a timestamp for any event in the conversation (for example from a prior run_query result), pass it as event_timestamp — this skips a backwards probe scan over the last 60 days and is the dominant factor in tool latency.

ActionTry it

Get dataset

Get dataset metadata and its full column schema (columns + calculated fields), sorted by most recent write activity. When to use: - "What columns does the api-service dataset have?" — retrieve the schema for one dataset. - Before run_query, to verify column names and types exist in the target dataset. - "When was this dataset last updated?" — dataset metadata includes oldest queryable event time. Difference from get_dataset_columns: this tool returns dataset-level metadata (description, granularity, oldest event) alongside the column list. get_dataset_columns additionally supports fetching sample values for specific columns and has metrics-dataset support via metric_name. Pairs with: get_environment (upstream — confirms the dataset slug); get_dataset_columns (fetch sample values for columns or explore metrics datasets); find_columns (search across all datasets when the right dataset is unknown).

ActionTry it

Get dataset columns

Get the full column schema for one dataset, with optional sample values for specific columns. When to use: - Validating column names before composing a run_query (check the column exists and note its type). - "What values does the status column hold?" — pass the column name in 'columns' to fetch sample values. - Exploring a metrics dataset: list metric names first, then pass metric_name to discover filterable attributes. - When find_columns returns too many results and you want the authoritative schema for one dataset. Pairs with: find_columns (intent-based search when you do not know the dataset); get_dataset (dataset metadata alongside schema); run_query (use validated column names here).

ActionTry it

Get environment

Get details for a specific environment, including its dataset list sorted by most recent activity. When to use: - After get_workspace_context returns environment slugs, drill into one to see which datasets it contains. - "What datasets exist in staging?" — list mode for dataset discovery. - Before calling get_dataset or get_dataset_columns, confirm the dataset slug by checking environment contents. Returns up to 100 datasets per page by default, sorted by most recent write activity. Pairs with: get_workspace_context (upstream — provides environment slugs); get_dataset (drill into a specific dataset's schema); get_dataset_columns (full column schema once you know the dataset slug); find_columns (search across all datasets in this environment by intent).

ActionTry it

Get query results

Retrieve results and metadata from an existing query execution. Accepts a Honeycomb URL, a run_pk, or a query_id (returns most recent run). Provide exactly one of these three inputs. When to use: - After find_queries returns a run_pk and you want the actual result rows. - The user pastes a Honeycomb query URL from the browser — extract results without re-running. - After run_query executes a new query and returns a run_pk, use this to fetch the structured output. - You have a query_id and want the latest available result without triggering a new execution. Pairs with: find_queries (source of run_pks); run_query (source of fresh run_pks); list_boards (board detail mode returns query_ids per panel — pass them as query_id here to get the most recent run).

ActionTry it

Get semconv attribute

Get the full definitions of one or more semantic convention attributes by their exact names. Returns complete metadata for each attribute: type, brief description, detailed note, stability, deprecation status, requirement level, and examples. Accepts a batch of IDs so you can resolve all column names observed in a trace (e.g. from get_trace) in a single call. Attributes not found in the registry are returned in the "not_found" list rather than causing an error.

ActionTry it

Get span details

Summarize attributes and their common values observed on spans with a specific name. USE THIS AFTER list_spans (or whenever you already know a span_name) and BEFORE run_query. It tells you which attributes are populated on that operation, how many distinct values each has, and the top observed values — enough to answer most "what does X look like / what fields does X have / what status codes does X return / which users hit X" questions directly, without composing a custom query. Only escalate to run_query when you need: exhaustive value distributions beyond the sample cap, custom calculations (P95/P99, HEATMAP, math across columns), per-attribute COUNT/SUM aggregates over the full time range, or comparison/baseline analysis. Results are paginated with page and items_per_page after applying the sample cap. Paging is a presentation control, not an exhaustive cursor. Values are based on matching span samples, capped at 1000 rows across the selected time range.

ActionTry it

Get trace

Retrieve all spans for a specific trace ID and render them as a waterfall. When to use: - User pastes a trace ID from logs, a Slack alert, or the Honeycomb UI — fetch it here. - Drilling into a specific trace from a run_query result (trace.trace_id column). - Comparing parent/child span timing for a known trace to diagnose latency attribution. Pairs with: - run_query — filter where trace.trace_id = <value> to find traces matching a pattern, then drill in here. - list_spans / get_span_details — use first to discover span names so you can focus this view with focus_span_id. - run_bubbleup — if a query surfaces an anomalous cluster, BubbleUp identifies why; get_trace lets you verify with individual examples. <sampling> Span counts are actual stored spans, not sample-rate-adjusted. When sampling is active, the output includes a mean sample rate. Do not compare corrected query COUNTs (which are sample-rate-adjusted) directly to trace span counts. </sampling>

ActionTry it

Get triggers

List triggers (alert rules) for the team, or fetch full configuration for a single trigger. When to use: - "What alerts are firing?" / "What triggers do we have?" — list mode (no trigger_id). - "Show me the config for trigger X" / "Who gets paged for this alert?" — detail mode by trigger_id. - Auditing trigger configurations before creating or updating triggers. - Investigating an active alert to understand its threshold, query, and recipients. Modes: - List mode (no trigger_id): paginated table with name, status, threshold, frequency, recipients, and tags. - Detail mode (trigger_id provided): full query spec (calculations, filters, group-by, formulas), threshold, schedule, and recipient list. Recipients are shown as: type (name/target) [id:ID] — e.g. 'pagerduty (Platform Rotation) [id:abc123]'. Dynamic baseline vs static threshold: triggers with a populated 'baseline' column (list view) or 'Baseline' row (detail view) use a dynamic baseline — the threshold value is a delta (e.g. 50% higher than 1 hour prior), not an absolute count. The detail view formats Threshold as plain-English when baseline is in use. Pairs with: - create_trigger / update_trigger — list first to avoid duplicates; detail view shows current config to inform updates. - list_recipients — to resolve recipient IDs to human-readable names before creating or updating a trigger. - find_queries — to inspect the underlying saved query for a saved-query-backed trigger. - get_slos — SLO burn alerts appear as triggers; cross-reference here when an SLO's burn alert fires.

ActionTry it

Get workspace context

Call this tool first to orient yourself in a Honeycomb workspace. Takes no parameters. Returns the team name and slug, the current time, and a list of available environments with their slugs and dataset counts. Use the returned environment slugs with 'get_environment' to get dataset details for a specific environment.

ActionTry it

List aiconversations

Discover recent AI agent conversations (gen_ai.conversation.id values) in an environment, ordered by total event count (most active first) with per-agent activity. Use this tool as the starting point for any investigation of a dataset containing OpenTelemetry GenAI telemetry (attributes like gen_ai.conversation.id, gen_ai.agent.name, gen_ai.operation.name, gen_ai.request.model, or gen_ai.usage.*) — including service-level agent health, latency, failure, or token-usage questions. Prefer it over ad-hoc run_query to first identify the conversations worth drilling into. Output is a table with one row per conversation and columns: Conversation ID, Event Count, Error Count, Total Tokens, Agents (events/errors), Services, Start Time, End Time. The Event Count, Error Count, and Total Tokens columns are conversation-wide totals summed across every agent in that conversation. Total Tokens is SUM(gen_ai.usage.input_tokens) + SUM(gen_ai.usage.output_tokens) across the conversation's events, matching the definition used by get_aiconversation; events that lack token attributes contribute 0, so tool-only conversations will show 0. The Agents (events/errors) column is a semicolon-separated list of "<gen_ai.agent.name>=<events>/<errors>" entries so you can attribute activity or errors to a specific agent. The Services column is a comma-separated, alphabetically sorted list of the service.name values that emitted events for the conversation. Start Time and End Time are the earliest and latest gen_ai event timestamps seen for the conversation, each formatted in RFC3339 UTC (empty string when unknown). Pass a returned gen_ai.conversation.id into get_aiconversation to load the full timeline for that conversation. Events that carried no gen_ai.agent.name are excluded from the Agents column but their counts still roll up into the conversation-level Event Count and Error Count totals; likewise events with no service.name are excluded from the Services column. To answer questions like "which conversations had the most errors for agent X", parse the Agents column on each row for the entry whose name matches X and use its errors value. Default window is the last 24 hours, matching the Honeycomb UI behavior. Optional agent_name and service_name filters restrict the returned conversations to those that include at least one event for the given gen_ai.agent.name and/or service.name. Both filters are exact, case-sensitive string matches and are combined with AND when both are supplied. When agent_name is supplied the filter is applied at query time, so the Event Count, Error Count, and Total Tokens columns reflect only that agent's activity within each conversation (not the conversation-wide totals). IMPORTANT: For time parameters, prefer human-readable formats over Unix epoch integers: - Use relative expressions like "now", "-24h", "last 7 days", "2 hours ago" - Use datetime strings like "2024-01-15T10:30:00Z" or "2024-01-15" - Use duration strings like "24h", "7d", "2h30m" for time_range - Avoid calculating Unix epoch timestamps yourself

ActionTry it

List boards

List boards (saved dashboards) in an environment, or fetch one board's full contents by ID. When to use: - "What dashboards do we have for service X" / "is there an existing board for Y" — list mode with tag filters. - "Show me the contents of board Z" — detail mode by board_id, returns every panel (queries, SLOs, text) with descriptions. - Before calling create_board, to check whether a similar board already exists. Modes: - List mode (default): pass environment_slug, optionally filter by tags (AND semantics across multiple tags). Returns paginated board metadata only. - Detail mode: pass board_id (environment_slug still required). Returns the single board with all panels and their underlying queries/SLOs resolved. Pairs with: create_board (this tool's output reveals existing tags and naming conventions to follow); get_query_results (panel query_ids from detail mode can be passed as query_id to fetch the most recent run's results).

ActionTry it

List recipients

List all pre-registered notification recipients (email, Slack, PagerDuty, webhook) for the team. When to use: - Before create_trigger or update_trigger, to find the recipient IDs to attach. - "What Slack channels are configured for alerts?" — audit existing notification targets. - When a user asks which notification channels are available for a new alert. Returns each recipient's ID, type, and routing details. Pass recipient IDs directly to create_trigger or update_trigger. Pairs with: create_recipient (register a new notification target); create_trigger (attach recipients by ID); update_trigger (update which recipients a trigger notifies).

ActionTry it

List semconv namespaces

List the top-level semantic convention namespaces available in this team's registry. Returns namespace prefixes like "http", "db", "messaging", "rpc", "k8s". Use this to orient yourself before calling search_semconv — it tells you what telemetry domains have standardised attribute definitions.

ActionTry it

List spans

List span names in trace data, ranked by count, with how often each is a trace root and which dataset the count came from. USE THIS FIRST for any question about what's happening in the system: "what's slow", "what's erroring", "what does service X do", "which endpoints exist", "what jobs run here", "show me the operations on Y". It is faster, cheaper, and more diagnostic than composing an equivalent run_query by hand, and it works across all trace-aware datasets in the environment without you having to know which dataset to target. Workflow: 1. Call list_spans (this tool) to see the span-name landscape and pick a candidate. 2. Call get_span_details with that span_name (and its dataset_slug from the row) to learn which attributes and values are present. 3. ONLY if you need a custom calculation, exhaustive value distribution, percentile/heatmap, or per-attribute aggregate that get_span_details cannot express — fall through to run_query, scoped to the dataset_slug from the row. Reverse lookup — "which span carries attribute X": set populates_attribute to the attribute name to restrict results to only the span names that POPULATE that attribute, still ranked by count. Use this when you have an attribute and need the span that emits it (e.g. find the span that populates mcp.tool.name), instead of trusting whichever span happens to have the highest raw volume. Each row has: - span_name: the operation/endpoint/job name. - dataset_slug: which dataset this row's counts came from. The same span_name can appear in multiple datasets (e.g. a service emits to several); each (span_name, dataset_slug) pair is a separate row. Use the dataset_slug in follow-up tool calls so aggregates aren't smeared across datasets. - count: total spans with that name in that dataset over the time range. - root_count: subset of those spans that have no parent (i.e. are trace roots). Names where root_count == count are always trace entry points (HTTP handlers, root jobs). Names where 0 < root_count < count are operations that appear as both roots and children — common for shared names across services. Names where root_count == 0 are always children (DB calls, internal helpers). Results are paginated with page and items_per_page after applying the query cap. Paging is a presentation control, not an exhaustive cursor; narrow the time range or dataset when you need deeper coverage.

ActionTry it

Refinery docs

Read Honeycomb Refinery documentation. Refinery is Honeycomb's trace-aware tail-based sampling proxy. Available topics: - overview: Refinery overview and key concepts - architecture: Architecture, deployment patterns, and how it works - sampling-types: Sampling strategies (deterministic, dynamic, rules-based, throughput) - stress-relief: How stress relief works and how to respond when it activates - troubleshooting: Common Refinery issues, diagnostic queries, and solutions - metrics: Complete reference of all Refinery metrics with descriptions - configuration: Configuration reference for all Refinery settings - rules: Guide to writing sampling rules for the rules-based sampler Use this tool when you need detailed technical information about Honeycomb Refinery to answer user questions.

ActionTry it

Run bubbleup

Run BubbleUp analysis to find what makes a selected data subset different from the baseline. BubbleUp compares value distributions across all schema columns between a "foreground" selection (the interesting region) and the remaining data (the baseline). Columns where the foreground and baseline distributions diverge most are ranked highest. When to use: - User asks "why did latency spike at 14:00?" — pick a heatmap region and BubbleUp it. - Investigating a heatmap selection returned by run_query; you already have a query_pk. - "Compare this known-bad subset to baseline" — user wants to know what's different. - After a run_query heatmap shows an interesting region, surface the root-cause attributes. Pairs with: - run_query — must run first to obtain a query_pk; that query's time range becomes the baseline. - get_trace — drill into specific traces that fall inside the anomalous selection. - find_columns / get_dataset_columns — if you need to know what columns exist before starting analysis. Modes: - New analysis: provide query_pk + selection (heatmap or group selection). - Paginate existing results: provide bubbleup_result_id (query_pk and selection are ignored).

ActionTry it

Run query

Run a time-series aggregation query against a Honeycomb dataset and return computed results. When to use this tool: - "Compute a percentile / histogram of X" — use P50/P99/HEATMAP calculations. - "Show me error rate before and after deploy" — use two named calcs + a formula, scoped by time. - "Rank services by p99 latency" — use P99 with a breakdown + order. - "See distinct values of X and their frequency" — COUNT with a breakdown on X. - "Compare request volume across services" — COUNT breakdown on service.name. - "Find endpoints where tail latency exceeds 1s" — P99 + having clause. - "Generate a heatmap of request duration" — HEATMAP calculation. When NOT to use this tool: - Discovering what spans or operations exist → use list_spans instead. - Looking at a specific trace → use get_trace instead. - Finding existing saved queries → use find_queries instead. - Exploring which columns a dataset has → use get_dataset_columns or find_columns first. Pairs with: list_spans, get_span_details, find_columns, get_dataset_columns, get_trace, run_bubbleup. <examples> Basic COUNT over the last 24 hours: ```json {"environment_slug": "production", "dataset_slug": "api", "query_spec": {"calculations": [{"op": "COUNT"}], "time_range": "24h"}} ``` Error rate formula: two named calcs combined with a formula, ordered by the formula name (the correct ordering style when formulas are present). The passthrough formula "volume" surfaces a raw calc value alongside formulas: ```json {"environment_slug": "production", "dataset_slug": "api", "query_spec": { "calculations": [ {"op": "COUNT", "name": "total"}, {"op": "COUNT", "name": "errors", "filters": [{"column": "error", "op": "=", "value": true}]}], "formulas": [ {"name": "error_rate", "expression": "$errors / $total * 100"}, {"name": "volume", "expression": "$total"}], "breakdowns": ["service.name"], "orders": [{"column": "error_rate", "order": "descending"}], "time_range": "1h", "limit": 20}} ``` Relational fields: any.X in a breakdown requires a matching WHERE filter on the same any.X column: ```json {"environment_slug": "production", "dataset_slug": "traces", "query_spec": { "calculations": [{"op": "COUNT"}, {"op": "P99", "column": "duration_ms"}], "filters": [{"column": "any.http.route", "op": "exists"}], "breakdowns": ["any.http.route"], "time_range": "2h"}} ``` </examples> <interpreting_results> The response is rendered as Markdown with these sections (each is omitted if empty): - "# Results" — a Markdown table of aggregate rows. Headers are breakdown columns followed by calculation columns. When formulas are present, the table contains ONLY breakdown columns and formula columns — raw calculation columns (including percentiles like P50/P95, and even named COUNTs) are NOT rendered. To surface a raw calculation's value alongside formulas, add a passthrough formula such as {"name": "p95", "expression": "$p95_latency"}. If a breakdown's cardinality exceeded the spec's limit, an "OTHER" row collapses the remainder; a "TOTAL" row may also appear summing across groups. A "Truncated: shown N / total M" footer indicates more rows than the table displays. - 1D heatmaps render inline within Results when a HEATMAP calculation has no breakdown. - "# Samples" — present only when include_samples=true. Up to 10 raw matching events; aggregations are stripped from the underlying execution in this mode, so samples replace aggregates rather than accompany them. - "# Time Series" — ASCII line graphs per group when the spec has a granularity (time-bucketed series). Width 120, height 12. - "# Heatmaps" — 2D time-series heatmaps when a HEATMAP calculation is paired with breakdowns or granularity. - "# Markers" — deploy/incident markers overlapping the time range, when present. - "# Query Spec" — the canonicalized JSON spec the server actually executed. Useful when comparing what you sent to what ran. - "Metadata:" YAML block at the bottom — contains query_run_pk (passable to get_query_results), query_url (Honeycomb permalink to share with humans), query_result_json / query_result_image (download URLs), elapsed_str, granularity, total (result count), rows_examined. When data is sampled, a sampling banner appears above Results listing the mean sample rate and which calculations are sample-rate-weighted vs. raw. If mean_sample_rate > 10x and usage_mode is off, an extra warning notes that COUNT values are corrected estimates and won't match raw trace span counts. </interpreting_results> Important: filter operators use symbols (=, >=, !=). Expression functions inside calculated_fields use words (GTE, EQUALS). Never use GTE/LTE as filter operators.

ActionTry it

Search semconv

Search the semantic convention registry for attributes matching a query. Returns structured attribute definitions including name, type, brief description, stability, and deprecation status. Use this to discover canonical attribute names before constructing queries. The registry is backed by OTel semantic conventions at the team's configured version (defaulting to the latest release). Teams with a custom attribute schema will also see their custom attributes. Typical workflow: 1. list_semconv_namespaces → understand what telemetry domains are covered 2. search_semconv(query="http status") → find relevant attribute names 3. get_semconv_attribute(id="http.response.status_code") → get full definition before using in a query When building queries across datasets with mixed schema versions, search_semconv returns the canonical name at the team's configured version. Use that name in queries — Honeycomb normalises attribute names at ingest using schema migration transforms.

ActionTry it

Update board

Edit an existing board (dashboard) in place. Add, remove, update, or reorder panels; rename; and replace preset filters or tags. When to use: - "Add the new error-rate query to the API board" — append panels to an existing board. - "Remove the deprecated SLO panel from this dashboard" — drop a panel by id. - "Rename the panel" / "switch this query to a table view" — modify an existing panel's name, description, chart_type, display_style, or size. - "Reorder the board so SLOs come first" — reorder panels via panel_order. - "Update the preset filters / tags" — replace the full set (replace, not merge). - Always run list_boards with board_id first so you have the current type+id of each panel. Pairs with: list_boards (board_id and per-panel ids; the IDs you reference here come from there), find_queries (query run PKs for new query panels), get_slos (SLO PKs for new SLO panels), create_board (create instead of update). Operations apply in this order: remove_panels -> update_panels -> add_panels -> panel_order. Within a single call: removed panels can be referenced in remove_panels but not anywhere else; newly added text panels can not be referenced in panel_order or update_panels because they have no stable id until saved (added text panels are appended after any ordered panels). Replacement-set semantics: tags and preset_filters replace the full set when provided. To add one tag, read the current tags from list_boards, append, and pass the full updated list. Pass an empty array to clear. Omit entirely to leave unchanged. Sizing: if you omit size on an added panel, MCP auto-sizes it (queries by complexity; SLO/text use defaults). For updated panels, size is preserved unless you explicitly supply a new size or set auto_size_updated_panels=true (which auto-sizes query panels in update_panels when their size is omitted).

ActionTry it

Update slo

Update an existing SLO. Only the fields you supply change; omitted fields keep their current values. When to use: - "Tighten the SLO target to 99.95%" / "extend the window to 30 days" — adjust reliability parameters. - "Rename this SLO" / "update the SLO description" — housekeeping changes. - "Replace the SLO's tags" — tag management (tags replace entirely; pass empty array to clear all). - Datasets cannot be changed after creation; create a new SLO if you need different datasets. Pairs with: get_slos (retrieve slo_id and current values), create_slo (create instead of update), update_trigger (update a paired burn-alert trigger simultaneously). Tag replacement semantics: when tags is provided it replaces the entire tag set. To add one tag, first read the current tags via get_slos, append the new tag, and pass the full updated list.

ActionTry it

Update trigger

Update an existing trigger. Partial update — only the fields you supply change; omitted fields keep their current values. When to use: - "Disable this trigger temporarily" — set disabled=true without touching other fields. - "Add a Slack channel to the trigger's recipients" — replace recipients with the full updated list (note: replaces, does not merge). - "Lower the threshold from 5% to 3%" — update threshold.value. - "Slow down the evaluation frequency" — change frequency. Pairs with: get_triggers (retrieve trigger_id and current state), list_recipients / create_recipient (get recipient IDs before updating), update_slo (update the paired SLO at the same time). Recipients replacement semantics: when recipients is provided, it replaces the entire recipients list. To add one recipient, read current recipients from get_triggers, append the new ID, then pass the full list here. Pass an empty array [] to remove all recipients.

ActionTry it

How the Honeycomb MCP integration works

The Honeycomb MCP integration connects your Dench AI CRM directly to Honeycomb MCP, so agents can read and act on your Honeycomb MCP data as part of everyday work — answering questions in chat, keeping your CRM in sync, and running automations without anyone copying data between tools.

32 actions are available for agents to invoke on your behalf. Every call runs through Honeycomb MCP's own authorization, scoped to the account you connect.

Set up Honeycomb MCP in Dench

  1. 1

    Sign in to your Dench workspace and open Integrations.

  2. 2

    Find Honeycomb MCP and click Connect — you'll authorize access through Honeycomb MCP's own sign-in flow. No API keys or code required.

  3. 3

    Ask an agent to use Honeycomb MCP in chat, or call it from an automation.

  4. 4

    Manage or disconnect the connection any time from workspace settings.

Frequently asked questions

How does the Honeycomb MCP integration work with Dench?

The Dench Honeycomb MCP integration connects your AI CRM to Honeycomb MCP, so AI agents can work with your Honeycomb MCP data as part of chats, automations, and CRM workflows. You connect your account once, and every agent in your workspace can use it — governed by your workspace permissions.

What actions can AI agents perform with Honeycomb MCP via Dench?

The Honeycomb MCP integration currently exposes 32 actions, including Canvas agent invoke, Canvas agent poll response, Create board, Create marker, Create recipient, and Create slo. Agents invoke them on your behalf from chat or from automations.

Do I need to write code to connect Honeycomb MCP to Dench?

No. You connect Honeycomb MCP from your Dench workspace using Honeycomb MCP's own sign-in and authorization flow — no API keys to copy, no glue code to maintain.

Is the Honeycomb MCP integration secure?

Connections are authorized through Honeycomb MCP's own authentication flow, and Dench stores only the authorization needed to act on your behalf. You can review and disconnect the Honeycomb MCP connection from your workspace settings at any time.

Honeycomb MCP | Dench AI CRM