Model Context Protocol

Tools built inside an agent live and die with that agent's process. The Model Context Protocol is the material's answer: expose the tools once, as a server, and every client — your notebook, your agent framework, your editor — reaches the same tools over the same protocol.

Tools behind a server

Building AI Agents with MCP, PydanticAI, and OpenAI makes the problem concrete first: the FAQ agent's search tool works, but it is locked inside the notebook. Parts 8 through 10 fix that — the tools move into a separate project served with FastMCP, a Python client connects over stdio, and finally Cursor uses the same FAQ server as an MCP client. The tools did not change; their address did.

The AI Engineering Buildcamp module 3 gives the transports names — Stdio Transport, SSE Transport, Cursor Integration — so the workshop's moves become vocabulary.

Why one protocol matters

Two payoffs recur in the material:

• Write tools once, use them everywhere. The same FAQ server serves the notebook, a PydanticAI agent, and an IDE — the workshop demos all three against one server.
• Editors become agent hosts. When Cursor is just another MCP client, the coding agent in AI Coding Tools and the agent you built on the Agents page share a tool ecosystem instead of maintaining two.

The boundary discipline also shows up outside the protocol proper: the AI Data Cleaning Assistant keeps structured JSON boundaries between its LLM planner and the deterministic execution layer — MCP thinking, applied to architecture.

Where to go next

• The agent loop these tools serve: Agents
• The editors that speak MCP: AI Coding Tools
• Build the server yourself: Building AI Agents with MCP, PydanticAI, and OpenAI