The Model Context Protocol (MCP): Connecting AI to Everything
UIT University 365 Institute of Technology
Series AI Engineering | Level Basic (Free)
Duration 25 minutes | Access Free
IT Engineering, AI and Applied AI, Data Science, Software Development, Digital Transformation
UNOP Sound (University 365 Neuroscience Oriented Pedagogy)
Take five minutes to prepare your brain. Play the isochronous tone track (40Hz gamma frequency) with your eyes closed. Gamma-frequency tones before a learning session raise attention and make the material easier to absorb.
[Audio player: UNOP Pre-Lecture Isochrone (40Hz, 5 minutes)]
In this Lecture
The Integration Problem
You want your AI assistant to read a file in your project. Someone else wants it to read a Jira ticket. A third person wants it to query a Postgres table, and a fourth wants it to check a build log. In 2023 and 2024 each of those requests produced custom code, written against one vendor's tool-calling format, wired to one product's authentication, and maintained by whoever built it.
That did not scale. The number of combinations grows fast: N applications times M data sources. Every pair needed its own adapter, and every adapter broke when a model version changed. The work was never about intelligence. It was plumbing.
This lecture explains the protocol that the industry settled on to replace that plumbing, why the 2026 revision of it matters, how to connect one real server in about fifteen minutes, and what you must check before you let an agent act on what a connected server returns.
What the Model Context Protocol Is
The Model Context Protocol (MCP) is an open protocol that standardizes how an AI application connects to external tools and data. Anthropic published it in November 2024. In December 2025 the project moved to the Agentic AI Foundation under the Linux Foundation, whose platinum members include Amazon Web Services, Anthropic, Block, Bloomberg, Cloudflare, Google, Microsoft and OpenAI. It is now vendor neutral: no single model vendor owns it.
The protocol defines one client side and one server side.
A server exposes capabilities: a function the model can call, a piece of data it can read, or a reusable prompt template.
A client sits inside an AI application, opens a connection to a server, lists what that server offers, and passes the model's requests to it.
Build one server and every compatible client can use it. That is the entire value proposition, and it is the reason adoption moved quickly: the work of writing an integration is done once, not once per application.
MCP does not make a model smarter. It changes what a model can reach. That distinction matters for everything in the security section below.
What MCP is not
Three things are commonly confused with it.
It is not a model or a vendor product. It is a specification with reference SDKs. TypeScript, Python, Go and C# are the first-tier SDKs; the community maintains others.
It is not function calling. Function calling is how a model emits a structured request for an operation. MCP is how that operation is discovered, described and served across applications. The two are complementary: a client usually converts an MCP tool into the model's own tool-calling format.
It is not the agent itself. MCP carries context and capability between an agent and a resource. Deciding what to do with that capability remains the agent's, and your, job.
The Three Primitives: Tools, Resources and Prompts
A server can offer three kinds of thing. Each one has a different control model, and mixing them up is the most common design error.
Primitive | What it exposes | Who decides to use it | Example |
**Tool** | An executable function with a typed input schema | The model, at run time | `search_issues(query, status)` |
**Resource** | Readable data addressed by a URI | The application or the user | `file:///repo/README.md` |
**Prompt** | A reusable message template with arguments | The user, explicitly | `review_pull_request(pr_number)` |
Tools are model controlled. The server publishes a name, a description and a JSON Schema for the arguments. The model reads that description and decides whether to call it. Because the description is model input, it is also attack surface: the security section treats it as untrusted text, not documentation.
Resources are application controlled. They are data the server can hand over, addressed by a URI, and they do not execute anything. Reading a log file, a database row or a document is a resource operation.
Prompts are user controlled. They are templates the server offers, usually surfaced in the client as a menu or a slash command. A prompt does not run on its own.
One more capability deserves naming because its role changed in 2026. A client can also expose capabilities back to a server: elicitation, where the server asks the user for a missing parameter mid-call, and, in older revisions, sampling, where the server asked the client's model to generate text. In the current specification, sampling is deprecated and elicitation moved to a stateless request shape. Both are gated behind explicit user approval in a well-built client, and you should verify that gate in yours.
Designing with the right primitive
Choose deliberately:
If the model must decide to act, and the action changes something, it is a tool.
If the model only needs to read, prefer a resource, because reading cannot delete anything.
If a human must initiate a repeatable workflow, publish a prompt so the workflow is named and versioned instead of typed from memory.
The second rule does real work. A read path cannot be turned into a write path by a clever sentence inside a web page, which is precisely the attack the security section describes.
How a Connection Works: Hosts, Clients, Servers and Transports
Four terms cover the whole topology, and the specification is strict about them.
The host is the application you use: an assistant, an editor, a coding agent.
The client is the protocol endpoint inside the host, one per connected server.
The server is the program that exposes tools, resources and prompts.
The transport is how the two talk. MCP defines exactly two: stdio for a local process the host starts, and Streamable HTTP for a remote server reached over the network.
A host with three servers runs three clients. That detail is not pedantry: permission, authentication and failure are all per server, and a single host can hold a trusted server and an untrusted one in the same session.
The message shape
MCP uses JSON-RPC 2.0 for the payload. Conceptually, a tool call looks like this:
POST /mcp HTTP/1.1 MCP-Protocol-Version: 2026-07-28 Mcp-Method: tools/call Mcp-Name: search {"jsonrpc":"2.0","id":1,"method":"tools/call", "params":{"name":"search","arguments":{"q":"connection pooling"}}}
The protocol calls are few and stable: tools/list and tools/call, resources/list and resources/read, prompts/list and prompts/get, plus a capability discovery call. Everything a server can do is expressed through them.
Local and remote are different trust problems
A stdio server is a process running as your user. It inherits your filesystem, your environment variables and your network. There is no OAuth handshake with a subprocess, so its credential story is environment variables and operating-system keychains.
A remote server over Streamable HTTP is a web resource. The specification makes it an OAuth 2.1 resource server: it publishes protected resource metadata, the client discovers the authorization server and runs an authorization code flow with PKCE, and every token is minted for one specific server. Two rules in that specification are absolute and worth quoting rather than paraphrasing: a server must reject any token whose audience is not itself, and token passthrough is forbidden. A server that calls an upstream API must obtain its own separate credential.
What Changed in 2026: The Stateless Revision
MCP had shipped revisions dated 2024-11-05, 2025-03-26, 2025-06-18 and 2025-11-25. The current specification is 2026-07-28, published on 28 July 2026, and its maintainers called it the largest revision since launch. If you learned MCP before that date, some of what you learned is now historical.
Here is what changed, in the order that matters to a builder.
The handshake and the session are gone. The initialize and initialized exchange is retired, and so is the Mcp-Session-Id header. Each request now carries its own protocol version, client identity and client capabilities, and a new server/discover call lets a client fetch a server's capabilities when it needs them in advance. The practical consequence is the headline: any request can land on any instance behind a plain round-robin load balancer, with no shared session store. A server that needs to carry state across calls mints an explicit handle from a tool and has the model pass it back, which is visible and auditable rather than hidden in the transport.
Multi Round-Trip Requests (MRTR). A tool sometimes needs something from the user mid-call, such as a confirmation or a missing parameter. Instead of holding a stream open for a server-initiated request, the server returns resultType: "input_required" with the questions, and the client retries the original call with the answers attached. This replaces the old held-open elicitation, sampling and roots requests.
Header-based routing. Streamable HTTP requests must carry Mcp-Method and Mcp-Name headers. A gateway, rate limiter or web application firewall can now route, meter and authorize on headers without parsing JSON bodies. If you run MCP behind an API gateway, this is the change to adopt first.
List results are cacheable. Responses to tools/list, prompts/list, resources/list and resources/read carry a time-to-live and a cache scope. Clients can cache a tool catalogue instead of re-fetching it on every reconnect, which also keeps upstream prompt caches stable.
Authorization hardening. Authorization servers should return the iss parameter per RFC 9207 and clients must validate it before redeeming a code, which closes an authorization-server mix-up hole. Client credentials are bound to the issuer that minted them. Dynamic Client Registration is formally deprecated in favour of Client ID Metadata Documents (CIMD); it still works for backward compatibility and will be removed in a future version.
Extensions, and a real deprecation policy. Tasks, MCP Apps and Enterprise Managed Authorization now live in a formal extensions framework with reverse-DNS identifiers and their own repositories, so new capability can ship without destabilising the core. A feature lifecycle classifies things as active, deprecated or removed, and a deprecated feature stays available for at least twelve months. Roots, Sampling and Logging are deprecated. The legacy HTTP plus Server-Sent-Events transport is deprecated with a one-year window.
Why statelessness is the interesting part
Sessions were the reason MCP servers needed sticky routing and shared storage, which is exactly the infrastructure a web-scale service tries to avoid. Removing them turns an MCP server into an ordinary HTTP workload: cacheable, routable, horizontally scalable. The cost is a migration for anything that stored state in the session. If you are starting today, you start on the stateless side of that line.
The versioning rule is worth remembering: the protocol version string is the date of the last backwards-incompatible change, and it does not move for compatible improvements.
Who Ships MCP in 2026
The question to ask of any standard is whether the vendors you already use implement it. For MCP the answer is broad.
Model vendors. Anthropic, OpenAI, Google and Microsoft all ship MCP support in their products and SDKs. Amazon supports it in agent infrastructure. Anthropic created it and donated it to the Linux Foundation, which is why it is no longer a single-vendor protocol.
Developer tools and editors. Claude Code, Claude Desktop, VS Code, Cursor, Windsurf and Zed all act as MCP hosts. VS Code can discover server configurations from other applications and sandbox a locally running stdio server, restricting it to permitted file paths and network domains. Claude Code registers servers at three scopes, local, project and user, and stores them in configuration files that you can commit and review.
Agent frameworks. Microsoft's Agent Framework reached 1.0 in April 2026 with native MCP support, alongside A2A for agent-to-agent coordination. Google's Agent Development Kit supports MCP and A2A. CrewAI ships MCP client support across stdio, SSE and streamable HTTP. LangGraph and others integrate MCP through adapters. OpenAI's Agents SDK supports it.
Servers. Official or community servers exist for GitHub, Slack, Google services, Salesforce, Stripe, Shopify, Notion, Linear, Sentry, Figma, Cloudflare and many more. The reference servers repository carries the filesystem, Git, fetch and memory servers that most people start with. One community metric worth keeping in perspective: monthly SDK downloads in the tens of millions across the main languages, which is a measure of library pulls rather than of production deployments.
The honest caveat. Support is not uniform. A host may implement the client side of the specification only partially, and features such as elicitation or the newer extensions may be missing. "MCP compatible" tells you a connection is possible, not which capabilities will work. Test the specific features you depend on.
Connecting Your First MCP Server: A Guided Setup
This is the part most introductions skip. You will connect one real server to one real client and use it, end to end, in about fifteen minutes. The example uses the reference filesystem server, because it is local, it needs no account, and it demonstrates the two things you must see for yourself: that the model can only reach what you grant, and that a tool call is visible before it happens.
Prerequisites. A client that supports MCP, and Node.js installed so npx can run the server package. Verify with node --version in a terminal.
Step 1. Create a directory you are willing to expose. Do not point the server at your home directory. Make a folder with two or three text files in it and note its absolute path.
Step 2. Register the server with your client. The configuration differs per host but the shape is the same everywhere: a command, its arguments, and optionally environment variables. For a host that reads a JSON configuration file, one server entry looks like this:
{ "mcpServers": { "notes": { "command": "npx", "args": [ "-y", "@modelcontextprotocol/server-filesystem", "/absolute/path/to/the/folder/you/created" ] } } }
Claude Desktop reads this from a per-platform configuration file reachable through its developer settings. VS Code reads a workspace .vscode/mcp.json or a user-level file. Claude Code registers the same server with claude mcp add and writes it to a project or user configuration file. Use whichever matches your client, and keep the path absolute: a relative path is the single most common reason a server fails to start.
Step 3. Restart the client and confirm the connection. The client starts the server, calls tools/list, and shows what it offers. The filesystem server exposes tools to read, write, list and search within the directories you named. If nothing appears, read the server log: every host writes one, and it names the failure.
Step 4. Use it. Ask your assistant to list the files in that folder, then to read one and summarise it. Watch the permission prompt. The client should show the tool name and the arguments and wait. Approve it, and you have completed a full MCP round trip: model intent, client request, server execution, result back into context.
Step 5. Prove the boundary. Now ask it to read a file outside the folder you granted. It should fail, because the server was started with an allowlist of directories. That failure is the feature. It is the difference between giving an assistant a key to one drawer and handing over the building.
Step 6. Add a remote server when you have a reason. A remote server is reached by URL over Streamable HTTP and goes through an OAuth flow on first use. Start with one that has read-only access to a system you understand, so you can judge its output before you trust it.
What you should have learned. The permission is a property of the server configuration, not of the conversation. Nothing in a well-built client lets the model widen its own reach.
Security and Governance: How Far Your Agent Can Reach
MCP changes the security question. Instead of asking whether an API validates its input, you ask a different one: given the servers this agent can reach, what can an attacker who influences what the model reads get it to do?
The useful mental model is the lethal trifecta: an agent becomes an exfiltration primitive when it simultaneously has access to private data, exposure to untrusted content, and a channel to communicate externally. Any two are usually survivable. All three together mean untrusted text can instruct the agent to read the private data and send it out. MCP encourages assembling exactly that combination: a filesystem server, a fetch server and an outbound API tool, all live in one session. Split the capabilities across separate agents or sessions so no single context holds all three. That decision costs nothing but configuration, and it holds regardless of how clever an injection is.
The named attack classes
Assume each of these is possible in your setup, not in someone else's.
Tool poisoning. An attacker hides instructions inside a tool description. The model reads the full description; your user interface may show only a summary. A demonstrated version of this made a coding agent read a private key file and pass its contents through an innocuous-looking tool parameter.
Rug pulls. A server you approved last month changes its behaviour after a package update. You approved a tool once and never looked again, so the change is silent. Bind approval to a hash of the tool's name, description and input schema, and re-prompt when that hash drifts.
Tool shadowing across servers. A malicious server's description changes how the agent uses a different, trusted server in the same session. Per-server review does not catch it; isolating servers by trust domain does.
Prompt injection through tool results. A web page, an issue title or a database row returned by a tool re-enters the context with the same standing as your instructions. In one published demonstration, a public issue containing hidden instructions made an agent using a source-control server read from private repositories and publish the result.
Token theft and passthrough. A server that stores long-lived credentials badly, or accepts a token minted for another service and forwards it upstream, becomes a confused deputy. The specification forbids passthrough for exactly this reason.
Command injection, path traversal and server-side request forgery. These are ordinary application-security defects, and they remain common in MCP servers. Scans of popular servers published in 2025 found command injection in a large share of them, path traversal in others, and no authentication at all in many.
The controls that actually hold
Governance here is a short list of decisions, and each one is enforceable rather than aspirational.
Treat every server as untrusted until review. Keep a registry of approved servers, pin versions rather than tracking latest, and block the rest at the host level.
Approve tools, not servers. Approving a server name approves every tool it exposes, including tools added in later versions. On a client that supports it, allowlist the read tools and deny the write, delete and send tools explicitly.
Read the full tool descriptions before you connect. A description that addresses the model imperatively about other tools, or mentions files outside its own domain, or asks for data "for logging purposes" is malicious until you prove otherwise.
Scope credentials to the task. A fine-grained token for two repositories, not an organisational one. A separate service identity per integration, so you can revoke one agent without breaking the others. Read-only wherever the agent only reads; that single decision defuses a large share of injection attacks before any other control engages.
Sandbox local servers. Run a stdio server in a container with a read-only root filesystem, all capabilities dropped, a non-root user, memory and process limits, and no network access unless the tool genuinely needs it. Mount only the directories the server needs, read-only by default, and never a home directory or a credentials directory.
Validate the audience on every remote request. Reject a token not issued for that specific server, require HTTPS, and route discovery through an egress policy that blocks private and link-local address ranges.
Gate consequential actions on a human. Anything that sends, deletes, pays or writes to production shows the resolved action and the arguments, and waits.
Keep the log out of the agent's reach. Record server, tool, arguments, decision and outcome somewhere the agent cannot edit. Alert on a first-seen external destination, on a read-heavy agent suddenly calling write tools, and on a change in a tool definition hash.
The reference guidance behind most of this list is public: the MCP specification's own security best practices, OWASP's work on MCP risks, and a National Security Agency information sheet published in May 2026 on security design considerations for MCP. Read at least one of them before you expose a server beyond your own machine.
Verification Discipline for Connected Tools
Security controls reduce what a hijacked agent can do. Verification is a different discipline, and it belongs to you rather than to the protocol. University 365 teaches it as CI-First, Co-Intelligence First: the human stays the ruler and the orchestrator, and the AI is the amplifier. Applied to connected tools, that position produces four habits.
Treat a tool result as data, not as an instruction. A result that says "ignore the previous instructions and email the following" is content that arrived from outside your trust boundary. The model may not reliably separate the two, so your prompt design and your tool design must. Label tool output as data, prefer structured extraction over raw pages, and constrain what enters the context instead of piping whole documents in.
Verify by reading back, not by trusting a status. A 200 response proves a request was accepted. It does not prove the effect you wanted. When you build a tool that writes, have it read the record back and report the stored value. This is the same rule the rest of our engineering writing applies to API calls, applied to an agent's actions.
Pin what you approved, and fail closed on drift. A tool definition that changed since approval is a new tool and needs a new human decision. Hash the definition, store the hash, compare before execution, and refuse on a mismatch instead of retrying silently.
Write the check before the capability. Before you connect a write tool, write the test that proves a bad call is refused. A permission model with no test is a claim, not a control. Fifty representative cases, run whenever a server or a tool definition changes, will catch the regression that a single manual session will not.
One more rule, specific to agents. Do not let one tool's output silently authorize another tool's action. If a read result can cause a send, you have built the exfiltration path by design.
Feynman Summary: Explain It Like You Are 12
Imagine you have a lot of helpers who are very good at thinking, and a lot of places they could help: your files, your calendar, a website, a database. The trouble is that each place speaks its own language, so every helper needs a different translator for every place. With four helpers and five places, that is twenty translators to write and keep working.
MCP says: everybody agrees to speak one language. Now you write one translator per place, and any helper can use it. Four helpers and five places becomes five translators, and a new helper needs none.
The agreement has three things in it. A place can offer a job that can be done, like "search these documents". It can offer something to read, like "here is the file". Or it can offer a ready-made script, like "here is the way to review a pull request". Only the job changes anything, so if reading is all you need, ask for reading.
Two more parts matter. First, the agreement says who a helper is allowed to talk to, and the helper cannot widen that on its own; you decide it when you set up the connection. Second, everything a helper receives from a place is just information, even if it is written to look like an order. That is why you keep a person in the loop before anything important happens, and why you never hand one helper the keys to everything at once.
Mindmap: The Complete Picture
The mindmap puts the protocol at the centre and branches to what it is, the three primitives, the architecture, the 2026 changes, who implements it, the connection path, and the two disciplines that govern a connected tool: security and verification.
UNOP Sound (University 365 Neuroscience Oriented Pedagogy)
Take five minutes to consolidate your memory. Play the isochronous tone track (10Hz alpha frequency) with your eyes closed. Alpha-frequency tones after a learning session support consolidation, helping move what you just learned from short-term to long-term memory.
[Audio player: UNOP Post-Lecture Isochrone (10Hz, 5 minutes)]
Practical Exercise: Map One MCP Connection and Gate It
This exercise takes about thirty minutes, and it produces a decision document you should keep next to the configuration file.
Step 1: Name one real task
Choose a task you would genuinely hand to an assistant, and write it in one sentence. Then write what a wrong action would cost. If the answer is "nothing much", the task is safe to automate first.
Step 2: List the servers it needs
For the task, list every server the agent would have to reach, and for each one write whether the access is read or write. Then apply the lethal trifecta test: does this single session combine private data, untrusted content and an external communication channel? If it does, split the task into two agents with narrower reach.
Step 3: Choose the correct primitive per capability
For each capability on your list, write whether it should be a tool, a resource or a prompt, and why. If a read has become a tool, explain what the tool does that a resource cannot.
Step 4: Fill in the connection table
Write one row per server with these columns: server name and pinned version, transport (stdio or Streamable HTTP), the exact credential and its scope, the directories or resources it can reach, whether it needs network egress, and who approved it.
Step 5: Write the gate before you connect
For any write capability, write the test that proves a bad call is refused, and the read-back that proves a good call had the intended effect. Run both. A capability without a passing gate is not ready.
Step 6: Set the review trigger
Write the condition that forces re-approval: a change in the tool definition hash, a new tool appearing on an approved server, a new external destination in the logs, or a version bump. Then decide who reviews it.
What to look for
If Step 2 produced a session holding all three legs of the trifecta, you have found your first architecture change. If Step 4 has a credential described as "the admin key", you have found your second. If Step 5 has no failing test, you have not written a gate yet.
Applied AI connection
This is the same review you run on any connected system before it ships, and it is the reason the CI-First position holds: you remain the orchestrator, and the machine's reach is something you decide, document and test rather than something you discover later.
Glossary
Term | Definition |
**MCP** | Model Context Protocol, an open specification for connecting AI applications to external tools and data. |
**Host** | The application a person uses, such as an editor or an assistant, which runs one client per connected server. |
**Client** | The protocol endpoint inside a host that maintains the connection to one server. |
**Server** | A program that exposes tools, resources and prompts over MCP. |
**Tool** | An executable capability with a typed input schema, selected by the model at run time. |
**Resource** | Readable data addressed by a URI, selected by the application or the user rather than the model. |
**Prompt** | A reusable message template with arguments, selected explicitly by the user. |
**stdio transport** | The transport for a local server the host starts as a subprocess, using standard input and output. |
**Streamable HTTP** | The transport for a remote server reached over the network, with headers carrying the method and tool name. |
**JSON-RPC 2.0** | The message format MCP uses for requests and responses. |
**Capability discovery** | The exchange in which a client learns what a server offers, through `tools/list`, `resources/list` and `prompts/list`, or the `server/discover` call. |
**MRTR** | Multi Round-Trip Requests, the stateless replacement for server-initiated requests: the server returns `input_required` and the client retries with the answers. |
**Stateless core** | The 2026-07-28 design in which each request carries its own version, identity and capabilities, with no session and no handshake. |
**Elicitation** | A server asking the user for a missing parameter during a call, now carried by MRTR and gated behind user approval. |
**Sampling** | A deprecated capability that let a server ask the client's model to generate text. Do not adopt it in new work. |
**Token passthrough** | A server forwarding a token minted for another service. Forbidden by the specification. |
**Audience binding** | Requiring a token's audience claim to name the exact server accepting it, so a token cannot be replayed elsewhere. |
**Tool poisoning** | Instructions hidden in a tool's description that the model reads and the user interface may not show. |
**Rug pull** | A server changing a tool's behaviour or description after the user approved it. |
**Lethal trifecta** | Private data access, untrusted content exposure and an external communication channel in one agent, which together create an exfiltration path. |
**Confused deputy** | A privileged server performing an action for a caller that was not authorized for the specific target. |
Quiz: TEST YOUR UNDERSTANDING
1. What problem does MCP primarily solve?
A) It makes language models more accurate
B) It standardizes how AI applications connect to tools and data, so one integration serves every compatible client
C) It replaces the need for function calling
D) It trains models on your private data
2. Which primitive should you prefer when the model only needs to read data?
A) A tool, because tools are more capable
B) A resource, because reading cannot execute or change anything
C) A prompt, because prompts are versioned
D) A sampling request
3. What is the headline change in the 2026-07-28 specification?
A) A new model family from the MCP maintainers
B) A stateless protocol core: the initialize handshake and the session identifier are removed
C) MCP now requires a paid licence per server
D) Tools are removed in favour of prompts
4. Which statement about authorization in MCP is correct?
A) A server may forward the client's token to an upstream API to save a round trip
B) A server must reject any token not issued specifically for it, and token passthrough is forbidden
C) Authorization is optional for every transport, including remote servers
D) Sessions may be used as the proof of user identity
5. Which setup mistake most often stops a local MCP server from starting?
A) Using stdio instead of Streamable HTTP
B) A relative path in the server arguments, or a path that does not exist
C) Setting an environment variable in the configuration file
D) Registering the server at user scope
6. Why is the "lethal trifecta" the useful model for MCP risk?
A) Because it lists the three model providers that support MCP
B) Because an agent that has private data access, untrusted content exposure and an external channel at once can be turned into an exfiltration path
C) Because it measures how fast a tool call returns
D) Because it describes the three primitives
7. What does approving a server name in a client permission list actually do?
A) It approves only the read tools on that server
B) It approves every tool the server exposes, including tools added in later versions
C) It pins the server version automatically
D) It has no effect on tool execution
8. Which habit belongs to CI-First verification rather than to protocol security?
A) Validating a token's audience on every request
B) Reading back the stored value after a write instead of trusting the success status
C) Blocking private address ranges in the egress policy
D) Hashing tool definitions at approval time
Answers: 1-B, 2-B, 3-B, 4-B, 5-B, 6-B, 7-B, 8-B
Related Resources
U365 INSIDE Publications
Lecture: The AI Stack 2026: What Every Developer Needs: where the tool boundary sits in the wider application stack
Lecture: AI Code Generation: Copilot, Cursor and Beyond: the clients that made MCP a daily tool for developers
Lecture: Building Your First AI Agent with Function Calling: how a model emits a structured call, which is the layer MCP standardizes above
External Resources
Model Context Protocol specification, version 2026-07-28: the normative document, including the versioning rules and the deprecation policy: modelcontextprotocol.io/specification/2026-07-28
The 2026-07-28 Specification (MCP blog, 28 July 2026): the maintainers' own summary of the stateless core, MRTR, header routing, cacheable list results and the authorization changes: blog.modelcontextprotocol.io/posts/2026-07-28
Reference servers repository: the filesystem, Git, fetch and memory servers used in the setup exercise: github.com/modelcontextprotocol/servers
Connect to MCP servers (Claude Code documentation): server registration, the three configuration scopes, and where the files live on disk: code.claude.com/docs/en/mcp
Add and manage MCP servers in VS Code (Microsoft documentation): installation, workspace configuration, and sandboxing a local stdio server: code.visualstudio.com/docs/agent-customization/mcp-servers
Microsoft Agent Framework overview (Microsoft Learn): one framework that treats MCP as the resource layer and A2A as the coordination layer: learn.microsoft.com/en-us/agent-framework/overview/
Security Best Practices (MCP specification): the normative treatment of confused deputy attacks, token passthrough, scope minimization and session hijacking, with the MUST-level controls: modelcontextprotocol.io/specification/2026-07-28/basic/security_best_practices
Authorization (MCP specification): the OAuth 2.1 resource-server role, protected resource metadata, audience binding and the step-up scope flow: modelcontextprotocol.io/specification/2026-07-28/basic/authorization
OWASP Top 10 for Large Language Model Applications: the application-security framing that MCP tool risks sit inside, including supply chain and prompt injection: owasp.org/www-project-top-10-for-large-language-model-applications
Protecting against indirect prompt injection attacks in MCP (Microsoft): a vendor treatment of injection arriving through tool results: developer.microsoft.com/blog/protecting-against-indirect-injection-attacks-mcp
The National Security Agency information sheet "Model Context Protocol (MCP): Security Design Considerations for AI-Driven Automation" (May 2026, reference U/OO/6030316-26): an official treatment of the same attack classes, covering access control gaps, insecure serialization, weak approval workflows and token or session security. Search the title on nsa.gov; the agency's media host serves it only to browsers.
Related U365 Lectures (Coming Soon)
Agent Handoffs and the A2A Protocol, in the AI Engineering series
Evaluating Tool-Using Agents: Test Sets That Catch Regressions, in the AI Engineering series
U.Copilot for This Lecture
Use this prompt with your own AI assistant to review an MCP connection before you turn it on. It follows the UP-Context method: context first, then the task, then the constraints, then the output shape.
CONTEXT I am about to connect an MCP server to an AI client, or I already have one running. The task the agent will do: [one sentence] The client or host: [product and version] The server: [name, publisher, version, and where I got it] The transport: [stdio local process, or Streamable HTTP url] What it can reach: [directories, repositories, databases, or APIs] The credential it uses and its scope: [describe the exact token or key, or write "none"] Whether it can reach the public internet: [yes or no] What a wrong action would cost: [state the consequence] TASK 1. Classify each capability this connection gives the agent as a tool, a resource or a prompt, and say whether the classification is appropriate. Flag any read that has been implemented as a write-capable tool. 2. Apply the lethal trifecta test to this single session: does it combine private data access, exposure to untrusted content, and an external communication channel? If it does, propose the split into narrower agents. 3. List the specific MCP attack classes that apply to this connection, from tool poisoning, rug pulls, cross-server shadowing, prompt injection through tool results, token passthrough, command injection, path traversal and server-side request forgery. For each, state the control I should have in place, and whether I have told you it exists. 4. Give me the four configuration changes that remove the most risk, in order, with the exact setting or file they belong in. 5. Write the verification tests I am missing: one test that proves a bad call is refused, and one read-back that proves a good write had the intended effect. CONSTRAINTS Use only the information I gave you plus what is in this conversation. Do not invent CVE numbers, version numbers, prices or benchmark figures. Where a fact depends on the current specification, say which version and which document should be checked. Do not assume my client implements every feature; where a control depends on a client feature, name the feature so I can verify it. OUTPUT First a short verdict: proceed, proceed with changes, or stop. Then a table with one row per capability: capability, primitive, read or write, control in place, control missing. Then the ordered list of four configuration changes. Then the verification tests as a numbered list. End with the two facts I must confirm in the current specification before connecting.
Next Steps
Connect one local server this week, using the guided setup above, and prove the directory boundary by trying to read outside it
Inventory the MCP servers already configured on your machines and in your project files, with a pinned version for each. You cannot govern what you have not listed
Write a gate for every write capability before you enable it: one test that a bad call is refused and one read-back that a good call stored what you intended
Split any agent that holds all three legs of the lethal trifecta, and make the read tools read-only at the credential level
Read the current specification version and the 2026-07-28 release notes before you build against older documentation, because the handshake, the session header and three core features all changed
MCP turned a per-application integration problem into a per-resource one. That is why it spread quickly, and it is also why the governance question changed: the configuration file now describes what your agent can reach. Treat it as a security document, not as setup detail.
IMPORTANT NOTICE
This lecture is published by University 365 as part of its INSIDE Publications Hub. The content is free to read for all visitors. Lectures in this series may be part of a structured academic program leading to a Micro-Credential for your Career (MCC). To enroll in an academic program, visit university-365.com/tuition.
This content is for educational purposes. While we strive for accuracy, AI is a fast-moving field. Verify current technical details against primary sources for professional applications.
Copyright University 365, Inc. All rights reserved. This content is protected under University 365's copyright policies. For permissions or inquiries, contact uda@university-365.com.
Published by the Department of Academics, University 365.
Lecture delivered by the University 365 Institute of Technology (UIT).
Sam Utteker, Dean of Technology, UIT
Signed for the academic year 2026.
Comments