Christine Yen—developer-turned-CEO—explains why Honeycomb built an MCP server and why every observability vendor may follow. MCP, short for Model Context Protocol, acts like a concierge for AI agents: It makes a product’s API, telemetry schema and helper tools easily discoverable so large-language models can ask precise questions instead of guessing. Yen sees it as table stakes for letting bots troubleshoot production just as humans do.

Speed is the first requirement. Engineers won’t wait minutes for an LLM to fetch a log slice or distribution graph. Honeycomb’s mantra—fast is a feature—now pays off when an agent fires off dozens of sub-queries during root-cause analysis. Yen jokes that no one wants to brew coffee while a model thinks, so the platform’s near-instant queries translate directly into snappier conversational answers.

Depth of data is the second pillar. Because customers pipe richly labeled events (“checkout_latency_ms”, “user_tier”) instead of fixed dashboards, even off-the-shelf models can map plain-English prompts to meaningful fields. Yen argues this beats the “narrow metric lists” many teams still rely on; a model that understands business context can pinpoint anomalies without endless prompt engineering.

Yen admits she no longer remembers every field in Honeycomb’s own dog-food cluster—but the MCP server does. She expects newcomers to treat agents as default copilots, while power users toggle between raw queries and natural language. The challenge for vendors, she says, is balancing both paths without forcing engineers into one camp.

Yen’s closing advice: start experimenting now, map where your context lives and demand that every tool expose it through open protocols. The future observability stack won’t just collect data; it will serve it—fast and in the right context—to whatever human or agent asks first.