Building on MCP.

The session

Building on MCP.

Model Context Protocol (MCP) is the standard for how an agent invokes an action. It is not an agent framework. It is not a workflow engine. It is a JSON-RPC contract that lets an action advertise what it can do, and lets an agent ask for the action to be performed. 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-action integration is a bespoke connector. The agent vendor writes one. The action vendor writes another. The customer pays for both. With MCP, the action 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 actions (with name, description, input schema, output schema), a list of resources (data the action 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 action list, decides which action to call, calls it, gets the result, and continues reasoning. The agent does not need to know how the action is implemented. The action 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" action. InboxGrove exposes a "classify email" action. The ChartFlow service exposes a "generate clinical note" action. TrackSphere exposes a "log field event" action. 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 actions with a single responsibility, structured inputs, structured outputs, fast response times, and explicit error semantics. The patterns that fail: stateful actions that hold long-running connections, actions that depend on user-specific context that the agent does not have, actions with ambiguous error responses, and actions that are too slow for an interactive agent loop.

The most common production failure is an action that takes 30 seconds to return. The agent times out. The user sees an error. The right answer is to make the action async — return a job ID immediately, let the agent poll. The second most common failure is an action 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 an action that does too much. The agent picks it when it should have picked a more specific action. The right answer is to break the action 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 action to complete a real task end-to-end. The recording and the example server code are sent to all registrants.