MCP (Model Context Protocol)

MCP Protocol (Model Context Protocol) é o protocolo aberto publicado pela Anthropic em novembro de 2024 que padroniza como modelos de linguagem se conectam a fontes de dados e ferramentas externas. Em vez de cada empresa criar sua própria forma de plugar IA em sistemas, o MCP propõe um padrão único de cliente-servidor que qualquer LLM pode consumir. É a tentativa de virar o USB-C da integração entre IA e software, e WordPress já tem servidores MCP disponíveis.

O que é o MCP

MCP é um protocolo de comunicação que define um contrato entre cliente (a aplicação que hospeda o LLM, como Claude Desktop ou Claude Code) e servidor (um processo que expõe capacidades específicas: leitura de arquivos, query em banco, chamada de API, manipulação de WordPress). O modelo conversa com o cliente, e o cliente chama o servidor MCP quando o modelo precisa de ferramenta externa.

O protocolo é baseado em JSON-RPC 2.0 e roda sobre stdio, HTTP+SSE ou WebSocket. Servidores MCP podem ser escritos em Python, TypeScript, Go, Rust, Java. A SDK oficial em github.com/modelcontextprotocol cobre essas linguagens com geradores de boilerplate.

A motivação técnica é simples: function calling tradicional acopla modelo e ferramenta. Cada LLM tem seu jeito de declarar tools (OpenAI tem um schema, Anthropic tem outro, Gemini tem outro). Servidor MCP exposto uma vez funciona com qualquer cliente compatível, sem precisar reescrever a integração.

O movimento ganhou tração rápido. Em poucos meses, Microsoft, OpenAI, Cursor e dezenas de fornecedores anunciaram suporte. A Apify, GitHub, Slack, Notion, Figma, Stripe têm servidores MCP públicos. O ecossistema cresceu de zero a centenas de servidores em menos de um ano.

Como o MCP padroniza tools

Servidor MCP expõe três primitivos: tools (funções que o modelo pode chamar), resources (dados que o modelo pode ler) e prompts (templates de prompt que o servidor sugere). Cliente conectado descobre os primitivos via discovery e os disponibiliza para o LLM no contexto da conversa.

Tools funcionam como function calling tradicional, mas o esquema é universal. Cada tool tem nome, descrição em texto natural, JSON Schema do input e definição de output. O modelo escolhe qual tool chamar baseado na descrição, o cliente invoca a tool no servidor, o servidor retorna o resultado, o modelo formula a resposta final.

Resources são URIs que apontam para dados estáticos ou dinâmicos: arquivo no disco, registro de banco, página web. O modelo pode ler resources sem chamar uma tool, e o cliente decide quando carregar o conteúdo no contexto. Útil para passar contexto extenso sem inflar o histórico de mensagens.

Prompts são templates parametrizados que o servidor expõe para o cliente. Em vez de o usuário precisar saber como formular um pedido complexo, o cliente apresenta os prompts disponíveis e o usuário só preenche os campos. Tira atrito de descoberta e padroniza fluxos comuns.

MCP vs function calling tradicional

Function calling clássico exige que cada integração seja codificada dentro do app que usa o LLM. Se você quer Claude lendo Google Drive e Slack, escreve duas funções, declara em formato Anthropic, gerencia autenticação e tratamento de erros para cada. Trocar para GPT-4 implica reescrever os schemas para o formato OpenAI.

MCP inverte o modelo. O servidor é escrito uma vez, separado da aplicação cliente. Slack publica um servidor MCP oficial, Google publica outro, qualquer cliente compatível (Claude Desktop, Claude Code, Cursor, Cline) consome ambos sem código extra. Mudou o LLM? O servidor continua igual.

Discovery dinâmica é outra vantagem. Cliente lista tools disponíveis no servidor em runtime, sem precisar declarar tudo no system prompt. Servidores podem expor centenas de tools sem sobrecarregar contexto, e o cliente carrega só o que for relevante. É padrão de “progressive disclosure” aplicado a IA.

Trade-offs existem. Latência adiciona um hop extra (cliente → servidor → API → servidor → cliente). Servidores mal escritos podem retornar dados gigantes que estouram contexto. Padronização ainda está em evolução: especificação muda, e versões antigas de servidor precisam migrar.

Implementação MCP em projetos WP

Servidor MCP para WordPress já existe na comunidade. Projetos no GitHub expõem operações de wp-admin via MCP: listar posts, criar posts, atualizar custom fields, executar queries, instalar plugins, rodar comandos WP-CLI. Cliente conectado consegue controlar o site WordPress conversando com o LLM.

O fluxo padrão usa REST API WordPress por baixo. O servidor MCP autentica via Application Password, traduz pedidos do LLM em chamadas REST e devolve resultados estruturados. Para sites com necessidades específicas, dá para criar tools customizadas que rodam SQL direto ou hooks PHP via plugin companion.

Casos de uso emergentes: agente que cria posts de blog a partir de briefing curto, agente que diagnostica problemas de performance lendo logs e métricas, agente que faz auditoria de SEO checando cada página, agente que gerencia comentários e modera spam. Cada cenário vira um workflow conversacional em vez de uma feature codificada na mão.

Pareando MCP com RAG, o site WordPress vira fonte de conhecimento que o agente consulta dinamicamente. Em vez do LLM tentar lembrar o conteúdo do site, ele busca via MCP em runtime, com dados sempre atualizados. Combine com IA generativa WordPress e Claude WordPress para entender o ecossistema completo.

Para times que estão experimentando MCP em WordPress sem montar a infra de servidor manualmente, a FULL Services entrega ambientes WordPress com Application Password configurada, REST API tunada e logs estruturados que servem como base para qualquer servidor MCP customizado. Dentro dos planos da FULL, o time tem ambiente pronto para conectar agentes IA ao WordPress sem precisar reconfigurar segurança, autenticação ou rotas a cada nova integração experimental.