TL;DR: Wix released App Tools Extension - a new feature for developers who build applications for the Wix ecosystem, enabling app users to interact with an app’s functionality using Aria, Wix’s AI assistant, instead of navigating menus. This article presents a deep dive into the concepts and ideas behind the new App Tools Extensions feature so developers can better utilize it.
Introduction: Wix Apps
Hi, it’s Ran from the Wix Developer Relations team - and in this article, I’ll take you on a deep dive into a cool new feature we’ve recently released: App Tools Extensions.
An app is an easy concept to understand. Mobile phones, for example, come out of the box with plenty of built-in software - a web browser, a basic calendar, and things like that - but we all know phones have huge potential for features that manufacturers didn’t include right out of the box: navigation, instant messaging, gaming, and a ton of other stuff. For these kinds of extended features, we have apps: software bundles created by third-party developers.
The Wix App Market plays the exact same role inside the Wix ecosystem. Wix’s infrastructure includes plenty of useful features for its users: a Drag & Drop website editor, a Dashboard to help the user run their ecommerce business and backend full to the brim with useful business solutions. But just like in mobiles phones, there are plenty of opportunities for further enhancements that could be hugely beneficial for Wix’s users. That’s where 3rd-party app on the Wix ecosystem come in: they are software bundles created by third-party developers that Wix users can add to their websites to unlock extra functionality.
The Problem: How users interact with an App
Users interact with Wix apps much like we interact with apps on our phones. For instance, if I’m using an app to track a package for a client, I might navigate through a menu in the Dashboard to find the Package Tracking page and then type in the tracking number. That works fine when an app is pretty simple, but what if I want to keep track of all the packages that were sent to all the customers? That might be a bit more involved. Wix apps can - and often do - pack a ton of functionality. They can be complete business solutions with custom backend logic, UI, databases, automations, and API integrations. When an app does so much, navigation menus get long and clunky, and nobody enjoys digging through submenus just to get things done. In the era of AI prompting and interacting with chat first interfaces, your app’s data can now be accessible too to your users.
The Solution: Apps Tools Extensions
The new App Tools Extension feature enables a whole new way for users to take advantage of the functionality that apps provide: by talking directly to Aria, Wix’s AI assistant. Users can interact with Aria right from the dashboard, and Aria interacts with the app on their behalf before returning the results - completely bypassing the need to navigate menus and buttons.
How does this magic work? Let’s dive in. I’ll focus on the overarching concepts and ideas behind the technology: this will help you get your bearings and understand how to implement the feature in the best way possible. For exact implementation details, check out our technical documentation.
Back to Basics: LLMs and Tools
Large Language Models are amazing. I mean, back when I was a kid in the '80s, I would never have believed that I’d be talking to computers like the characters in science fiction books. But as Tuco said in The Good, the Bad and the Ugly - “When you have to shoot, shoot! Don’t talk.” To be truly useful, an AI has to have the ability to take action: search the web for up-to-date data, run tests, build websites, and more. Since all LLMs can really do is output words, we - their overlords (at least for now) - need to give them Tools. It’s these tools that turn a chatbot into an agent.
In June of 2023, OpenAI unleashed the Agentic Revolution when it released its Function Calling API, a technology that enabled LLMs to execute software tools. Function Calling was quickly adopted by all major vendors, and is nowadays known also as Tool Use.
So, how does Tool Use work?
At its core, the system consists of an LLM model wrapped in a software layer called a Harness (Claude Code, Codex, and Cursor are familiar examples). Think of the harness as a general contractor on a job site: when a client asks for something to be built, they talk to the contractor, who then assigns the work to the actual crew. Similarly, when a user prompts an agent, the harness receives the prompt and forwards it to the LLM.
When the model receives a prompt, it has a decision to make: it can either respond with a plain-text message to the user (“You’re absolutely right - jumping out of an airplane without a parachute is a great idea. However…”), or it can ask the harness to execute a function call - in other words, to use a tool. This brings us to our first major hurdle: the LLM needs to understand when a prompt calls for a simple text response versus when it needs to operate a tool to fulfill the user’s request.
AI companies address this challenge mostly during the fine-tuning phase of model development: LLMs go through a specialized post-training phase where they’re trained on datasets of tool invocation examples - user prompts that require tools, along with examples of the exact outputs the LLM should generate to operate them. Over many examples, the models learn to understand user intent and select the correct tool with the right parameters for the requested action.
Additionally, most harnesses allow developers who interact with LLMs via API calls to add a special parameter to their requests called “tool_choice,” which can force the model’s behavior: if tool_choice is set to “Auto,” the model decides whether to return a regular text response or execute a tool call. But if tool_choice is set to “Required,” the model is forced to generate a tool call - though it can still choose which tool to use.
Tool Discovery
The million-dollar question now is: how does an LLM know what tools it has at its disposal? Guessing is definitely off the table. It’s the harness’s job to provide the model with a list of all available tools. This list is passed along as structured metadata - usually JSON - though the exact format can vary slightly between AI vendors.
Here’s a simple example of a tool-discovery JSON object. It provides the LLM with the tool’s name, a description of what it does, and instructions on how to structure the function call:
{
"name": "run_terminal_command",
"description": "Executes a shell command in the local terminal environment.",
"parameters": {
"type": "object",
"properties": {
"command": { "type": "string", "description": "The exact shell command to run." }
},
"required": ["command"]
}
}
Tool Calling
The LLM uses this information to craft it Tool Use call - the request it sends through the harness - also as structured metadata:
{
"tool_call": {
"name": "run_terminal_command",
"arguments": {
"command": "npm install express"
}
}
}
Here we encounter another potential pitfall. LLMs are inherently non-deterministic: their output can never be guaranteed to be exactly what you expect, unlike a Python script, for instance, which will emit the exact same string of characters every time you run it. This means the model might randomly decide to prefix a tool call with something like “I’m going to execute the following tool…” - an addition that will break the tool call, which relies on a precise, well-structured request.
To ensure the emitted JSON is well crafted, AI vendors have developed two main solutions.
The first is straightforward: Schema Validation. This is essentially what any developer would do: run the output through a software-based validator like Pydantic or Zod to make sure it follows strict, hard-coded rules. This catches any hallucinated arguments.
The second is even more interesting: Constrained Decoding (or Grammar-Based Sampling). During inference - the phase where the LLM selects the tokens to output based on its training - the inference engine restricts its choices to only those allowed when building a valid tool call. For example, if the JSON schema specifies that the next field must be a number, the inference engine filters out non-numeric tokens so the LLM can only select a number. It might choose the wrong number, but at least it won’t output an emoji… Continuing our earlier analogy, it’s like handing a construction crew a specific set of power tools so they don’t try to put up drywall with a butter knife.
Tool Execution
Once the tool call is ready, the LLM passes it to the harness, which executes it - usually using Python or Node. The command runs (or at least, it should) in a sandboxed environment to limit any accidental fallout (after all, as the saying goes, “to err is human, but to really screw things up, you need a computer”). Once the command runs, the harness captures its output log and passes it back to the LLM for evaluation.
Back to App Tools Extensions
Now that we understand the basic architecture and workflow of tool calling in LLMs, we can better appreciate how App Tools Extensions work.
For the new feature to work, our app needs two new additions.
The first is the App Tools Extension: this is the tool discovery element - the structured metadata that declares the tools (the functionality) your app exposes. That way Aria, our LLM, knows each tool’s name, purpose, and optional request and response schema. For example, if a user asks Aria to show the tracking status of a package, this App Tools Extension lets Aria know the correct tool to use and how to call it:
{
"tools": [
{
"methodName": "getPackagesTracking",
"description": "Fetches the current tracking status of all packages by their tracking numbers. Returns status, location, and estimated delivery date. Use when the Wix user wants to know the status of all packages.",
"requestSchema": {
"type": "object",
"required": ["trackingNumber", "trackingNumber"...],
"properties": {
"trackingNumber": {
"type": "string",
"description": "The carrier tracking number for the package, for example '1Z999AA10123456784'."
}..
Notice how important it is at this stage for the name and description in the schema to be clear and concise. Any vagueness in the description makes it harder for Aria to use the tool properly - or even realize it should trigger it in the first place.
The second piece is the Tool Provider Service Plugin, which is the actual method - the underlying tool - that Aria invokes. That’s the part of the app doing the heavy lifting and executing your business logic.
Together, these two elements make up the smart system that allows Aria to discover and use functionality your app provides, saving the user the need to browse menus and click buttons. Neat!
I hope this brief deep dive gives you a solid mental model of how App Tools Extensions work and helps you craft a seamless experience for your users. For step-by-step guidance on implementing App Tools Extensions in a new or existing app, using our newly released skill - check out our technical documentation.
Cheers,
Ran