Agents, Tools, and MCP

How conversations, workflows, and agents differ, and what tool use, connectors, and permissions change.

About 15 minutes

By the end of this lesson you should be able to

Tell a conversation, a workflow, and an agentic system apart by who or what decides the next step
Separate a system’s ability to call a tool from its permission to take an action
Explain in plain terms what MCP standardizes, and what it does not decide for you

When the system chooses the next step

Lesson 1 described the parts of an AI system. This lesson is about what changes when a system can choose among tools and take several steps on its own. More can happen between your request and the result, and more of it happens without anyone watching each step. That can save real effort. It also moves decisions you used to make into the system, so they have to be designed, limited, and checked.

Conversation, workflow, agentic system

These are working distinctions for this course, not universally agreed technical or legal definitions. Many real products mix them.

Conversation: A user asks; the assistant responds. Each next step is the user’s choice.
Workflow: The steps are substantially set in advance by whoever designed it. AI may perform some steps, such as summarizing each new submission, but the sequence does not change from run to run.
Agentic system: The system can choose among actions or tools as it works toward a goal: which source to search, whether to read further, whether to draft or stop, possibly over many steps.

Anthropic offers one widely cited provider framework. It calls both arrangements “agentic systems,” and distinguishes workflows, “systems where LLMs and tools are orchestrated through predefined code paths,” from agents, “systems where LLMs dynamically direct their own processes and tool usage.” (Anthropic: Building effective agents (opens in a new tab), December 19, 2024; the article notes that much of the tooling it describes has since changed.) Other providers and researchers draw the lines differently.

Use the simplest arrangement that works

Do not use an agent merely because one is possible. Anthropic recommends “finding the simplest solution possible, and only increasing complexity when needed,” noting that agentic systems “often trade latency and cost for better task performance” and that autonomy brings “the potential for compounding errors.” A predictable task is usually better served by a workflow, whose steps can be reviewed and tested one by one.

An agentic design is worth considering only when all of these hold:

the steps genuinely cannot be fixed in advance;
success can be checked at the end, against something other than the system’s own report;
mistakes along the way can be caught and reversed;
the tools and permissions it needs can be kept narrow.

Tools, and the difference between can and may

A tool is a capability the system can invoke: search a website, read a file, query a database, create a draft, send a message, change a record. Typically the model proposes a tool call and the surrounding application carries it out. Two distinctions matter more than the list:

Reading versus acting. Reading a file and deleting one are both tool calls, with very different consequences. Sort tools by what they can change.
Ability versus permission. That a system can call a tool means the capability is wired in. Whether it may take a particular action, on particular data, for a particular person, is a separate question, best enforced by the service being acted on and by approval steps, not left to the model’s judgment.

A connector is an integration between an AI application and another service, such as a cloud drive, a calendar, or an email system. Depending on the integration, it may provide information to read, tools that take actions, or both. What it can actually reach depends on the identity it uses, the permissions attached to that identity, whether an account has been authorized, and how the service is configured. Keep three things apart: a capability being available, authorization to use an account or its data, and permission for a particular action.

MCP in plain terms

The Model Context Protocol (MCP) is, in its maintainers’ words, “an open-source standard for connecting AI applications to external systems.” Instead of every AI application building its own integration with every service, a service can offer an MCP server that any compatible AI application can connect to. (MCP: What is the Model Context Protocol? (opens in a new tab))

According to the specification, a server can offer three kinds of things:

Tools: “Functions for the AI model to execute,” such as searching a catalog or creating a record.
Resources: “Context and data, for the user or the AI model to use,” such as a document or a database entry.
Prompts: “Templated messages and workflows for users,” such as a prepared request for a common task.

(MCP specification (opens in a new tab).) The protocol changes over time. Its versioning page gave the current protocol version as 2026-07-28 when this lesson was written; the live specification governs. (MCP: Versioning (opens in a new tab), checked September 28, 2026.) You do not need its message formats or transports to supervise a system that uses it.

What MCP is not:

