MCP Server — Module 15.3

How This Lesson Fits the Module & Volume

The MCP overview named three roles. This lecture is the server: the process that wraps your APIs, files, and databases and advertises them as tools, resources, and prompts. The next lecture is the client that lives in the host. Together they replace one-off plugins for AI agents.

Servers are also a natural place to enforce ACLs before anything reaches working memory or long-term memory.

Learning Objectives

By the end of this lesson, students should be able to:

Define an MCP server as a capability provider over JSON-RPC transports.
List what a server advertises: tools, resources, prompts (and optional sampling).
Choose stdio vs remote HTTP/SSE based on local vs shared deployment.
Sketch initialize → capabilities → list/call handlers.
Apply least privilege: credentials live on the server, not in the prompt.
Relate server design to later tool and resource lectures.

Definition

An MCP server is a program that implements the server side of the Model Context Protocol: it declares capabilities, answers list/read/call methods, and performs the real I/O against downstream systems. Clients never talk to those systems directly.

What a Server Must Do

Phase	Server responsibility
Transport	Speak stdio or HTTP/SSE; framing JSON-RPC messages
Initialize	Protocol version + capability flags (tools, resources, prompts)
Discovery	tools/list, resources/list, prompts/list (and templates)
Execution	tools/call, resources/read; structured results or errors
Updates	Optional notifications when catalogs change

Local vs Remote Servers

stdio (local)

Host spawns a subprocess
Great for desktop IDEs
Uses the user’s machine creds

HTTP / SSE (remote)

Shared team or org server
Needs auth (tokens, mTLS)
Central logging and ACLs

Hybrid

Local proxy → remote API
Secrets stay off the laptop
Common in enterprise agents

Minimal Server Sketch

SDKs exist in Python, TypeScript, and others; APIs evolve. The sketch shows the shape you implement: declare tools, validate arguments, return text (or resource contents) without leaking secrets into logs.

# Conceptual MCP server (SDK names vary; focus on the contract)
from typing import Any

TOOLS = {
    "lookup_ticket": {
        "description": "Fetch a support ticket by id (read-only).",
        "input_schema": {
            "type": "object",
            "properties": {"ticket_id": {"type": "string"}},
            "required": ["ticket_id"],
        },
    }
}

def handle_initialize(params: dict) -> dict:
    return {
        "protocolVersion": "2024-11-05",
        "capabilities": {"tools": {}, "resources": {}},
        "serverInfo": {"name": "support-mcp", "version": "0.1.0"},
    }

def handle_tools_list() -> dict:
    return {
        "tools": [
            {"name": n, "description": t["description"], "inputSchema": t["input_schema"]}
            for n, t in TOOLS.items()
        ]
    }

def handle_tools_call(name: str, arguments: dict[str, Any]) -> dict:
    if name != "lookup_ticket":
        return {"isError": True, "content": [{"type": "text", "text": "Unknown tool"}]}
    ticket_id = arguments.get("ticket_id", "")
    row = db.fetch_ticket(ticket_id, tenant=current_tenant())  # ACL inside server
    if not row:
        return {"isError": True, "content": [{"type": "text", "text": "Not found"}]}
    return {"content": [{"type": "text", "text": f"#{row.id} {row.status}: {row.title}"}]}

Design Rules

Keep secrets on the server. The model sees ticket text, not the DB password. Fail closed on missing tenant. Keep tools small—one clear side-effect each—so HITL approval is meaningful. Version your catalog so hosts can refresh after deploys. Expose read-only data as resources when the agent only needs context, not an action.

Strengths

One server, many MCP hosts
Central place for ACL + audit
Swap downstream APIs without changing the agent graph
Can wrap existing internal services

Tradeoffs

Process/ops overhead vs in-process fns
Must handle schema validation yourself
Remote servers need auth story
A buggy server is a wide blast radius

Common Misconception

“The MCP server is the agent.” The server has no planner. It should not call the LLM in a loop (except optional sampling features some specs allow). Planning, reflection, and memory live in the host. A server that “just does the whole task” becomes an uninspectable mega-tool.

Knowledge Check

Short Answer: What does an MCP server expose to clients? Answer: Capabilities such as tools, resources, and prompts (via list/call/read).
True/False: An MCP server should typically hold API secrets rather than putting them in the prompt. Answer: True.
Multiple Choice: Desktop IDEs often connect to servers via: (a) stdio subprocess, (b) SMTP, (c) HDMI. Answer: (a).
Short Answer: Name the handshake method conceptually used first. Answer: initialize (protocol version + capabilities).
True/False: The server is responsible for the agent’s multi-step plan. Answer: False—that is the host/agent loop.
Multiple Choice: Tenant ACL checks belong: (a) only in the LLM prompt, (b) in the server before I/O, (c) in CSS. Answer: (b).
Short Answer: When would you prefer a remote HTTP MCP server? Answer: Shared org access, central creds/logging, or non-local data.
True/False: tools/list is part of discovery. Answer: True.
Multiple Choice: A mega-tool that “does the whole ticket” is risky because: (a) it hides planning, (b) JSON-RPC forbids it, (c) vectors cannot embed. Answer: (a).
Short Answer: Which role inside the host speaks to this server? Answer: The MCP client.

Key Takeaways

MCP servers advertise and execute tools/resources; they are not planners.
stdio vs HTTP/SSE is a deployment choice; auth and ACL always matter.
Keep secrets server-side; return only context the model should see.
Small, well-described tools beat opaque mega-actions.
Continue with MCP Client.

Trainer’s Guide

Lab: Implement lookup_ticket against a fake dict DB with tenant filters; show a cross-tenant id returning Not found.

Whiteboard: Host vs server process boxes; arrows for initialize, list, call. Mark where API keys sit.

Recap: The MCP server is the capability provider. Continue with MCP Client.