Seu kit de partida: os SDKs MCP

• Construir Clients MCP: aplicações que vão consumir as capacidades oferecidas por um Server MCP (pode ser seu app web, uma ferramenta de linha de comando, ou até mesmo um plugin para sua IDE).

• Construir Servers MCP: aplicações ou serviços que vão expor capacidades e contexto para os Clients (pode ser uma ferramenta externa, um wrapper para uma API legada, um acesso inteligente a um banco de dados).

• TypeScript/JavaScript: essencial para o mundo web e Node.js.

• Python: queridinho da galera de dados e IA.

• Java/Kotlin: fortes no mundo corporativo e Android.

A mágica por trás das cortinas: entendendo a comunicação MCP

• Protocol Layer (o maestro): essa camada é o "cérebro" que entende a linguagem MCP. Ela sabe interpretar os diferentes tipos de mensagens (vamos vê-las já já!), processar Requests, enviar Notifications, formatar Results e lidar com Errors.
• Analogia: pense no Protocol Layer como o gerente experiente de um restaurante. Ele recebe seu pedido, sabe exatamente o que você quer, se espera uma resposta ou não, encaminha para a cozinha (Server) e depois traz a resposta formatada ou avisa se houve algum problema.

• Transport Layer (o entregador): essa camada é responsável por levar as mensagens de um ponto a outro. Ela não precisa entender o conteúdo da mensagem MCP, apenas garantir que ela chegue ao destino. Os meios de transporte mais comuns aqui são:
• stdio (Standard Input/Output): ideal para comunicação local, na mesma máquina. O Client "conversa" com o Server diretamente pela linha de comando (entrada e saída padrão). Super útil para ferramentas CLI ou quando Client e Server rodam juntinhos.
• HTTP/SSE (Server-Sent Events): a escolha para comunicação remota (rede). Usa o protocolo HTTP que amamos, mas com um tempero especial: SSE. Isso permite que o Server envie atualizações para o Client em tempo real, sem que o Client precise ficar perguntando ("polling"). É uma comunicação mais eficiente para notificações e eventos assíncronos do Server para o Client.
• Flexibilidade: o MCP também permite a criação de transportes customizados, caso você precise de algo muito específico (talvez WebSockets? gRPC? As possibilidades são abertas!).

Os 4 tipos de mensagem MCP:

1. Request: um pedido do Client para o Server executar algo. Sempre espera uma Result ou um Error.
• Exemplo (Conceitual): { "jsonrpc": "2.0", "id": 1, "method": "listProjectFiles", "params": { "projectId": "rocketseat-launch" } }

2. Result: a resposta positiva a um Request. Contém o resultado da operação.
• Exemplo (Conceitual): { "jsonrpc": "2.0", "id": 1, "result": { "files": ["launch.ts", "rocketseat.rs"] } }

3. Error: a resposta quando algo dá errado no processamento do Request. Contém código e mensagem de erro.
• Exemplo (Conceitual): { "jsonrpc": "2.0", "id": 1, "error": { "code": -32601, "message": "Project not found" } }

4. Notification: uma mensagem enviada em uma única direção (geralmente do Server para o Client, mas pode ser o contrário) que não espera resposta. Ideal para avisos, eventos ou atualizações.
• Exemplo (Conceitual): { "jsonrpc": "2.0", "method": "fileDidChange", "params": { "filePath": "rocketseat.rs" } }

Os superpoderes do MCP: construindo capacidades incríveis!

Resources: dando olhos e memória à IA

• O quê? São a forma padronizada de expor dados do seu sistema (código-fonte, logs, documentos, informações de um banco, etc.) para serem usados como contexto pela IA ou pelo usuário final.

• Como? Cada Resource é identificado por uma URI (Uniform Resource Identifier), tipo file:///app/src/user.ts ou db://products/sku/12345. O Server MCP implementa a lógica para:
• ListResources: informar quais Resources estão disponíveis.
• ReadResource: ler e entregar o conteúdo de um Resource específico quando solicitado.

• Por quê? Isso permite que a IA "enxergue" informações relevantes do mundo real de forma controlada. Ela pode ler um arquivo de código para te ajudar a refatorar, analisar um log para diagnosticar um erro, ou consultar dados de um produto para responder a um cliente.

• Exemplo prático (conceitual):

// No seu Server MCP (usando um exemplo de SDK hipotético)
// Handler para listar os logs disponíveis
server.setRequestHandler(ListResourcesRequestSchema, async () => {
  console.log(">> Client pediu a lista de Resources!");
  // Lógica para buscar os logs disponíveis (ex: últimos 5 arquivos de log)
  const availableLogs = await findAvailableLogFiles(); // Sua função
  return {
    resources: availableLogs.map(log => ({
      uri: `file:///var/log/${log.fileName}`, // URI única para cada log
      name: `Log: ${log.date}`, // Nome amigável
      mimeType: "text/plain"
    }))
  };
});

