MCP vs. API explicado: ainda precisamos de APIs depois do MCP?

Ver no idioma original →

Autoria: Cloud DevOps with Ana · Assistir no YouTube

Vídeo de autoria do canal indicado, não da IANIA; todos os direitos pertencem ao criador. Transcrição, resumo e tradução gerados automaticamente; o conteúdo no idioma original é preservado na versão em idioma original.

Idioma original: inglês

Vídeo original: MCP vs API Explained: Do We Need API After MCP? · Canal: Cloud DevOps with Ana · 10:46 · Assistir no YouTube

Tópicos: Agentes de IA, Automação de tarefas e workflows, Cibersegurança e segurança de software, Infraestrutura e hardware de IA

Resumo

APIs permitem que softwares acessem funções e dados de outros sistemas, enquanto o MCP oferece um protocolo compartilhado para conectar aplicações de IA a ferramentas e contextos. O modelo pode propor chamadas de ferramentas, mas é a aplicação que as executa e controla o acesso. O MCP não substitui APIs nem garante que o modelo escolha a ação correta. A escolha entre integração direta por API e MCP depende de fatores como reutilização, compatibilidade e controle.

Pontos-chave

• Sem ferramentas conectadas, um modelo não tem acesso automático aos dados e sistemas da empresa.
• APIs definem como pedir dados ou executar operações em outro sistema, com autenticação, validação e tratamento de erros.
• No tool calling, o modelo propõe uma chamada, mas a aplicação executa a operação e devolve o resultado.
• MCP padroniza parte da conexão entre aplicações de IA compatíveis e ferramentas ou dados externos.
• Servidores MCP podem expor tools, resources e prompts, e não precisam necessariamente envolver uma API web.
• O MCP não elimina a necessidade de configurar credenciais, permissões e a lógica das operações.
• Mais ferramentas podem confundir o modelo; é importante expor apenas as necessárias e descrevê-las com clareza.
• Uma integração direta por API pode bastar para uma aplicação fixa; MCP é mais interessante quando várias aplicações compatíveis reutilizam operações.

Capítulos

Início	Capítulo	Resumo
00:00	Por que conectar a IA aos sistemas	O vídeo apresenta o problema de modelos sem acesso aos dados empresariais e explica os fundamentos de APIs.
03:33	Tool calling e o papel do MCP	A aplicação executa as ferramentas propostas pelo modelo, e o MCP padroniza a conexão entre aplicações de IA e serviços.
06:07	Recursos, limites e segurança	O vídeo apresenta tools, resources e prompts do MCP e destaca que permissões, validação e escolhas corretas continuam sendo responsabilidade da implementação.
08:42	Quando usar API ou MCP	A conclusão compara integração direta e MCP, propõe um projeto prático e resume como construir fluxos confiáveis.

Citações

O modelo não costuma pegar sua chave de API e começar a fazer requisições de rede por conta própria. — 03:33

O modelo propõe e o software executa. — 05:37

Execução bem-sucedida e comportamento correto são duas coisas diferentes. — 07:39

Mais opções não produzem automaticamente decisões melhores. — 08:10

APIs expõem as funcionalidades do sistema. O MCP fornece um protocolo compartilhado para conectar aplicações de IA compatíveis a ferramentas e contexto. — 10:14

Conceitos e entidades

• API (conceito): Interface que permite a um software solicitar dados ou usar funções de outro sistema.
• MCP (conceito): Protocolo compartilhado para conectar aplicações de IA compatíveis a ferramentas e dados externos.
• tool calling (conceito): Mecanismo em que o modelo propõe uma chamada de ferramenta e a aplicação executa a operação.
• REST (conceito): Estilo comum de API web que costuma usar métodos HTTP e JSON.
• GraphQL (conceito): Forma de API que permite ao cliente solicitar campos específicos de acordo com suas necessidades.
• gRPC (conceito): Tecnologia baseada em contratos de serviço definidos, frequentemente usada na comunicação entre serviços de backend.
• WebSockets (conceito): Mecanismo que mantém uma conexão aberta para troca de mensagens nos dois sentidos.
• Webhooks (conceito): Mecanismo para um serviço notificar outro sistema quando ocorre um evento.
• JSON (conceito): Formato usado com frequência para representar dados em respostas de APIs web.

Tradução completa (pt-BR)

