Fala dataholics! Chegamos no terceiro post da série de Tools e hoje é o assunto que mais cresceu no mundo dos agentes esse ano: o MCP, o Model Context Protocol. Nos posts anteriores a gente deu tools pro agente de dois jeitos, pegando um conector pronto e criando uma tool REST via OpenAPI. O MCP é o próximo degrau, e o Copilot Studio já suporta. Pra esse eu preparei uma animação curta que explica a ideia do começo ao fim, e embaixo dela eu abro cada parte com calma.

O que veremos nesse post:

• O problema que o MCP resolve

• O que é MCP, sem enrolação

• O pulo do gato: um servidor, várias tools

• Na prática no Copilot Studio

• Conector vs REST vs MCP: quando usar cada um

• Resumo

---

O problema que o MCP resolve

Antes do MCP, dar ferramentas pra um agente era um trabalho de formiguinha. Cada sistema que você queria plugar, um banco, um CRM, um sistema de tickets, exigia uma integração feita na mão, com o seu jeito de autenticar, os seus endpoints, o seu formato de resposta. Multiplica isso por quantas ferramentas o agente precisa e por quantos agentes você tem, e vira um monte de código pra manter. Toda vez que a ferramenta muda, alguém corre atrás pra arrumar.

A pergunta que o pessoal começou a fazer foi simples: e se existisse um jeito padrão do agente conversar com qualquer ferramenta, sem inventar a roda toda vez? É aí que entra o MCP.

---

O que é MCP

MCP, ou Model Context Protocol, é um padrão aberto pra conectar agentes a ferramentas e dados. A analogia que eu mais gosto é a do USB-C: em vez de um cabo diferente pra cada aparelho, um conector só que todo mundo fala. No MCP é a mesma ideia, um protocolo só entre o agente e as ferramentas, e quem expõe as ferramentas é um servidor MCP.

Como é um padrão, ele não é preso a uma plataforma. O mesmo servidor MCP que você conecta no Copilot Studio pode ser consumido por outros agentes que falam MCP, e é por isso que ele virou meio que a cola universal entre agentes e ferramentas.

---

O pulo do gato: um servidor, várias tools

Aqui está a parte que faz o MCP valer a pena. Um conector normalmente te dá uma ação. Um servidor MCP entrega várias tools de uma vez. Você conecta uma vez no servidor e o agente ganha, de bandeja, todas as operações que aquele servidor publica: buscar um pedido, criar um ticket, listar uma agenda, consultar estoque, o que o servidor oferecer.

No Copilot Studio isso aparece de um jeito bem prático: cada tool ou resource que o servidor MCP publica fica automaticamente disponível pro agente. Você não configura uma por uma, elas vêm junto quando o servidor conecta. Conecta uma vez, ganha todas.

---

Na prática no Copilot Studio

O fluxo pra plugar um servidor MCP é o mesmo caminho das tools que a gente já viu na série. Dentro do agente você vai na aba Tools, clica em Add a tool e escolhe Model Context Protocol. Aí você aponta pro servidor, informando o endpoint e a autenticação, e confirma.

Dois detalhes técnicos que valem a pena guardar:

• O transporte usado é o Streamable HTTP. É a forma como o Copilot Studio conversa com o servidor MCP, com sessão HTTP e a comunicação acontecendo em streaming.

• A autenticação é configurada na hora de conectar, do mesmo jeito das outras tools: pode ser sem auth, por chave ou por OAuth, dependendo do que o servidor exige. Vale a mesma conversa do post [1], credencial do usuário respeita o acesso de cada um, credencial do maker vale pra todos.

Depois de conectado, o servidor MCP aparece como uma tool na aba Tools, com o Type Model Context Protocol, e o Trigger fica como by agent, ou seja, quem decide chamar cada operação é o próprio modelo na hora que precisa. Se isso soou familiar, é porque você já viu na prática: lá no post [1] a tool de agenda que eu testei, a Work IQ Calendar, era MCP por baixo, e o agente sozinho chamou a operação ListCalendarView pra ler minha agenda. Aquilo já era MCP em ação.

---

Conector vs REST vs MCP: quando usar cada um

Fechando a série de tools, é assim que eu decido:

• Conector pronto (post [1]): quando já existe um no catálogo pro serviço que você quer. É o caminho mais rápido, zero código.

• REST via OpenAPI (post [2]): quando não tem conector, mas o serviço tem uma API REST. Você descreve a API num OpenAPI e cria a sua tool.

• MCP (esse post): quando você quer plugar um servidor que já fala MCP e trazer um pacote inteiro de tools de uma vez, ou quando quer reaproveitar o mesmo servidor em vários agentes e plataformas. Padrão aberto, um monte de tool numa conexão só.

Reginaldo, então o MCP substitui os conectores?

Não precisa escolher um só. Eles convivem no mesmo agente. Conector é ótimo pro que já está pronto no catálogo, REST resolve a sua API específica, e o MCP brilha quando você quer padronizar e reaproveitar. No mundo real você mistura os três.

---

RESUMO

• MCP (Model Context Protocol) é um padrão aberto pra conectar agentes a ferramentas. Pensa no USB-C dos agentes.

• Antes, cada ferramenta era uma integração na mão. O MCP troca isso por um protocolo só.

• O ganho principal: um servidor MCP entrega várias tools de uma vez, e no Copilot Studio elas ficam disponíveis automaticamente.

• Pra plugar: aba Tools, Add a tool, Model Context Protocol, aponta o servidor (transporte Streamable HTTP) e configura a autenticação.

• O servidor vira uma tool na aba Tools, com Trigger by agent. A Work IQ Calendar do post [1] já era MCP na prática.

