← Master Index
Vol. 15 Module 15.3 Lecture

MCP Tools

Model Context Protocol — MCP (added)

How This Lesson Fits the Module & Volume

Module 15.1 introduced tool calling and function calling as model APIs. MCP tools are the same idea on a protocol: named actions with JSON Schemas, listed and invoked across process boundaries. The client maps them into whatever tool format your model vendor uses.

The next lecture, MCP resources, covers read-only context. Confusing the two is both a design error and a security error. Frameworks in 15.4 wrap MCP tools inside ReAct / graph loops.

Learning Objectives

By the end of this lesson, students should be able to:

  • Define an MCP tool as an invocable, schema-described action on a server.
  • Write a tight tool description and inputSchema the model can follow.
  • Contrast MCP tools with in-process functions and with MCP resources.
  • Classify tools by side-effect risk and attach HITL accordingly.
  • Handle errors (isError) without poisoning working memory.
  • Avoid mega-tools and underspecified arguments.
Definition

An MCP tool is a server-exposed function: a unique name, human/LLM-readable description, JSON Schema for arguments, and an implementation that returns content (text, images, etc.) or an error. Calling it may read or mutate external state.

Tools vs Function Calling vs Resources

In-process functionMCP toolMCP resource
Where it runsYour agent processMCP serverMCP server (read)
DiscoveryHard-coded listtools/listresources/list
InvocationPython/JS calltools/call (JSON-RPC)resources/read
Side effectsPossiblePossible—assume yesShould be none
Reuse across hostsNoYesYes

Risk Tiers (HITL Mapping)

Read / Search

  • lookup_ticket, search_docs
  • Usually auto-allow
  • Still apply ACLs on server

Bounded write

  • comment_on_ticket
  • Confirm once or dry-run
  • Log actor + args

Dangerous

  • delete_*, run_sql, shell
  • Always HITL + allowlist
  • Prefer not to expose

Schema Quality Is Agent Quality

Models call what they can parse. Vague descriptions cause wrong tools; missing required fields cause retries that burn working memory. Return short, structured observations—not HTML dumps.

# Good vs poor MCP tool definitions (conceptual) good_tool = { "name": "create_jira_comment", "description": ( "Add a comment to an existing Jira issue. " "Use after lookup_ticket confirms the issue key. " "Does not change status or assignees." ), "inputSchema": { "type": "object", "properties": { "issue_key": {"type": "string", "description": "e.g. OPS-881"}, "body": {"type": "string", "description": "Markdown comment, max 2000 chars"}, }, "required": ["issue_key", "body"], "additionalProperties": False, }, } poor_tool = { "name": "do_jira", "description": "Does Jira stuff.", "inputSchema": {"type": "object"}, # model will invent random keys } def tools_call(name: str, arguments: dict) -> dict: try: text = jira.add_comment(arguments["issue_key"], arguments["body"][:2000]) return {"content": [{"type": "text", "text": text}], "isError": False} except PermissionError: return {"content": [{"type": "text", "text": "Forbidden for this tenant"}], "isError": True}

Errors, Retries, and the Agent Loop

Surface isError honestly so reflection can change plan. Do not retry dangerous writes automatically. Compact error strings; a 50-line stack trace teaches the model to ramble. Frameworks like LangChain agents will loop on tool errors until a max-iterations cap—set that cap.

Strengths

  • Portable actions across MCP hosts
  • Schemas double as documentation
  • Clear HITL attachment points
  • Fits ReAct / graph tool nodes

Tradeoffs

  • Bad schemas → hallucinated args
  • Write tools need strong policy
  • Latency per RPC hop
  • Catalog sprawl confuses the model
Common Misconception

“If it is listed in tools/list, the model is allowed to call it.” Listing is discovery, not authorization. Host allowlists and HITL still apply. A server that exposes run_shell to every connected client is misconfigured even if the protocol is valid.

Knowledge Check

  1. Short Answer: What three parts define an MCP tool? Answer: Name, description, and input JSON Schema (plus implementation).
  2. True/False: MCP tools are guaranteed side-effect free. Answer: False—assume they can mutate state.
  3. Multiple Choice: tools/call is issued by the: (a) client to the server, (b) vector DB to DNS, (c) CNN pooling layer. Answer: (a).
  4. Short Answer: Why is additionalProperties: false useful? Answer: It stops the model from inventing extra arguments.
  5. True/False: A resource and a tool are interchangeable if both return text. Answer: False—tools may have side effects; resources should not.
  6. Multiple Choice: run_shell should be: (a) auto-allowed, (b) HITL + tightly allowlisted or omitted, (c) embedded in prompts. Answer: (b).
  7. Short Answer: How should tool errors be returned? Answer: Explicit isError (or equivalent) with a short, usable message.
  8. True/False: tools/list implies the host has authorized every listed tool. Answer: False.
  9. Multiple Choice: Mega-tool “do_everything” hurts agents because: (a) planning becomes opaque, (b) JSON-RPC cannot name it, (c) RAG forbids tools. Answer: (a).
  10. Short Answer: What MCP primitive is for readable URIs rather than actions? Answer: Resources.

Key Takeaways

  • MCP tools are schema’d, invocable actions—portable function calling.
  • Write tight descriptions; fail closed; classify risk for HITL.
  • Discovery ≠ authorization; hosts still allowlist.
  • Errors must be explicit and compact for the agent loop.
  • Continue with MCP Resources.
Trainer’s Guide

Lab: Rewrite three poor tools into good schemas; have students predict which arguments a model would hallucinate on the poor versions.

Whiteboard: Risk tiers vs HITL gates. Draw tools/call landing in working memory next to a resource/read.

Recap: MCP tools are portable, schema-described actions. Continue with MCP Resources.