OpenWebUI walkthrough shows how to combine System Prompt, Skills and MCP Tools to verify links

The OpenWebUI ecosystem now has a practical demonstration of why a system prompt alone is not enough for a reliable AI assistant. Using a technical support bot as the example, the authors break down how to split responsibilities between the model, post-processing and an external tool so the bot does not hand users broken URLs.

Three layers of logic

The HOSTKEY piece is not about a new model but about the architecture around it. The authors take a typical support problem: the assistant answers from a knowledge base, builds links to documentation, and must not merely guess the right address but confirm that it actually opens. This is where the three-level split comes in.

The System Prompt defines the model's behavior, explains the answer format and even teaches it to assemble URLs from internal document names, but it cannot access the network itself.

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

Next in the chain comes a Skill, a post-processing layer that receives the already-drafted answer. It can extract links from the text, call an external tool, check the result against the rules and return a cleaned-up version to the user.

The third level is the MCP Tool: standalone executable code that performs a real action. In this case it sends an HTTP request and reports whether the link works.

• System Prompt handles the role, tone, constraints and the algorithm for building links.
• Skill parses the model's answer, coordinates the check and changes the final text.
• MCP Tool performs the network request and returns a structured result: status, response time, error.
• Together, these layers give a predictable scheme instead of an attempt to solve everything with one prompt.

How the check works

The article walks through a live scenario: a user asks how to configure a network interface in the Invapi panel. The model, guided by the system prompt, finds the right document in the knowledge base, converts the internal file name into a public documentation address and inserts the link into the answer. At this stage everything still looks plausible, but that does not guarantee the page exists and does not lead to a 404.

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

If the tool gets a valid server response, the Skill leaves the link in the text and additionally checks the formatting. If the check returns a 404, an SSL error or a timeout, the Skill removes the dead link entirely and shows the user no technical clutter. As a fallback, the bot can leave a safe path, such as a link to technical support, instead of an invented instruction.

Why it matters

The article's main point is that System Prompt, Skills and MCP Tools do not compete with each other. They cover different classes of tasks. The prompt knows the dialogue context and business rules but has no direct network access. The Skill sees the finished answer and can organize a check, but downloads nothing itself. The MCP Tool can work with the outside world, but does not understand what the conversation with the user was about or what the final answer should look like.

For teams building applied assistants, this is a useful pattern. A Skill can be reused with different models, and an external tool can be plugged into other pipelines, not just this scenario. The article specifically notes that the same Skill is already used in translators to keep broken links out of the output.

That makes the architecture practical in production, not just tidy on a diagram: it is easier to test layers separately, log errors and swap out a single component without rewriting the whole assistant.

What this means

The HOSTKEY write-up shows where the AI tooling 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 "smart answer" is no longer enough. It needs a layer that verifies the result in the real world before the user sees it.