LS-Labs
GLM character holding a book

Research guide · TSO

TSO Tool Selection OptimizationYour tool is ready.
Why wasn’t it selected?

TSO (Tool Selection Optimization) is LS-Labs’ operational framework for examining how AI agents find, select and invoke tools. It covers integration, candidate exposure, model selection and execution.

Explore tool retrieval, MCP integration and tool definitions, keeping candidate exposure, model selection and execution results separate.

01

TSO reading guide

Start with tool selection, then explore integration protocols, search interfaces and practical examples.

Related terms: Tool metadata · Tool descriptions · Candidate recall · TCC.

Further reading: Review tool definitions with TCC · How AI agents select tools.

02

Four stages of TSO

TSO separates tool use into integration, candidate exposure, model selection, and invocation and execution. An unused tool might never have reached the candidate list, or might have been considered and rejected. Separating the stages helps locate the failure.

  1. 01

    Tool integration Integration

    Is it connected to a system the agent can use?

    For example, MCP tool definitions include names, descriptions and input parameters. The model sees this metadata, rather than the quality of your underlying code.

  2. 02

    Candidate exposure Exposure

    Was it loaded for the model to see?

    Systems that use tool search retrieve candidates first, then load a subset of tool definitions. In Anthropic’s tool search, deferred tools are loaded when Claude finds them. Tools that are never loaded cannot be selected in that subsequent step.

  3. 03

    Model selection Selection

    Why did the model choose this candidate?

    The model chooses among loaded tools. How closely a tool description matches the request can affect that choice. The BiasBusters study found that small changes to descriptions could substantially change results.

  4. 04

    Invocation and execution Execution

    After selection, did the task actually finish?

    After the model chooses a tool and its arguments, the client sends a request through mechanisms such as MCP’s tools/call . Check the arguments, returned results and execution errors. An invocation does not establish completion.

Apply it to a reservation

Suppose a booking API is connected to an agent but is not called for a reservation request. If it was absent from retrieved candidates, inspect candidate exposure. If another booking tool was chosen instead, inspect model selection. If the tool was selected with an incorrect date, inspect invocation and execution.

Treat discovery and selection separately. Microsoft Foundry allows search-only text for each tool. It is indexed but not shown to the model, which still uses the tool name, description and parameters for selection.

03

Three booking tool scenarios

For the same reservation request, a booking tool may be unloaded, unsuitable or a match for the task. Switch between these scenarios to see what to inspect.

User request“Find a restaurant and book a table for two tonight at 19:00.”

Choose a scenario

A connected booking tool was not retrieved

Loaded for this taskRestaurant searchVisible
Loaded for this taskMap lookupVisible
Connected but not loadedBooking toolAbsent

What to checkInspect which tools were loaded for this task. A booking tool absent from the candidates cannot reach the selection and invocation stages.

Restaurant search does not offer booking

The task needsCheck availability and create a reservation
The tool canSearch names, addresses and descriptions

Missing capabilities: availability and booking

What to checkBooking requires checking availability and creating a reservation. A description limited to name and address searches does not communicate booking capabilities.

Capabilities and inputs match the booking task

Candidate capabilitiesCheck availability, create a reservation
  • Date Tonight
  • Time 19:00
  • Party size Two

What to checkAvailability and booking capabilities, together with date, time and party size, let the model turn the request into a tool call.

How should you define tools? Explore three diagrams ↓
Small GLM character holding a book

04

How agents narrow down tools

Systems with tool search retrieve candidates before model selection and invocation. The 12 → 3 → 1 diagram is a teaching example; actual candidate counts and processes vary by system.

Choose a diagram

Only some connected tools reach the model

“Book a table for four this Saturday at 19:00.”

First gate

Which tools are retrieved?

Names, descriptions and parameter information help the retriever identify task-relevant candidates.

Second gate

Choose a suitable tool

The model reads the full candidate definitions, comparing availability, booking capabilities and required inputs.

Further reading: Anthropic’s tool search workflow and ToolLLM’s API retriever.

Three possible reasons a booking fails

