OpenWebUI decompõe como conectar System Prompt, Skills e MCP Tools para validação de links

O ecossistema do OpenWebUI demonstrou na prática por que um único prompt de sistema não é suficiente para um assistente IA confiável. Usando um bot de suporte técnico como exemplo, os autores explicaram como dividir papéis entre o modelo, pós-processamento e ferramentas externas para que o bot não entregue URLs quebradas aos usuários.

Três Camadas de Lógica

O artigo da HOSTKEY não fala sobre um novo modelo, mas sobre a arquitetura ao seu redor. Os autores pegam um problema típico de suporte técnico: um assistente responde a partir de uma base de conhecimento, constrói links para documentação e deve não apenas adivinhar o endereço correto, mas confirmar que ele realmente abre. É aqui que surge a divisão em três níveis.

System Prompt define o comportamento do modelo, explica o formato das respostas e até ensina como montar URLs a partir de nomes internos de documentos, mas não consegue navegar na rede por conta própria.

"System Prompt é uma descrição de cargo de um funcionário."

A seguir, uma Skill é adicionada à cadeia — uma camada de pós-processamento que recebe um rascunho de resposta já preparado. Ela consegue extrair links do texto, chamar uma ferramenta externa, verificar o resultado em relação às regras e retornar uma versão limpa ao usuário.

O terceiro nível é uma MCP Tool, ou seja, código executável separado que realiza uma ação real: neste caso, envia uma solicitação HTTP e informa se o link funciona ou não.

• System Prompt é responsável por papel, tom, restrições e o algoritmo para construir links.
• Skill analisa a resposta do modelo, coordena a verificação e altera o texto final.
• MCP Tool executa uma solicitação de rede e retorna um resultado estruturado: status, tempo de resposta, erro.
• Juntas, essas camadas fornecem um esquema previsível em vez de tentar resolver tudo com um único prompt.

Como a Verificação Funciona

O artigo analisa um cenário ao vivo: um usuário pergunta como configurar uma interface de rede no painel Invapi. O modelo com um prompt de sistema encontra o documento correto na base de conhecimento, transforma o nome do arquivo interno em um endereço de documentação pública e insere o link na resposta. Neste estágio, tudo ainda parece plausível, mas isso não garante que a página exista e não leve a um 404.

Após a geração, a Skill url-validator-with-mcp é ativada. Ela analisa a resposta, encontra URLs e as envia uma a uma para a ferramenta MCP. A ferramenta em si é implementada como um serviço Python no fastmcp: primeiro valida o formato do endereço, depois faz uma solicitação HEAD, consegue seguir redirecionamentos, verifica SSL e trata timeouts. O exemplo usa um timeout padrão de cinco segundos, e a resposta é retornada como JSON com campos como status_code, response_time_ms, final_url e error.

Se a ferramenta receber uma resposta correta do servidor, a Skill deixa o link no texto e verifica adicionalmente a formatação. Se a verificação retornar 404, erro de SSL ou timeout, a Skill remove completamente o link quebrado e não mostra ao usuário lixo técnico. Como opção de backup, o bot pode deixar um caminho seguro, por exemplo um link para suporte técnico, em vez de uma instrução inventada.

Por Que Isso Importa

O ponto principal do artigo é que System Prompt, Skills e MCP Tools não competem entre si. Eles cobrem diferentes classes de tarefas. O prompt conhece o contexto do diálogo e as regras de negócio, mas não tem acesso direto à rede. Skill vê a resposta acabada e pode organizar a verificação, mas não baixa nada por conta própria. MCP Tool sabe trabalhar com o mundo externo, mas não entende sobre o que foi a conversa com o usuário ou como a resposta final deve parecer.

Para equipes que constroem assistentes aplicados, esse é um padrão útil. A habilidade pode ser reutilizada com diferentes modelos, e a ferramenta externa pode ser conectada não apenas a este cenário, mas também a outros pipelines. O artigo enfatiza especificamente que a mesma Skill já é usada em tradutores para evitar que links quebrados apareçam na saída. Isso torna a arquitetura não apenas elegante em um diagrama, mas prática em produção: é mais fácil testar as camadas separadamente, registrar erros e alterar um único componente sem reescrever todo o assistente.

O Que Isso Significa

A análise da HOSTKEY demonstra bem para onde o ecossistema de ferramentas de IA está se movimentando: o valor cada vez mais não está na LLM em si, mas na combinação de regras, verificações e ações externas. Se um produto precisa de confiabilidade, uma única "resposta inteligente" não é mais suficiente — você precisa de uma camada que verifique o resultado no mundo real antes que o usuário o veja.