00:00 Sua IA pode explicar Kubernetes. Pode escrever um e-mail bonito. Pode até dar uma resposta muito confiante que está completamente errada. Mas peça que ela verifique um chamado de suporte real, encontre a política de reembolso da empresa e prepare uma resposta. De repente, ser bom com palavras não basta. Ela precisa ter acesso aos seus sistemas. É aí que entram as APIs. E agora há outra peça sobre a qual todo mundo está falando: MCP. Você provavelmente já ouviu dizer que o MCP está substituindo as APIs. Essa explicação deixa de lado a parte mais interessante, porque o verdadeiro desafio é como

00:30 conectamos um aplicativo de API às ferramentas que ele pode usar. [música] Vamos acompanhar uma solicitação de um usuário até uma ação real. Você verá o que uma API faz, o que o MCP acrescenta e onde o modelo realmente se encaixa. E, no fim, entenderá por que dar mais ferramentas a um agent às vezes pode piorá-lo. Então, vamos começar. O problema: seu modelo não consegue ver sua empresa. Imagine que você esteja criando um assistente de suporte. Você pede: “Encontre o chamado de suporte mais recente da Sarah, confira nossa política de reembolso e redija uma resposta.” Sem ferramentas conectadas, o modelo

01:01 não tem esses registros. Ele pode explicar como lidar com a solicitação. Pode pedir que você cole as informações. Ou, se o aplicativo tiver sido mal projetado, pode inventar uma resposta. Saber como costuma ser uma política de reembolso é bem diferente de ler a política real da sua empresa. Então, seu assistente precisa de três coisas: acesso aos chamados, acesso à política e uma forma de preparar uma resposta. Vamos começar pela base: APIs. APIs sem jargão. Uma API é uma interface que permite que um software use as funcionalidades de outro sistema. Para este

01:32 exemplo, vamos usar uma API da web. Pense no aplicativo do seu banco. Quando você o abre, seu celular não sabe magicamente o saldo da sua conta. Ele pede essa informação a um sistema de backend. Essa API define como fazer a solicitação e como a resposta é retornada. No nosso assistente de suporte, uma solicitação poderia ser assim. Get [música] significa que estamos pedindo para recuperar algo. O caminho informa ao servidor qual recurso queremos, e o ID do cliente restringe a busca. A resposta pode conter o número do chamado, o assunto, o status e a mensagem mais recente,

02:02 normalmente em JSON. Se quisermos criar um chamado, podemos usar post e enviar os detalhes no corpo da solicitação. Para atualizações, você verá com frequência put ou patch. Para remoções, delete. Mas o método e a URL são apenas parte da história. O sistema também precisa saber quem está fazendo a solicitação, se essa pessoa tem permissão para acessar os dados daquele cliente e o que acontece se a solicitação falhar. Por isso, integrações reais envolvem autenticação, validação, tratamento de erros e limites. Uma demonstração pode funcionar com uma única solicitação no cenário ideal, mas, em produção, tudo precisa funcionar quando o serviço de chamados

02:32 está lento, o token expira e alguém clica no botão duas vezes. Nem todas as APIs funcionam da mesma forma. REST é um estilo comum para APIs da web, que costuma usar métodos HTTP e JSON. GraphQL permite que os clientes solicitem campos específicos, o que é útil quando diferentes telas precisam de combinações distintas de dados. gRPC usa contratos de serviço definidos, geralmente com Protocol Buffers. Você vai encontrá-lo com frequência na comunicação entre serviços de backend. Também pode encontrar SOAP em sistemas corporativos consolidados. E há ainda

03:03 padrões de comunicação associados a essas interfaces. WebSockets mantêm uma conexão aberta para mensagens nos dois sentidos. Webhooks permitem que um serviço notifique outro sistema quando algo acontece, como a conclusão de um pagamento ou uma alteração em um chamado. Você não precisa memorizar todas as siglas hoje. A pergunta útil é: esse workflow precisa buscar dados, executar uma operação, receber um evento [música] ou manter uma conexão ativa? Agora, vamos incluir a IA nesse workflow. Como um modelo usa uma ferramenta? Esta é a parte que costuma ficar confusa em muitas explicações.

03:33 Em geral, o modelo não pega sua chave de API e começa a fazer solicitações de rede por conta própria. Seu aplicativo fornece descrições das ferramentas disponíveis. Por exemplo, [música] buscar chamados encontra os chamados de um cliente. Essa ferramenta exige um ID de cliente. Então, o modelo pode propor uma chamada de ferramenta [música] com os argumentos apropriados. Seu aplicativo a executa, retorna o resultado e permite que o modelo continue. No nosso assistente de suporte, isso pode [música] significar encontrar o chamado, recuperar a política e, em seguida, gerar um rascunho com base nas informações retornadas. Isso é tool calling, e tool calling já existia

04:04 antes do MCP. Então, se os modelos já podiam usar ferramentas, o que o MCP realmente resolve? O problema de integração que o MCP busca resolver. Imagine que você criou um conector para chamados para um aplicativo de IA. Depois, quer usá-lo em outro assistente e em mais um. Sem uma interface compartilhada, talvez precise de adaptadores, formatos de registro e código de integração diferentes. Agora, repita isso para documentos, calendários, sistemas de monitoramento e serviços internos. O problema não é simplesmente a existência de uma API. É que cada aplicativo de IA pode esperar se conectar a essas ferramentas de um jeito diferente.

04:35 >> [música] >> MCP, o Model Context Protocol, fornece um protocolo compartilhado para conectar aplicativos de IA a ferramentas e dados externos. Aqui vai uma analogia. Imagine que cada aparelho na sua mesa precise de um conector diferente. Você passa metade do tempo procurando adaptadores. Um conector compartilhado reduz essa confusão, mas não cria eletricidade nem faz todos os aparelhos funcionarem da mesma maneira. Da mesma forma, o MCP padroniza parte da conexão. O sistema subjacente ainda precisa fazer o trabalho. Uma API de chamados continua gerenciando chamados, e um servidor MCP pode expor operações selecionadas de chamados

05:06 por meio de uma interface que um aplicativo compatível com MCP entende. [música] E esse servidor também pode trabalhar com arquivos, bancos de dados ou programas locais. Ele não precisa envolver uma API da web. [música] Acompanhe uma solicitação pelo MCP. Vamos voltar à solicitação de suporte da Sara. Há três nomes que você precisa conhecer. O host é o aplicativo de API com o qual o usuário interage; o cliente é o componente que se comunica com um servidor MCP; e o servidor expõe funcionalidades ou dados. O cliente pode [música] perguntar ao servidor quais ferramentas estão disponíveis. O servidor pode descrever uma ferramenta de busca, seu nome,

05:37 o que ela faz e a estrutura das entradas. Essas informações de descoberta ajudam o host a decidir quais ferramentas disponibilizar para o modelo. Então, quando ocorre uma chamada, o host aplica seus controles e o cliente envia a solicitação ao servidor. O servidor executa a operação, e o resultado retorna ao aplicativo. Em seguida, o modelo usa esse resultado para continuar. No nosso exemplo, ele lê o chamado e a política e, então, redige uma resposta. Observe a separação: o modelo propõe, e o software executa. O MCP fornece o protocolo de comunicação entre cliente e servidor. Ele

06:07 não se torna o cérebro do modelo. O MCP é mais do que chamadas de ferramentas. Os servidores MCP podem expor três componentes importantes: ferramentas, recursos e prompts. As ferramentas permitem que um aplicativo execute operações, por exemplo, buscar chamados ou criar um rascunho. Os recursos fornecem contexto, como um documento ou arquivo que o aplicativo pode ler. Os prompts oferecem modelos reutilizáveis que usuários ou aplicativos podem selecionar para uma tarefa. No nosso workflow de suporte, pense em uma ferramenta de busca de chamados, um recurso com a política de reembolso e um modelo para redigir respostas aos clientes. Nem todo

06:37 servidor expõe os três, e os hosts diferem quanto ao que oferecem e à forma como apresentam esses recursos. [música] Por isso, o suporte a MCP é o começo de uma verificação de compatibilidade, não o fim. O protocolo pode funcionar localmente usando entrada e saída padrão ou remotamente usando >> [música] >> HTTP com transmissão contínua. Você não precisa dominar esses transportes para entender a arquitetura. Basta lembrar que um servidor MCP pode ser um processo local, não necessariamente outro serviço na nuvem. O que o MCP não remove magicamente? É aqui que a empolgação passa à frente da realidade. O MCP

07:09 não dá automaticamente ao seu assistente acesso a todos os serviços. Você ainda precisa de uma configuração adequada do servidor, credenciais e permissões. Alguém ainda precisa implementar as operações por trás das ferramentas. Se a API de chamados tiver paginação, limites de taxa ou campos que mudam, sua integração ainda precisará lidar com isso. E as APIs comuns não são necessariamente misteriosas ou sem documentação. Muitas já têm contratos legíveis por máquina. A diferença é que o MCP oferece aos aplicativos de IA compatíveis uma forma compartilhada de descobrir e interagir com as funcionalidades expostas. Ele também não

