O que e MCP e Por que Existe
O padrao aberto da Anthropic para conectar IA a dados e ferramentas
O Model Context Protocol (MCP) e um padrao aberto criado pela Anthropic em novembro de 2024 para resolver um problema fundamental: cada aplicacao de IA precisava implementar integracoes customizadas com cada fonte de dados e ferramenta. Se voce queria conectar ao GitHub, ao Slack e ao PostgreSQL, precisava de 3 integradores diferentes, cada um com sua propria API, autenticacao e formato de dados.
MCP e o "USB-C para integracao de IA". Assim como USB-C padronizou a conexao entre dispositivos e perifericos, MCP padroniza como aplicacoes de IA se conectam a fontes de dados e ferramentas. Um MCP Server escrito uma vez funciona com qualquer host compativel: Claude Desktop, VS Code, Cursor, sua app customizada, qualquer um.
π O Ecossistema MCP em Numeros
Lancamento publico do MCP pela Anthropic como padrao open-source
MCP Servers criados pela comunidade em menos de 6 meses
Especificacao aberta: qualquer empresa pode implementar, nao so Anthropic
SDKs oficiais em Python, TypeScript e Java. Comunidade criou Go, Rust e mais
O Problema que MCP Resolve
Sem MCP: N x M integraΓ§Γ΅es
Cada app precisa de integrador customizado:
- Claude Desktop + GitHub = integrador 1
- Claude Desktop + Slack = integrador 2
- VS Code + GitHub = integrador 3
- VS Code + Slack = integrador 4
- Sua App + GitHub = integrador 5
- Sua App + Slack = integrador 6
3 apps x 2 servicos = 6 integradores
Com MCP: N + M conectores
Cada servico tem 1 server MCP:
- MCP Server GitHub (funciona em qualquer host)
- MCP Server Slack (funciona em qualquer host)
- Claude Desktop (conecta a qualquer server)
- VS Code (conecta a qualquer server)
- Sua App (conecta a qualquer server)
3 apps + 2 servers = 5 componentes
A escala mostra o poder: com 10 apps e 20 servicos, sem MCP voce precisa de 200 integradores. Com MCP, 30 componentes. O ganho e exponencial.
Por que um Protocolo Padronizado?
Interoperabilidade
Um MCP Server de PostgreSQL funciona com Claude Desktop, Cursor, Windsurf e qualquer app que implemente o protocolo. Escreve uma vez, conecta em qualquer lugar.
Ecossistema Compartilhado
Em vez de cada empresa recriar integradores, a comunidade compartilha MCP Servers. O server de GitHub que a Anthropic criou voce usa de graca. O que voce criar, outros usam.
Seguranca e Isolamento
Cada MCP Server roda como processo isolado com suas proprias permissoes. O server de filesystem so acessa os diretorios que voce autorizar. Principio de menor privilegio built-in.
Vendor-Agnostic
MCP nao e preso a Anthropic. OpenAI, Google e outros provedores podem (e estao comecando a) suportar. E um padrao aberto, nao um lock-in.
π‘ Dica
Pense em MCP como HTTP para IA. Assim como HTTP padronizou comunicacao web e permitiu que qualquer browser acesse qualquer site, MCP padroniza integracao de IA e permite que qualquer host conecte a qualquer ferramenta. Se voce sabe criar um API REST, sabe criar um MCP Server.
Fazer
- ●Verificar se ja existe um MCP Server para seu caso antes de criar um
- ●Entender a diferenca entre MCP e function calling direto
- ●Acompanhar a especificacao oficial em modelcontextprotocol.io
- ●Considerar MCP para qualquer integracao que outros possam reutilizar
Evitar
- ●Criar integracoes customizadas quando um MCP Server ja resolve
- ●Confundir MCP com API REST (sao coisas diferentes)
- ●Ignorar MCP porque "so funciona com Claude" (e open standard)
- ●Tentar entender MCP sem entender function calling primeiro
Arquitetura Host/Client/Server
Os tres componentes do MCP, como se comunicam e transportes disponiveis
A arquitetura do MCP segue um modelo de tres camadas: Host, Client e Server. O Host e a aplicacao principal (como Claude Desktop). O Client e o componente dentro do Host que gerencia conexoes MCP. O Server e o processo externo que expoe capacidades (tools, resources, prompts). A comunicacao entre Client e Server usa JSON-RPC 2.0 como protocolo de mensagens.
Cada Client mantem uma conexao 1:1 com um Server especifico. Um Host pode ter multiplos Clients, cada um conectado a um Server diferente. Isso permite que Claude Desktop, por exemplo, esteja simultaneamente conectado ao filesystem, GitHub, PostgreSQL e Slack, cada um em seu proprio Server isolado.
Os 3 Componentes
A aplicacao que o usuario interage diretamente.
- Claude Desktop
- VS Code / Cursor
- Sua app SaaS
- CLI tools
Cria e gerencia Clients. Controla quais Servers podem conectar e quais capacidades expor ao LLM.
Componente interno do Host que gerencia conexao.
- Conexao 1:1 com Server
- Negocia capacidades
- Gerencia lifecycle
- Roda dentro do Host
Voce raramente implementa Clients: os SDKs ja fornecem. Seu trabalho e configurar quais Servers conectar.
Processo externo que expoe capacidades.
- Expoe tools, resources, prompts
- Roda como subprocess ou remoto
- Isolado com permissoes proprias
- Voce vai criar esses!
Onde voce passa a maior parte do tempo: criando Servers que expoe os dados e acoes do seu sistema.
Transportes de Comunicacao
MCP suporta dois transportes principais. A escolha depende de onde o Server roda:
stdio (Standard I/O)
O Host lanca o Server como subprocess e comunica via stdin/stdout. Ideal para Servers locais.
- Sem rede, sem portas, sem CORS
- Seguro por padrao (processo isolado)
- Startup rapido
- Usado por Claude Desktop e IDEs
HTTP + SSE (Streamable HTTP)
O Server roda como servico HTTP. Client conecta via rede. Ideal para Servers remotos e cloud.
- Funciona pela rede (remoto)
- Suporta multiplos Clients simultaneos
- Requer autenticacao e TLS
- Ideal para deploy em producao
Fluxo de Comunicacao (JSON-RPC)
// 1. Client descobre capacidades do Server
β { "jsonrpc": "2.0", "method": "initialize",
"params": { "capabilities": { "tools": {} } } }
β { "result": { "capabilities": { "tools": {} },
"serverInfo": { "name": "postgres-server" } } }
// 2. Client lista tools disponiveis
β { "jsonrpc": "2.0", "method": "tools/list" }
β { "result": { "tools": [
{ "name": "query", "description": "Execute SQL query",
"inputSchema": { "type": "object", ... } }
] } }
// 3. LLM decide chamar tool, Client executa via Server
β { "jsonrpc": "2.0", "method": "tools/call",
"params": { "name": "query",
"arguments": { "sql": "SELECT * FROM users LIMIT 5" } } }
β { "result": { "content": [
{ "type": "text", "text": "[{\"id\":1,...}]" }
] } }
O protocolo e stateful: primeiro inicializa, depois descobre capacidades, e entao executa chamadas. Todo o fluxo usa JSON-RPC 2.0 padrao.
π‘ Dica
Comece com stdio. E o transporte mais simples: sem configuracao de rede, sem autenticacao, sem deploy. So funciona. Quando precisar rodar o Server remotamente (ex: em producao na cloud), migre para HTTP+SSE. A logica do Server nao muda, so o transporte.
Fazer
- ●Usar stdio para desenvolvimento local e testes
- ●Implementar autenticacao ao usar HTTP transport
- ●Manter Servers isolados: um Server por responsabilidade
- ●Entender que Client e parte do SDK, nao algo que voce implementa
Evitar
- ●Expor MCP Server via HTTP sem autenticacao
- ●Criar um mega-Server com tudo (violar separacao de responsabilidades)
- ●Implementar Client/Host do zero (use os SDKs)
- ●Ignorar o lifecycle initialize/shutdown do protocolo
As 3 Capacidades: Resources, Tools, Prompts
Os tres tipos de capacidade que um MCP Server pode expor
Um MCP Server pode expor tres tipos de capacidade: Resources (dados que o LLM pode ler), Tools (acoes que o LLM pode executar) e Prompts (templates reutilizaveis que o LLM pode invocar). Cada tipo tem um proposito distinto e regras de quando usar.
A distincao chave: resources sao passivas (dados para ler), tools sao ativas (acoes para executar), e prompts sao templates (fluxos pre-definidos para reutilizar). Um server de GitHub, por exemplo, pode expor repos como resources, "create_issue" como tool, e "summarize_pr" como prompt.
Comparacao das 3 Capacidades
| Aspecto | Resources | Tools | Prompts |
|---|---|---|---|
| Tipo | Dados (read) | Acoes (execute) | Templates (invoke) |
| Controle | App ou usuario decide quando ler | LLM decide quando chamar | Usuario seleciona explicitamente |
| Analogia | GET request (leitura) | POST request (acao) | Macro/shortcut |
| Exemplo | Conteudo de um arquivo, registro do DB | Criar issue, enviar email | "Resuma este PR", "Analise este log" |
Resources: Dados para Contexto
Resources sao fontes de dados identificadas por URIs. O Host/LLM pode le-las para obter contexto:
// Listar resources disponiveis
server.listResources(() => ({
resources: [
{
uri: "file:///project/README.md",
name: "Project README",
mimeType: "text/markdown"
},
{
uri: "db://customers/recent",
name: "Recent Customers",
mimeType: "application/json"
}
]
}));
// Ler conteudo de um resource
server.readResource(({ uri }) => {
if (uri === "db://customers/recent") {
const data = db.customers.findMany({ take: 10 });
return {
contents: [{
uri, mimeType: "application/json",
text: JSON.stringify(data)
}]
};
}
});
Tools: Acoes Executaveis
Tools sao acoes que o LLM pode chamar. Seguem o mesmo padrao de function calling, mas via protocolo MCP:
server.tool(
"create_issue",
"Cria uma issue no repositorio GitHub",
{
repo: z.string().describe("Owner/repo (ex: 'user/project')"),
title: z.string().describe("Titulo da issue"),
body: z.string().optional().describe("Descricao detalhada"),
labels: z.array(z.string()).optional()
.describe("Labels para classificar")
},
async ({ repo, title, body, labels }) => {
const issue = await github.issues.create({
owner: repo.split("/")[0],
repo: repo.split("/")[1],
title, body, labels
});
return {
content: [{
type: "text",
text: `Issue #${issue.number} criada: ${issue.html_url}`
}]
};
}
);
Prompts: Templates Reutilizaveis
Prompts sao templates parametrizados que o usuario pode invocar. Ideais para fluxos complexos e repetitivos:
server.prompt(
"review_code",
"Revisa codigo e sugere melhorias de qualidade",
[
{ name: "language", description: "Linguagem do codigo",
required: true },
{ name: "focus", description: "Foco da revisao (security, perf, style)",
required: false }
],
({ language, focus = "general" }) => ({
messages: [{
role: "user",
content: {
type: "text",
text: `Revise este codigo ${language} com foco em ${focus}. ` +
`Aponte: bugs, vulnerabilidades de seguranca, ` +
`problemas de performance, e melhorias de legibilidade. ` +
`Formate como checklist com severidade (alta/media/baixa).`
}
}]
})
);
Prompts nao executam codigo. Geram uma sequencia de mensagens que o Host envia ao LLM. Sao como macros: encapsulam um fluxo complexo num unico comando.
π‘ Dica
Se esta na duvida entre resource e tool: resource = ler, tool = agir. Se o LLM so precisa ver o dado (ex: conteudo de arquivo), use resource. Se precisa mudar algo no mundo (ex: criar issue, enviar email), use tool. Prompts sao para quando voce tem um fluxo complexo que quer expor como atalho.
Fazer
- ●Usar resources para dados que o LLM precisa como contexto
- ●Usar tools para acoes com side effects no mundo
- ●Criar prompts para fluxos que usuarios repetem frequentemente
- ●Dar nomes e descricoes claras em todas as capacidades
Evitar
- ●Expor acoes destrutivas como resources (resources sao read-only)
- ●Criar tools para leitura pura (use resources)
- ●Prompts com logica de negocio complexa (prompts sao templates)
- ●Misturar as 3 capacidades sem criterio
Criando um MCP Server
Passo a passo: init, tools, handlers, transport e configuracao
Criar um MCP Server e mais simples do que parece. Os SDKs oficiais cuidam de todo o protocolo, JSON-RPC, negociacao de capacidades e transporte. Voce so precisa definir suas tools/resources e implementar os handlers. O resultado e um processo que qualquer host MCP compativel pode usar.
Vamos construir um server passo a passo em TypeScript e Python, cobrindo: setup do projeto, definicao de tools, implementacao de handlers, configuracao de transporte e teste local com Claude Desktop.
Passo 1: Setup do Projeto (TypeScript)
# Criar projeto
mkdir meu-mcp-server && cd meu-mcp-server
npm init -y
npm install @modelcontextprotocol/sdk zod
npm install -D typescript @types/node
# tsconfig.json
{
"compilerOptions": {
"target": "ES2022",
"module": "Node16",
"outDir": "./dist",
"strict": true
}
}
Passo 2: Definir Server + Tools (TypeScript)
// src/index.ts
import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { StdioServerTransport }
from "@modelcontextprotocol/sdk/server/stdio.js";
import { z } from "zod";
// 1. Criar instancia do server
const server = new McpServer({
name: "saas-analytics",
version: "1.0.0"
});
// 2. Registrar tool: buscar metricas
server.tool(
"get_metrics",
"Busca metricas de negocio do SaaS: MRR, churn, " +
"usuarios ativos. Use quando o usuario pedir dados " +
"de performance ou KPIs.",
{
metric: z.enum(["mrr", "churn", "active_users", "revenue"])
.describe("Tipo de metrica"),
period: z.enum(["today", "last_7_days", "last_30_days", "last_90_days"])
.default("last_30_days")
.describe("Periodo de analise")
},
async ({ metric, period }) => {
// Sua logica de negocio aqui
const data = await fetchMetrics(metric, period);
return {
content: [{
type: "text",
text: JSON.stringify(data, null, 2)
}]
};
}
);
// 3. Registrar tool: executar acao
server.tool(
"send_report",
"Envia relatorio por email para stakeholders. " +
"Use quando o usuario pedir para compartilhar dados.",
{
to: z.string().email().describe("Email do destinatario"),
subject: z.string().describe("Assunto do email"),
metrics: z.array(z.string()).describe("Metricas para incluir")
},
async ({ to, subject, metrics }) => {
await sendEmail(to, subject, metrics);
return {
content: [{
type: "text",
text: `Relatorio enviado para ${to} com sucesso.`
}]
};
}
);
// 4. Conectar transporte e iniciar
const transport = new StdioServerTransport();
await server.connect(transport);
Passo 2b: Versao Python
# pip install mcp[cli]
from mcp.server.fastmcp import FastMCP
# 1. Criar instancia
mcp = FastMCP("saas-analytics")
# 2. Registrar tool com decorator
@mcp.tool()
def get_metrics(
metric: str, # mrr, churn, active_users, revenue
period: str = "last_30_days"
) -> dict:
"""Busca metricas de negocio do SaaS.
Use quando o usuario pedir KPIs ou dados de performance."""
data = fetch_metrics(metric, period)
return data
@mcp.tool()
def send_report(
to: str, # Email do destinatario
subject: str, # Assunto
metrics: list[str] # Metricas para incluir
) -> str:
"""Envia relatorio por email para stakeholders."""
send_email(to, subject, metrics)
return f"Relatorio enviado para {to}"
# 3. Registrar resource
@mcp.resource("db://dashboard/summary")
def dashboard_summary() -> str:
"""Resumo atual do dashboard com KPIs principais."""
return json.dumps(get_dashboard_data())
# 4. Iniciar com stdio
if __name__ == "__main__":
mcp.run(transport="stdio")
A versao Python com FastMCP e ainda mais concisa: decorators @mcp.tool() e @mcp.resource() registram automaticamente com base nos type hints e docstrings.
Passo 3: Configurar no Claude Desktop
// ~/Library/Application Support/Claude/claude_desktop_config.json
// ou ~/.config/claude/claude_desktop_config.json (Linux)
{
"mcpServers": {
"saas-analytics": {
"command": "node",
"args": ["/path/to/meu-mcp-server/dist/index.js"],
"env": {
"DATABASE_URL": "postgresql://localhost:5432/mydb",
"SMTP_HOST": "smtp.sendgrid.net"
}
}
}
}
Reinicie o Claude Desktop. As tools get_metrics e send_report aparecem automaticamente. O Claude decide quando chama-las com base na conversa.
π‘ Dica
Para debug: use npx @modelcontextprotocol/inspector para testar seu server interativamente sem precisar do Claude Desktop. O Inspector mostra todas as tools/resources, permite chamar manualmente e inspecionar responses. Essencial para desenvolvimento.
Fazer
- ●Testar com MCP Inspector antes de conectar ao Claude
- ●Usar variaveis de ambiente para credenciais
- ●Logar requests e responses para debug
- ●Versionar o server e manter changelog
Evitar
- ●Hardcodar credenciais no codigo do server
- ●Ignorar error handling nos handlers
- ●Pular testes e ir direto para Claude Desktop (dificil debugar)
- ●Expor dados sensiveis sem controle de acesso
Conectores Existentes
Milhares de MCP Servers prontos: databases, APIs, file systems e mais
Uma das maiores vantagens do MCP e o ecossistema de Servers prontos. Em vez de criar um conector do zero para cada servico, voce instala um MCP Server existente e conecta. A Anthropic mantΓ©m servers oficiais para os servicos mais comuns, e a comunidade criou milhares de outros.
O MCP Registry (em modelcontextprotocol.io) e repositorios como awesome-mcp-servers no GitHub catalogam os servers disponiveis. Antes de criar um server customizado, sempre verifique se ja existe um pronto.
π Categorias Principais
PostgreSQL, MySQL, SQLite, MongoDB, Supabase, Redis, Neon, PlanetScale
GitHub, GitLab, Linear, Jira, Sentry, Docker, Kubernetes
Filesystem, Google Drive, S3, Notion, Obsidian, Confluence
Slack, Discord, Gmail, Google Calendar, Telegram, WhatsApp
Servers Oficiais da Anthropic
| Server | Pacote | Capacidades |
|---|---|---|
| Filesystem | @modelcontextprotocol/server-filesystem | Ler/escrever/buscar arquivos em diretorios autorizados |
| GitHub | @modelcontextprotocol/server-github | Repos, issues, PRs, branches, code search |
| PostgreSQL | @modelcontextprotocol/server-postgres | Queries SQL, schema inspection, read-only por padrao |
| Brave Search | @modelcontextprotocol/server-brave-search | Web search e local search via Brave API |
| Puppeteer | @modelcontextprotocol/server-puppeteer | Browser automation: navegar, screenshot, preencher forms |
Instalacao Rapida
A maioria dos servers funciona com npx sem instalacao previa:
# Filesystem - acesso a arquivos locais npx -y @modelcontextprotocol/server-filesystem /home/user/projetos # GitHub - acesso a repositorios GITHUB_TOKEN=ghp_xxx npx -y @modelcontextprotocol/server-github # PostgreSQL - acesso a banco de dados npx -y @modelcontextprotocol/server-postgres \ postgresql://user:pass@localhost:5432/mydb # Testar qualquer server com o Inspector npx @modelcontextprotocol/inspector \ npx -y @modelcontextprotocol/server-filesystem /tmp
Onde Encontrar MCP Servers
modelcontextprotocol.io
Site oficial com documentacao, especificacao e lista de servers mantidos pela Anthropic e parceiros.
github.com/punkpeye/awesome-mcp-servers
Lista curada pela comunidade com centenas de servers categorizados. Atualizada frequentemente.
npm / PyPI
Busque por "mcp-server" no npm ou "mcp" no PyPI. Muitos servers sao publicados como pacotes.
Smithery.ai
Marketplace de MCP Servers com instalacao one-click e reviews da comunidade.
π‘ Dica
Antes de instalar um MCP Server da comunidade, verifique: (1) o codigo-fonte no GitHub, (2) numero de stars e ultima atualizacao, (3) quais permissoes ele pede. Um server malicioso com acesso ao filesystem pode ler seus arquivos. Use somente servers de fontes confiaveis ou revise o codigo.
Fazer
- ●Verificar se existe server pronto antes de criar um
- ●Testar com Inspector antes de conectar ao Claude
- ●Ler o README e verificar quais capacidades expoe
- ●Limitar permissoes (ex: diretorio especifico, read-only)
Evitar
- ●Instalar servers sem verificar o codigo-fonte
- ●Dar permissoes amplas demais (ex: filesystem no /)
- ●Conectar muitos servers sem necessidade (overhead + confusao)
- ●Usar servers abandonados (sem updates ha meses)
Exercicio: MCP Server Custom
Construir um server que expoe dados e acoes do seu SaaS
Neste exercicio voce vai construir um MCP Server completo que expoe os dados e acoes do seu SaaS. O server vai ter resources (dados para contexto), tools (acoes executaveis) e ser configuravel para conectar com Claude Desktop ou qualquer outro host compativel.
O resultado e um conector padronizado que qualquer pessoa pode usar para conectar IA ao seu sistema. Voce vai sair com um MCP Server funcional, testado e pronto para deploy.
Entregas do Exercicio
Resources: Dados do SaaS
Expor pelo menos 2 resources: um de metricas do dashboard e um de dados de clientes. O LLM pode ler esses dados como contexto antes de responder.
db://dashboard/summary - KPIs atuaisdb://customers/recent - Ultimos 10 clientes
Tools: Acoes do SaaS
Registrar pelo menos 3 tools: buscar dados com filtros, calcular metricas e executar uma acao (enviar notificacao, criar registro). Cada tool com JSON Schema completo.
search_customers | get_metrics | send_notification
Transporte + Configuracao
Server funcional com stdio transport. Arquivo de configuracao pronto para Claude Desktop. Credenciais via variaveis de ambiente.
Teste + Validacao
Testar com MCP Inspector: verificar que tools listam corretamente, chamadas retornam dados esperados e erros sao tratados.
Estrutura do Projeto
meu-saas-mcp-server/
src/
index.ts # Entry point + server setup
tools/
search-customers.ts # Tool: busca de clientes
get-metrics.ts # Tool: calcular metricas
send-notification.ts # Tool: enviar notificacao
resources/
dashboard.ts # Resource: dados do dashboard
customers.ts # Resource: dados de clientes
db.ts # Conexao com banco de dados
package.json
tsconfig.json
claude_desktop_config.json # Exemplo de config
.env.example # Template de variaveis
README.md
Checklist de Validacao
Bonus: Deploy Remoto
Apos validar localmente, considere deploy do server para acesso remoto:
Containerize o server. Dockerfile simples com Node.js. Deploy em qualquer cloud.
Deploy serverless com HTTP+SSE transport. Edge locations globais. Free tier generoso.
Deploy com um push. Suporte nativo a Node.js e Python. Persistent volumes para SQLite.
π‘ Dica
Use Vibe Coding para criar o server: descreva as tools e resources que quer, os dados que seu SaaS tem, e deixe o LLM gerar a estrutura. Depois itere: ajuste descricoes, melhore error handling, adicione validacoes. Um MCP Server bem feito e uma vantagem competitiva real: seus usuarios podem conectar IA ao seu produto sem sair do workflow deles.
Fazer
- ●Comecar com 1 tool, testar, expandir gradualmente
- ●Usar MCP Inspector como ferramenta principal de dev
- ●Documentar cada tool/resource com descricoes claras
- ●Pensar no MCP Server como produto: outros vao usar
Evitar
- ●Criar tudo de uma vez sem testar incrementalmente
- ●Ignorar a documentacao do SDK (muitos gotchas)
- ●Expor operacoes destrutivas sem rate limiting
- ●Deployar em producao sem autenticacao
π Resumo do Modulo 4.5
MCP e o "USB-C da IA": padrao aberto que padroniza como apps de IA conectam a dados e ferramentas. Resolve o problema N x M de integracoes.
Host/Client/Server: Host e sua app, Client gerencia conexao (SDK), Server expoe capacidades. Transportes: stdio (local) ou HTTP+SSE (remoto).
3 Capacidades: Resources (dados para ler), Tools (acoes para executar), Prompts (templates reutilizaveis). Cada uma com proposito distinto.
Criar um Server e simples: SDK cuida do protocolo. Voce define tools/resources e implementa handlers. Python ou TypeScript.
Ecossistema: 3000+ servers prontos para databases, APIs, dev tools, comunicacao. Verifique antes de criar do zero.
Na pratica: MCP Server do seu SaaS com resources, tools, teste via Inspector e conexao ao Claude Desktop.