Understanding MCP Servers (Model Context Protocol) — A Deep, Practical Guide (with Microsoft Learn as the backbone)

If you’re building AI agents that need to search documentation, query enterprise data, or run actions (create tickets, call APIs, read SharePoint, etc.), you quickly hit a wall:

• LLMs are great at reasoning, but they don’t natively “connect” to your systems.
• Every integration becomes custom glue code (auth, schemas, retries, logging, permissions…).

That’s exactly the problem MCP (Model Context Protocol) solves.

An MCP Server is a service that exposes tools, resources, and prompts to an AI client/agent in a standard way—so the agent can discover capabilities and call them safely and predictably. MCP is documented and standardized by the MCP project and specification. (Model Context Protocol)

Microsoft has been adopting MCP across the ecosystem (Windows AI, Foundry agents, Microsoft Learn content integration, Graph MCP for enterprise). (Microsoft Learn)

1) What an MCP Server actually is (in one sentence)

An MCP Server is a tool host that an AI client connects to so the model can:

1. Discover what it can do (list tools/resources/prompts)
2. Call tools with structured inputs
3. Receive structured outputs back
4. Operate under security and governance boundaries

This is similar to an API, but designed specifically for LLM tool usage, including discovery and model-friendly schemas. (Model Context Protocol)

2) MCP’s mental model: “Brain vs Hands”

• Model / LLM → “brain” (reasoning, text generation)
• MCP Client → “operator” (the agent runtime: VS Code, GitHub Copilot Agent mode, Foundry agent runtime, etc.)
• MCP Server → “hands and eyes” (tools + data sources)

The agent says:

“I need to search docs / fetch a page / call an internal API.”

The MCP Server provides those actions in a standard contract.

3) Core building blocks: Tools, Resources, Prompts

Tools

Tools are callable functions the agent can invoke.

Examples:

• search_docs(query)
• get_article(url_or_id)
• create_work_item(title, description)
• sharepoint_create_item(listName, fields)

Resources

Resources are readable entities (documents, files, records) that can be fetched as context.

Examples:

• learn://article/xyz
• file://…
• db://record/123

Prompts

Prompts are server-provided prompt templates (pre-baked instructions or structured prompt patterns) the client can use.

All of this is formalized in the MCP spec and implemented in the SDKs. (Model Context Protocol)

4) Transport: how clients connect to MCP servers

MCP supports multiple transports, depending on your environment. Two common patterns:

A) Local “stdio” style (developer workstation)

• Client spawns the server process (Node/Python/etc.)
• Communication via standard IO streams
• Great for local dev and private tools

B) Remote “Streamable HTTP” style (enterprise/hosted)

• MCP server is a web service endpoint
• Clients connect remotely and stream results
• Great for shared tools and governance

Microsoft Learn MCP Server is explicitly described as remote and using streamable HTTP. (Microsoft Learn)

5) Microsoft Learn MCP Server (real Microsoft example)

Microsoft provides an official MCP Server that lets clients bring trusted, up-to-date Microsoft Learn documentation into an agent workflow.

Key points:

• Endpoint: https://learn.microsoft.com/api/mcp
• Supports searching docs, fetching full articles, searching code samples
• Publicly available (terms apply)
• Designed for MCP clients (may return 405 in a normal browser) (Microsoft Learn)

Why that matters:
In real agent systems, you want ground truth and trusted sources. This server is basically “official docs-as-a-tool”.

6) Microsoft MCP Server for Enterprise (Graph-powered)

Microsoft also provides an MCP Server that translates natural language requests into Microsoft Graph API calls, enabling AI agents to query enterprise identity data in your Entra tenant:

• Endpoint documented as: https://mcp.svc.cloud.microsoft/enterprise
• Built on MCP
• Enforces limits (example: calls/min) and licensing follows underlying data licensing (Microsoft Learn)

This is a big clue about the direction: MCP becomes a standardized “tool layer” for enterprise data access, rather than every product building its own agent plugin format.

7) MCP in Windows and “enterprise controls”

Microsoft Learn also documents MCP “on Windows,” focusing on:

• User/admin control over MCP server access (per agent)
• Logging and auditability
• Built-in connectors (example: File Explorer MCP server)
• Integration with tools like VS Code / Visual Studio agent modes (Microsoft Learn)

This matters because it frames MCP as not just “developer convenience”, but as an OS-level capability with governance.

8) MCP in Azure AI Foundry / Agent ecosystems

Microsoft’s agent ecosystem supports MCP as a tool integration path (including samples and tool catalogs):

• Foundry agent docs include examples for connecting to MCP servers (Microsoft Learn)
• Foundry tool catalog explicitly defines “MCP server” as a server exposing tools using MCP (Microsoft Learn)

So your mental model becomes:

Agent runtime (Foundry) → Tool Catalog → MCP Server(s) → Your APIs/data

Step-by-step: Build your first MCP Server (2 real implementations)

Below are two practical minimal servers:

• Python (FastMCP)
• TypeScript (official SDK)

These are “starter patterns” you can expand into SharePoint/Graph/APIM-secured tools.

Part A — Python FastMCP server (quickest path)

The MCP docs show using FastMCP to define tools quickly, leveraging Python type hints/docstrings. (Model Context Protocol)

1) Install dependencies

python -m venv .venv
# Windows
.venv\Scripts\activate
# macOS/Linux
source .venv/bin/activate
pip install mcp

2) Create server.py

This example creates a tiny server with 2 tools: ping and add.

