Tool Integration & MCP Frameworks
Course Target: Connect your AI agents and agentic browsers to the tools and data they need — using the Model Context Protocol (MCP) as the universal connector and code sandboxes for safe data analysis — so automation reaches your real systems without handing it the keys to everything.
Lessons 7–9 built agents that act; this lesson is about what they can reach. MCP is the standard way to plug an AI agent into a tool or data source — "USB-C for AI." As faculty you'll mostly decide which connections to allow in tools you already use, not build them — so we focus on what happens when you click "Allow," and what to check first. You'll also learn to run AI analysis in a sandbox so it can crunch your data without touching the rest of your system. This sets up Lesson 11 (Governance).
Start from your task
Learning Objectives
- Explain the MCP host → client → server architecture and the tools/resources/prompts a server exposes, and decide which MCP connections to enable or approve for one classroom or department use.
- Evaluate when AI-generated code should run in a sandbox vs. not, and configure a least-privilege sandbox (no network, read-only data, no PII) for a data task.
- Run a verification workflow on AI data analysis — confirm de-identification, recompute a figure, and catch hallucinated results — before trusting it.
Key Terms
Select any card to flip it. Cards are keyboard-operable — press Enter or Space.
Course Outline & Lesson Modules
The picture
HOST (your AI app: Claude Desktop, an IDE, an agentic browser) | |-- client --------▶ SERVER: Catalog • resource (read) |-- client --------▶ SERVER: Ticketing • tool (act) resources = data to READ tools = actions to TAKE prompts = templates
A server can offer up to three things:
- Tools — actions the model can take ("create a ticket," "run a query"). Model-initiated, so the riskier ones.
- Resources — data the model can read ("the syllabus," "a policy doc").
- Prompts — reusable templates a user invokes ("draft feedback for this rubric").
Read isn’t automatically safe
Exposing a resource feels harmless because the model is "only reading" — but that data can carry hidden instructions (text in a PDF or web page telling the agent to do something). That’s indirect prompt injection, and it’s the bridge to Lesson 11. Reading untrusted content is itself a risk.
Worked example
An advising agent needs the course catalog (read) and the ticketing system (act). You enable a catalog server (exposes catalog data as a resource) and a ticketing server (exposes "create ticket" as a tool) — and nothing else.
Decision aid — "Should I connect this MCP server?"
- Who runs it? A vetted/official server, or an unknown third party?
- What can it do? Only resources (read), or tools that can change things? Grant the least it needs.
- Local or remote? Remote means your data leaves your machine — acceptable here?
- Does it touch student data? If yes, it’s also a FERPA question (Lesson 11) — confirm it’s approved or use de-identified data.
Quick check: your agent should read the registrar’s policy PDF (from outside) but never change a record. Safe to connect?
Connect it as a resource (read-only, no write tools) — and remember reading isn’t risk-free: a malicious instruction hidden in that PDF could still try to hijack the agent, which is why human sign-off on actions (Lesson 11) matters.
AI is great at writing analysis code; you should never run that code with full access to your machine or network. A sandbox is a disposable container with least privilege: no network egress, a read-only copy of just the dataset it needs, resource limits, and nothing identifiable it doesn’t require. If the code is wrong — or a hidden instruction in the data tries to make it misbehave (Lesson 11) — the blast radius is one throwaway container.
When to sandbox vs. not
Sandbox any time AI-generated code touches data, files, or the network. Skip it only for pure, self-contained calculations you can read and verify by eye.
Worked example
To analyze a term’s quiz scores, put a de-identified CSV (no names, no IDs) into a sandbox with no internet, let the AI write and run the analysis there, and pull back only the chart and summary — the raw data never leaves your control, and the model never had system access.
Quick check: the AI proposes a script that "downloads the latest enrollment data from the SIS to merge in." Run it?
Not in an open sandbox — that needs network + live student data. Re-scope to already-exported de-identified data, or route it through an approved, governed connection (Lesson 11).
A trustworthy workflow has four steps: De-identify → Generate (let AI write the code/plan) → Run (in the sandbox) → Verify. Verification is the actual skill, so spend your time here:
- Recompute one figure by hand or a second way.
- Check one chart — does it really show what the caption claims?
- Watch for hallucinated results — confident numbers, columns, or trends that aren’t in the data.
Common failure modes: the AI invents a column that doesn’t exist; reports a correlation it never computed; the chart title overstates the finding; a date or unit is silently wrong.
Quick check: the AI hands you a clean summary with three statistics and no code shown. Trust it?
No — ask to see the steps and recompute one statistic. "Looks polished" is not "is correct."
Cumulative Check
You want an agent to read a de-identified quiz CSV, analyze it, and post a summary to your course site. Name one risk at each stage — connection, execution, analysis — and a control.
Reveal model answer
Connection (MCP): only connect servers you need; expose the CSV as a read-only resource, not a write tool, and remember a resource can still carry injected text. Execution (sandbox): run the analysis in an isolated, no-network sandbox on the de-identified copy. Analysis: recompute one statistic and check the chart claim before posting; require your sign-off before it publishes.
Hands-on Workspace Modules
Decide the Connections
Map a sample agent workflow, classify what each MCP server exposes (tool / resource / prompt), run the "Should I connect this server?" aid, and mark the one connection you’d refuse.
- each server’s primitives identified;
- decision aid applied to each;
- the unsafe connection refused with a reason.
Scope a Sandbox
Given an AI-generated analysis script and a dataset, decide sandbox-or-not, set least-privilege, and justify each setting — catching the risky line in the script.
- network off, read-only, de-identified;
- risky network call caught;
- each setting justified.
Verified Data Analysis
Run a guided analysis on a de-identified sample; recompute one statistic, check one chart claim, flag any hallucination, and write a defensible summary.
- one statistic recomputed;
- one chart claim checked;
- hallucination flagged + summary written.
Wrap-up
Sources & Further Reading
- Primary Model Context Protocol specification & introduction — modelcontextprotocol.io (hosts/clients/servers; tools/resources/prompts; local vs. remote connections).
- Primary Anthropic MCP announcement & documentation (Nov 2024 introduction; current client/server support).
- Primary FERPA, 20 U.S.C. § 1232g; U.S. Dept. of Education, Student Privacy Policy Office (studentprivacy.ed.gov) — whenever student data is involved.
MCP architecture and security concepts are stable; specific server names, client support, and features change quickly — verify against current vendor docs before relying on them.