OpenWebUI mostra como combinar System Prompt, Skills e MCP Tools para verificar links

No ecossistema do OpenWebUI, foi demonstrado na prática por que um prompt de sistema sozinho não basta para um assistente de IA confiável. Usando um bot de suporte técnico como exemplo, os autores explicam como dividir os papéis entre o modelo, o pós-processamento e uma ferramenta externa para que o bot não entregue URLs quebradas ao usuário.

Três camadas de lógica

O material da HOSTKEY não trata de um novo modelo, mas da arquitetura ao redor dele. Os autores partem de um problema típico de suporte técnico: o assistente responde com base em uma base de conhecimento, monta links para a documentação e não deve apenas adivinhar o endereço certo, mas confirmar que ele realmente abre. É aí que entra a divisão em três níveis.

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

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

Em seguida entra na cadeia um Skill, uma camada de pós-processamento que recebe o rascunho da resposta já pronto. Ele consegue extrair os links do texto, chamar uma ferramenta externa, comparar o resultado com as regras e devolver ao usuário uma versão limpa.

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

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

Como funciona a verificação

O artigo analisa um cenário real: o usuário pergunta como configurar uma interface de rede no painel Invapi. O modelo, com o prompt de sistema, encontra o documento certo na base, converte o nome interno do arquivo em um endereço público da documentação e insere o link na resposta. Nessa etapa 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, entra o Skill url-validator-with-mcp. Ele analisa a resposta, encontra as URLs e as envia uma a uma à ferramenta MCP. A ferramenta é um serviço em Python baseado em fastmcp: primeiro valida o formato do endereço, depois faz uma requisição HEAD, pode seguir redirecionamentos, verifica o SSL e trata timeouts. O exemplo usa um timeout padrão de cinco segundos, e a resposta volta em JSON com campos como status_code, response_time_ms, final_url e error.

Se a ferramenta recebe uma resposta correta do servidor, o Skill mantém o link no texto e ainda confere a formatação. Se a verificação retorna 404, erro de SSL ou timeout, o Skill remove o link quebrado por completo e não mostra lixo técnico ao usuário. Como alternativa, o bot pode deixar um caminho seguro, como um link para o suporte técnico, em vez de uma instrução inventada.

Por que isso importa

A ideia central do artigo é que System Prompt, Skills e MCP Tools não competem entre si. Eles cobrem classes diferentes de tarefas. O prompt conhece o contexto da conversa e as regras de negócio, mas não tem acesso direto à rede. O Skill vê a resposta pronta e pode organizar uma verificação, mas sozinho não baixa nada. A MCP Tool sabe lidar com o mundo externo, mas não entende sobre o que foi a conversa com o usuário nem como deve ser a resposta final.

Para equipes que constroem assistentes aplicados, é um padrão útil. O Skill pode ser reaproveitado com diferentes modelos, e a ferramenta externa pode ser conectada não só a este cenário, mas a outros pipelines. O artigo destaca que o mesmo Skill já é usado em tradutores para evitar links quebrados na saída.

Isso torna a arquitetura não apenas organizada no diagrama, mas prática em produção: fica mais fácil testar as camadas separadamente, registrar erros em log e trocar um componente sem reescrever todo o assistente.

O que isso significa

A análise da HOSTKEY mostra para onde caminha o ecossistema de ferramentas de IA: o valor está cada vez menos no LLM em si e mais na combinação de regras, verificações e ações externas. Se um produto precisa de confiabilidade, uma "resposta inteligente" já não basta: é preciso uma camada que verifique o resultado no mundo real antes que o usuário o veja.