Not an agent. It is a way of connecting capabilities. A plain workflow can use an MCP server; an agent can work without one.
Not the model. An MCP server is a program that offers tools and data; the model is elsewhere.
Not authorization. Connecting to a server does not by itself grant rights to the data behind it; the underlying service’s accounts and permissions still apply.
Not permission for a particular action. A tool call is a request. The specification says hosts “must obtain explicit user consent before invoking any tool,” and also that “MCP itself cannot enforce these security principles at the protocol level.” Whether consent is actually asked for depends on the application.

Worked example: one goal, three arrangements

A constructed example.

A faculty member wants, each week, a short list of new public commentary on a seminar topic.

Conversation: each Monday they ask an assistant with web search, and read what comes back.
Workflow: every Monday, a set sequence searches two named public sites, summarizes up to five new items with links, and places the draft in the faculty member’s inbox for review. Nothing is sent to students automatically.
Agentic system: given the goal, the system decides which sites to search, how many items to read, whether to follow links, and whether to email the list to the seminar.

The workflow fits best: the steps are predictable, each can be tested, and a person reviews the output before anyone else sees it. The agentic version adds choices nobody needs delegated, plus an email action that would reach students without review.

Try it: take a research assistant apart

A fictional assistant and tool list. Nothing is connected or configured.

The request. A clinic student asks Brief Helper: “Find recent public commentary on the new state tenant-screening rule, check our shared folder for the memo we wrote last spring, and send Professor Lee a one-page summary.”

Brief Helper: available tools (fictional)
Tool	What it does	Acts as
search_public_site	Searches public websites and returns pages	No account
read_shared_folder	Reads any file in the clinic’s shared folder	The student’s account
create_draft	Creates a document in the student’s drafts	The student’s account
send_email	Sends email to any address	The student’s account

What is the goal, and what is the model’s part in reaching it?
Sort the tools into those that read and those that act.
What permissions does each tool carry, and which are broader than the task needs?
Which actions should require a person’s approval?
What information should not automatically enter the loop?
Does this task need an agentic design at all?

Answers and discussion

Goal: an accurate one-page summary for Professor Lee, combining current public commentary with the clinic’s earlier memo. Model: plans steps, proposes tool calls, and drafts text. It does not itself search, read, or send; the tools do.
Read: search_public_site, read_shared_folder. Act: create_draft (low consequence; it stays in the student’s drafts) and send_email (external, under the student’s name, hard to undo).
read_shared_folder can open any file in the folder, far more than one memo. send_email can reach any address. Narrower versions: read only a named file, or ask the student to pick it; send only to addresses the student confirms, or not at all.
Sending the email, always. Arguably also opening any file other than the named memo. Creating a draft needs no approval, because nothing leaves the student’s control.
Other clients’ files in the shared folder; any confidential clinic material if the assistant is not approved for it; and text inside public web pages treated as instructions rather than as content (Lesson 5).
Probably not. A simple workflow does the job: search, then read one memo the student chooses, then draft, then the student reads, edits, and sends the email themselves. Some would allow the assistant to propose the email for one-click approval; the approval should show the exact text and recipient.

Decision criteria for tools and agents

Is a conversation or a fixed workflow enough? Prefer it if so.
For each tool: does it read or act, and what is the worst thing it could do?
Does each tool reach only what this task needs, under the right person’s identity?
Which actions need a person’s approval, and does the approval show exactly what will happen?
Is there a record of which tools were called and what they did?

A tool call is a request, not a permission. Give a system only the tools the task needs, keep actions that reach other people behind approval, and do not add autonomy the task does not require.

Resources

Model Context Protocol: introduction (opens in a new tab) and current specification (opens in a new tab) — official documentation; the specification is versioned and changes over time.
Anthropic: Building effective agents (opens in a new tab) — a provider framework for workflows and agents, and when not to use agents.
Agents Without the Hype, modules 4–7 — optional deeper material on tools, multi-step work, changing plans, and reading versus acting.