07:39 garante que o modelo escolherá a ferramenta correta. Uma solicitação perfeitamente válida ainda pode ser a ação errada. Você pode criar um chamado com sucesso no projeto errado. Pode enviar um e-mail com sucesso para a pessoa errada. Execução bem-sucedida e comportamento correto são duas coisas diferentes. Mais ferramentas podem significar mais confusão. Lembra da pergunta do começo? Por que mais ferramentas poderiam piorar um agent? Imagine entregar [música] a alguém uma caixa de ferramentas com cinco ferramentas claramente identificadas. Agora imagine entregar 500 ferramentas, várias com nomes quase idênticos. Mais opções não

08:10 produzir automaticamente decisões melhores. Essa é a minha conclusão de engenharia. Exponha as ferramentas de que a tarefa realmente precisa e descreva-as com clareza. Compare “executar consulta” com “encontrar chamados em aberto do cliente”. O segundo nome dá ao modelo uma pista muito mais clara sobre o uso pretendido. Comece nosso assistente de suporte com a leitura de chamados e a preparação de rascunhos. Adicione o envio mais tarde, com uma etapa explícita de confirmação, e mantenha as verificações de autorização no sistema de execução. Uma frase [música] em um prompt não substitui uma verificação de permissão. Recupere o conteúdo com cuidado. Uma instrução maliciosa dentro de um chamado de suporte é

08:42 ainda conteúdo do cliente, não uma instrução que seu assistente deva obedecer. Em um deploy real, registre quais ferramentas são executadas, valide as entradas e garanta que falhas não acionem ações duplicadas. Conectar a ferramenta é a etapa um. Tornar o workflow confiável é o trabalho de engenharia. Você deve usar uma API diretamente ou usar MCP? Se você tem um aplicativo fixo chamando um serviço conhecido, a integração direta com a API pode ser tudo de que precisa. Não é necessário adicionar MCP só para consultar um saldo ou enviar um formulário. Se você quer expor um conjunto útil de operações a vários aplicativos de IA compatíveis,

09:13 o MCP se torna mais interessante. Por exemplo, você poderia criar um servidor que expõe o status de deploy somente para leitura, o status recente >> [música] >> e os erros recentes, além de runbooks aprovados. Diferentes assistentes poderiam reutilizar essa interface, em vez de cada equipe criar seu próprio conector. A decisão diz respeito a reutilização, compatibilidade e controle, não a qual sigla é mais nova. O que eu criaria para aprender isso? Aqui vai um projeto prático. Crie uma pequena API de chamados com dados de exemplo. Teste-a diretamente para entender as requisições e as respostas. Depois, exponha duas

09:44 ferramentas MCP: pesquisar chamados e criar uma resposta preliminar. Conecte um aplicativo de IA compatível e peça que encontre o chamado de um cliente e prepare uma resposta. Depois, examine o que realmente aconteceu. Qual ferramenta ele escolheu? Quais argumentos enviou? Usou as informações retornadas? O que fez quando não havia nenhum chamado? Esse projeto ensina APIs, tool calling, MCP e tratamento de falhas em um único workflow. Para engenheiros de cloud e DevOps, adapte-o a incidentes. Leia o status do serviço, recupere os erros recentes e redija uma atualização sobre o incidente.

10:14 Comece pela observação, antes de dar ações operacionais ao assistente. Então, para concluir, um modelo pode gerar uma resposta convincente. Ferramentas conectadas permitem que um aplicativo verifique informações reais e execute trabalho de verdade. APIs expõem a funcionalidade do sistema. MCP fornece um protocolo compartilhado para conectar aplicativos de IA compatíveis a ferramentas e contexto. E seu aplicativo ainda decide como esse acesso é controlado. Quando você entende essas partes separadamente, a arquitetura fica muito mais fácil de compreender. Agora, estou curioso: qual é a primeira ferramenta que você conectaria a um assistente de IA

10:46 — GitHub, sua pilha de monitoramento ou seu sistema de suporte? Conte nos comentários. E, se você gostou do vídeo, curta e inscreva-se no canal. Até o próximo.

Transcrição original

