Kollabe
Retrospectivas
Poker de Planejamento
Standups
Quebra-gelos
Preços
Painel de Controle

Postagens

O que é MCP? O model context protocol explicado para times ágeis

Ilustração editorial moderna de um desenvolvedor em um laptop com linhas de conexão translúcidas saindo de uma janela de chat até ícones estilizados de um quadro de backlog, um baralho de planning poker e um quadro de retro, representando um assistente de IA orquestrando ferramentas reais ao longo de um fluxo de sprint
Kelly Lewandowski

Kelly Lewandowski

Última atualização 27/04/20269 min de leitura

Se você usou Claude, Cursor ou ChatGPT nos últimos meses, provavelmente viu o MCP aparecer no painel de configurações sem muita explicação. A Anthropic publicou a spec no fim de 2024, os principais assistentes de código lançaram suporte ao longo de 2025 e, no começo de 2026, toda ferramenta SaaS com uma API está correndo para publicar um servidor MCP. Em resumo: MCP é como um assistente de IA deixa de ser um chatbot e passa a ser um colega de time que faz trabalho de verdade nas suas ferramentas. Para times ágeis que já vivem o dia inteiro dentro do Jira, GitHub, Linear e Slack, essa mudança é maior do que parece.

O que o MCP é de fato

O Model Context Protocol (MCP) é um padrão aberto, originalmente publicado pela Anthropic, que define como um assistente de IA conversa com um sistema externo. Em vez de cada fornecedor de IA construir uma integração própria com cada ferramenta SaaS, a ferramenta publica um único servidor MCP e qualquer cliente compatível pode usá-lo. Pense nele como o USB-C das ferramentas de IA. O host (Claude Desktop, Cursor, ChatGPT, sua IDE) fala o mesmo protocolo com qualquer servidor MCP para o qual seja apontado, do mesmo jeito que qualquer cabo USB-C funciona em qualquer porta USB-C.
Servidor MCP
Um programa (geralmente rodado pelo fornecedor SaaS) que expõe uma lista de ferramentas que uma IA pode chamar, além da auth e do transporte para chamá-las.
Cliente MCP
O app de IA que consome o servidor. Claude Desktop, Cursor, Zed, ChatGPT e Claude Code já trazem clientes MCP hoje.
Tool
Uma única ação nomeada com um schema JSON. Coisas como retro_create_item, planning_poker_cast_vote ou standup_submit_answers.
Recurso
Um pedaço de contexto que o servidor pode devolver, como um arquivo, um quadro ou um resumo de sprint. O modelo pode ler esses dados sem executar nenhuma ação.
Quando o usuário envia um prompt para o assistente, o modelo decide quais tools chamar, o cliente faz essas chamadas via MCP, o servidor as executa contra a API por baixo, e os resultados voltam para a conversa. O usuário vê uma única resposta. Por trás, aconteceram de uma a algumas dezenas de chamadas de tools.

Como o MCP é diferente de uma REST API ou de um webhook

Ferramentas ágeis têm REST APIs e webhooks há mais de uma década. Então por que o MCP precisa existir? A resposta é que REST APIs e webhooks foram feitos para desenvolvedores, não para modelos. Eles esperam que um humano leia a documentação, decida o que chamar, escreva o código e faça o deploy. O MCP é construído para que uma IA descubra e use uma ferramenta em tempo de execução, sem ninguém escrever código de integração antes. Ilustração editorial comparando três abordagens em três faixas verticais: um desenvolvedor digitando código rotulado como REST API, uma seta automatizada disparando em um evento rotulada como webhook, e uma interface de chat onde uma IA seleciona ferramentas de um menu rotulada como MCP, tudo renderizado em cores vibrantes e planas
AspectoREST APIWebhookMCP
DireçãoVocê chamaEle chama vocêO modelo chama em seu nome
Quem escreve a integraçãoUm dev, com antecedênciaUm dev, com antecedênciaO modelo, em tempo de execução, a partir de uma lista de tools
DescobertaLer a documentaçãoLer a documentaçãoO servidor retorna uma lista tipada de tools
Modelo de authAPI keys, OAuthPayloads assinadosOAuth 2.1 + PKCE + Dynamic Client Registration
Melhor paraApps e scriptsReagir a eventosFluxos conversacionais e de agentes
Um webhook é push. Uma REST API é pull. MCP é o modelo pegando o telefone, perguntando "o que você pode fazer por mim agora?" e fazendo só as chamadas que ele precisa para esse prompt específico. A outra coisa que importa é que ele retorna definições tipadas das tools, então o modelo sabe quais argumentos são obrigatórios, quais são opcionais e como será a resposta. Sem mais chutes a partir de uma página de documentação.

