Pular para o conteúdo principal

Como adicionar servidores MCP

Pela linha de comando

A maneira mais rápida de adicionar um servidor MCP:
O tipo de transporte é inferido automaticamente: uma URL implica HTTP (Streamable HTTP), e argumentos no final (ou --command) implicam stdio.
Servidores MCP remotos usam Streamable HTTP por padrão. Se o servidor responder com um erro HTTP 4xx, a CLI recorre a SSE na mesma URL. Defina "transport": "sse" explicitamente, se necessário — veja fallback legado para SSE abaixo.
Por padrão, os servidores são salvos no escopo local (.devin/config.local.json, ignorado pelo git). Use -s/--scope para alterar:
Você também pode gerenciar servidores pela linha de comando:

Via arquivo de configuração

Adicione servidores diretamente à seção mcpServers do seu arquivo de configuração:
Os servidores no nível do projeto são compartilhados com sua equipe por meio do controle de versão.

Opções de configuração de servidor

Os servidores MCP podem ser configurados de duas formas: como um comando local (transporte stdio) ou como um servidor remoto (transporte HTTP).

Comando local (stdio)

Servidor remoto (Streamable HTTP)

Exemplos

Depois de adicionar um servidor com OAuth, execute devin mcp login notion para se autenticar. Consulte Autenticação abaixo.
Depois de adicionar, execute devin mcp login atlassian para se autenticar. Cada cliente MCP (Windsurf, Claude Code, Devin CLI) mantém sua própria sessão OAuth, então você precisa fazer login separadamente, mesmo que já tenha se autenticado em outra ferramenta.

Autenticação

Alguns servidores MCP remotos exigem autenticação OAuth. Depois de adicionar um servidor com autenticação OAuth à sua configuração, autentique-se usando o comando login:
Por exemplo:
Isso abre uma janela do navegador na qual você pode autorizar o acesso. Os tokens OAuth são armazenados localmente e atualizados automaticamente. Se quiser, você pode solicitar escopos específicos do OAuth:
Para remover credenciais OAuth armazenadas para um servidor:
Se o servidor oferecer suporte a OAuth, você também receberá automaticamente uma solicitação para se autenticar quando o servidor for usado pela primeira vez.

Clientes OAuth pré-registrados

A maioria dos servidores MCP baseados em OAuth oferece suporte ao registro dinâmico de clientes (DCR), então o Devin CLI se registra automaticamente e você não precisa fornecer nenhuma credencial de cliente. Alguns provedores (por exemplo, GitHub) não oferecem suporte a DCR e, em vez disso, exigem um cliente OAuth pré-registrado. Nesses casos, informe o ID do cliente — e o client secret, se for um cliente confidencial — por meio de oauthClientId / oauthClientSecret:
Quando oauthClientId é definido, o Devin CLI não faz o registro dinâmico do cliente e usa o cliente pré-registrado por você durante o fluxo do OAuth. Execute devin mcp login <name> (ou acione o primeiro uso) para se autenticar normalmente. Você também pode defini-los pela linha de comando ao adicionar um servidor ou fazer login nele:
oauthClientId / oauthClientSecret são credenciais de cliente OAuth usadas durante o fluxo de autorização. Não são credenciais genéricas para cada requisição — se um servidor espera um token estático, use headers (HTTP) ou env (stdio).
Não faça commit de um client secret em uma configuração compartilhada. Referencie-o a partir de uma variável de ambiente (${env:VAR}), leia-o de um arquivo (${file:/path}) ou coloque-o em .devin/config.local.json (incluído no .gitignore). Consulte a seção “Gerenciando segredos” abaixo.

Override do recurso OAuth

Durante a autorização OAuth e a troca de tokens, o Devin CLI envia um parâmetro resource da RFC 8707 para que o servidor de autorização possa emitir tokens restritos à audiência. Por padrão, o valor é a URL do servidor MCP. Para substituí-lo, use oauthResource:
O campo tem três comportamentos:
  • Não definido (padrão): envia resource com a URL do servidor MCP.
  • Valor não vazio: substitui o padrão pelo valor especificado (por exemplo, um URI de ID de app específico).
  • String vazia (""): omite totalmente o parâmetro resource tanto da URL de autorização quanto da troca de token.
Você também pode defini-lo pela linha de comando ao adicionar ou fazer login em um servidor:
Assim como outros campos do OAuth, oauthResource oferece suporte à expansão de ${env:VAR} e ${file:/path}.

Ativando e desativando servidores

Você pode desativar temporariamente um servidor MCP sem remover sua configuração. Um servidor desativado é ignorado durante a descoberta de ferramentas — suas ferramentas não aparecerão, e o processo do servidor não será iniciado.
Isso define a flag "disabled": true na entrada do servidor no arquivo de configuração. Use -s/--scope para selecionar um escopo específico:
Também é possível definir a flag diretamente no arquivo de configuração:
Desabilitar é útil quando você quer manter a configuração de um servidor (incluindo variáveis de ambiente e credenciais OAuth), mas deixar de usá-lo temporariamente — por exemplo, para reduzir o tempo de inicialização ou isolar um problema.

Gerenciando segredos

Nunca faça commit de Chaves de API ou segredos no controle de versão. Use .devin/config.local.json para armazenar valores sensíveis.
Para projetos em equipe, o padrão recomendado é:
  1. Defina o servidor em .devin/config.json com marcadores de posição ou sem variáveis de ambiente
  2. Cada membro da equipe adiciona suas chaves pessoais em .devin/config.local.json
O arquivo de configuração local é automaticamente excluído do Git.

Permissões do MCP

Você pode aprovar previamente, negar ou exigir confirmação para ferramentas específicas do MCP na sua configuração de permissões:
Padrões de correspondência de permissão:

Restrições da organização

Se você faz parte de uma equipe Enterprise, seu administrador pode restringir a quais servidores MCP você pode se conectar. Um servidor que você configurou pode ser bloqueado se o MCP estiver desativado para a sua equipe ou se ele não estiver na lista de permissões da equipe nem em um registro de MCP aplicado — nesse caso, ele não se conectará e suas ferramentas não ficarão disponíveis. Consulte Configurações da equipe — registro de MCP para mais detalhes.

Solução de problemas

Se você vir erros como Auth required ou AuthRequired ao se conectar a um servidor MCP remoto, isso significa que o servidor exige autenticação OAuth.Execute:
Cada cliente MCP se autentica de forma independente. Mesmo que você já tenha se autenticado no Windsurf ou no Claude Code, é preciso executar devin mcp login separadamente no Devin CLI.Para verificar seu status de autenticação, tente remover e adicionar as credenciais novamente:
Verifique se o comando funciona fora do Devin CLI:
Confira se todas as variáveis de ambiente obrigatórias estão definidas.
Peça ao agente para listar os servidores MCP e as ferramentas. O servidor pode precisar de alguns instantes para inicializar.
Verifique a configuração das suas permissões. Por padrão, as ferramentas MCP pedem aprovação. Adicione-as a permissions.allow para aprová-las automaticamente.
Alguns servidores de autorização rejeitam requisições OAuth que incluem o parâmetro resource da RFC 8707. Defina oauthResource como uma string vazia para omitir o parâmetro:
Em seguida, autentique-se novamente:
Consulte override do recurso OAuth para ver o conjunto completo de comportamentos de oauthResource.
Ao se conectar a um servidor HTTP, o Devin CLI tenta primeiro Streamable HTTP. Se o servidor responder com um erro HTTP 4xx (por exemplo, 404 ou 405), ele recorre automaticamente a SSE legado na mesma URL configurada. Isso segue a orientação de retrocompatibilidade da spec do MCP.O fallback só é acionado em respostas 4xx — erros de conexão, timeouts e respostas 5xx são reportados diretamente, sem tentativa de SSE.Se o endpoint de SSE do seu servidor estiver em um caminho diferente (por exemplo, /sse em vez de /mcp), defina "transport": "sse" com a URL de SSE para se conectar diretamente, sem tentar Streamable HTTP antes.Se ambos os transportes falharem, a mensagem de erro incluirá detalhes das duas tentativas para ajudar na solução de problemas.