[00:00] Your AI can explain Kubernetes. It can write a beautiful email. It can even give you a very confident answer that is completely wrong. But ask it to check a real support ticket, find the company’s refund policy, and prepare a reply. Suddenly, being good with words isn’t enough. It needs access to your systems. That’s where APIs come in. And now, there’s another piece everyone is talking about, MCP. You have probably heard that MCP is replacing APIs. That explanation misses the most interesting part because the real challenge is how

[00:30] we connect an API application to the tools it can use. [music] We’re going to follow one request from a user all the way to a real action. You will see what an API does, what MCP adds, and where the model actually fits. And by the end, you will understand why giving an agent more tools can sometimes make [music] it worse. So, let’s get into it. The problem, your model cannot see your business. Imagine you’re building a support assistant. You ask, “Find Sarah’s latest support ticket, check our refund policy, and draft a response.” Without connected tools, the model

[01:01] doesn’t have those records. It might explain how to handle the request. It might ask you to paste the information. Or if your application is poorly designed, it might invent an answer. Knowing what a refund policy usually looks like is very different from reading your company’s actual policy. So, your assistant needs three things: access to tickets, access to the policy, and a way to prepare a response. Let’s start with the foundation, APIs. APIs without the jargon. An API is an interface that lets software use another system’s functionality. For this

[01:32] example, we will use a web API. Think about your banking app. When you open it, your phone doesn’t magically know your account balance. It asks a back-end system for that information. That API defines how to ask and how the answer comes back. In our support assistant, a request might look like this. Get [music] means we are asking to retrieve something. The path tells the server what resource we want, and the customer ID narrows the search. The response might contain the ticket number, subject, status, and latest message,

[02:02] commonly as JSON. If we want to create a ticket, we might use post and send the details in the request body. For updates, you will often see put or patch. For removal, delete. But the method and URL are only part of the story. The system also needs to know who is making the request, whether they are allowed to access that customer’s data, and what happens if the request fails. That’s why real integrations involve authentication, validation, error handling, and limits. A demo can work with one happy path request, but production has to work when the ticket

[02:32] service is slow, the token expires, and somebody clicks the button twice. Not every API works the same way. REST is a common style for web APIs, often using HTTP methods and JSON. GraphQL lets clients request a specific fields, useful when different screens need different combinations of data. gRPC uses defined service contracts in commonly protocol buffers. You will often encounter it in communication between back-end services. You may also see SOAP in established enterprise systems. And then, there are

[03:03] communication patterns around those interfaces. WebSockets keep a connection open for messages in both directions. Webhooks let a service notify another system when something happens, like a payment completing or a ticket changing. You don’t need to memorize every acronym today. The useful question is, does this workflow need to fetch data, run an operation, receive an event, [music] or maintain a live connection? Now, let’s put AI into that workflow. How a model uses a tool? Here’s the part that gets blurred in a lot of explanations.

[03:33] The model doesn’t usually take your API key and start making network requests by itself. Your application gives it descriptions of available tools. For example, [music] search tickets finds tickets for a customer. It requires a customer ID. The model can then propose [music] a tool called with the appropriate arguments. Your application executes it, returns the result, and lets the model continue. For our support assistant, that might [music] mean finding the ticket, retrieving the policy, and then generating a draft based on the return information. That’s tool calling, and tool calling existed

[04:04] before MCP. So, if models could already use tools, what does MCP actually solve? The integration problem MCP targets. Imagine you have built your ticket connector for one AI application. Then, you want to use it in another assistant and another. Without a shared interface, you may need different adapters, registration formats, and integration code. Now, repeat that for documents, calendars, monitor systems, and internal services. The pain isn’t simply that an API exists. It’s that every AI application may expect to connect to those tools differently.

[04:35] >> [music] >> MCP, the model context protocol, provides a shared protocol for connecting AI applications to external tools and data. Here’s my analogy. Imagine every device on your desk needs a different connector. You spend half your time looking for adapters. A shared connector reduces that mess, but it doesn’t create electricity, and it doesn’t make every device do the same thing. Similarly, MCP standardizes part of the connection. The underlying system still has to do the work. A ticket API still manages tickets, and an MCP server can expose selected ticket operations

[05:06] through an interface an MCP compatible application understands. [music] And that server can also work with files, databases, or local programs. It doesn’t have to wrap a web API. [music] Follow one request through MCP. We go back to Sara’s support request. There are three names to know. The host is the API application the user interacts with, the client is the component that communicates with an MCP server, and the server exposes functionality or data. The client can [music] ask the server what tools are available. The server might describe a search tool, its name,

