Module 24 / Designing AI systems

Module 24 · lesson 6 of 12 · Read 12 min

MCP: tools as a service

The Model Context Protocol: servers, transports, OAuth sign-in, and when plain tool calls are enough.

In the tools lesson, every tool lived inside your app: you wrote a JSON Schema, passed it to the model, and ran the function when the model asked. That works well for one feature. It stops working when ten AI products all want the same tools.

The Model Context Protocol (MCP) is an open standard for exposing tools and data to AI applications. You build an MCP server once, and any app that speaks MCP can discover and call its tools: your own agents, a coding assistant in someone's editor, a chat app on their desktop. This lesson covers what the protocol actually is, how it runs over the network, how it does sign-in, and when it's worth the extra moving part. It describes the 2026-07-28 revision of the spec, the current one in late 2026.

The problem it solves

Tiffin now has four AI features that all need order data:

  • The customer support assistant (Module 24's running example)
  • The ops agent that handles "rider didn't show" cases
  • An internal assistant that analysts use to ask questions about orders
  • A new restaurant-partner assistant, which restaurants want to use from their own AI tools, not from a Tiffin page

Without a standard, each one defines its own get_order_status tool, with its own permission checks, its own timeouts and its own bugs. The fourth one is worse: Tiffin can't put its tool code inside a restaurant's chat app at all.

MCP turns "tools" into a network service with a standard interface. The spec itself borrows the idea from the Language Server Protocol, which did the same thing for editors: before it, every editor needed its own plugin for every programming language. After it, a language ships one server and every editor can use it.