Inicio / Trilha 4 / Modulo 4.5
MODULO 4.5

MCP (Model Context Protocol)

O padrao aberto da Anthropic que conecta IA a qualquer fonte de dados e ferramentas externas.

6
Topicos
~55
Minutos
Avanc
Avancado
T+P
Teoria+Pratica
1

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

Nov 2024

Lancamento publico do MCP pela Anthropic como padrao open-source

3000+

MCP Servers criados pela comunidade em menos de 6 meses

Open Source

Especificacao aberta: qualquer empresa pode implementar, nao so Anthropic

3 SDKs

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
2

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

Host

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.

Client

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.

Server

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
3

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
4

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
5

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

Databases

PostgreSQL, MySQL, SQLite, MongoDB, Supabase, Redis, Neon, PlanetScale

Dev Tools

GitHub, GitLab, Linear, Jira, Sentry, Docker, Kubernetes

Data & Files

Filesystem, Google Drive, S3, Notion, Obsidian, Confluence

Communication

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)
6

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

1

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 atuais
db://customers/recent - Ultimos 10 clientes
2

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
3

Transporte + Configuracao

Server funcional com stdio transport. Arquivo de configuracao pronto para Claude Desktop. Credenciais via variaveis de ambiente.

4

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:

Docker

Containerize o server. Dockerfile simples com Node.js. Deploy em qualquer cloud.

Cloudflare Workers

Deploy serverless com HTTP+SSE transport. Edge locations globais. Free tier generoso.

Railway / Fly.io

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

1.

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.

2.

Host/Client/Server: Host e sua app, Client gerencia conexao (SDK), Server expoe capacidades. Transportes: stdio (local) ou HTTP+SSE (remoto).

3.

3 Capacidades: Resources (dados para ler), Tools (acoes para executar), Prompts (templates reutilizaveis). Cada uma com proposito distinto.

4.

Criar um Server e simples: SDK cuida do protocolo. Voce define tools/resources e implementa handlers. Python ou TypeScript.

5.

Ecossistema: 3000+ servers prontos para databases, APIs, dev tools, comunicacao. Verifique antes de criar do zero.

6.

Na pratica: MCP Server do seu SaaS com resources, tools, teste via Inspector e conexao ao Claude Desktop.

Modulo 4.4: Skills e Tools Modulo 4.6