MCP for App Builders
What the Model Context Protocol means for a product team: connecting MCP servers to your features, exposing your product to AI clients, and the security trade-offs.
Every tool you've built in this module was written by you, for your app. That works until your customers want the assistant to work with their other tools: create an issue in their tracker, check a document in their drive, look up a deal in their CRM. Writing and maintaining a custom integration for each one doesn't scale. Neither does the reverse problem, where customers want to use your product from inside the AI assistants they already use.
The Model Context Protocol (MCP) is the open standard for both directions. This lesson is about what MCP means for a product team, not how to build MCP servers from scratch: when to connect third-party MCP servers to your features, how to do it with per-user credentials and an allowlist, what exposing your own product over MCP involves, and the security trade-offs that come with each.
MCP in one page
MCP standardizes how an AI application discovers and calls capabilities that live somewhere else. Anthropic introduced it in late 2024, and in December 2025 it was donated to the Agentic AI Foundation under the Linux Foundation, so it's now governed as a vendor-neutral standard. Most major AI assistants and coding tools support it.
Three roles matter:
- An MCP server exposes capabilities: tools (functions the model can call), resources (data the application can read), and prompts (reusable templates the user can pick).
- An MCP client connects to one server and speaks the protocol.
- A host is the application that contains the model and the clients: Claude's apps, an IDE, or your product.
Servers run either locally (over stdio, as a process on the user's machine) or remotely (over Streamable HTTP, as a web service). For a web product, remote servers are the ones that matter, since you can't launch processes on your users' laptops.
The spec keeps evolving. The 2026-07-28 revision, the current one at the time of writing, removed the separate initialization handshake (each request now carries its protocol version) and deprecated some older features, while Tasks (for long-running operations) and MCP Apps (for interactive UI provided by servers) are official extensions. The TypeScript SDK's stable line is v2, split into @modelcontextprotocol/client and @modelcontextprotocol/server (the older @modelcontextprotocol/sdk package is the maintenance-only v1).
The key product insight: an MCP tool is just a tool. Once you've listed a server's tools, they plug into the same call-and-return loop you built in Tool Use for App Features. Everything you learned about bounding loops and treating results as untrusted still applies, with one big difference: you didn't write these tools, and you don't control them.