MCP virou o padrão para ligar agentes de IA a bancos de dados e APIs internas

Quando uma aplicação de IA precisa ler uma planilha, consultar um CRM e rodar uma query num banco de dados, alguém tem que escrever a integração para cada um desses sistemas, e normalmente de um jeito que não serve para outra ferramenta de IA.

O Model Context Protocol (MCP) existe para acabar com essa reinvenção: é um protocolo aberto, especificado em JSON-RPC 2.0, que padroniza como um agente de IA descobre e usa dados e funções de sistemas externos. A versão mais recente da especificação, datada de 18 de junho de 2025, é o documento de referência que qualquer um que for montar um servidor ou cliente MCP precisa ler antes de escrever a primeira linha de código.

O MCP se tornou peça comum em aplicações de chat e em editores com suporte a extensões de IA. A proposta declarada na especificação é dar a diferentes LLMs e aplicações hospedeiras uma forma única de se conectar a fontes de contexto e ferramentas, em vez de cada fabricante inventar seu próprio formato de plugin.

Três papéis fixos: host, cliente e servidor

A arquitetura do MCP separa responsabilidades em três papéis bem definidos, e entender essa separação evita confusão na hora de decidir onde entra o código que você vai escrever.

• Host: a aplicação que o usuário final usa, como um assistente de chat ou um IDE. É quem inicia a conexão.
• Cliente: o conector dentro do host que fala MCP com um servidor específico. Um host pode manter vários clientes, um para cada servidor conectado.
• Servidor: o serviço que expõe dados e funções, geralmente um processo separado que roda perto do sistema que ele representa (um banco de dados, uma API interna, um sistema de arquivos).

Na prática, quem desenvolve para conectar um agente a um sistema da empresa quase sempre está escrevendo o servidor. O host e o cliente normalmente já vêm prontos na aplicação de IA que o time escolheu usar.

O que um servidor pode oferecer ao agente

A especificação define três tipos de capacidade que um servidor MCP pode expor, e cada um responde a uma necessidade diferente:

1. Resources (recursos): dados e contexto que o usuário ou o modelo podem consultar, como o conteúdo de um arquivo ou o resultado de uma consulta.
2. Prompts: modelos de mensagem e fluxos de trabalho prontos, pensados para o usuário disparar, não para o modelo chamar sozinho.
3. Tools (ferramentas): funções que o modelo de IA pode executar, como criar_ticket(titulo, descricao) ou consultar_estoque(sku).

Tools são a capacidade mais usada quando o objetivo é ligar um agente a um CRM, um banco de dados ou uma API interna: é o servidor que decide que funções existem e com que parâmetros, e é o agente que decide quando chamar cada uma durante a conversa.

O que o host pode oferecer de volta ao servidor

A troca não é de via única. A especificação também define capacidades que o cliente, dentro do host, pode oferecer ao servidor, o que abre espaço para comportamentos mais agentivos:

• Sampling: o servidor pode pedir ao host que faça uma chamada recursiva a um LLM, delegando parte do raciocínio de volta para o modelo.
• Roots: o servidor pode perguntar ao host quais diretórios ou URIs estão liberados para operar, em vez de assumir acesso total ao sistema de arquivos.
• Elicitation: o servidor pode pedir informação adicional ao usuário no meio da execução, em vez de falhar por falta de dado.

Essas três capacidades são opcionais e dependem de negociação na abertura da conexão: um servidor simples pode funcionar sem nenhuma delas, só expondo tools.

A segurança não vem de graça, o protocolo só abre a porta

A especificação é direta num ponto que costuma passar batido: o MCP não aplica segurança no nível do protocolo. Ela lista princípios que ficam a cargo de quem implementa o host, e os mais relevantes para quem vai subir um servidor em produção são:

• O host deve obter consentimento explícito do usuário antes de expor dados a um servidor e antes de invocar qualquer tool.
• Descrições de comportamento de uma tool devem ser tratadas como não confiáveis, a menos que venham de um servidor confiável, porque representam execução arbitrária de código.
• Toda chamada de sampling precisa de aprovação explícita do usuário sobre o prompt que será enviado e sobre o que o servidor pode ver do resultado.

Isso significa que, do lado de quem escreve o servidor, a responsabilidade não acaba na implementação da tool: documentar com clareza o que cada função faz, e nunca assumir que o host vai confiar cegamente, faz parte do trabalho.

Por baixo do capô: o que trafega é JSON-RPC puro

Toda troca de mensagem no MCP segue o formato JSON-RPC 2.0, o que significa que dá para inspecionar o protocolo sem SDK nenhum. Uma chamada de listagem de tools e a resposta do servidor se parecem com isto:

// Requisição do cliente
{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/list"
}

// Resposta do servidor
{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "tools": [
      {
        "name": "consultar_estoque",
        "description": "Consulta a quantidade em estoque de um SKU",
        "inputSchema": {
          "type": "object",
          "properties": { "sku": { "type": "string" } },
          "required": ["sku"]
        }
      }
    ]
  }
}

Para executar a função, o cliente manda um tools/call com o nome e os argumentos, e o servidor devolve o resultado no mesmo formato. É esse contrato fixo, documentado via JSON Schema em cada tool, que permite que qualquer host compatível com MCP converse com qualquer servidor compatível, sem acoplamento direto entre os dois lados.

Primeiro servidor: o esqueleto mínimo

