Prove
LiveProof-of-Work · Oct–Nov: every verified proof counts. 35 days leftAll outcomes
Skills

Learn Tools & Protocols (AI Engineering Phase 13)

6 weeks · 2 milestones

Phase 13 of AI Engineering from Scratch: 45 free lessons, then one project of your own that is run, evaluated and documented. Part of the Varsity Curriculum: AI Engineering.

Milestone map

Milestone map

2 milestones

Do the phase's lessons in public

2–3 weeks (about 10 hrs/week, est)

Work through the 45 lessons of Phase 13: Tools & Protocols from AI Engineering from Scratch (free) and keep the tools and protocols lessons' code (tool interfaces, function calling, MCP servers and clients, MCP security, tracing) in one public repo as you go. About 25 hours (est).

Proof required

Link your public repo with the tools and protocols lessons' code (tool interfaces, function calling, MCP servers and clients, MCP security, tracing), and show your self-check (quizzes passed, notebooks run, tests passing where they exist).

What gets checked

  • Each lesson's code runs and its quiz is passed.
  • MCP examples work with a real client.
  • Security lessons are done on your own setup only.

Common mistakes

  • Copying the repo's solutions: verifiers read your history and ask about your code.
  • Skipping the self-check, then asking for review too early.

Powstik Guide

A public repo with the tools and protocols lessons' code (tool interfaces, function calling, MCP servers and clients, MCP security, tracing).

Steps

  1. Make a public repo for this phase.
  2. Do one lesson at a time and commit after each.
  3. Self-check: Run each lesson's code; it must work on your machine as the lesson shows. Run each lesson's notebook top to bottom; its outputs must match the lesson. Each lesson has a quiz (quiz.json, also on the course site): pass it.
  4. Write a short README: what is here and how to run it.
  5. Ask three people who know the topic to check it.

Template

README
Phase 13: Tools & Protocols (AI Engineering from Scratch)
What is here:
How to run it:
Self-check result:
What was hardest:

What gets sent back

  • One big upload with no history.
  • Self-check not shown.
  • Code that does not run from the README.

Resources

Foundationstart here

Depthgo deeper

What a verifier looks for

  • Each lesson's code runs and its quiz is passed.
  • MCP examples work with a real client.
  • Security lessons are done on your own setup only.
  • Ask about one choice in the code; the answer should be clear.

You'll sign in first, then come straight back here.

Build an MCP server for a real tool

2–4 weeks (6–10 hrs/week)

Use what you learned. Make an MCP server that exposes a real tool or data source you use, with input schemas, tests and a short security check (tool poisoning, authentication). It must run, be evaluated and be documented.

Proof required

Link an MCP server that exposes a real tool or data source you use, with input schemas, tests and a short security check (tool poisoning, authentication), with a README that says how to run it and what the evaluation found.

What gets checked

  • It works from a real MCP client.
  • Its tests pass.
  • The security check names what was tried and what was fixed.

Common mistakes

  • A demo with no evaluation.
  • Numbers without the data or code that produced them.

Powstik Guide

An MCP server that exposes a real tool or data source you use, with input schemas, tests and a short security check (tool poisoning, authentication).

Steps

  1. Write one line: what it does and for whom.
  2. Build the smallest version that works.
  3. Write the evaluation first, then improve against it.
  4. Write the README with the results.
  5. Ask three people to check it.

Template

README
What it does:
How to run it:
How it was evaluated:
Results:
Limits:

What gets sent back

  • Does not run from the README.
  • No evaluation.
  • Claims more than the evaluation shows.

Resources

Foundationstart here

What a verifier looks for

  • It works from a real MCP client.
  • Its tests pass.
  • The security check names what was tried and what was fixed.
  • Run it, or watch it run: it must work, be evaluated and be documented.
  • Check that the work is the person's own.

You'll sign in first, then come straight back here.