MCP Servers as an Encouraging Parent

Even in the hype-driven world of LLMs, the buzz around Model Context Protocol (MCP) is hard to ignore. Which is interesting because it seems there is still a significant amount of confusion as to what MCP actually is.

In particular, what exactly distinguishes an MCP server from an API? Should you pick one over another and, if so, how does one decide which is right for which use-case?

In thinking through those questions I believe I have a nice analogy which at least hints at how one might think about the main pieces of the protocol. That is - the MCP server as an encouraging parent.

To land at that spot, I should first introduce the other players which make up the protocol.

MCP Elements

  • Host - Some Large Language Model (LLM) interface. E.g. Claude Desktop Application
  • Client - A chunk of logic (configuration) on the Host with knowledge of the available MCP servers
  • Server - ??? AGI ???
  • Local or Remote Service - A service which you'd like the LLM to control or interact with

To put the above in a sentence - hosts have clients which inform them about servers which do something to aid the communication with/control of services.

The Encouraging Parent

Imagine the following scene - A parent and their child sit before a large clear plastic box, full to the brim of Lego1 bricks.

We can imagine preset day LLMs as something similar to that child - very energetic, occasionally confused, agentic systems. Left alone with the Lego bricks perhaps something useful may emerge, but you wouldn't bet on it. However, with some guidance from their parent, the odds increase significantly.

If we now transpose the assembly of those Lego bricks to the various functionalities of the services which we may want our LLM assistants to control:

  • Host - Child
  • Client - familial relationship between child and parent. I.e. some bond that establishes a common language and knowledge of the parent from the child.
  • Server - Parent
  • Local/Remote service - Lego bricks

Back in MCP-land, the server may provide some or all of the following:

  1. Resources: File-like data that can be read by clients (e.g. API responses or the contents of a file)
  2. Tools: Functions that can be called by the LLM
  3. Prompts: Pre-written templates that can help the user accomplish specific tasks using the LLM

Clearly the communication between parent and child is far richer but, if you'll indulge me, you can imagine extending the analogy. Parents can reach farther to grab bricks (resources) their child cannot reach. They can snap together pieces on their child's behalf (tools) and perhaps most critically, they can prompt their child to think this way or that, to help them achieve their goal (prompts).

The Missing User

You may have noticed, at no point have we invoked the notion of a user. I suppose we could retrofit the analogy to consider the scene above as playing out in a psychologist's office where the user is the tasking the child with some objective. However, I think perhaps that misses the longer term aim of agentic systems.

If we model forward what agency is supposed to look like - LLMs should act independent of user instruction. Or at least, on a local (sub-task) level, it may appear that way - "ah you're currently looking up Indonesian sesame seed futures and the hatching cycle of the Myanmar cicada. I did give you the prime directive to make me money on the stock market so I don't get it, but cool, here's that Bloomberg MCP server you requested."

While I have major doubts text completion, however lengthy or rich with context, is anything approaching actual intelligence. MCP opens up fantastic new possibilities to further extend LLM capabilities by bringing functionality and resources from the "real world" into textual space. As MCP specific training data grows, I'm excited to see what new possibilities are unlocked.

Footnotes

  1. While other toys may work for this analogy, there is something quite special about Lego. Other toys have a "correct" way to engage with them, Lego does not. The end result of a session with Lego bricks is up to the agency of the individual doing the assembling. Given agency is the primary thing we want to give to (or perhaps see emerge in) LLMs, an analogy to Lego bricks feels most appropriate. ↩