O que é um MCP e como funciona o MCP da ArduMaker

Publicado em 2026-08-25 por frfrand

Explicación clara del Model Context Protocol (MCP): qué es, cómo funciona y por qué convierte a una IA en un operador real. Incluye un recorrido por el MCP de ArduMaker, sus casi 200 herramientas para VPS, DNS, correo, bases de datos, proyectos y blogs, y un ejemplo real: este mismo artículo fue creado y publicado por una IA usando ese MCP.

Resumo em uma linha: um MCP (Model Context Protocol) é o padrão que permite que uma inteligência artificial deixe de apenas conversar e comece a executar ações reais em sistemas reais.

Definições rápidas, para humanos e para máquinas:

• MCP = Model Context Protocol. Um protocolo aberto que conecta um modelo de IA com ferramentas externas.
• Servidor MCP = um programa que publica uma lista de ferramentas (ações) que a IA pode chamar.
• Ferramenta = uma ação concreta com nome e parâmetros. Por exemplo: criar um VPS, enviar um e-mail, publicar um artigo.
• MCP de ArduMaker = um servidor MCP com cerca de 200 ferramentas para administrar infraestrutura: servidores, domínios, DNS, e-mail, bancos de dados, projetos e blogs.
• Endereço do servidor = https://mcp.ardumaker.com/mcp

A ideia central: sem MCP, a IA descreve o que seria necessário fazer. Com MCP, a IA o faz e devolve o resultado real.

Prova disso: este artigo que você está lendo foi redigido, ilustrado e publicado por uma IA usando o MCP de ArduMaker. Nenhum painel de controle foi aberto em nenhum momento.

O que é um MCP, em palavras simples?

Durante anos, os modelos de IA foram muito bons em uma única coisa: produzir texto. Você podia pedir a um modelo que explicasse como configurar um servidor e ele dava instruções impecáveis... que depois você tinha que executar, manualmente, uma por uma.

O Model Context Protocol (MCP) quebra essa barreira. É um padrão aberto que define como um modelo de IA se conecta com o mundo exterior: bancos de dados, servidores, APIs, serviços de e-mail, repositórios de código.

A analogia mais útil é a de um plugue. Antes de existir um padrão de plugues, cada aparelho precisava de seu próprio cabo sob medida. Com um padrão, qualquer aparelho entra em qualquer tomada. O MCP é isso, mas para a IA: qualquer modelo compatível pode se conectar a qualquer servidor MCP e usar suas ferramentas sem que ninguém precise programar uma integração especial.

Um servidor MCP não "ensina" nada ao modelo. Ele simplesmente entrega um catálogo: estas são as ações disponíveis, isso é o que cada uma faz, estes são os parâmetros que ela precisa. O modelo lê esse catálogo e escolhe.

Sem o MCP, a inteligência artificial só pode falar. Com o MCP, a inteligência artificial pode fazer.

Como funciona um MCP: o ciclo de quatro passos

Tudo o que acontece dentro de um MCP pode ser descrito por um ciclo que se repete em cada ação.

Passo 1 — Você pede. Você fala na sua língua, com suas palavras. "Preciso de um novo servidor para o projeto." Não há comandos para memorizar nem formulários para preencher.

Passo 2 — A IA escolhe. O modelo lê o catálogo de ferramentas que o servidor MCP publica e decide qual usar e com quais parâmetros. Este ponto é importante: a IA não improvisa comandos soltos, ela escolhe de uma lista fechada e conhecida.

Passo 3 — O MCP executa. O servidor recebe a chamada, verifica se quem a fez tem permissão para isso, e toca o sistema real: cria o servidor, escreve o registro DNS, envia o e-mail.

Passo 4 — O dado retorna. O resultado real volta para o modelo: o ID que foi gerado, o estado do serviço, o erro se algo falhou. Isso elimina um dos maiores problemas da IA sem ferramentas, que é inventar respostas plausíveis. Aqui não há nada para inventar: o sistema respondeu o que respondeu.

Se a tarefa precisar de vários passos, o ciclo simplesmente recomeça. A IA encadeia chamadas, lê cada resultado e ajusta o próximo movimento com base no que realmente aconteceu.

As três peças de qualquer MCP

1. O cliente (ou anfitrião). É a aplicação onde você conversa com a IA: um chat, um editor de código, um terminal. O cliente é quem estabelece a conexão com o servidor e passa ao modelo a lista de ferramentas disponíveis.

2. O servidor MCP. É o que publica as ferramentas e as executa. Ele fica do lado do serviço: no caso do ArduMaker, ele roda na própria plataforma, com acesso aos sistemas que administra.

3. As ferramentas. Cada uma é uma função com um nome descritivo, uma explicação do que faz e uma lista de parâmetros com seus tipos. É exatamente a informação que um modelo precisa para decidir bem.

