Model Context Protocol (MCP) Overview
Course Information & Prerequisites
Use this sequence to get the most value from the full MCP section:
- Start here with MCP Overview for the protocol mental model.
- Continue to MCP Architecture for hosts, servers, transports, and message flow.
- Read MCP Tools, Resources & Prompts for capability types.
- Go to MCP in .NET and MCP in Python for implementation patterns.
- Finish with MCP Role Play and Quiz.
Recommended background before this module:
- Prompt Engineering, especially Prompt Engineering Core.
- Basic API and JSON familiarity.
- Comfort with the idea that AI apps often need structured access to external tools and data.
Summary
Role Play and Quiz - Prompt Engineering completed the Prompt Engineering module. This page begins the standalone MCP module and explains what MCP is, why it matters, and how it differs from ordinary function calling.
MCP is a protocol for connecting AI applications to external capabilities in a standardised way. Instead of every AI host inventing its own tool schema, transport contract, and discovery mechanism, MCP defines a common protocol so hosts can discover tools, resources, and prompts from compatible servers.
| Concept | In plain terms | Why it matters |
|---|---|---|
| Host | The AI application or environment using MCP | Can connect to many servers through one contract |
| Server | A process exposing tools, resources, and prompts | Makes capabilities reusable across hosts |
| Protocol | Standard JSON-RPC style messages over transport | Eliminates one-off integration formats |
| Discovery | Host asks server what it supports | Reduces hard-coded tool wiring |
A desktop coding assistant, an internal support bot, and a document workflow app all need access to the same policy search tool and SharePoint knowledge base. Without MCP, each app ships its own integration layer. With MCP, one policy server exposes the capability once and each host consumes it through the same protocol.
Function calling standardises how a model asks for a tool during a single conversation. MCP standardises how an application discovers, describes, and invokes tools and other context providers across a reusable client-server boundary. It is an application integration protocol, not just a model output format.
An MCP host does not need every tool definition compiled into the application. It can connect to a server, list its tools, enumerate resources, inspect prompt templates, and decide what to expose to the model. This is the difference between a hard-coded adapter and a reusable integration surface.
MCP does not replace prompt engineering, RAG, or model orchestration. It complements them by defining a stable contract for external capabilities. The right mental model is: models generate intent, MCP supplies structured access to execution and context.
Why This Matters
Teams often start with a few in-process functions. Six months later, they have separate schemas for the web app, the desktop assistant, and the internal bot framework. MCP replaces repeated glue code with a protocol-level contract that each host can reuse.
A host can ask an MCP server what tools exist, what inputs they accept, and what resources are available. This removes the need to manually synchronise tool contracts across every client application.
When multiple hosts talk to a shared MCP server, policy enforcement can move to the server boundary: request validation, tool-level authorization, audit trails, rate limiting, and approval workflows can be centralised instead of reimplemented per host.
Function calling is what the model emits. MCP is how the application ecosystem exposes structured capabilities around that model.
Learning Flow
If you are learning MCP for the first time, follow this sequence:
- Understand host, client, and server responsibilities.
- Learn the capability primitives (tools, resources, prompts).
- Understand transport and lifecycle (initialize, discover, invoke, shutdown).
- Apply policy boundaries (authorization, approval, audit).
- Implement one minimal server before scaling to multi-server environments.
Core Concepts
MCP vs Function Calling
| Question | Function calling | MCP | Example impact |
|---|---|---|---|
| Who defines the tool contract? | Usually the host team defines JSON schema directly in app code (for example, one get_ticket_status function). | The server publishes contracts through protocol metadata, so multiple hosts can discover the same tool surface without duplicating schema work. | New host onboarding is faster with MCP because tool contracts are discovered rather than reimplemented. |
| Discovery built in? | Not built in by default; tools are typically hard-coded and versioned per app. | Built in through capability discovery (tools, resources, prompts) so clients can enumerate and adapt at runtime. | A host can auto-list newly added server tools without a code redeploy. |
| Transport standardised? | Varies by implementation (direct SDK calls, custom HTTP routes, ad hoc wrappers). | Standardized transport patterns (stdio, HTTP/streaming) make client-server interoperability predictable across runtimes. | Teams can reuse the same MCP server across desktop and web hosts with minimal protocol changes. |
| Supports resources/prompts as first-class primitives? | Usually limited to callable functions; read-only context and reusable prompt templates are often custom features. | Yes; resources and prompts are protocol primitives, so hosts can consume policy docs or reusable workflows consistently. | Incident triage prompt templates and policy docs can be shared centrally instead of copied per app. |
| Best scope | Best for one app with a narrow tool set where speed of local integration matters most. | Best for many hosts sharing reusable capabilities, centralized governance, and consistent observability. | A single IT operations MCP server can serve IDE assistant, web copilot, and support bot simultaneously. |
The three capability types
| Primitive | Purpose | Example |
|---|---|---|
| Tools | Execute an action or computation | Search CRM, create ticket, run query |
| Resources | Expose read-oriented content | Policy document, schema, repository file |
| Prompts | Provide reusable prompt templates | Incident triage prompt, onboarding workflow |
When to use MCP vs not use MCP
| Situation | MCP fit | Why | Mini case |
|---|---|---|---|
| One app with 1-2 in-process tools | Optional | Simpler direct integration may be enough. | A single internal chatbot with one CRM lookup can start without MCP and evolve later. |
| Multiple AI hosts need shared capabilities | Strong fit | Discovery + reusable contracts reduce duplicated glue code. | Desktop agent and web support assistant both consume the same search_knowledge and create_ticket capabilities. |
| Need centralized policy/audit across tools | Strong fit | Protocol boundary supports governance consistency. | Security team enforces approval and logs at one MCP boundary rather than in every host. |
| Rapid prototype with no reuse expectations | Low fit initially | Add MCP when integration surface starts repeating. | Hackathon prototype can stay direct-call until tool reuse becomes a product requirement. |
Where MCP fits in a GenAI stack
- User request enters the host.
- Host decides which MCP servers are connected.
- Host exposes selected MCP capabilities to the model.
- Model chooses a tool or prompt-assisted path.
- Host executes the MCP call and returns the result.
- Model completes the response with the new context.
Realistic Example
Scenario
An enterprise support assistant needs three capabilities:
- Search the internal knowledge base.
- Fetch employee device details from Intune.
- Load a standard triage prompt for security incidents.
Without MCP, the support app embeds three different integration clients and tool schemas. With MCP, the host connects to:
knowledge-serverdevice-serversecurity-prompts-server
At startup the host discovers available tools, resources, and prompts, then selectively exposes them to the agent handling support requests.
Senior Tech vs Dev Conversation
Senior Tech: We already have function calling. Why do we need MCP?
Dev: Function calling solves only the last mile between the model and the host loop. It does not solve discovery, reusable capability sharing, or a transport contract between multiple hosts and external tool providers. MCP becomes useful when capabilities need to live outside one application and be consumed consistently across multiple AI clients.
Senior Tech: So is MCP replacing APIs?
Dev: No. MCP servers often sit on top of existing APIs, databases, queues, or file systems. MCP is the AI-facing protocol boundary. The underlying business systems remain normal services. MCP is an integration layer, not a replacement for core application architecture.
Common Pitfalls
| Pitfall | What goes wrong | Prevention |
|---|---|---|
| Treating MCP as a model feature | Team looks for MCP settings inside the model API | Explain that MCP is an application protocol boundary |
| Exposing every server capability to the model | Tool sprawl and unsafe action surface | Curate which tools/resources each host exposes |
| Skipping audit and authorization | Shared server becomes an unmanaged execution surface | Enforce auth, policy, and logging on the server boundary |
| Confusing resources with tools | Read-only content gets modelled as expensive actions | Use resources for content, tools for operations |
References and Next Steps
- Next: MCP Architecture →
- Previous: Role Play and Quiz - Prompt Engineering →
- Specification: modelcontextprotocol.io
- Reference servers: github.com/modelcontextprotocol