O Model Context Protocol explicado a quem constrói

Frameworks e modelos 8 min de leitura

Cabos a convergir num único hub, imagem de uma interface de ferramentas partilhada
Uma forma de ficha para muitas ferramentas. A fechadura da porta continua convosco.

Toda equipa que constrói mais do que um agente escreve o mesmo adaptador duas vezes: ligar a um sistema, descrever o que ele faz e expor essas capacidades ao modelo na forma que o cliente do momento espera. O Model Context Protocol existe para travar essa duplicação.

É genuinamente útil e também mais estreito do que o entusiasmo sugere. O MCP descreve como as capacidades são anunciadas e invocadas. Não decide quem as pode invocar, e confundir as duas coisas é a origem dos incidentes de segurança.

O que o protocolo normaliza#

  • Descoberta: o servidor diz ao cliente que ferramentas e recursos oferece, com esquemas.
  • Invocação: o cliente chama com argumentos tipados e recebe um resultado estruturado.
  • Recursos: conteúdo só de leitura que o cliente puxa para o contexto quando pede.
  • Transporte: um formato comum para que cliente e servidor de autores diferentes se entendam.

O que deliberadamente não faz#

O MCP não autentica os vossos utilizadores, não decide que registos cada um pode ler nem se uma ação precisa de aprovação. Isso continua vosso e tem de viver do lado do servidor.

Tratem cada ferramenta MCP como se um chamador confuso ou manipulado a fosse invocar com os piores argumentos plausíveis.

Onde compensa hoje#

O Model Context Protocol explicado a quem constrói — Onde compensa hoje
SituaçãoValor do MCP
Um sistema interno, vários clientes de agenteAlto — o servidor escreve-se uma vez
Assistentes de secretária com contexto localAlto — o ecossistema nasceu aí
Um agente com três ferramentas própriasBaixo — chamadas diretas são mais simples
Ferramentas de terceiros fora do vosso controloMédio — prático, mas auditem o servidor

Uma forma segura de adotar#

  1. Encapsulem capacidades estreitas, não poder geral: `get_order(id)` em vez de `sql(query)`.
  2. Apliquem autorização dentro do servidor, por chamada, com a identidade do utilizador final.
  3. Devolvam erros curtos e honestos — `não encontrado`, `sem permissão`.
  4. Registem cada invocação com argumentos e identidade.
  5. Fixem os servidores usados em versões revistas.

Perguntas frequentes

Preciso de MCP para construir um agente?

Não. Para um agente com poucas ferramentas próprias, chamadas diretas são mais simples.

O MCP é seguro por omissão?

É uma norma de transporte e descoberta, não um modelo de segurança.

Os servidores MCP podem ser vetor de injeção?

Sim, tanto por descrições que entram no contexto como pelo conteúdo devolvido.

model context protocolmcp explicadonorma de ferramentassegurança mcpdescoberta de ferramentas

Todos os guias

Última atualização 2026-08-04 por aiagentdevelopment.info · Sobre nós

Escrito por quem constrói

Cada guia é escrito por engenheiros que operam agentes em produção, não reescrito a partir de outros sites.

Revisto com regularidade

A área muda depressa. Cada guia traz a data da última revisão, publicada mesmo quando nada mudou.

Sem espaços pagos

Nenhum fornecedor de modelos, framework ou plataforma pode comprar uma menção, uma posição ou uma ligação.

Doze idiomas

Cada guia é traduzido, não substituído por máquina — cada idioma tem o seu URL e a sua data de revisão.

Limites nomeados

Dizemos com clareza quando uma tarefa não precisa de agente e um script simples sairia mais barato e mais fiável.