Afternoon Session

Building and deploying a Python MCP server

Course delivery kit

The afternoon should make MCP feel buildable

Set the expectation: this is not protocol theory. This is a build story from Python function to usable endpoint.

One architecture picture beats a long definition

Walk left to right. Keep the words client and server, but do not dwell on formalism yet.

uv keeps the environment calm

uv lock
uv sync
uv run --directory .\mcp-servers\hello-world hello-world-server

Why it helps

• fewer setup surprises
• repeatable commands
• good live-demo rhythm

Tell the room they do not need to memorize many commands. The repetition is part of the teaching design.

MCP concepts should stay concrete

Tool

Call a function

Resource

Read useful data

Prompt

Reuse task framing

Make it explicit that the class will mostly build tools. That keeps the scope manageable and visible.

A tiny server makes the pattern visible

from mcp.server.fastmcp import FastMCP

mcp = FastMCP("hello-world")

@mcp.tool()
def ping(name: str) -> str:
    """Return a simple greeting."""
    return f"Hello, {name}!"

Pause here and ask the room which lines are ordinary Python and which line changes the role of the function.

The decorator is the turning point

from mcp.server.fastmcp import FastMCP

mcp = FastMCP("hello-world")

@mcp.tool()
def ping(name: str) -> str:
    """Return a simple greeting."""
    return f"Hello, {name}!"

Teaching line

@mcp.tool() is the moment a normal function becomes a discoverable capability.

Spend time on this slide. It is the mental bridge most attendees need.

FastMCP removes protocol plumbing from the first lesson

It handles

• schema generation
• argument validation
• protocol wiring

That lets us teach

• naming
• tool design
• response shape

Emphasize that abstractions are helping us teach the right layer first, not hiding important concepts forever.

Two small tools are enough for a walkthrough

Canonical shape

One simple lookup plus one live-data or status tool is enough to teach discovery, invocation, and deployment.

Keep the class away from over-engineering. The goal is a pattern the room can reuse, not a large application.

Local inspection should happen before hosting

Inspect for

• tool names
• descriptions
• parameters
• output shape

Say clearly that a bad local loop becomes a worse cloud loop. Validate discoverability before deployment.

Deployment should feel like packaging, not magic

The deployment story should stay linear. If the room loses the story here, the Azure steps will feel random.

Azure needs one clean visual anchor

Replace this placeholder with your own Azure screenshot if you have one. Use it to keep the deployment explanation concrete.

Connection back to Copilot Studio closes the loop

Why this matters

This is the moment the protocol stops feeling abstract.

Frame this as the payoff slide. The room has now seen a full path from code to capability.

The final discussion should stay practical

Internal lookups

What should become a tool

Public data blends

What outside signal helps

Governance

What still needs approval

End by translating the demo into attendee context. That is where future adoption ideas usually appear.

The takeaway is that MCP is approachable

Final message

The goal is not protocol expertise. The goal is confidence that this can be built, tested, and connected.

Close with confidence and restraint. The room should leave feeling that the path is understandable and repeatable.