Introduction to MCP

What is MCP?

MCP (Model Context Protocol) is an open standard for connecting AI applications to external systems. Officially: applications such as Claude or ChatGPT can reach data sources (local files, databases), tools (search, calculators, business APIs), and workflows (specialized prompt templates) so they can read important information and take actions.

Think of MCP as USB-C for AI applications. USB-C standardized power and data plugs; MCP standardizes how a model discovers and calls external capabilities. You write a server once and many hosts can attach to it.

MCP only specifies how context is exchanged. It does not specify how a host calls the LLM, runs an agent loop, or stores a chat. Those remain product concerns for Cursor, Claude Code, LangChain, and similar stacks.


Why MCP exists

Before MCP, every AI product invented its own “plugin / function-calling / tool” shape:

ApproachPain
A unique tool schema per hostThe same capability is rewritten N times
Secrets and business logic stuffed into promptsHard to audit, hard to reuse, easy to leak
Hard-coded HTTP calls inside one IDESwitching to Codex or Claude Code means a rewrite

MCP standardizes the capability catalog and the call convention. Developers spend less time integrating; AI apps gain a whole server ecosystem; end users get assistants that can actually touch data and act.

Official examples include agents that read calendars and Notion, Claude Code generating a UI from Figma, enterprise chatbots querying many databases, and models that design in Blender then send work to a 3D printer. The shared idea: the model stays in the host; capabilities live in servers.


Official project scope

The open MCP ecosystem has four main pieces (see the architecture overview):

ProjectRole
SpecificationRules clients and servers must implement
SDKsOfficial TypeScript, Python, Go, C#, and more
InspectorBrowser, CLI, and TUI debugger
Reference serversfilesystem, fetch, git, and other references

Vendors and the community publish many more servers and directories. This course follows the spec, the Python SDK, and Inspector.


Who should learn this?

A good fit if you:

  • Want Cursor / Claude Code / Codex to reach an internal wiki, tickets, or a read-only database
  • Plan to publish a tool once and reuse it across hosts
  • Review tool permissions, token scope, or supply-chain risk
  • Already know function calling and want capabilities that are not locked to one product

You can wait if you:

  • Only send one-off prompts and never touch external systems
  • Have not written a Python function or used a virtualenv yet (see the Python tutorial first)

If you only need “install GitHub in one agent,” start with that client’s MCP chapter. Come back here when you expose your own capabilities or reuse one server across hosts.


What MCP is not

  • Not another chat app, and not an agent framework like LangChain
  • Not a remote code-execution protocol; a server exposes only the tools, resources, and prompts you declare
  • Not “put the model inside the server.” As of protocol version 2026-07-28, Sampling (the server asking the host to complete a prompt) is deprecated. New work should call a model provider API directly instead of relying on Sampling

The protocol moved from a stateful handshake-and-session model to stateless request/response: every request carries version and capability metadata; server/discover is there when you want a catalog first. That matters for load balancing. The SDK hides most of it when you write everyday tools.


What you will be able to do

  1. Build a Python server with a tool, a resource, and a prompt
  2. Verify it in Inspector instead of guessing in chat
  3. Attach the same process to Cursor and Claude Code
  4. Evaluate third-party servers: trusted sources only, least-privilege tokens, approval for dangerous tools

Next

评论