Systems Design Meditation · Edition 2
Depois das APIs
Por que o MCP sinaliza uma nova camada de infraestrutura
Edward Calderón
Arquiteto de Software
As APIs conectaram softwares. Os agentes introduzem software que precisa decidir a qual software se conectar.
Uma integração convencional começa com conhecimento: o desenvolvedor seleciona um endpoint, estuda seu esquema e escreve código determinístico ao redor dele. O chamador conhece o serviço e geralmente conhece a operação. O software agêntico muda essa premissa. Ele pode precisar descobrir capacidades, entender suas descrições, escolher entre elas e carregar contexto através da fronteira.
Da invocação à descoberta
REST, RPC e fluxos de eventos continuam essenciais. O MCP não os torna obsoletos. Ele aborda uma camada diferente: apresentar ferramentas, recursos e prompts a clientes orientados por modelos por meio de uma interface compartilhada. A operação subjacente ainda pode ser uma chamada de API, uma consulta a banco de dados ou um processo local.
Essa distinção importa. Descoberta não é apenas um SDK mais agradável. Uma máquina que seleciona uma capacidade precisa de nomes e descrições que sustentem um raciocínio correto, esquemas que restrinjam as entradas e fronteiras de segurança explícitas. Uma descrição ambígua de ferramenta é um defeito arquitetural, porque altera o comportamento de seleção.
A especificação do MCP define uma arquitetura cliente-host-servidor e a negociação de capacidades. Ela também adverte os implementadores a preservar consentimento, privacidade de dados e segurança das ferramentas. Essas são pistas sobre a nova camada: a troca de contexto não pode ser separada da autoridade.
O que me interessa não é se o MCP se tornará o protocolo definitivo. É que a interação entre agentes e sistemas se tornou importante o suficiente para exigir uma camada de protocolo. O protocolo pode mudar. A necessidade permanecerá.
O plano de controle em torno das ferramentas
Um ecossistema útil de ferramentas para agentes precisa de mais do que um catálogo. Precisa de ciclo de vida e governança. Quem registrou uma ferramenta? Qual versão está ativa? Qual tenant pode vê-la? A descoberta implica permissão ou apenas conhecimento? Como os resultados são marcados como não confiáveis? O que acontece quando um servidor desaparece no meio de um fluxo de trabalho?
Essas são perguntas de sistemas distribuídos. Serviços falham independentemente. Esquemas evoluem. Novas tentativas podem duplicar efeitos colaterais. O agente pode manter contexto desatualizado. Uma chamada de ferramenta que parece atômica para o modelo pode abranger várias operações não atômicas por baixo.
Imagine um agente de operações escolhendo entre ferramentas para ler telemetria, criar um incidente e alterar a capacidade. A descoberta deve expor as três capacidades, mas a autorização não deve ser uniforme. A leitura pode ser ampla. A criação de um incidente deve ser idempotente. Alterações de capacidade devem exigir políticas mais fortes e incluir um intervalo delimitado. Um protocolo compartilhado ajuda a descrever a interface; a plataforma ainda precisa impor a fronteira.
As fronteiras entre fornecedores tornam isso mais importante. As organizações usarão vários provedores de modelos e centenas de serviços internos e externos. Adaptadores sob medida criam acoplamento nas duas direções. Uma camada de protocolo pode permitir que uma ferramenta evolua sem que cada cliente aprenda sua integração privada, e permitir que um cliente mude sem que cada serviço seja reescrito.
Padronização sem mitologia
Ecossistemas importantes frequentemente aceleram quando as interfaces se tornam previsíveis. Mas analogias podem esconder mais do que explicam. O MCP não é simplesmente “o novo HTTP”. O HTTP transporta representações entre componentes em rede. O MCP define convenções para contexto e capacidades voltados a modelos, geralmente usando transportes existentes por baixo.
A alegação arquitetural útil é mais estreita. Interfaces padrão reduzem o número de acordos bilaterais necessários para que os componentes cooperem. Elas criam espaço para ferramentas: registros, gateways, motores de políticas, ambientes de teste e observabilidade. Também tornam as falhas comparáveis.
A padronização não cria interoperabilidade automaticamente. Dois servidores podem implementar o mesmo protocolo usando semânticas incompatíveis. Uma ferramenta chamada `search` pode pesquisar os documentos de um cliente, a web pública ou um banco de dados operacional. Qualidade semântica, proveniência e confiança continuam sendo questões de sistema.
Isso sugere um design em camadas. Use protocolos para descoberta e troca. Use identidade e políticas para autorização. Use contratos de domínio para significado. Use rastreamento e registros de auditoria para responsabilização. Use APIs comuns e filas para execução confiável. Nenhuma camada isolada deve fingir que resolve as outras.
Para quem constrói, o valor imediato do MCP não é, portanto, uma promessa de universalidade. É uma pressão prática em direção ao desacoplamento dos clientes de modelo das implementações de ferramentas. Isso torna a experimentação mais barata e a substituição mais reversível.
Protocolos importam porque permitem que os sistemas evoluam independentemente.