# Function tool or MCP? Count the consumers.

> One consumer: function tool. Two: MCP.

- **Format:** short video, 9 steps, ~51 seconds
- **Topic:** What MCP (Model Context Protocol) is for Microsoft Foundry agents: how it differs from a function tool, consuming remote MCP servers with an approval loop, and publishing your own tools through a Toolbox.
- **Author:** Suthahar Jegatheesan (MSDEVBUILD)
- **Category:** Azure · Azure
- **Published:** 2026-07-03
- **Tags:** mcp, modelcontextprotocol, aiagents, microsoftfoundry, azureai, dotnet, aicoding, msdevbuild
- **Canonical URL:** https://blog.msdevbuild.com/shorts/foundry-mcp-second-consumer/

---
## What you'll learn

- How MCP differs from a function tool
- Why approval matters for remote servers
- When MCP is not worth it

## Understand it one step at a time

### 1. A tool belongs to one agent

A function tool is declared on one agent definition.

### 2. Then a second consumer

The support console wants the same tools. Copy the schemas again?

### 3. MCP: a tool layer

An MCP server exposes tools any agent or client can discover and call.

### 4. Preview surface

Approval and Toolbox types need 2.1.0-beta.4. The shape can change.

### 5. Approval before the call

With approval on, the model asks first and your code decides.

### 6. Allow-list the tools

A server exposes forty tools; you need three. Take three.

### 7. Your logic, now reachable

An MCP server runs where a remote caller can reach it. Security is re-established there.

### 8. Count the consumers

One consumer: function tool. A second appears: that is the day.

### 9. Count the consumers, then decide

MCP buys nothing until a second consumer appears. Then it buys a lot.

---

## The takeaway

**Count the consumers. Then decide.**

The approval policy is the control that matters: keep it on always for any server you did not write.