What is an MCP server?

The Model Context Protocol splits the world into clients, which live inside AI assistants, and servers, which sit in front of services. An MCP server declares a list of tools with names, descriptions, and typed parameters; the assistant’s client fetches that list, and the model reads it to decide which tool fits the task. Servers can run locally on the user’s machine or remotely over HTTP, and one server can serve many different assistants, which is the point of the standard.

What separates a good server from a technically working one is mostly writing. Tool names and descriptions are read by a model, not a human, so they need to say precisely when the tool applies, what it returns, and what the parameters mean; a server with vague descriptions gets called wrongly or not at all. Consistent response shapes and sensible auth scopes matter for the same reason: the caller is software that will act on whatever it receives.

The evaluation question buyers should ask is parity. Many vendors ship a thin MCP wrapper over a small fraction of their API, so an agent hits walls a human user would not. Before building on a server, check what share of the real product surface it exposes, whether the shapes match the API, and how authentication is handled. A server that mirrors the full API is a second front door; a partial wrapper is a demo.

How this shows up in Waldo

Waldo’s MCP server is native rather than a wrapper: the same 200+ tools as the API, with the same auth and the same shapes, covering brand, category, and audience surfaces through tools like brand_overview, discover_ads, audience_insights, and category_trends. Every response links to sources, which matters when the caller is an agent that will summarize what it gets. Self-serve key at /build/get-started.

Related terms and reading