from mcp.server.fastmcp import FastMCP
# Name your server (shows up in client UIs)
mcp = FastMCP("demo-mcp-server")
@mcp.tool()
def ping() -> str:
    """Health check tool: returns a constant string."""
    return "pong"
@mcp.tool()
def add(a: float, b: float) -> float:
    """Adds two numbers and returns the result."""
    return a + b
if __name__ == "__main__":
    # Default is typically stdio transport for local usage.
    mcp.run()

3) Run locally

python server.py

4) Connect using an MCP-capable client

Examples of clients that commonly support MCP include agent-enabled IDE workflows (for example, Windows/VS tooling and other MCP clients). Microsoft’s Windows MCP overview discusses how agents can discover and use MCP servers with controls and auditing. (Microsoft Learn)

Next step: Once you confirm the client sees your tools (ping, add), you can start adding real enterprise tools: call APIs, query SharePoint, etc.

Part B — TypeScript MCP server (official TypeScript SDK path)

The official TypeScript SDK exists and includes runnable examples. (GitHub)

1) Initialize project

mkdir demo-mcp-ts
cd demo-mcp-ts
npm init -y
npm install @modelcontextprotocol/sdk
npm install -D typescript ts-node @types/node
npx tsc --init

2) Create server.ts (minimal tool server)

import { Server } from "@modelcontextprotocol/sdk/server/index.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import { z } from "zod";
const server = new Server(
  { name: "demo-mcp-ts", version: "1.0.0" },
  { capabilities: { tools: {} } }
);
// Register a tool: "add"
server.tool(
  "add",
  {
    a: z.number().describe("First number"),
    b: z.number().describe("Second number"),
  },
  async ({ a, b }) => {
    return {
      content: [{ type: "text", text: String(a + b) }],
    };
  }
);
async function main() {
  const transport = new StdioServerTransport();
  await server.connect(transport);
}
main().catch((err) => {
  console.error(err);
  process.exit(1);
});

3) Run it

npx ts-node server.ts

4) Validate tool discovery in the client

Your client should see a tool named add with schema-defined inputs. That schema-first approach is core to MCP’s “predictable integration” story. (Model Context Protocol)

Step-by-step: Production-grade MCP Server architecture (how to do it “enterprise right”)

This is the pattern you should follow if your MCP server will touch SharePoint, Graph, databases, or internal APIs.

Step 1 — Decide where the server runs

Option 1: Local dev tools

• stdio transport
• fastest iteration

Option 2: Hosted service

• Streamable HTTP
• centralized logging, throttling, versioning
• aligns with Microsoft Learn MCP Server style (Microsoft Learn)

Step 2 — Put a security gateway in front (recommended)

For enterprise MCP servers, treat them like APIs.

Azure API Management (APIM) is a strong fit to:

• enforce OAuth tokens
• validate JWT
• apply quotas/rate limits
• log requests

Microsoft Learn has guidance for protecting APIs in APIM using OAuth 2.0 with Microsoft Entra ID and validating JWTs. (Microsoft Learn)

Step 3 — Use Entra ID properly

For enterprise data access, you will typically choose:

• Delegated (user-based): “act as the signed-in user”
• App-only (client credentials): “service identity”
• Managed Identity (recommended on Azure): avoid storing secrets

Microsoft’s managed identity guidance shows how to use managed identities in App Service / Functions to access other resources. (Microsoft Learn)

Step 4 — Implement tool-level authorization (least privilege)

Even if the client can connect, you still want:

• tool-level allow/deny
• resource scoping (which site/list/library)
• audit trails per tool call

MCP has security/authorization guidance (OAuth-oriented) in its documentation. (Model Context Protocol)

Step 5 — Make tools “boring and deterministic”

The best MCP tools:

• accept a small, well-defined input schema
• return structured output
• do one thing well
• have clear error codes/messages

Bad tools:

• too broad (“do everything”)
• unclear schemas
• giant responses without pagination
• side effects without confirmation

Step 6 — Add logging and correlation IDs

Log:

• tool name
• parameters (redacted)
• start/end timestamps
• correlation ID
• response size
• errors

This aligns with Microsoft’s emphasis on auditability in Windows MCP guidance. (Microsoft Learn)

A practical SharePoint/M365 MCP server blueprint (what you likely want next)

If your real goal is “MCP server for SharePoint automation”, a clean tool set looks like this:

1. sp_list_items(siteUrl, listTitle, odataFilter, top)
2. sp_create_item(siteUrl, listTitle, fields)
3. sp_update_item(siteUrl, listTitle, id, fields)
4. sp_upload_file(siteUrl, libraryTitle, folderPath, fileName, bytesBase64)
5. graph_get_user(upn) / graph_search_groups(query) etc.

Then protect it with:

• Entra ID
• APIM validate-jwt policy
• least privilege app permissions

This mirrors the enterprise approach Microsoft uses in Graph MCP Server for Enterprise (Graph calls behind an MCP interface). (Microsoft Learn)

Using Microsoft Learn MCP Server in your workflow (high leverage)

If you’re writing code and want the agent to always use the latest official docs, connect your client to:

• https://learn.microsoft.com/api/mcp (Microsoft Learn)

Then your agent can:

• search docs for “SharePoint list formatting schema”
• fetch full doc pages
• pull code samples

This is especially useful when Microsoft changes APIs/SDKs—your agent can “refresh itself” with official documentation.

Final tables (as requested)

Table 1 — Implementation Steps Checklist

Table 2 — Key Technical Concepts (MCP + Microsoft ecosystem)