Seems like you can’t throw a rock without hitting an announcement about a Model Context Protocol server release from your favorite application or developer tool. While I could just write a couple hundred words about the Honeycomb MCP server, I’d rather walk you through the experience of building it, some of the challenges and successes we’ve seen while building and using it, and talk through what’s next. It should be pretty exciting, so strap in!

(I get it, skip the explanation and show me the good stuff)

Help! I studiously avoid everything involving AI…

…and/or I just got out of a time portal from 2021. What’s Model Context Protocol?

An exhaustive description of what MCP is is slightly out of scope for this blog post, but I do want to give you a brief overview. First, recall how modern AI tools work—specifically, Large Language Models. In an extremely broad sense, LLMs are designed to predict ‘what token should come next’ in response to input. If you’ve ever played around with markov chain generators, this concept shouldn’t be too unapproachable. Where LLMs shine, though, is that they’re more or less able to function as non-deterministic, natural language computers. Through prompting—the inputs you provide to a LLM—you’re able to control and specify the output of the model, even going so far as to coerce it to output in a specific format.

This notion led to the development of tool calling in LLMs. The idea of tool calls is that, through crafted prompts, an LLM can both read and write to JSON objects that obey a defined schema, provided in their context. The context is, effectively, the ‘short term memory’ of an LLM. Tool calling opened up a lot of doors for generative AI, because it gave developers a way to interface with the model. Developers could write tools that could expose functions through JSON Schema, LLM interface authors could provide those tool definitions to the model context in a conventional way, and the LLM could kinda figure the rest out on the fly. 

A simple example of this is a calculator. LLMs aren’t great at doing math, but if you provide a ‘calculator’ tool that exposes a schema of operations—add, subtract, etc.—and write some code to perform the calculation, then the LLM can determine what to do when a user asks “What’s 9394792 + 190100158?” It calls the calculator tool with the appropriate parameters, gets the result, and displays it to the user. These tool calls can be then chained by the LLM in order to perform more complex operations.

Wait, that sounds extremely stupid.

I mean, kinda, sure.

Tool calling is great because it allows you to build systems, which is the point of this job, I think. LLMs aren’t great at doing things that aren’t… well, token prediction or classification or other machine learning stuff. It doesn’t make sense to try to ‘teach’ an LLM to be ‘good at calculations.’ We don’t need the ML model to do that if we can give it a calculator, right? 

In addition, while passing JSON around seems pretty inelegant, it’s one of those things that LLMs have a great intrinsic sense for because there’s so much JSON in the training data. Models are ridiculously good at parsing and writing valid JSON, partially because it’s simple, and partially because it’s ubiquitous. Why not use something that already exists and everyone understands pretty well for the task of “having a LLM talk to things that aren’t the LLM and also aren’t the user?”

In late 2024, Anthropic introduced the Model Context Protocol, a specification for writing servers and clients that respected this tool calling approach. MCP has become an overnight hit (so big in fact that there are already competing standards, wee!) because it solves a pretty big pain point for d