List of Values Filtering: Natural Language Replaces UI Controls

Instead of sidebar filters and dropdowns, give the model a List of Values (LOV) for tool parameters and let natural language do the filtering.

Source: Alpic – 15 Lessons Building ChatGPT Apps

The Problem

Traditional dashboards are built on sidebars full of checkboxes, range sliders, and dropdowns. Porting these into agentic interfaces adds friction. When users can express intent directly (“sunny destinations in Europe for under $200”), forcing them through multiple UI controls is a regression.

The model also “guesses” when it doesn’t know what valid options exist, leading to hallucinated filter values that don’t match your backend’s API.

The Solution

Provide a List of Values (LOV) as tool parameter enums. The model maps natural language directly to your backend’s requirements.

// Tool definition with LOV
{
  name: "search_destinations",
  parameters: {
    weather: {
      type: "string",
      enum: ["sunny", "mild", "cold", "tropical", "any"],
      description: "Weather preference for the destination"
    },
    region: {
      type: "string",
      enum: ["europe", "asia", "americas", "africa", "oceania"],
      description: "Geographic region"
    },
    budget: {
      type: "string",
      enum: ["budget", "mid-range", "luxury"],
      description: "Price tier"
    }
  }
}

User says “sunny” and the model knows to call the tool with weather="sunny". No dropdown needed. No hallucinated values.

Why This Works

1. Constrains the model: Enum values prevent hallucinated parameters
2. Removes UI friction: Users state intent naturally instead of clicking through controls
3. Maps to backend contracts: LOV values match exactly what your API accepts
4. Reduces token waste: No need to load complex UI state into context

When to Use LOV vs Traditional Filters

Related Concept: Context Asymmetry

The same team identified a key principle: not all context should be shared between the user, UI, and model. Each body in the system (user, widget, model) may need intentionally different views of the same state.

This applies to LOV too. The model needs the enum values to route correctly. The UI might display richer labels or icons. The user sees natural language. Each participant gets the view they need.

Related

• Constraint-Based Prompting – WHAT vs HOW in tool design
• Agent Capabilities: Tools & Eyes – Tool design principles
• Progressive Disclosure – Loading tool context on demand