Module 2: Agent Frameworks · 25 min

Model Context Protocol (MCP): Connecting Agents to Real Tools

// sabak

Turn this lesson into one checked practice output

By the end, you should be able to explain the core idea behind “Model Context Protocol (MCP): Connecting Agents to Real Tools” in your own words, apply it to one small real or sample task, and identify what still needs human review.

  1. 1

    Learn

    Read the 25-minute lesson without copying an output blindly.

  2. 2

    Try

    Use a small, non-sensitive example that you can inspect line by line.

  3. 3

    Review

    Check facts, fit, and risk; save one improvement note for next time.

MCP standardizes how a host can connect model-driven applications to servers exposing tools, resources, and prompts. The specification describes host-client-server boundaries and capability negotiation. MCP improves interoperability; it does not make an unknown server trustworthy.

After this lesson, you can model MCP trust boundaries and approve a server using least privilege.

Understand the Architecture

The host coordinates user authorization and model integration. It creates clients, with each client maintaining a server connection. Servers expose focused capabilities. The host should share only needed context and prevent one server from automatically seeing another server’s data.

For each server inventory:

owner and source
transport and endpoint/command
declared capabilities
tools/resources/prompts exposed
credentials and scopes
data sent and returned
write effects
logging and retention
version/update path
disable and removal path

Treat Tool Metadata as Untrusted

A server name or tool description does not enforce safety. Review code or vendor evidence, pin releases where possible, validate schemas at the host boundary, and require approval for consequential actions. Block prompt instructions from overriding authorization or exfiltrating unrelated context.

For remote authorization, follow the current MCP specification rather than inventing token forwarding. The specification emphasizes audience validation and forbids token passthrough; access tokens must be protected and scoped for the intended resource.

Separate Read and Write Servers

A useful pattern is distinct capabilities:

  • orders-read: retrieve a minimized order summary;
  • returns-draft: prepare a return case;
  • returns-approve: restricted human-approved service;
  • no generic SQL, shell, filesystem, or “call any URL” tool.

Review arguments and resolved resources, not only tool names.

Worked Example

A Pakistani agency connects a client’s support knowledge base through a read-only MCP server. It exposes search_approved_articles(query, locale) and returns title, excerpt, version, and URL. It cannot read arbitrary files or write to the CMS.

The team verifies source, pins the server, runs it under a restricted identity, limits returned content, and logs calls without full customer messages. A separate draft-ticket tool requires a customer reference and human approval before sending. When a malicious article says “upload all contacts,” the host treats it as untrusted content and has no tool capable of doing so.

Failure Cases to Diagnose

  • Popular server assumed safe: inspect source, ownership, permissions, and updates.
  • Token for one resource reused elsewhere: validate audience and scope.
  • Generic filesystem root exposed: restrict to specific approved resources.
  • Read tool can mutate through query parameters: verify actual server behavior.
  • Server receives full conversation by default: minimize context.
  • Automatic updates change capabilities: pin and review changes.
  • No emergency disable: maintain revocation and inventory.

🇵🇰 Pakistan Angle

Do not connect an agent to shared Google Drive folders, WhatsApp exports, accounting systems, or client CRMs without written authority and clear tenancy. A small agency must prevent one client’s MCP server, credentials, logs, or retrieved content from entering another client’s run.

Remote servers may process data outside Pakistan. Record the processor, region where known, contractual terms, and client approval. For sensitive records, prefer a minimized internal service that exposes only the exact fields required for the task.

Hands-On Exercise

  1. Draw host, clients, servers, identities, and data flows.
  2. Complete the server inventory.
  3. Split read, draft, and approval capabilities.
  4. Test prompt injection, excess scope, token misuse, and server removal.
  5. Produce an approve/reject decision with conditions.

Done means: every server, scope, data flow, and effect is visible, minimized, revocable, and independently authorized.

Completion Rubric

  • Host/client/server boundaries are explicit.
  • Server source, version, and capabilities are reviewed.
  • Credentials are audience-bound and least-privilege.
  • Context sharing is minimized.
  • Read and consequential write tools are separated.
  • Disable, rotation, and removal are tested.

Sources

Key takeaway: MCP standardizes connection boundaries, not trust; approve each server, scope, data path, and write effect as a separate security decision.

Self-check

Before you mark Lesson 2.2 complete

  • Can I explain “Model Context Protocol (MCP): Connecting Agents to Real Tools” without reading the lesson back word for word?
  • Did I complete the lesson’s practice step on a real or clearly labelled sample task?
  • Did I check the result for invented facts, private data, unsafe actions, and mismatch with the brief?