AI Agents and the Model Context Protocol: How AI Tools Connect to Real Software

You will learn how AI agents call tools and how the Model Context Protocol (MCP) standardizes those connections. The course starts with why tool calling is hard, then explains MCP's client-server design, its messages, and its security model. You will compare MCP with older approaches, read real server code, and judge when MCP helps and when it adds risk. By the end you can decide whether to build an MCP server, pick an existing one, or use a simpler method.

Why AI models need a standard way to call tools

Explain why connecting an AI model to outside software is hard without a shared standard.

Key takeaways

  • Models cannot execute anything themselves. They emit a structured request, and separate code validates and runs it.
  • Prompt-based tool use breaks when the model's text does not match the expected format, which is why structured JSON schemas became standard.
  • Tool definitions cost tokens and attention, so large catalogs hurt both accuracy and cost.
  • Practitioner sources document the failure modes but treat them as provider details. Only one vendor source names MCP as the shared standard, and it offers no interoperability data.

Sources

How MCP splits work between a client and a server

Describe the roles of the MCP host, client, and server in a single connection.

Key takeaways

  • The host is the AI application you use, and it runs the model and the conversation.
  • The client is a connector inside the host, and the host creates one client per server.
  • The server holds the tools, resources, and prompts, and it does the actual work when called.
  • The connection starts with an `initialize` handshake where each side declares its capabilities.

Sources

The messages MCP sends: tools, resources, and prompts

List the three main things an MCP server can offer and give an example of each.

Key takeaways

  • An MCP server offers three primitives: tools (model-controlled actions), resources (application-controlled read-only data), and prompts (user-controlled templates).
  • Tools are discovered with `tools/list` and called with `tools/call`; resources with `resources/list` and `resources/read`; prompts with `prompts/list` and `prompts/get`.
  • The control model is also the security model: tools need human approval because they can change state, resources are safe to inject because they are read-only, and prompts run only when the user asks.
  • A database server illustrates all three at once: `query_database` as a tool, `db://schema/main` as a resource, and a few-shot SQL prompt the user fires with a slash command.

Sources

Security risks when an AI can call real software

Identify the main security risks of giving an AI agent tool access and name one defense for each.

Key takeaways

  • Giving an agent tools turns any content it reads into a possible instruction, so the host must enforce which tools can run.
  • Tool descriptions can be poisoned or swapped after approval, so pin and review server definitions.
  • Over-broad credentials cause the most common failures, so scope tokens to the task and separate read from write.
  • Run untrusted agent code in a microVM or sandbox, and keep snapshots so a bad action can be rolled back.

Sources

MCP compared with plugins, OpenAPI, and custom glue code

Compare MCP with older ways of connecting AI to software and say when each is better.

Key takeaways

  • Function calling is a model feature, OpenAPI is an API contract, and MCP is a protocol for discovering and calling tools across apps.
  • MCP pays off when tools must be shared across applications, users, or model providers, and costs context tokens to do it.
  • Keep MCP tools few and task-oriented, because tool-selection quality drops as the list grows.
  • A generated MCP server from an OpenAPI spec saves work, but you should curate which operations it exposes.

Sources

Building and testing a small MCP server

Build a minimal MCP server that exposes one tool and test it with a client.

Key takeaways

  • A minimal MCP server is a server object plus a typed function marked with `@mcp.tool()`.
  • Type hints and docstrings become the tool's schema and description, so you write no JSON Schema by hand.
  • Test with `Client(mcp)` in memory for speed, and use the Inspector to watch the actual JSON-RPC messages.
  • Serving over Streamable HTTP lets a separate process call the same tool at `http://localhost:8000/mcp`.

Sources

Deciding whether MCP fits your project

Decide whether to adopt MCP for a given project by weighing its benefits and costs.

Key takeaways

  • MCP solves a real integration problem (N×M to N+M) and has reached ecosystem maturity, but it is a protocol layer, not a product. Production-grade servers require weeks of hardening, not an afternoon.
  • Token overhead is measurable and compounds: a single multi-system sweep can burn tens of thousands of tokens, so MCP pays off only when the agent genuinely needs to reason across tools.
  • The protocol enforces no security, so authentication, authorization, and audit logging are your responsibility, and "MCP Shadow IT" is a documented governance failure mode.
  • Adopt MCP when you expect to connect more than three to five tools or when the LLM must reason across systems; skip it when you already know what context to paste.
  • Budget for client-compatibility friction, stateless transport quirks, and a four-layer testing pyramid before you commit. The demo-to-production gap is where most "MCP is overhyped" complaints originate.

Sources