Nota da redação: o código desta seção não foi executado em ambiente real nem confirmado contra documentação oficial de SDK. Valide antes de usar em produção.

Para ilustrar como ficaria a implementação de um servidor na prática, veja abaixo um exemplo em Python que usa decoradores para expor funções como tools, abstraindo a parte de JSON-RPC:

from mcp.server.fastmcp import FastMCP

mcp = FastMCP("estoque-interno")

@mcp.tool()
def consultar_estoque(sku: str) -> dict:
    """Consulta a quantidade em estoque de um SKU no banco interno."""
    # aqui entraria a query real ao banco de dados da empresa
    return {"sku": sku, "quantidade": 42}

if __name__ == "__main__":
    mcp.run()

Esse servidor, rodando localmente, já pode ser apontado por qualquer host MCP configurado para conversar com ele via stdio ou HTTP, dependendo do transporte escolhido. O trabalho de verdade, nesse ponto, deixa de ser protocolo e vira o de sempre: validar entrada, tratar erro, e decidir o que a função pode e não pode tocar no sistema de produção.

Quanto isso custa e quando não vale montar um servidor

O protocolo em si é uma especificação aberta, documentada publicamente, o que significa que não há licença a pagar para adotar o MCP como protocolo. O custo real tem duas frentes: a infraestrutura para hospedar e manter o servidor, que cresce com o número de integrações e volume de chamadas, e as chamadas de LLM feitas pelo host durante a conversa, cobradas pelo provedor do modelo por token, como em qualquer uso de API de IA.

Para quem só precisa de uma integração pontual entre um agente e um único sistema, escrever um servidor MCP completo pode ser esforço desnecessário: um function calling direto na API do modelo resolve com menos peça móvel. O MCP compensa quando há várias ferramentas de IA que precisam falar com os mesmos sistemas internos, porque aí o custo de manter N integrações separadas supera o de manter um servidor único e padronizado.

Fonte 1: Especificação oficial do Model Context Protocol (MCP) (https://modelcontextprotocol.io/specification/2025-06-18)

Specification - Model Context Protocol

Documentation Index Fetch the complete documentation index at: /llms.txt Use this file to discover all available pages before exploring further. Skip to main content Model Context Protocol (MCP) is an open protocol that enables seamless integration between LLM applications and external data sources and tools. Whether you’re building an AI-powered IDE, enhancing a chat interface, or creating custom AI workflows, MCP provides a standardized way to connect LLMs with the context they need.

This specification defines the authoritative protocol requirements, based on the TypeScript schema in schema.ts . For implementation guides and examples, visit modelcontextprotocol.io . The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in BCP 14 [ RFC2119 ] [ RFC8174 ] when, and only when, they appear in all capitals, as shown here.

​ Overview MCP provides a standardized way for applications to:

Share contextual information with language models

Expose tools and capabilities to AI systems

Build composable integrations and workflows

The protocol uses JSON-RPC 2.0 messages to establish communication between:

Hosts : LLM applications that initiate connections

Clients : Connectors within the host application

Servers : Services that provide context and capabilities

MCP takes some inspiration from the Language Server Protocol , which standardizes how to add support for programming languages across a whole ecosystem of development tools. In a similar way, MCP standardizes how to integrate additional context and tools into the ecosystem of AI applications.

​ Key Details

​ Base Protocol

JSON-RPC message format

Stateful connections

Server and client capability negotiation

​ Features Servers offer any of the following features to clients:

Resources : Context and data, for the user or the AI model to use

Prompts : Templated messages and workflows for users

Tools : Functions for the AI model to execute

Clients may offer the following features to servers:

Sampling : Server-initiated agentic behaviors and recursive LLM interactions

Roots : Server-initiated inquiries into uri or filesystem boundaries to operate in

Elicitation : Server-initiated requests for additional information from users

​ Additional Utilities

Configuration

Progress tracking

Cancellation

Error reporting

Logging

​ Security and Trust & Safety The Model Context Protocol enables powerful capabilities through arbitrary data access and code execution paths. With this power comes important security and trust considerations that all implementors must carefully address.

​ Key Principles

User Consent and Control

Users must explicitly consent to and understand all data access and operations

Users must retain control over what data is shared and what actions are taken

Implementors should provide clear UIs for reviewing and authorizing activities

Data Privacy

Hosts must obtain explicit user consent before exposing user data to servers

Hosts must not transmit resource data elsewhere without user consent

User data should be protected with appropriate access controls

Tool Safety

Tools represent arbitrary code execution and must be treated with appropriate caution.

In particular, descriptions of tool behavior such as annotations should be considered untrusted, unless obtained from a trusted server.

Hosts must obtain explicit user consent before invoking any tool

Users should understand what each tool does before authorizing its use

LLM Sampling Controls

Users must explicitly approve any LLM sampling requests

Users should control:

Whether sampling occurs at all

The actual prompt that will be sent

What results the server can see

The protocol intentionally limits server visibility into prompts

​ Implementation Guidelines While MCP itself cannot enforce these security principles at the protocol level, implementors SHOULD :

Build robust consent and authorization flows into their applications

Provide clear documentation of security implications

Implement appropriate access controls and data protections

Follow security best practices in their integrations

Consider privacy implications in their feature designs

​ Learn More Explore the detailed specification for each protocol component:

Architecture Base Protocol Server Features Client Features Contributing Was this page helpful? Yes No Assistant Responses are generated using AI and may contain mistakes.

Fonte: Especificação oficial do Model Context Protocol (MCP)