O fluxo de auth: OAuth 2.1, PKCE e DCR em português claro

Essa é a parte que a maioria das pessoas pula, e é a parte que de fato torna o MCP utilizável dentro de uma empresa. Quatro peças se encaixam, e cada uma resolve um problema específico.
  1. Dynamic Client Registration (DCR, RFC 7591)
    O OAuth tradicional exigia que cada cliente fosse pré-registrado na mão: um dev entra no painel de admin do SaaS, preenche um formulário, copia um client ID e secret, e cola em algum lugar. Isso não escala quando "o cliente" é toda instalação do Claude no mundo. O DCR deixa o cliente MCP se apresentar ao servidor de forma programática ("Sou o Claude Desktop no laptop deste usuário, aqui está a minha redirect URI") e o servidor devolve um client ID novo. Sem envolvimento de admin.
  2. Fluxo authorization code do OAuth 2.1
    Uma vez com um client ID, o assistente abre seu navegador, redireciona para a página de login do provedor SaaS e pede que você aprove a conexão. É o mesmo fluxo que você usa no "Sign in with Google" em um site de terceiros. Você vê exatamente qual organização está conectando e quais escopos (leitura, escrita) o assistente está pedindo. O provedor SaaS devolve um authorization code, que o cliente troca por um access token.
  3. PKCE (Proof Key for Code Exchange)
    O PKCE impede que o authorization code seja roubado no meio do caminho. O cliente gera um secret de uso único, faz um hash com SHA-256 e envia o hash logo no início. Quando ele depois resgata o code, precisa enviar o secret original. Um atacante que intercepta o code não consegue resgatá-lo sem aquele secret. A spec do MCP exige PKCE com o método S256, sem fallback para variantes mais fracas.
  4. Resource indicators (RFC 8707)
    A spec do MCP de 2026 também exige que o cliente nomeie o servidor específico que ele pretende chamar quando solicita um token. Isso evita que um token emitido para um servidor MCP seja replayed contra outro. O token fica vinculado a uma única audience.
O resultado, do ponto de vista do usuário, é um clique no navegador. Do ponto de vista do time de segurança, é OAuth feito direito: por usuário, com escopo, vinculado a uma audience, revogável e sem secrets compartilhados parados em arquivos de config.

Por que times ágeis em particular deveriam se importar

A maior parte da cobertura inicial do MCP foca em desenvolvedores usando IA para ler código ou consultar bancos de dados. Isso subestima o protocolo. Times ágeis estão em um ponto único: muito da preparação das suas reuniões é agregar contexto de cinco ferramentas (PRs, tickets, incidentes, releases, feedback de cliente) e depois escrever isso em uma única ferramenta (o standup, o quadro de retro, a sala de planning poker). Esse é exatamente o tipo de trabalho em que o MCP é bom.
🌅Standups que se escrevem sozinhos

Seu assistente puxa os PRs e a movimentação de tickets de ontem das suas ferramentas de dev, formata as suas três respostas e submete no standup de hoje antes de você abrir o Slack.

🃏Planning poker direto do backlog

"Pegue os próximos 10 tickets sem estimativa, abra uma sala de planning poker chamada Sprint 47 e adicione cada ticket como uma rodada." Um prompt, sala da sprint pronta.

🪞Retros pré-populadas com dados reais

Entre na retro com os incidentes, releases e relatos de cliente desta sprint já no quadro, agrupados por coluna. O time discute, em vez de transcrever.

✅Action items com contexto

O assistente transforma a discussão da retro em action items, atribui responsáveis e linka cada um de volta ao thread ou ticket de origem. Sem imposto de copy-paste.