• Conector, REST e MCP convivem: pronto do catálogo, sua API via OpenAPI, ou um pacote de tools via servidor MCP.

Com isso a gente fecha as três formas de dar tools pro agente. No próximo post eu pego uma dessas ideias e levo pro nosso terreno: chamar uma Azure Function como tool do agente, e aí a coisa começa a encostar no Databricks.

Referências:

https://learn.microsoft.com/en-us/microsoft-copilot-studio/agent-extend-action-mcp

https://learn.microsoft.com/en-us/microsoft-copilot-studio/mcp-add-existing-server-to-agent

Fique bem e até a próxima.

#copilotstudio #mcp #modelcontextprotocol #ia #agentes #datainaction

Hey dataholics! We've reached the third post in the Tools series and today it's the topic that grew the most in the agent world this year: MCP, the Model Context Protocol. In the previous posts we gave the agent tools in two ways, grabbing a ready-made connector and creating a REST tool via OpenAPI. MCP is the next step up, and Copilot Studio already supports it. For this one I put together a short animation that explains the idea from start to finish, and below it I break down each part slowly.

What we'll cover in this post:

• The problem MCP solves

• What MCP is, no fluff

• The key trick: one server, many tools

• In practice in Copilot Studio

• Connector vs REST vs MCP: when to use each

• Summary

---

The problem MCP solves

Before MCP, giving tools to an agent was tedious grunt work. Each system you wanted to plug in, a database, a CRM, a ticketing system, required an integration built by hand, with its own way to authenticate, its own endpoints, its own response format. Multiply that by how many tools the agent needs and how many agents you have, and it turns into a lot of code to maintain. Every time the tool changes, someone has to run and fix it.

The question people started asking was simple: what if there were a standard way for the agent to talk to any tool, without reinventing the wheel every time? That's where MCP comes in.

---

What MCP is

MCP, or Model Context Protocol, is an open standard to connect agents to tools and data. The analogy I like most is the USB-C one: instead of a different cable for each device, a single connector everyone speaks. MCP is the same idea, a single protocol between the agent and the tools, and what exposes the tools is an MCP server.

Because it's a standard, it isn't tied to one platform. The same MCP server you connect in Copilot Studio can be consumed by other agents that speak MCP, and that's why it has become something like the universal glue between agents and tools.

---

The key trick: one server, many tools

Here's the part that makes MCP worth it. A connector usually gives you one action. An MCP server delivers several tools at once. You connect to the server once and the agent gets, on a plate, all the operations that server publishes: look up an order, create a ticket, list a calendar, check inventory, whatever the server offers.

In Copilot Studio this shows up in a very practical way: each tool or resource the MCP server publishes becomes automatically available to the agent. You don't configure them one by one, they come together when the server connects. Connect once, get them all.

---

In practice in Copilot Studio

The flow to plug in an MCP server is the same path as the tools we've already seen in the series. Inside the agent you go to the Tools tab, click Add a tool and choose Model Context Protocol. Then you point at the server, providing the endpoint and the authentication, and confirm.

Two technical details worth holding on to:

• The transport used is Streamable HTTP. It's how Copilot Studio talks to the MCP server, with an HTTP session and the communication happening as a stream.

• The authentication is configured at connection time, just like the other tools: it can be no auth, an API key or OAuth, depending on what the server requires. The same conversation from post [1] applies, user credentials respect each person's access, maker credentials work for everyone.

Once connected, the MCP server shows up as a tool on the Tools tab, with the Model Context Protocol Type, and the Trigger stays as by agent, meaning the model itself decides when to call each operation. If that sounds familiar, it's because you've already seen it in practice: back in post [1] the calendar tool I tested, Work IQ Calendar, was MCP under the hood, and the agent called the ListCalendarView operation on its own to read my calendar. That was already MCP in action.

---

Connector vs REST vs MCP: when to use each

Wrapping up the tools series, here's how I decide:

• Ready-made connector (post [1]): when one already exists in the catalog for the service you want. It's the fastest path, zero code.

• REST via OpenAPI (post [2]): when there's no connector, but the service has a REST API. You describe the API in an OpenAPI and create your own tool.

• MCP (this post): when you want to plug in a server that already speaks MCP and bring in a whole package of tools at once, or when you want to reuse the same server across several agents and platforms. Open standard, lots of tools in a single connection.

Reginaldo, so does MCP replace connectors?

You don't have to pick just one. They live together in the same agent. A connector is great for what's already in the catalog, REST solves your specific API, and MCP shines when you want to standardize and reuse. In the real world you mix all three.

---

RECAP

• MCP (Model Context Protocol) is an open standard to connect agents to tools. Think of the USB-C of agents.

• Before, each tool was an integration built by hand. MCP swaps that for a single protocol.

• The main gain: an MCP server delivers several tools at once, and in Copilot Studio they become available automatically.

• To plug it in: the Tools tab, Add a tool, Model Context Protocol, point at the server (Streamable HTTP transport) and configure the authentication.

• The server becomes a tool on the Tools tab, with the by agent Trigger. The Work IQ Calendar from post [1] was already MCP in practice.

• Connector, REST and MCP coexist: ready from the catalog, your API via OpenAPI, or a package of tools via an MCP server.

With that we close the three ways to give tools to the agent. In the next post I take one of these ideas to our own turf: calling an Azure Function as an agent tool, and that's where things start touching Databricks.

References:

https://learn.microsoft.com/en-us/microsoft-copilot-studio/agent-extend-action-mcp

https://learn.microsoft.com/en-us/microsoft-copilot-studio/mcp-add-existing-server-to-agent

Stay well and see you next time.

#copilotstudio #mcp #modelcontextprotocol #ai #agents #datainaction