Building on MCP.

The session

Building on MCP.

Model Context Protocol (MCP) is the standard for how an agent talks to a tool. It is not an agent framework. It is not a workflow engine. It is a JSON-RPC contract that lets a tool advertise what it can do, and lets an agent ask for the tool to do it. That is the entire spec. The rest is implementation, and the implementation is where the production work happens.

The reason MCP matters is that without a standard protocol, every agent-to-tool integration is a bespoke connector. 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. The integration surface collapses from N×M to N+M.

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 agent does not need to know how the tool is implemented. The tool does not need to know how the agent is implemented.

In Netwit Agentic OS, every system integration is an MCP server. PostMTA exposes a "send email" tool. InboxGrove exposes a "classify email" tool. The ChartFlow service 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. The RBAC layer checks every call against the agent's permissions.

The patterns that work in production are narrower than the spec. The patterns that fail in production are also narrower. The patterns that work: 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 agent cannot reason about a 500. The right answer is to return a structured error with a code the agent can match on and a human-readable message. The third most common failure is a tool that does too much. The agent picks it when it should have picked a more specific tool. The right answer is to break the tool apart.

The session walks through the MCP spec at the wire level (JSON-RPC over stdio, over HTTP, over WebSocket), a live build of an MCP server for a fictional internal system, the connection of that server to Netwit Agentic OS, and the agent calling the tool to complete a real task end-to-end. The recording and the example server code are sent to all registrants.