nup_logo

Building AI Agents

Tools and MCP


Alex Avdiushenko
October 15, 2026

LLMs without Tools


  1. Have limited capabilities due to the specifics of their training
  2. Do not have access to up-to-date information
  3. Cannot take actions on their own
=== Counting characters task ===
87

Ground truth: 97
=== Math ===
8293

Ground truth: 825.444444444445
=== Up-to-date info ===
I don't have access to real-time data, 
including the current Bitcoin price.
USER: 1) Cancel reservation EHGLP3.
AGENT: I'm unable to access specific reservations 
or cancel them directly.

What Are Tools

A tool is a function that an LLM can call to interact with external systems

A tool should include:

  • What it does (text description)
  • Executable function (runtime implementation)
  • Input arguments (with types)
  • Output (with type)
AI_agent_diagram

How Tool-Calling Works

LLMs can only generate text, don't execute code.

Airports in London?
🧠 LLM
"The airports are Heathrow, Gatwick, and City."
calllist_all_airports("London")
🤖 Agent
Heathrow,
Gatwick,
City
  • Detects the tool call
  • Executes the tool
  • Gets real data
  • Returns it to the model

To the user, it looks like the LLM used the tool — but the agent did the actual work.

How to Provide Tools to LLM

Providing tools to an LLM means:

  • The model is informed about available tools - via the system prompt
  • The model learns to generate tool calls when needed through:
    • Models that support tool calling are trained on tool-usage examples, using the required format (e.g., special tokens)
    • Understanding your tool descriptions - that's why it must be clear, precise, and consistent

Tool Design Principles

Handling Partial Failures

Tools must handle partial failures while keeping the system consistent

charge payment → reserve inventory → create delivery

 Idempotency & Safe Retries

Tools must safely handle repeated calls (after crashes, timeouts, agent restarts)

Sending an email → gets timeout → retry must not send it twice

 Clear Error Messages

Errors must be understandable for LLMs so the agent can decide what to do next

Good errors enable the agent to:

  • Ask the user for missing parameters
  • Retry or offer alternatives during temporary outages
Guidance for Next Steps

Tools can return guidance that helps the agent continue the conversation properly.

Examples

  • Ask the user for a delivery date
  • Request a phone number in the correct format
 Structured Outputs

Return structured, machine-readable outputs instead of free-form text.

Examples

  • {status, order_id, delivery_window}
  • Analytics returning aggregates instead of prose
 Key Takeaway

A good tool for an AI agent is not just a function

It is a reliable contract between the LLM and external systems, designed to withstand failures, retries, and changing environments.

Source: Yandex Lavka on Agents Week 2026, Slide 7

When is Protocol Needed

Yes,

Tools have significantly expanded the capabilities of LLMs and enabled them to act as agents

But

  • Tools are embedded inside each agent
  • APIs change over time
  • Different models expect tools/invoke them in different formats

→

  • Tool reusability remains low
  • Any API change requires updating multiple agents
  • Systems become fragile and hard to scale
sad doge → buff doge

What is MCP

On November 25, 2024, Anthropic open-sourced the Model Context Protocol (MCP)

Model Context Protocol (MCP) is an open standard that enables secure, bidirectional connections between AI models and external systems (APIs, tools, data sources)

a very buff doge with cybernetic gauntlets

MCP is the “USB-C port” or “HTTP layer” of the AI ecosystem.

Chat interface
Claude Desktop, LibreChat
IDEs and code editors
IntelliJ, Visual Studio Code
Other AI applications
Sire, SuperInterface
AI applications
↔
Bidirectional
data flow
MCP
Standardized protocol
↔
Bidirectional
data flow
Data and file systems
PostgreSQL, SQLite, GDrive
Development tools
Git, Sentry, etc.
Productivity tools
Slack, Google Maps, etc.
Data sources and tools

https://www.anthropic.com/news/model-context-protocol
https://modelcontextprotocol.io/docs/getting-started/intro

Architecture & Roles

Client–server architecture with three roles

MCP Host
Role: Handles UI and connects to servers
AI
MCP Client
Role: Sends prompts and returns model responses
APP
MCP Server
Role: Serves tools, data, prompt templates
🌐🧮📁🛢️
MCP Tools

Roles: Host

Orchestrates LLMs and AI workflows Manages connections: one MCP client per MCP server Controls UI: User-facing application (e.g., Cursor, custom agents)
Security & permissions: auth, limits, policies User consent: approvals for data sharing & tool use
AI Chat

Roles: Server

Server = provider of context and capabilities

  • A lightweight program exposing tools, context, and capabilities
  • Can run locally or remotely

Tasks:

  • Registers capabilities
  • Processes requests
  • Providing context
  • Client connection handling
  • Sends updates/notifications to clients

Roles: Client

Client = connector between Host and Server

  • Protocol communication: JSON-RPC 2.0 requests, secure communication channels
  • Capability negotiation: features & versions during initialization
  • Tool execution: sends tool calls, returns results
  • Real-time updates: handles server notifications

MCP Flow

MCP-host 👤 User 🖥 App 🔧 MCP Client 1 📚 MCP Client 2 🧠 Client LLM 🔧 MCP Server 1 📚 MCP Server 2 Create Request available tools/resources Return tool list Return tool list Create Request available tools/resources Return tool list Return tool list Store combined toolcatalog locally Enter natural language prompt Forward prompt + tool catalog Analyze prompt & select tools Request tool execution Choose, provide info Execute tool Return results Return results Process results Generate response Display final answer

Recap: problems solved

Problem Without MCP With MCP
Tool reusability Each team reimplemented the same tools independently. Tools live in MCP servers — standalone infrastructure components (like microservices).
Write once → reuse across many agents and products.
API updates & maintenance All agent teams had to update their integrations manually. Responsibility shifts to MCP server maintainers. Agents automatically discover updated capabilities during initialization.
Scaling and modifications Components were tightly coupled. Changing one component required rewriting many parts in each agent Separation of responsibilities. Changes are localized to individual components.
Vibe spaghetti code as the final boss OOP meme

But

Do not over-engineer. Start simple. Add MCP when complexity forces you.

In the middle ground you can use lightweight tool ecosystems
(e.g., AgentSkills) that provide:

  • Ready-to-use skills
  • Standardized interfaces
  • Faster development without heavy infrastructure
  • A stepping stone toward more structured architectures like MCP

Ready-to-use Tools

Practice

A few tasks to solve (15-20 min)

  1. LRU Cache Decorator
  2. Context Managers

Notebook for this intensive: