VZU Insights · VZU primer · 2026-06-12
MCP, explained.
Model Context Protocol, in plain language. What it does, what it does not, and how VZU uses it inside Agentic OS.
The essay
MCP, explained.
Model Context Protocol (MCP) is a JSON-RPC standard for how an agent calls a tool. It is not an agent framework. It is not a workflow engine. It is the contract that lets a tool advertise what it can do and lets an agent ask for the tool to do it. This is a primer on what MCP is, what it does, and what it does not.
The reason MCP matters is the integration math. Without a standard, every agent-to-tool integration is bespoke. The agent vendor writes one. The tool vendor writes another. The customer pays for both. With MCP, the tool vendor writes one MCP server and every MCP-compatible agent can use it. The economics flip from N×M (every agent to every tool) to N+M (every agent speaks MCP, every tool speaks MCP).
An MCP server is, conceptually, three things: a list of tools (with name, description, input schema, output schema), a list of resources (data the tool can read), and a list of prompts (pre-built sequences the agent can invoke). When an agent connects to an MCP server, it reads the tool list, decides which tool to call, calls it, gets the result, and continues reasoning.
The patterns that work in production: stateless tools with a single responsibility, structured inputs, structured outputs, fast response times, and explicit error semantics. The patterns that fail: stateful tools that hold long-running connections, tools that depend on user-specific context that the agent does not have, tools with ambiguous error responses, and tools that are too slow for an interactive agent loop.
The most common production failure is a tool that takes 30 seconds to return. The agent times out. The user sees an error. The right answer is to make the tool async — return a job ID immediately, let the agent poll. The second most common failure is a tool that returns a 500 when the input is wrong. The right answer is to return a structured error with a code the agent can match on. The third most common failure is a tool that does too much. The right answer is to break the tool apart.
In the Netwit runtime, every system integration is an MCP server. PostMTA exposes a "send email" tool. InboxGrove exposes a "classify email" tool. ChartFlow exposes a "generate clinical note" tool. TrackSphere exposes a "log field event" tool. The agent composes them. The agent decides which to call, in what order, and what to do with the result. The audit trail records every call.
Disclosure
Dhiraj Chatpar is the founder of VZU. The VZU team wrote this essay. The runtime described is in production at a small number of operators. The benchmarks, where cited, are from internal testing or from operators who have given permission to publish.