Hugging Face's MCP Course: FDEs should study Unit 3 closely and move quickly through Unit 2

Hugging Face and Anthropic have built a free course on MCP that promises to take learners from beginner level to a solid grasp of how to understand, use and build MCP applications.

For an FDE, the useful question is not whether to take it, but which parts deserve close study and which only need to be finished.

That matters because MCP targets exactly what FDEs do every day: connecting models to customers’ systems.

When Anthropic announced the protocol on 25 November 2024, it described the problem plainly: every new data source requires its own custom integration, which makes a system that needs to connect to many sources hard to scale.

Anyone who has written a fifth connector for the same customer will recognise it.

What the course covers and how long it takes

The official page is at huggingface.co/learn/mcp-course. Each unit is designed to be completed in 1 week, at about 3-4 hours of work, so the whole course takes only a few weeks of evening study. You need to know at least one programming language, and all the examples are in Python or TypeScript.

There are two certificates, both free. The Fundamentals certificate requires only Unit 1. The Completion certificate also requires the two hands-on units, Unit 2 and Unit 3, so the sensible order depends on which certificate you need.

Unit 1 gives you the words you need in front of a customer

Unit 1 is theory: what MCP is, its terminology, the integration problem it solves, its benefits and a simple example. Experienced engineers will get through it quickly.

Do not skip it, though, because this unit defines the three roles of host, client and server. The server is an external program or service that provides tools, resources and prompts to the model through MCP.

Unit 1 also defines the primitives: Tools, Resources, Prompts and Sampling. Tools are executable functions the model can call on its own to perform an action or fetch pre-computed data, and most customer integrations will revolve around them.

Picture a delivery company that wants its AI assistant to look up orders. You would build a server exposing a “look up order by ID” tool, while the shipping rate table, which rarely changes, could be exposed as a resource.

What to do at the customer site: before writing a line of code, draw that diagram on the whiteboard. Which application is the host, which server exposes which tool. A drawing like that moves a first meeting along far faster than a demo.

Unit 2: get it done, don’t polish it

Unit 2 is a sample project: a sentiment analysis application with a server built in Gradio, a client written with HuggingFace.js or smolagents, deployed to Hugging Face Spaces. The server, client and deployment structure is worth learning. But the tooling in this unit is tightly bound to the Hugging Face ecosystem, and your customers may run on an entirely different stack.

So do Unit 2 to understand how an MCP application works end to end, and because it is required for the Completion certificate. Do not spend an extra week making the Gradio interface look nice.

Unit 3 is the part that resembles FDE work

Unit 3 builds a workflow server for Claude Code, designed to help Claude Code understand how a team works and what its processes are. The server suggests PR templates, monitors CI/CD through GitHub Actions using Cloudflare Tunnel, standardises prompts and sends notifications to Slack. The Slack section is where MCP’s primitives work together.

A project like this is very close to real customer requests along the lines of “let the agent know when the build breaks and tell the team”. You have to connect several existing systems, handle webhooks from outside and choose the right primitive for each job. This is the unit that deserves most of your time.

Carry the delivery company example over. Following the Unit 3 pattern, the order-lookup server could expose an extra tool that posts to the dispatch team’s Slack channel when an order is late, just as the workflow server reports a broken build.

You are not building a new system but adding capabilities to an existing server, and that is usually how an integration grows at a customer site.

Three ideas to keep after the course

The first is the framing of the problem. “Every new data source requires its own custom integration” is the best opening line when explaining MCP to a CTO. It talks about the integration costs they are already paying, not about technology.

The second is splitting capabilities into tools, resources and prompts. The habit of asking “is this an action the model calls on its own, or just data to read?” helps you design leaner servers and avoid exposing tools you don’t need.

The third is the comparison in the official documentation at modelcontextprotocol.io: MCP is like a USB-C port for AI applications. That documentation describes MCP as an open-source standard and is the up-to-date reference, so keep it open alongside the course.

Who should take it, and in what order?

If you are preparing to move into an FDE role, read Unit 1 in one evening to earn the Fundamentals certificate, do Unit 2 quickly, then spend most of your time on Unit 3. If you already know MCP, you can go straight to Unit 3 and come back to Unit 2 when you need the certificate.

On your CV, don’t just list the certificate. Rebuild Unit 3 with a different tool your team actually uses, put it on GitHub with a README explaining why you chose each primitive for each job.

When reading job descriptions, look for phrases such as “integrating with customer systems” or “building agents”: that is where to talk about this project.

The certificate proves you finished the course. A workflow server running on your own team’s tools proves you can do an FDE’s job.