[05:37] what it does, and the structure of its inputs. That discovery information helps the host decide which tools to make available to the model. The The a call, the host applies its controls and the client sends the request to the server. The server performs the operation and the result returns to the application. Then the model uses that result to continue. In our example, it reads the ticket and policy, then drafts set as response. Notice the separation. The model proposes and the software executes. MCP provides the communication protocol between client and server. It

[06:07] doesn’t become the model’s brain. MCP is more than tool calls. MCP servers can expose three important building blocks: tools, resources, and prompts. Tools let an application perform operations, for example, searching tickets or creating a draft. Resources provide context, such as a document or a file the application can read. Prompts offer reusable templates that users or applications can select for a task. For our support workflow, think of a ticket search tool, a refund policy resource, and a template for drafting customer replies. Not every

[06:37] server exposes all three and hosts differ in what they support and how they present it. [music] That’s why supports MCP is the beginning of a compatibility check, not the end. The protocol can run locally using standard input and output or remotely using >> [music] >> streamable HTTP. You don’t need to master those transports to understand the architecture. Just remember that an MCP server can be a local process, not necessarily another cloud service. What MCP does not magically remove? Here’s when the hype gets ahead of reality. MCP

[07:09] doesn’t actually give your assistant access to every service. You still need a suitable server configuration, credentials, and permissions. Somebody still implements the operations behind the tools. If the ticket API has pagination, rate limits, or changing fields, your integration still has to handle them. And ordinary APIs aren’t necessarily mysterious or undocumented. Many already have machine-readable contracts. The difference is that MCP gives compatible AI applications a shared way to discover and interact with exposed capabilities. It also doesn’t

[07:39] guarantee that the model will choose the correct tool. A perfectly valid request can still be the wrong action. You can successfully create a ticket in the wrong project. You can successfully send an email to the wrong person. Successful execution and correct behavior are two different things. More tools can mean more confusion. Remember the question at the beginning? Why might more tools make an agent worse? Imagine handing [music] someone a toolbox with five clearly labeled tools. Now imagine handing them 500 tools, several with almost identical names. More choice does not

[08:10] automatically produce better decisions. That’s my engineering takeaway. Expose the tools the task actually needs and describe them clearly. Compare run query with find open tickets for customer. The second name gives the model a much clearer clue about the intended use. Start our support assistant with reading tickets and preparing drafts. Add sending later with an explicit confirmation step and keep authorization checks in the execution system. A sentence [music] in a prompt is not a substitute for a permission check. Retrieve content carefully. A malicious instruction inside a support ticket is

[08:42] still customer content, not an instruction your assistant should obey. For a real deployment, record which tools run, validate inputs, and make sure failures don’t trigger duplicate actions. Connecting the tool is a step one. Making the workflow dependable is the engineering job. Should you use an API directly or use MCP? If you have one fixed application calling one known service, direct API integration may be all you need. You don’t have to add MCP just to retrieve a balance or submit a form. If you want to expose a useful set of operations to several compatible AI

[09:13] applications, MCP becomes more interesting. For example, you might build a server that exposes read-only deployment status, recent >> [music] >> status, and recent errors, and approved runbooks. Different assistants could reuse that interface instead of each team building its own connector. The decision is about reuse, compatibility, and control, not whether one acronym is newer. What I would build to learn this? Here’s a practical project. Create a small ticket API with sample data. Test it directly so you understand the request and responses. Then expose two

[09:44] MCP tools, search tickets and create a draft reply. Connect a compatible AI application, ask it to find a customer’s ticket and prepare a response. Then inspect what actually happened. Which tool did it choose? What arguments did it send? Did it use the return information? What did it do when no ticket existed? That project teaches you APIs, tool calling, MCP and failure handling in one workflow. For cloud and DevOps engineers, adapted to incidents. Read service status, retrieve recent errors and draft an incident update.

[10:14] Begin with observation before giving the assistant operational actions. So, for closing, a model can generate a convincing answer. Connected tools let an application check real information and perform real work. APIs expose the system’s functionality. MCP provides a shared protocol for connecting compatible AI applications to tools and context. And your application still decides how that access is controlled. Once you see those pieces separately, the architecture becomes much easier to understand. Now, I’m curious, what’s the first tool you would connect to an AI

[10:46] assistant? GitHub, your monitoring stack, or your support system? Tell me in the comments. And if you like the video, please like and subscribe, and see you in the next one.