A hands-on public lab for deploying a small Model Context Protocol tool server and adding it as a tool in Microsoft Copilot Studio.

The workflow before the build

MCP concepts can be difficult to connect to practice when the protocol, server deployment, tool definition, client configuration, and invocation path are learned separately.

What the public project delivers

The public lab uses a deliberately small TypeScript joke server to walk through MCP tools, Azure Container Apps deployment, a custom connector, and connection from Microsoft Copilot Studio.

  • Implements a small public MCP server and callable tool.
  • Documents deployment and connection steps for the lab.
  • Exposes four bounded tools backed by two public joke APIs.
  • Includes Azure Container Apps deployment infrastructure and Copilot Studio setup guidance.

The value case, stated honestly

The lab is designed to give builders a bounded end-to-end reference they can inspect before adapting the pattern to a real tool.

Evidence label: Designed value: a compact end-to-end MCP reference that makes server, tool, client, and invocation responsibilities easier to see.

Architecture in one view

A Copilot client sends an MCP request to a bounded tool server and presents the result back to the user.

Copilot Studio + MCP Lab architecture A Copilot client sends an MCP request to a bounded tool server and presents the result back to the user. 01 Copilot Studio 02 MCP request 03 Tool server 04 User response
01 / Copilot client

A user invokes the configured tool from Microsoft Copilot Studio.

02 / MCP request

The client sends a protocol request using the published tool contract.

03 / Tool server

The deployed sample server executes the bounded joke operation.

04 / User response

The client presents the tool result for the user to accept, ignore, or continue from.

Human control and guardrails

  • The sample tool is deliberately non-consequential and does not perform business writes.
  • The user chooses whether to invoke the tool and how to use its response.
  • The deployment guide warns that the lab creates a public MCP endpoint and recommends removing it after use.
  • Real tools require authentication, authorization, input validation, logging, and least-privilege design beyond the sample.

Where the pattern stops

  • The lab demonstrates a narrow sample tool rather than a production MCP operating model, and no automated tests are configured.
  • Repository license metadata is inconsistent: GitHub detects MIT while the package manifest declares ISC.
  • The support file remains an unedited template, and the example does not establish security, reliability, or support guarantees.

Explore the public proof