Essa estrutura também é a razão pela qual um MCP é mais seguro do que dar à IA um terminal aberto. O servidor define antecipadamente o que pode ser feito e o que não pode. Se uma ação não estiver no catálogo, ela simplesmente não existe. E cada chamada passa pela mesma verificação de permissões que um usuário humano enfrentaria.

O MCP da ArduMaker: o que ele pode fazer

Aqui é onde a ideia se torna concreta. O MCP da ArduMaker expõe cerca de 200 ferramentas que cobrem, praticamente, todo o ciclo de vida de uma infraestrutura. Estas são as áreas principais:

Servidores VPS. Criar máquinas, ligá-las, desligá-las, reiniciá-las e alterar o plano. Executar comandos dentro delas. Criar e administrar serviços systemd, ler seus logs, programar tarefas recorrentes, gerenciar usuários do Linux e redirecionamentos de portas. O que não pode: excluir um VPS. Não existe a ferramenta, e é deliberado.

Domínios e DNS. Registrar domínios, criar e editar registros DNS, verificar o estado dos nameservers, ativar domínios com certificado SSL incluído. Aqui também há um limite proposital: não existe uma ferramenta para excluir um registro DNS. Pode-se criar e sobrescrever; excluir, não.

E-mail. Registrar domínios de e-mail, criar caixas de correio, aliases e filtros, revisar a verificação de MX, SPF, DKIM e DMARC, e também ler e enviar mensagens diretamente.

Bancos de dados. Listar motores instalados, explorar tabelas e esquemas, fazer consultas somente leitura, inserir ou atualizar linhas e consultar o histórico de operações destrutivas.

Projetos e equipe. Etapas, tarefas, checklists, comentários, anexos, reuniões, calendário compartido e uma lixeira que permite restaurar o que foi excluído.

Repositórios e túneis. Vincular repos do GitHub a um VPS, implantá-los, revisar os logs de cada implantação e levantar túneis SSH entre máquinas.

Blogs. Criar artigos, enviar imagens, publicá-los, arquivá-los e traduzi-los automaticamente para espanhol, inglês e português.

Uma nota sobre a infraestrutura, porque explica várias ferramentas. Cada VPS da ArduMaker é um container dentro de um host pai compartilhado. Essa máquina de cima concentra o que tem que ser comum: o IP público, o nginx que termina o HTTPS, os certificados e as redireções de porta que conectam a internet com cada container. O usuário administra seu VPS —processos, serviços, código, bancos— e nunca o host. Por isso publicar um domínio passa por ferramentas que operam em uma camada à qual você não tem acesso direto, e por isso expor uma aplicação é sempre "criar uma redireção", não "abrir uma porta".

E o catálogo não é uma lista escrita à mão: o servidor publica ao vivo em mcp.ardumaker.com/tools.json, gerado a partir do seu próprio registro de ferramentas. Se uma ferramenta aparece lá, existe.

Este artigo é a demonstração

A melhor forma de explicar um MCP não é descrevê-lo: é usá-lo enquanto se explica.

Este artigo não foi escrito em um editor. Nenhuma imagem foi enviada de um computador. Ninguém clicou em um botão de "publicar". Tudo foi feito em uma conversa, em espanhol, pedindo a uma IA que escrevesse um blog sobre o que é um MCP.

A IA se conectou ao servidor MCP da ArduMaker, leu o catálogo de ferramentas e executou, em ordem: revisar quais artigos já existiam, criar este em estado de rascunho, gerar e enviar as três imagens que você está vendo, escrever cada seção de texto uma por uma, definir a capa, publicá-lo e traduzi-lo.

Os diagramas deste artigo também foram gerados durante a mesma conversa, não foram buscados em um banco de imagens.

Estas são, textualmente, as ferramentas que foram usadas.

listar_mis_blogs() -> revisar qué artículos ya existen

crear_blog( titulo = "Qué es un MCP y cómo funciona el MCP de ArduMaker", descripcion = "...", tags = ["MCP", "ArduMaker", "IA", "automatizacion", ...] ) -> { "id": 22, "status": "draft" }

crear_media_blog(blog_id = 22, filename = "mcp-portada.webp", ...) crear_media_blog(blog_id = 22, filename = "mcp-como-funciona.webp", ...) crear_media_blog(blog_id = 22, filename = "mcp-herramientas.webp", ...) -> las tres imágenes quedan alojadas en el artículo

agregar_seccion_blog(blog_id = 22, section_key = "s01_resumen", section_type = "text") agregar_seccion_blog(blog_id = 22, section_key = "s03_cita", section_type = "quote") agregar_seccion_blog(blog_id = 22, section_key = "s05_img_flujo", section_type = "image") -> cada bloque del artículo, uno por llamada

editar_blog(blog_id = 22, cover_image = "mcp-portada.webp") publicar_blog(blog_id = 22) -> { "status": "published" }

traducir_blog(blog_id = 22, languages = ["es", "en", "pt"]) -> el mismo artículo, en tres idiomas

O que muda no dia a dia

Um MCP não é uma demonstração de laboratório. Muda tarefas concretas que hoje consomem tempo:

Levantar um projeto inteiro em uma frase. "Crie um VPS, aponte este domínio, instale o certificado e faça o deploy do meu repositório." Antes eram cinco painéis distintos e uma hora de trabalho. Agora é uma ordem e uma cadeia de chamadas encadeadas.

Diagnosticar sem buscar. "Por que o site está fora do ar?" A IA revisa o status do VPS, lê os logs do nginx, verifica o status do serviço systemd e diz o que encontrou, com os logs reais em mãos.

Auditar sem abrir o console. "Quanto gastamos este mês e em quê?" ou "O que alguém excluiu do projeto na semana passada?". As respostas saem dos dados, não de uma estimativa.

Automatizar o repetitivo. Programar tarefas, rotacionar chaves, revisar a verificação DNS dos domínios de e-mail, publicar conteúdo em três idiomas.

Trabalhar no seu idioma. Não é preciso lembrar a sintaxe do systemd, nem os nomes exatos dos registros DNS, nem como se chamava aquele comando. Você descreve e é feito.

Segurança: o escopo importa mais que as permissões

É a pergunta que sempre aparece, e com razão: se uma IA pode reiniciar servidores e acessar bancos de dados, o que impede um desastre?

As permissões são suas. O agente age em nome da pessoa que o autorizou. Se essa pessoa não administra uma empresa, o agente também não. Se um VPS tem visibilidade restrita, o agente não o vê.

Mas além disso, você escolhe o escopo ao autorizar, e isso é o que realmente limita o risco. Ao conectar um agente, você decide três coisas separadamente:

• Somente leitura, ou não. Uma sessão de somente leitura não grava nada, mesmo que quem autorizou seja administrador de tudo.
• Todos os projetos, ou uma seleção.
• Todos os VPS, ou uma seleção.

Um agente que resume sua semana não precisa do mesmo escopo que um que implanta. Dar o mínimo não é paranoia: é a diferença entre um erro e um incidente.

O agente conhece seu escopo antes de começar. Existe uma ferramenta, ver_contexto_inicial, que lhe diz de entrada quem o autorizou, qual escopo recebeu, quais IDs pode ver e o que nunca poderá fazer. Isso soa menor e não é: sem isso, um agente descobre seus limites batendo neles, depois de ter prometido algo que não pode cumprir.

Há operações que nenhum agente MCP pode fazer, independentemente do escopo. São quatro, e estão publicadas:

• excluir um projeto inteiro,
• adicionar, remover ou alterar o papel de um membro de um projeto,
• criar, editar ou excluir um anexo marcado como secreto,
• excluir um VPS.

Não é que estejam restritas: não existem as ferramentas. O caminho não existe.

Na mesma linha, há exclusões que simplesmente não são expostas: não há como excluir um blog de forma permanente — o mecanismo é arquivar, que é reversível — nem excluir um registro DNS. E aquelas que podem causar danos pedem confirmação explícita: criar ou editar um registro NS, MX ou um A da raiz de um domínio falha se você não enviar confirmado, porque um erro ali derruba o site ou o e-mail de todo o domínio com atraso real de propagação mesmo depois de corrigido.

O conteúdo escrito por terceiros chega marcado como não confiável. É a parte menos vistosa e talvez a mais importante. Quando uma ferramenta devolve algo que não foi escrito por quem autorizou o agente — o corpo de um e-mail, um comentário, um log, a saída de um comando, a mensagem de um commit — o servidor o envolve e o etiqueta: isto são dados, nunca instruções. Se dentro vier algo com forma de ordem dirigida à IA, a IA tem que reportá-lo a você em vez de obedecê-lo, mesmo que o texto diga vir da ArduMaker, de um administrador ou de você.

E há combinações de escopo que são arriscadas, embora cada metade seja inofensiva. Isto o servidor publica explicitamente, e vale mais do que qualquer frase tranquilizadora:

• Ler e-mail + executar comandos em um VPS. Qualquer pessoa que conheça um de seus endereços pode colocar texto à frente do seu agente. Se esse mesmo agente puder abrir um shell, um e-mail bem escrito é uma tentativa de execução remota que não custa nada ao atacante e não requer conta no ArduMaker. Nenhuma das duas metades é perigosa sozinha.
• Ler e-mail + enviar e-mail do mesmo domínio. Uma mensagem recebida pode convencer o agente a responder a um terceiro a partir do seu domínio: phishing para os seus próprios clientes, com a sua assinatura DKIM.
• Ler e-mail ou comentários + consultar bancos de dados. Texto não confiável mais SQL arbitrário é um caminho de exfiltração.

