Skip to main content
HomeAboutSolutionsIndustriesContact

Tool Use, Function Calling and MCP, Explained

How models call tools, how to design tools they use well, how the Model Context Protocol standardises the connections, and how to keep tools safe.

IntermediateVerdeshell Team · 6 min read · Last reviewed

Function calling is how a model asks for a tool; MCP is a standard way to package and connect tools so any compatible application can use them. Tools are also the main attack surface of an agent, so design them narrow and treat their output as untrusted.

Key takeaways

  • With function calling, a model returns a structured request to use a tool; the application runs it and returns the result.
  • Good tools are narrow, clearly described and return useful errors — tool design matters as much as the prompt.
  • MCP, the Model Context Protocol, is an open standard for connecting applications to tools and data through servers that any compatible host can use.
  • An MCP server can offer tools the model calls, resources such as files and records, and reusable prompts.
  • Tool results and tool descriptions are untrusted input: limit permissions, require approval for consequential actions, and vet every server.
Model Context Protocol architecture: host, clients and serversThe host is the AI application, which contains the model and one MCP client for each server it connects to. Each client holds a connection to one server. In this example: a local files server reached over standard input and output, offering tools and resources; a remote CRM server reached over HTTP, offering tools and prompts; and a remote database server over HTTP, offering tools and resources. Messages are JSON-RPC.HOST — THE AI APPLICATIONModelMCP clientFiles serverlocal · stdio · tools, resourcesMCP clientCRM serverremote · HTTP · tools, promptsMCP clientDatabase serverremote · HTTP · tools, resourcesJSON-RPCOne client per server. Servers offer tools (the model calls), resources (data) and prompts (templates).
One host, one client per server. Each server offers tools, resources or prompts — and the host decides what the model may use.

Hover or tap the diagram to replay the animation.

Function calling in one paragraph

A model cannot run code, query a database or send an email. What it can do is return a structured request: “call get_order with order_id A1001”. The application receives that request, decides whether to honour it, runs the function, and sends the result back for the model to use. Providers call this tool use or function calling; it is the same mechanism.

Every agent is built on this. Build your first AI agent in code walks through the loop line by line.

Designing tools models use well

Describe each tool as you would to a new colleague: what it does, when to use it, when not to, and what it returns. The model chooses tools from these descriptions alone.

Keep tools narrow and task-shaped. A few tools that match real tasks — “find_customer”, “create_ticket” — work better than many thin wrappers over every API endpoint, and are far easier to secure than one general “run_query”.

Return what the model needs and no more. A tool that returns a whole customer record costs tokens and exposes data the task does not need. Return clear errors too — “No order A1001; check the ID format” lets the model recover, where a stack trace does not.

Make actions safe to repeat where you can. Agents retry; a payment tool that charges twice on a retry is a design bug.

Why MCP exists

Before a standard, every application wrote its own integration for every tool: each chat assistant, IDE and agent framework needed separate code for each database, file store and SaaS product.

The Model Context Protocol, introduced by Anthropic in November 2024, standardises that connection. A tool is wrapped once as an MCP server, and any application that speaks MCP can use it. In December 2025 MCP was donated to the Agentic AI Foundation under the Linux Foundation, and it is now supported across the major assistants, IDEs and agent frameworks.

How MCP works

There are three roles. The host is the AI application — a chat assistant, an IDE, your own agent. Inside it, a client manages the connection to one server. The server is the program that exposes a capability, such as access to a file system, a CRM or a database.

A server can offer three kinds of things: tools, which the model can call; resources, which are data such as files and records that the application can load into context; and prompts, which are reusable templates a user can pick.

Messages use JSON-RPC 2.0. Local servers usually run over standard input and output; remote servers use HTTP, with authorisation based on OAuth 2.1.

The specification is revised regularly — the 28 July 2026 revision, for example, made the protocol stateless and deprecated some features — so check which version your SDK supports before relying on any detail.

MCP and function calling are not rivals

They work at different layers. When a host connects to an MCP server, it lists the server’s tools and passes them to the model as ordinary tool definitions; the model calls them through function calling as usual.

MCP is about packaging and connecting tools so they are reusable across applications. Function calling is how a model asks for one. For how both relate to retrieval, see RAG, MCP and agents.

Tools are the attack surface

The MCP specification puts it plainly: tools represent arbitrary code execution, and there should always be a human able to deny a tool call. Everything a tool can do, an attacker who influences the model may try to make it do.

Prompt injection is the main route. Text inside a tool result — an email, a web page, a support ticket — can contain instructions aimed at the model. OWASP ranks prompt injection first in its 2025 Top 10 for LLM applications, and lists excessive agency — too many permissions, too little oversight — among the others.

Tool descriptions are a route too. A malicious or compromised server can hide instructions in a tool’s description, which the model reads but the user usually does not; security researchers call this tool poisoning.

The defences are unglamorous: least-privilege credentials for each tool, approval for consequential or irreversible actions, MCP servers only from sources you trust and pinned to reviewed versions, limits enforced in tool code rather than prompts, and a log of every call.

Next in the pathAI Agent Memory: Short-Term and Long-Term

More in AI Agents

AI Agents vs Agentic AI vs Generative AI5 min readChatbot, Copilot or Agent: What’s the Difference?6 min readAI Agents vs RPA and Workflow Automation6 min readA Learning Path for Building AI Agents4 min readHow to Build an AI Agent Without Code6 min readBuild Your First AI Agent in Code8 min readLoop Engineering: Design the Loop, Not Every Prompt5 min readAnatomy of a Good Agent Loop4 min readGraph Engineering: Coordinating Specialized Agents4 min readLoops vs Graphs: How the Two Patterns Nest3 min readAI Agent Frameworks Compared: What Each One Is For9 min read

Want this built properly?

We design and build AI systems for clients. Tell us the problem and we will tell you honestly whether AI — and which kind — is the right fit for it.