Prompt Chains, Tool Calling, and MCP: How AI Agents Actually Do Things

I run three AI agents in production. When I was preparing for job interviews, an assistant asked me a question that sounds simple and isn't: "Do your agents use tool calling or MCP, or are they just graph-orchestrated LLM calls?"

If that sentence reads like alphabet soup, this post is for you. By the end you'll know exactly what each of those words means, why the differences matter, and how to tell, for any "AI agent" anyone shows you, which kind you're actually looking at. No prior AI knowledge needed.

I also went and audited my own three agents against these definitions instead of assuming I knew the answer. The audit changed my answer. That part is at the end, and it's the most useful section in the post.

Start here: a brilliant intern with no hands

A large language model (LLM), the technology behind Claude, ChatGPT, and Gemini, is a computer program trained on enormous amounts of text until it became very good at one thing: reading text and writing the text that should come next. That one skill turns out to cover a lot: answering questions, summarizing, writing code, explaining ideas.

Here's the catch. Out of the box, an LLM can only talk. It can't check today's weather, look at your database, send a text message, or save a file. It has a brilliant mind and no hands.

Everything in this post is about the different ways engineers give the intern hands, and who stays in charge of them.

A few terms before we go further:

• Prompt — the text you send to the model. Its instructions plus your question.
• API (application programming interface) — a doorway that lets one program ask another program for something. Your weather app uses a weather API. When my code talks to Claude, it uses Claude's API.
• Agent — an AI system that doesn't just answer once, but works through a multi-step task, deciding what to do next as it goes.

Level 1: The prompt chain (the assembly line)

The simplest way to get real work out of an LLM is to break the job into steps and call the model once per step. My code decides the order; the model just fills in each blank.

Analogy: an assembly line. Station 1 stamps the metal, station 2 paints it, station 3 boxes it. The parts moving down the line are text. The model works at each station, but it never decides what the stations are or what order they run in. The factory layout, the orchestration, is mine, written in ordinary code.

One of my production agents, the WitUS Triage Agent, reads every form submission that comes into my product ecosystem and works through stages: classify it (bug report? partnership offer? spam?), enrich it (pull up related context), propose an action, then wait for me to approve before doing anything irreversible. Those stages are a fixed pipeline I wrote using a framework called LangGraph, a library for wiring LLM calls and logic into a flowchart-like graph, where each box (a node) does one job and the arrows decide what runs next.

That stage-to-stage structure is what "graph-orchestrated LLM calls" means: the model is brilliant inside each box, but the code owns the map.

The approval step is worth pausing on, because it's the part I'd defend hardest. It uses LangGraph's interrupt(), which genuinely suspends the graph and persists its state to a database, so the run can sit there for a day waiting on me and resume exactly where it stopped. Everything with irreversible consequences, sending an SMS, filing a ticket, lives strictly downstream of that gate.

SWOT: prompt chains / graph orchestration

Level 2: Tool calling (give the intern a phone)

Now the interesting jump. Tool calling (also called function calling) means you hand the model a menu of actions it's allowed to take, and let the model decide when to use them.

Each tool has a name, a plain-English description, and a schema: a precise, machine-checkable description of what inputs the tool accepts. During a conversation, the model can say, in a structured format, "I want to call get_product_status with productSlug: "flashlearnai"." Your code executes that call, the model never touches the database itself, and sends the result back. The model reads it and continues.

Analogy: the intern now has a phone and a directory of departments. You didn't script when to call accounting; the intern reads the situation and decides "before I answer this, I should check with accounting." But, and this matters, the intern can only call numbers in the directory you printed, and every request goes through your switchboard.

In code, the tell is a step where you attach the tool menu to the model, usually a call named something like bindTools. That's the moment you hand over the directory. Remember that name; it's how you audit any codebase, including your own, in about thirty seconds.

SWOT: tool calling

Level 3: MCP (the universal adapter)

Tool calling has one annoyance: every developer wires their tools into their own app, their own way. My tools work in my agents, but if you wanted your AI assistant to use them, I'd have to hand you my source code.

The Model Context Protocol (MCP) fixes this. It's an open standard, introduced by Anthropic in late 2024 and since adopted widely across the industry, for packaging tools in a server that any compatible AI app (a client) can plug into.

Analogy: USB-C. Before it, every gadget had its own charger, and drawers everywhere filled with incompatible cables. USB-C is an agreement about the plug, so any charger works with any laptop. MCP is USB-C for AI tools: build your tool server once, and Claude Desktop, Claude Code, and a growing list of other apps can all plug into it with one line of configuration, no custom wiring per app.

An MCP server is a small program that announces "here are my tools, here are their schemas" in the standard format. The AI app connects, discovers the tools, and the model can call them exactly like Level 2. The transport underneath is standardized, so nobody re-invents the wiring.

SWOT: MCP

The honest audit: what my three agents actually do

Here's where I have to correct my own first draft.

When that assistant asked whether my agents use tool calling, my instinct was "yes, obviously, I have tools with schemas." I had files named tools/, functions wrapped in LangChain's tool() helper, every input validated with Zod (a library that checks data shapes, like a bouncer checking IDs at the door). That sure looks like Level 2.

Then I actually went and read my own code with the definition in hand. bindTools appears nowhere in any of the three repositories. Neither does ToolNode. The model in my agents never emits a tool call, because it's never handed the directory.

What I actually built, in each case:

• WitUS Triage Agent. Five tools with Zod schemas: get_product_status, search_past_submissions, draft_reply, escalate_sms, tag_and_file. But the enrich node calls both of its enrichment tools on every run, unconditionally, and the execute node picks by action type in a switch. get_product_status reads a productSlug that arrives as a structured field on the submission; nothing extracts a product name from the complaint text. It reports red at three or more bug reports in seven days, yellow at one or two, green at zero: a fixed threshold, not a spike detected against a baseline.
• Wanderlearn Field Reporter. Its webSearch isn't a model-facing tool at all, just an async function with a Zod input schema that a node calls directly. There's a budget guard capping searches at five per run, which I'm still glad I wrote, but the research node only ever issues two hardcoded queries, so the cap has never actually fired.
• Centenarian Coach. Four specialists, each a compiled subgraph that imports only its own tools, so the scoping is real: grep for calorie anywhere under the workout specialist and you get nothing. But the mechanism isn't tool calling. An assess node uses withStructuredOutput() to have the model produce the arguments, and then a separate deterministic node invokes the tool with them. The model fills in the form; it doesn't decide whether to submit it. Two of those tools (sleep_data_mock, hrv_trend_mock) return fixed demo fixtures, not real wearable data. A fourth specialist, corrective, deliberately has no tools at all.

So the accurate answer to the interview question is: graph-orchestrated LLM calls, with deterministic invocation of schema-validated tool functions, plus structured-output argument extraction, and a durable human approval gate. Not model-driven tool calling. And no MCP: no MCP server, client, or adapter appears in any of the three codebases. Every tool is a local function.

Is that worse? For a job description asking about "tool use beyond prompting alone," it's a weaker claim than I'd have made from memory. But it's the true one, and two things about it hold up well under questioning. The scoping and the approval gate are real engineering, and choosing deterministic invocation for a pipeline that sends SMS messages on my behalf is a defensible call rather than an oversight. What I can't claim is that the model is making those decisions.

The gap is real and I'd rather name it than have an interviewer find it. My next two projects are wiring bindTools into the triage agent so the enrich stage genuinely chooses its own context, and wrapping my flashcard product's public API in an MCP server.

The transferable lesson: "we have tools" and "the model calls tools" are different claims, and the second one is checkable in about thirty seconds. Search a codebase for bindTools, ToolNode, or your framework's equivalent. If it isn't there, the model isn't choosing; your code is. Run that check on your own work before someone runs it for you.

The alternatives map (what else is out there)

• No AI at all. If the steps never change, a plain script is cheaper, faster, and perfectly predictable. Not every problem needs an intern.
• One big prompt, no tools. For summarizing, drafting, and explaining, a single model call is often enough. Simplest thing that works wins.
• RAG (retrieval-augmented generation) — automatically fetching relevant documents and pasting them into the prompt so the model answers from your information. My coach's specialists each search their own knowledge library this way. RAG gives the model better reading material; tools give it hands. Most serious systems use both.
• Other agent frameworks. LangGraph is what I use; the Claude Agent SDK is Anthropic's harness (it ships with built-in tools and, fittingly, exposes custom tools as MCP servers); OpenAI has an Agents SDK; CrewAI and AutoGen focus on teams of cooperating agents. The concepts in this post transfer across all of them, which is why the concepts, not the brand names, are the thing to learn.

The one-sentence answers (steal these)

• Graph orchestration: my code decides the sequence of steps; the model does the thinking inside each step.
• Tool calling: the model decides when to act, from a typed menu I define; my code executes and stays in control.
• MCP: a universal standard for offering that menu to any AI app, not just my own.

And the layered truth about real systems: mine sit at the first level, with typed tool functions and a human approval gate on anything irreversible. Knowing precisely which level you're on, and being able to prove it from the code, is worth more than claiming the highest one.

Keep learning

• Anthropic — Building Effective Agents: the clearest essay on when to use workflows vs. agents.
• Anthropic docs — Tool use overview: how tool schemas and the call/result loop actually work.
• Model Context Protocol: the MCP spec, tutorials, and example servers.
• LangGraph documentation: the graph-orchestration framework my agents use.
• Claude Agent SDK docs: Anthropic's batteries-included agent harness.
• 3Blue1Brown — Neural networks video series: the best visual explanation of what's inside the model itself.
• My triage agent is MIT-licensed and carries its own mini-curriculum in docs/lessons/. Reading a small real agent beats reading ten more explainers.

References

Anthropic. (2024). Building effective agents. https://www.anthropic.com/research/building-effective-agents

Anthropic. (n.d.). Tool use overview. Claude Developer Platform documentation. https://platform.claude.com/docs/en/agents-and-tools/tool-use/overview

Anthropic. (n.d.). Claude Agent SDK documentation. https://code.claude.com/docs/en/agent-sdk

LangChain. (n.d.). LangGraph documentation. https://langchain-ai.github.io/langgraph/

Model Context Protocol. (n.d.). Introduction and specification. https://modelcontextprotocol.io

Sanderson, G. (n.d.). Neural networks [Video series]. 3Blue1Brown. https://www.3blue1brown.com/topics/neural-networks