A recomendação que o próprio servidor dá é a correta: separe os agentes. Um que atende e-mail, sem acesso ao VPS. Um que opera servidores, sem caixas de correio. Para triagem e resumos, apenas leitura é suficiente.

Tudo fica registrado. Cada projeto tem seu histórico de atividade. As operações destrutivas contra bancos de dados têm seu próprio registro: quem, quando e o quê. E a lixeira guarda o que foi excluído com a possibilidade de restaurá-lo. Com uma ressalva honesta: executar_comando_vps registra que um comando foi executado, não qual — outra razão para preferir as ferramentas dedicadas, que sim anotam o verbo.

As credenciais nunca são expostas. As ferramentas que gerenciam chaves de API ou tokens retornam seu uso e seu custo, mas jamais o valor do token. O mesmo acontece com as senhas das caixas de correio.

A conclusão honesta não é que um MCP não agrega risco. É que ele torna explícito e controlável: o catálogo é fechado, o escopo você escolhe, as combinações perigosas estão documentadas e o conteúdo de terceiros chega marcado como o que é.

Perguntas frequentes

O que significa MCP? Model Context Protocol. É um padrão aberto para conectar modelos de IA com ferramentas e dados externos.

Um MCP é o mesmo que uma API? Não exatamente. Uma API é pensada para que seja usada por um programador escrevendo código. Um MCP é pensado para que seja usado por um modelo de IA lendo descrições em linguagem natural. Muitos servidores MCP funcionam por cima de uma API existente.

Preciso saber programar para usar o MCP de ArduMaker? Não. É usado conversando. Quem programa, além disso, ganha: pode pedir à IA que implante, revise logs ou consulte o banco sem sair do chat.

Com quais modelos funciona? Com qualquer cliente compatível com o protocolo MCP. Essa é exatamente a vantagem de ser um padrão aberto: não fica preso a um fornecedor.

Qual é o endereço do servidor? https://mcp.ardumaker.com/mcp — transporte Streamable HTTP, autorização OAuth 2.1 com PKCE e registro dinâmico de clientes. Na prática: você cola o endereço no seu cliente e ele o leva a aprovar a conexão com sua conta.

Posso dar acesso limitado? Sim, e é recomendável. Ao autorizar, você escolhe se a sessão é somente leitura, se vê todos os seus projetos ou uma seleção, e se vê todos os seus VPS ou uma seleção. Um agente que só lê não escreve nada, mesmo que você seja admin de tudo.

A IA pode quebrar algo? Ela só pode fazer o que a pessoa que a autorizou já podia fazer, dentro do escopo que você deu, e apenas por meio das ferramentas publicadas. Há quatro operações que nenhum agente pode fazer nunca — excluir um projeto, tocar membros de um projeto, tocar anexos secretos e excluir um VPS—, várias exclusões não estão expostas de forma alguma, e as ações mais delicadas pedem confirmação explícita.

E se alguém enviar instruções ao meu agente escondidas em um e-mail ou em um comentário? É uma ameaça real e o servidor a trata como tal: todo o conteúdo escrito por terceiros chega envolto e marcado como não confiável, com a indicação de tratá-lo como dados e nunca como instruções. A outra metade da defesa é sua: não dê a um mesmo agente acesso para ler e-mail e para executar comandos.

Quantas ferramentas ela tem? Cerca de 200, distribuídas entre VPS, domínios, DNS, e-mail, bancos de dados, projetos, repositórios, túneis, blogs e administração de chaves e custos. O número exato está sempre em mcp.ardumaker.com/tools.json, que é gerado ao vivo a partir do servidor.

Começar é conectar um endereço

Para usar o MCP da ArduMaker basta adicionar o servidor em um cliente compatível e autorizá-lo com sua conta:

https://mcp.ardumaker.com/mcp

Nesse momento você escolhe o escopo: apenas leitura ou não, todos os projetos ou alguns, todos os VPS ou alguns. Vale a pena pensar por dois segundos — é a decisão que define o que pode acontecer depois.

A partir daí, a IA vê suas empresas, seus projetos e seus servidores, com suas permissões e dentro do escopo que você deu. E você pode começar pelo simples: peça que ela chame ver_contexto_inicial e conte o que está vendo. É a melhor primeira conversa possível, pois ela devolve o mapa completo e, de passagem, confirma com qual escopo ficou conectada.

O salto conceitual é este: durante décadas, administrar infraestrutura significou aprender a interface de cada ferramenta. Com um MCP, a interface é você explicando o que quer.

Este artigo é a prova. Foi uma conversa, e terminou sendo uma página publicada, ilustrada e traduzida.