OpenWebUI breaks down how to connect System Prompt, Skills and MCP Tools for link validation

The OpenWebUI ecosystem demonstrated in practice why a single system prompt is not enough for a reliable AI assistant. Using a tech support bot as an example, the authors broke down how to divide roles between the model, post-processing, and external tools so that the bot doesn't give users broken URLs.

Three Layers of Logic

The HOSTKEY article is not about a new model, but about the architecture around it. The authors take a typical tech support problem: an assistant answers from a knowledge base, builds links to documentation, and must not just guess the right address but confirm that it actually opens. This is where the division into three levels appears.

System Prompt sets the model's behavior, explains the format of responses, and even teaches how to assemble URLs from internal document names, but cannot navigate the network itself.

"System Prompt is an employee's job description."

Next, a Skill is added to the chain — a post-processing layer that receives an already prepared draft answer. It can extract links from text, call an external tool, verify the result against rules, and return a cleaned version to the user.

The third level is an MCP Tool, that is, separate executable code that performs a real action: in this case, sends an HTTP request and reports whether the link works or not.

• System Prompt is responsible for role, tone, constraints, and the algorithm for building links.
• Skill parses the model's response, coordinates verification, and changes the final text.
• MCP Tool executes a network request and returns a structured result: status, response time, error.
• Together, these layers provide a predictable scheme instead of trying to solve everything with one prompt.

How the Verification Works

The article analyzes a live scenario: a user asks how to configure a network interface in the Invapi panel. The model with a system prompt finds the right document in the knowledge base, transforms the internal file name into a public documentation address, and inserts the link in the response. At this stage, everything still looks plausible, but this is not a guarantee that the page exists and doesn't lead to 404.

After generation, the url-validator-with-mcp Skill is activated. It parses the response, finds URLs, and sends them one by one to the MCP tool. The tool itself is implemented as a Python service on fastmcp: first it validates the address format, then makes a HEAD request, can follow redirects, checks SSL, and handles timeouts. The example uses a standard five-second timeout, and the response is returned as JSON with fields like status_code, response_time_ms, final_url, and error.

If the tool receives a correct server response, the Skill leaves the link in the text and additionally checks formatting. If verification returns 404, an SSL error, or a timeout, the Skill removes the broken link entirely and does not show the user technical garbage. As a backup option, the bot can leave a safe path, for example a link to tech support, instead of a made-up instruction.

Why This Matters

The main point of the article is that System Prompt, Skills, and MCP Tools do not compete with each other. They cover different classes of tasks. The prompt knows the context of the dialogue and business rules, but has no direct access to the network. Skill sees the finished answer and can organize verification, but doesn't download anything on its own. MCP Tool knows how to work with the external world, but doesn't understand what the conversation with the user was about or how the final answer should look.

For teams building applied assistants, this is a useful pattern. The skill can be reused with different models, and the external tool can be connected not only to this scenario, but also to other pipelines. The article specifically emphasizes that the same Skill is already used in translators to prevent broken links from appearing in the output. This makes the architecture not just neat on a diagram, but practical in production: it's easier to test layers separately, log errors, and change a single component without rewriting the entire assistant.

What This Means

HOSTKEY's analysis shows well where the AI tools ecosystem is heading: value increasingly lies not in the LLM itself, but in the combination of rules, checks, and external actions. If a product needs reliability, a single "smart answer" is no longer enough — you need a layer that will verify the result in the real world before the user sees it.