# The DeepLearning.AI and Anthropic MCP course: learn it fast, then rebuild it for the new spec

> Elie Schoppik teaches MCP in about two hours, but the spec has changed a lot since the course launched, so FDEs should rebuild each lesson themselves to see what is now different.

Original: https://fdetimes.net/en/books-courses/deeplearning-ai-anthropic-mcp-course-review/

On 25 November 2024 Anthropic announced MCP as a new standard for connecting AI assistants to the places where data actually lives. Less than six months later, on 19 May 2025, DeepLearning.AI launched the short course "MCP: Build Rich-Context AI Apps with Anthropic". Since then the protocol has gained a 2026-07-28 spec with changes that reach its core.

That sounds like a drawback, but the gap is exactly what makes the course useful to FDEs. Much of the work at a customer site is connecting a model to systems the customer already runs: tickets, documents, databases. MCP was built to solve that problem, and the best way to learn it is to watch the videos and then rewrite each part yourself against the current spec.

## Who teaches it, and what does it cover?

The course is made by DeepLearning.AI with Anthropic, and the instructor is Elie Schoppik. The course page lists it as Intermediate, with 11 video lessons and a total running time of about two hours or less.

You only need to be comfortable with Python and have a basic grasp of prompting and of how LLM applications are built. The lesson list includes a section on multi-client architecture, with one connection per client, a section on adding prompts and resources to a server, and a section on creating and deploying a remote server.

These sections map onto the stages of a real engagement: understand the problem, build a prototype, connect it to the customer's systems, then move it to a shared environment.

## One connection per client: why it shapes how you debug

According to MCP's official architecture documentation, each client keeps its own connection to its corresponding server. That sounds simple, but it determines how you track down faults.

Picture a logistics company that wants an assistant able to search its internal ticketing system and its library of process documents. That is two servers. Your host will have two clients with two separate connections.

When the document library times out, only one connection fails; ticket search keeps working. When the customer reports a fault, the first job is to work out which connection is in trouble.

The lessons on writing clients are the ones worth redoing by hand. If you only run the sample code, you will not know where the connection lifecycle sits.

## Tools, resources and prompts are three questions for discovery

Beyond tools, the course has a dedicated lesson, "Adding Prompt and Resource Features", in which the server also provides prompts and resources. For an FDE, this split is also a way to break down a customer's requirements.

Back to the logistics company. Looking up a ticket by order number is an action the model calls when needed, so it should be a tool. The process documents for handling damaged goods are data for the model to read, so they should be a resource. The "incident summary for the shift manager" template that staff use every day should be a prompt.

**Key point:** Before writing a server, classify each requirement: does the model need to do something, read something, or use a ready-made template?

To test yourself, cover the middle column of the table below and sort four hypothetical requirements from the same logistics company before checking the answers.

| Customer requirement | Type | Question that decides it |
|---|---|---|
| Create a new ticket when the warehouse reports damaged goods | Tool | Does the model need to perform an action? |
| Packing rules for fragile goods | Resource | Is this read-only data? |
| End-of-shift report template sent to managers | Prompt | Do users repeat exactly this template every day? |
| Look up order status by waybill number | Tool | Does the result depend on a parameter the model passes in? |

Two common mistakes in this exercise are worth remembering. The first is turning everything into a tool, including documents that only need to be read, which leaves the model guessing when to call them. The second is stuffing the report template into the host's system prompt instead of letting the server provide it as a prompt, so the customer cannot edit its own template.

At the first discovery session, you can write down the list of things the customer wants to do and place each line in one of these three columns. Once that is done, the server design is nearly there.

## From laptop to shared server

The course has a section on creating and deploying a remote server. The current spec documentation mentions the stdio transport when discussing logging, and Streamable HTTP when discussing the removal of sessions.

At a customer site, a stdio prototype running on your laptop is usually enough for a demo. Once the whole operations team needs it, the server has to run remotely, for example over Streamable HTTP. That is when questions about authentication, internal networking and who owns operations begin, so raise them early.

## What to rebuild by hand

According to the official documentation, the 2026-07-28 spec turns MCP into a stateless protocol: it removes protocol-level sessions along with the `Mcp-Session-Id` header, and drops the `initialize` handshake, so that each request carries its own protocol version and capabilities. Sampling and protocol-level logging are also deprecated.

The lesson page has no dedicated lesson on sampling, sessions or logging, so do not assume the sample code relies on them. But code you add yourself, or older code in a customer project, may well do so. These features still work during the deprecation period; they simply should not be added to new code.

Apply this to the logistics company's ticket server. Suppose you wrote a "summarise ticket" tool in which the server asks the client to call the model through sampling. The new spec recommends calling the LLM provider's API directly; when rewriting, a sensible approach is to have the tool return only the ticket data and let the host call the model to summarise it.

Statelessness needs the same audit. If your server remembers "the ticket currently being viewed" between two calls, the new spec requires an explicit handle passed through tool parameters, such as passing the order number into every call. Logs go to `stderr` with stdio, or through OpenTelemetry.

## In what order, and who should take it?

Read the introduction and architecture pages on modelcontextprotocol.io first. Then watch the course from start to finish, switch off the videos, rewrite the client and remote server yourself, and check each part against the 2026-07-28 spec changelog.

The course suits engineers who have called LLM APIs but have never connected a model to external systems. If you have already written MCP servers for production, you can skip the videos and just read the spec changelog.

## Turn the exercises into evidence for job applications

Watching all 11 videos only shows that you have studied. FDE interviewers will pay more attention to a GitHub repo with a remote server running over Streamable HTTP, with a README that states the spec version and why you chose a tool, resource or prompt for each capability.

When reading FDE job descriptions, look for mentions of MCP or integration with customer systems, then bring that repo to the interview.

The videos are enough to understand the architecture. But only by rewriting it against the new spec will you see what has changed.

**Try this week:**

- Read the introduction and architecture pages on modelcontextprotocol.io before watching the course's first lessons
- Write a host that connects to two MCP servers without copying the sample code, then audit every use of sampling, logging or session state against the 2026-07-28 spec changelog
- Deploy a remote server over Streamable HTTP and publish it on GitHub with a README stating the spec version you used

## Sources

- [✨ New course! Enroll in MCP: Build Rich-Context AI Apps with Anthropic (DeepLearning.AI Community)](https://community.deeplearning.ai/t/new-course-enroll-in-mcp-build-rich-context-ai-apps-with-anthropic/817997)

- [MCP: Build Rich-Context AI Apps with Anthropic - DeepLearning.AI](https://www.deeplearning.ai/courses/mcp-build-rich-context-ai-apps-with-anthropic)

- [MCP: Build Rich-Context AI Apps with Anthropic - DeepLearning.AI](https://www.deeplearning.ai/short-courses/mcp-build-rich-context-ai-apps-with-anthropic/)

- [What is the Model Context Protocol (MCP)?](https://modelcontextprotocol.io/docs/getting-started/intro)

- [Introducing the Model Context Protocol - Anthropic](https://www.anthropic.com/news/model-context-protocol)

- [Architecture overview - Model Context Protocol](https://modelcontextprotocol.io/docs/learn/architecture)

- [Key Changes - Model Context Protocol specification 2026-07-28](https://modelcontextprotocol.io/specification/2026-07-28/changelog)

- [MCP 2026-07-28 release (blog.modelcontextprotocol.io)](https://blog.modelcontextprotocol.io/posts/2026-07-28)

- [MCP goes stateless in the 2026-07-28 specification (WorkOS)](https://workos.com/blog/mcp-stateless-spec-2026-07-28)