// Handler para ler o conteúdo de um log específico
server.setRequestHandler(ReadResourceRequestSchema, async (request) => {
  const uri = request.params.uri;
  console.log(`>> Client quer ler o Resource: ${uri}`);
  if (uri.startsWith("file:///var/log/")) {
    const fileName = uri.replace("file:///var/log/", "");
    try {
      const logContent = await readSpecificLogFile(fileName); // Sua função para ler o arquivo
      // Retorna o conteúdo como texto simples
      return { contents: [{ uri, mimeType: "text/plain", text: logContent }] };
    } catch (err) {
      throw new Error(`Erro ao ler o log ${fileName}`); // Ou um erro MCP
    }
  }
  throw new Error("Resource URI inválida");
});

Prompts: suas receitas de bolo para interações inteligentes

• O quê? São templates de prompt reutilizáveis e workflows de interação que você define no Server. O Client (ou a própria IA) pode então acioná-los pelo nome.

• Como? Um Prompt pode:
• Aceitar argumentos dinâmicos (ex: "gere um commit para essas mudanças").
• Incluir automaticamente o conteúdo de Resources relevantes no contexto.
• Encadear múltiplas perguntas ou passos para guiar o usuário ou a IA.
• O Server implementa ListPrompts e GetPrompt (que pega os argumentos, busca os Resources se necessário, monta a mensagem final e a envia para a LLM).

• Por quê? Padroniza interações frequentes, garante a qualidade e o contexto dos prompts enviados à LLM, e permite criar experiências guiadas mais complexas de forma estruturada. É como ter suas "receitas" de interação com a IA prontas para usar!

• Exemplo prático (conceitual):

// No seu Server MCP (usando um exemplo de SDK hipotético)
// Handler para retornar um prompt específico formatado
server.setRequestHandler(GetPromptRequestSchema, async (request) => {
  const promptName = request.params.name;
  console.log(`>> Client pediu para usar o Prompt: ${promptName}`);

  if (promptName === "explainCode" && request.params.arguments?.codeUri) {
    const codeUri = request.params.arguments.codeUri;
    // 1. Usa o ReadResource internamente para buscar o código
    const codeResource = await server.internalReadResource(codeUri); // Função interna do SDK/Server
    const codeText = codeResource.contents[0].text;
    const language = request.params.arguments.language || "desconhecida";

    // 2. Monta a mensagem final para a LLM, incluindo o código
    return {
      messages: [{
        role: "user",
        content: { type: "text", text: `Por favor, explique este trecho de código em ${language}:\n\n\`\`\`\n${codeText}\n\`\`\`` }
      }]
    };
  }
  // ... outros prompts ...
  throw new Error("Prompt não encontrado ou argumentos inválidos");
});

Tools: dando mãos e ferramentas à IA

• O quê? São a forma de permitir que a IA execute ações no mundo real através do seu Server. É aqui que a IA deixa de ser só um cérebro e ganha "mãos" para agir.

• Como?
• O Server declara as Tools que oferece usando ListTools, descrevendo o que cada uma faz e quais parâmetros (inputs) ela espera (usando um schema JSON).
• Quando a IA decide que precisa usar uma ferramenta para cumprir uma tarefa, ela envia um CallToolRequest para o Server.
• O Server executa a lógica da ferramenta (chama uma API, atualiza um banco, etc.) e retorna o resultado para a IA.

• Por quê? Isso transforma a IA num agente poderoso! Ela pode calcular impostos, agendar reuniões, enviar e-mails, fazer deploy de uma aplicação, controlar dispositivos IoT... As possibilidades são imensas! É o equivalente padronizado pelo MCP aos famosos "Plugins" ou "Function Calling" das LLMs.

• Exemplo Prático (Conceitual em TypeScript):

// No seu Server MCP (usando um exemplo de SDK hipotético)
// Handler para listar as tools disponíveis para a IA
server.setRequestHandler(ListToolsRequestSchema, async () => {
  console.log(">> Client (IA) pediu a lista de Tools!");
  return {
    tools: [{
      name: "scheduleMeeting",
      description: "Agenda uma reunião no calendário.",
      inputSchema: { // Define os parâmetros esperados
        type: "object",
        properties: {
          attendees: { type: "array", items: { type: "string" }, description: "Emails dos participantes" },
          startTime: { type: "string", format: "date-time", description: "Início da reunião (ISO 8601)" },
          durationMinutes: { type: "number", description: "Duração em minutos" }
        },
        required: ["attendees", "startTime"]
      }
    }]
  };
});

// Handler para executar a tool quando a IA chamar
server.setRequestHandler(CallToolRequestSchema, async (request) => {
  const toolName = request.params.name;
  console.log(`>> Client (IA) quer executar a Tool: ${toolName}`);

  if (toolName === "scheduleMeeting") {
    const args = request.params.arguments;
    try {
      // Lógica REAL para chamar a API de calendário
      const meetingResult = await callCalendarAPI(args.attendees, args.startTime, args.durationMinutes);
      // Retorna um texto simples confirmando para a IA
      return { content: [{ type: "text", text: `Reunião agendada com sucesso! ID: ${meetingResult.id}` }] };
    } catch (err) {
      // Informa a IA que deu erro
      return { content: [{ type: "text", text: `Falha ao agendar reunião: ${err.message}` }] };
      // Ou poderia retornar um erro MCP estruturado
    }
  }
  throw new Error("Tool não encontrada");
});

Decolando com MCP: pronto para construir o futuro?

FAQ (perguntas mais frequentes):

Conclusão: seu mapa inicial para o universo MCP