A mudança mais profunda é que o papel de scrum master começa a ficar diferente. Boa parte do encanamento das reuniões (coletar updates, achar atrasados, resumir a sprint passada) é trabalho que uma IA consegue fazer de forma confiável dado o conjunto certo de tools. O tempo humano volta para as conversas que de fato precisam de um humano: facilitar a retro difícil, fazer coaching do time num impedimento recorrente, ajudar alguém recém-chegado a escrever histórias melhores. Para mais sobre como isso aparece na prática, veja o nosso texto sobre agentes de IA mudando como estimamos e refinamento de backlog assistido por IA.

O que dá para fazer hoje, na prática

Os clientes que suportam MCP atualmente são Claude Desktop, Claude Code, Cursor, Zed, ChatGPT e uma lista crescente de frameworks de agentes. Do lado dos servidores, GitHub, Linear, Sentry, PagerDuty, Notion, Slack, Atlassian e a maioria das ferramentas SaaS modernas ou já lançam um servidor MCP ou têm um em beta. Ilustração editorial de um quadro de sprint flutuando em primeiro plano com balões de chat estilizados fluindo para ele a partir da esquerda, cada balão carregando um pequeno ícone de código, ticket, incidente ou mensagem, com cores vibrantes e planas em um fundo gradiente suave A Kollabe também lança um servidor MCP. Conecte ao seu cliente de IA preferido e você ganha o conjunto completo de tools de standup, retro, planning poker e action item, com o mesmo modelo de auth descrito acima, com escopo para uma organização, e revogação em um clique se mudar de ideia. Tudo isso fica em kollabe.com/mcp, junto de snippets de configuração prontos para copiar e colar para cada cliente. Se você prefere construir algo mais sob medida do que uma sessão de chat, os mesmos endpoints estão expostos pela REST API pública da Kollabe usando personal access tokens. Mesmo modelo de auth, mesmas estruturas, sem necessidade de cliente MCP. Útil para uma Claude Skill que roda o formato exato do standup do seu time, um job de CI que abre uma sala de planning poker quando uma sprint começa, ou um cron que fecha uma retro toda sexta sim, sexta não.

Um ponto de partida razoável

Se o seu time ainda não mexeu com MCP, a porta de entrada com menor risco é escolher um ritual que você acha chato e conectar um servidor MCP. Standups costumam ser a primeira vitória porque o valor fica óbvio em uma única manhã. A partir daí, a sprint seguinte costuma achar um segundo caso de uso sozinha. Experimente o nosso gerador de templates de retrospectiva como um ponto de partida sem MCP se quiser ver como a IA se encaixa em rituais ágeis antes de plugar um servidor, e depois volte para este post quando estiver pronto para conectar um assistente às suas ferramentas reais.

Não. A Anthropic publicou a spec, mas ela é aberta. OpenAI, Google e vários clientes open-source a implementam, e qualquer modelo pode ficar atrás de um cliente compatível. O protocolo não se importa com qual modelo está do outro lado.

Para usar, não. Conectar um servidor MCP ao Claude Desktop ou Cursor é alguns cliques nas configurações mais uma aprovação OAuth. Para construir um servidor, sim; essa parte ainda é território de dev, mas a maioria dos times só vai consumir os servidores que os fornecedores publicarem.

Function calling é uma feature de um modelo. Os plugins do ChatGPT eram específicos da OpenAI. MCP é um padrão de transporte e auth que qualquer modelo e qualquer ferramenta podem implementar, então um servidor que você publica uma vez funciona em todo cliente compatível. A interoperabilidade é o ponto.

Continuam funcionando. O MCP geralmente fica em cima da mesma API interna que o seu app web já usa. Você não está migrando nada; está expondo uma nova superfície para clientes de IA enquanto seus dashboards e scripts seguem chamando a API do mesmo jeito.

Com OAuth 2.1, PKCE, tokens com escopo e um caminho claro de revogação, a postura de segurança é a mesma de conectar qualquer app de terceiro. O risco maior é prompt ruim, não design ruim de protocolo. Comece com escopos somente leitura, observe o que o assistente faz por uma sprint e libere acesso de escrita quando confiar no fluxo.