“Book a table for four this Saturday at 19:00.”

  1. 01

    Retrieval failure

    Did the tool reach the candidate list?

    service_v2“Digital transformation services for restaurants”

    This name and description do not identify a concrete capability to book restaurant tables.

    Inspect the tool indexSpecify the actual tasks: restaurant availability and creating reservations.

  2. 02

    Selection failure

    Can the candidates be distinguished?

    Delivery order/Table reservation

    Both tools say “hotpot booking,” but they perform different tasks.

    Inspect capability descriptionsSpecify whether each tool handles dine-in tables, delivery or collection.

  3. 03

    Invocation failure

    Do the arguments meet the requirements?

    "seven in the evening"→"19:00"

    Even with the right tool, the time must use a format the server accepts.

    Inspect arguments and resultsDeclare the time format and required fields, then verify the returned result.

Use MCP’s tool definition, invocation and result structures to locate the failing stage.

Compare tool names, descriptions and parameters

Names state actions, descriptions state capabilities, and parameters state formats.

Too vague

name
restaurant_helper_api
description
A complete dining experience for all your meal needs.
Parameters
date, num

Which date? Who counts in the party size? Does it check availability or create a reservation?

Clear action and inputs

name
search_restaurant_tables
description
Check availability for a specified date, time and party size. Return available slots, seating areas and booking conditions. To create a reservation, use create_table_reservation.
Parameters
restaurant, date, time, party_size, area

Separate availability and booking tools give the model a clear choice for each task.

Show the full input schema
{
  "type": "object",
  "properties": {
    "restaurant": { "type": "string", "description": "Restaurant name or branch" },
    "date": {
      "type": "string", "format": "date",
      "description": "Dining date, YYYY-MM-DD"
    },
    "time": {
      "type": "string",
      "description": "Dining time, 24-hour HH:MM"
    },
    "party_size": {
      "type": "integer", "minimum": 1,
      "description": "Party size, including children"
    },
    "area": {
      "type": "string",
      "description": "Preferred seating area, such as indoors or outdoors"
    }
  },
  "required": ["restaurant", "date", "time", "party_size"],
  "additionalProperties": false
}

Source: MCP Tools specification.

05

Common questions

Who proposed TSO?

TSO is an operational framework proposed by LS-Labs to investigate why an agent does or does not use a tool. Its four stages help avoid attributing every failure to the model.

How does TSO differ from GEO?

GEO examines who is mentioned or cited in AI answers. TSO examines which tools, APIs or MCP servers agents invoke when executing tasks.

Does TSO matter before I have an API or MCP server?

Yes. Tool integration is the starting point if no API is available. Whether agents can understand and operate the website itself falls under AX . Begin with one common task rather than implementing an entire system at once.

Does building an MCP server guarantee tool use?

No. Connecting through MCP only completes integration. The tool must also enter the candidate list, be visible to the model, and suit the task. In Anthropic’s tool search, deferred tools only become available when Claude finds them.

How should names, descriptions and parameters be written?

Names state actions, descriptions state capabilities, and parameters state formats. For example, separate availability checks from booking creation, define each capability, and specify time formats and required fields. See the MCP Tools specification.

What is candidate exposure?

In systems with tool search, candidate exposure is the process of retrieving tools and loading them for the model. Tools that are never loaded cannot be selected in the next step.

Does tool selection mean the task is complete?

No. After selection, inspect the arguments, returned results and execution errors. Invocation does not establish completion.

Does frequent visibility in AI answers lead to tool selection?

Agents choose among currently available tools for the task. GEO examines answer mentions and citations; TSO checks whether a tool was loaded, whether it fits the task, and which tool the model selected.

06

How the four research topics connect

GEO examines mentions and citations in organic answers, TSO examines which tool an agent selects, AX examines whether a task can be completed, and AI Ads examines how paid placements below an answer are matched and converted. These four topics address adjacent problems, so you can read across them as needed.

  1. GEOMentioned and citedCheck whether AI answers mention or cite you
  2. TSOSelected as a toolCheck whether agents select your tool
  3. AXComplete the taskCheck whether agents can finish the task
  4. AI AdsGet matched and clickedCheck how ads match the chat and drive results