Honeycomb MCP server
Honeycomb's official MCP server: query traces, metrics, and logs, run BubbleUp, and manage Boards, Triggers, and SLOs from your agent.
The Honeycomb MCP server is Honeycomb's official integration that connects a coding agent to your observability data so it can investigate production behavior and cross-reference it with the codebase. Instead of bouncing between the Honeycomb UI and your editor, the agent can discover environments and datasets, write and run time-series queries with calculations and breakdowns, fetch saved or historical query results, and run BubbleUp to surface the dimensions that explain an anomaly. It reaches into traces and spans (rendering a trace as a waterfall, listing span names, drilling into span attributes), maps service-to-service dependencies, reviews active anomaly profiles, and even reads recent AI-agent conversation telemetry. A set of write tools lets it create and update Boards, Triggers, SLOs, and notification recipients, and invoke Canvas investigations for collaborative root-cause work.
The canonical deployment is the hosted remote endpoint at https://mcp.honeycomb.io/mcp (with an EU endpoint at https://mcp.eu1.honeycomb.io/mcp), authenticated via OAuth 2.1 so teams can onboard through the browser with no long-lived tokens on disk; an API-key option exists for headless agents. The previously published self-hosted server is deprecated in favor of the hosted endpoint. Read tools work with read scopes; the write tools (Boards, Triggers, SLOs, recipients, Canvas) require the corresponding write scopes.
Quick install
Copy-paste configs are provided for all 8 supported clients. Pick your client below.
Available tools
| Tool | Description |
|---|---|
| get_workspace_context | Provides team name, current time, and the environment list with dataset counts. |
| get_environment | Returns details for a single environment, including its datasets and calculated fields. |
| get_dataset | Retrieves metadata and the full column schema for a dataset. |
| get_dataset_columns | Returns the column schema, with optional sample values for specific columns. |
| run_query | Executes time-series aggregation queries with support for calculations and breakdowns. |
| get_query_results | Fetches results from a previously executed query by URL or ID. |
| find_queries | Searches query history and saved queries by intent. |
| find_columns | Locates columns and calculated fields using natural-language keywords. |
| run_bubbleup | Runs BubbleUp analysis to identify statistically significant differences in query results. |
| get_trace | Retrieves all spans for a trace ID and renders them as a waterfall. |
| list_spans | Lists span names ranked by count, with trace-root frequency. |
| get_span_details | Returns attribute summaries and common values for specific span names. |
| get_service_map | Shows service-to-service call dependencies for a time range. |
| get_anomaly_service_profiles | Returns active anomaly-detection profiles for the team. |
| search_semconv | Searches the semantic convention registry for matching attributes. |
| get_semconv_attribute | Returns the full definitions of semantic convention attributes. |
| list_semconv_namespaces | Lists top-level semantic convention namespaces. |
| list_boards | Lists Boards in an environment or shows the full contents of a Board. |
| create_board | Creates a Board with query, SLO, and text panels. |
| update_board | Modifies an existing Board with panel changes and filter updates. |
| get_triggers | Lists Triggers or shows the detailed configuration for a single Trigger. |
| create_trigger | Creates a Trigger that fires alerts when a query threshold is crossed. |
| update_trigger | Modifies an existing Trigger configuration. |
| get_slos | Lists SLOs or returns the detailed status and graphs for a specific SLO. |
| create_slo | Creates an SLO with an auto-created Service Level Indicator derived column. |
| update_slo | Modifies an existing SLO configuration. |
| list_recipients | Lists pre-registered notification destinations with their IDs. |
| create_recipient | Creates a new notification recipient for Triggers and SLO burn alerts. |
| canvas_agent_invoke | Sends a message to a Canvas agent for a collaborative investigation. |
| canvas_agent_poll_response | Polls for results from a previously issued Canvas agent call. |
| list_aiconversations | Lists recent AI-agent conversations with telemetry summaries. |
| get_aiconversation | Returns the full event timeline for a single AI conversation. |
| refinery_docs | Reads Honeycomb Refinery documentation for configuration questions. |
| feedback | Submits feedback about the Honeycomb MCP server experience. |
Required configuration
- HONEYCOMB_API_KEYOptional
Honeycomb API key for headless/unattended agents. Not needed when using OAuth on the remote endpoint.
What you can do with it
Investigate a production spike without leaving the editor
The agent writes a query, runs BubbleUp to find the dimensions that explain an anomaly, then pulls the relevant trace waterfall and span attributes to point at the offending code path.
Manage observability config from the agent
Create or update Boards, Triggers, and SLOs and wire up notification recipients directly, so a new service ships with dashboards and alerting in the same session it was built.
FAQ
- Is it free?
- The MCP server itself is free and open source; you need a Honeycomb account, and usage of the underlying platform is governed by your Honeycomb plan. Querying enterprise data and the richer write tools follow your account's entitlements and scopes.
- Does it support remote/OAuth?
- Yes. The canonical deployment is the hosted remote endpoint at https://mcp.honeycomb.io/mcp (EU: https://mcp.eu1.honeycomb.io/mcp) using OAuth 2.1, so members onboard through the browser with no long-lived tokens on disk. An API-key option is available for headless agents, and the older self-hosted server is deprecated.
- Can the agent change my dashboards and alerts?
- Only with write scopes. Read tools work with read access; the write tools for Boards, Triggers, SLOs, recipients, and Canvas investigations require the corresponding write scopes, so you can grant a read-only token to keep an agent observational.