Agent Tool Optimization: how AI agents choose which brand to call

Ask ChatGPT for a hotel in Lisbon next weekend and two things happen. First the model decides what to say. Then, if it can act, it decides which tool to call: your booking engine, an OTA's, or nothing at all.

Most brands have spent the last two years on the first decision. Generative engine optimization (GEO) is about being cited in the answer. The second decision is newer, and it is where the sale happens. It has a name now: Agent Tool Optimization, or ATO.

What ATO is

The term comes from ToolRank, an open-source project that scores MCP tools. Their definition: ATO is "the practice of optimizing tools so AI agents discover, select, and execute them." SEO optimized for search engines. GEO optimizes for citations in AI answers. ATO optimizes for the moment an agent picks a tool.

ToolRank describes three stages:

1. Be recognized. The model knows your brand exists. This is where GEO lives.
2. Be selected. The agent chooses your tool over the alternatives in front of it.
3. Be used reliably. The call succeeds, the result is useful, and the agent comes back.

GEO stops at the first stage. A brand can be named in every answer and still lose the booking, because when the assistant needs live rates it calls whichever tool describes itself best.

How an agent actually chooses

An agent does not browse your website when it picks a tool. Through MCP, the protocol behind ChatGPT apps and Claude connectors, your server hands the model a list of tools: a name, a short description, and a schema for the inputs. That list is all the model sees. Choosing a tool is one more prediction the model makes, and it makes it from your words.

So the description is your storefront. Anthropic's own documentation calls a detailed tool description "by far the most important factor in tool performance," and asks for at least three or four sentences per tool. OpenAI offers a simple test: could an intern use the tool correctly given nothing but what you gave the model?

A tool called get with the description "Gets data" fails that test. search_hotel_availability, described as "Search live room availability and prices across our properties. Use when the guest gives a destination and dates," passes it. Not because the second hotel is better, but because the model can tell what it does and when to use it.

Most tools fail this test

A 2026 study looked at 856 tools across 103 MCP servers (Hasan et al., 2026). They graded each description on six parts: purpose, usage guidelines, limitations, parameter explanations, completeness and examples.

• 97.1% of descriptions had at least one problem.
• 56% did not state their purpose clearly.
• 89% never said what the tool cannot do, or when to use it.
• 84% left their parameters unexplained.

Official servers from large vendors were no better than community ones.

Fixing the descriptions helped. Across the benchmark, task success rose by a median of almost 6 percentage points, and partial goal completion by 15%. Two details matter for anyone writing tools. Longer was not always better: short, targeted descriptions matched fully rewritten ones at a lower token cost. And the fixes raised the number of steps agents took, so clarity has to come with restraint.

The same pattern shows up in practice. Anthropic reported that when it had an agent rewrite poor tool descriptions in its own research system, later agents finished their tasks 40% faster. In another case, a vague search tool led Claude to append the year to every query, quietly skewing results, until the description was fixed.

What good looks like

A tool an agent will pick, and use correctly, answers five questions on its own:

• What does it do? One plain sentence, with the business object in the name: search_flights, hold_fare, change_booking_dates. Not execute or api_call.
• When should it be used? "Use when the traveler gives a route and dates." Anthropic's guidance is to say when a tool should be used and when it should not, so the agent does not have to guess.
• What can it not do? "Does not cover group bookings of more than nine passengers." This is the most commonly missing part, and it is what stops an agent from calling you for something you cannot serve.
• What does each input mean? Types, formats, allowed values and defaults. "Date in YYYY-MM-DD" saves a failed first call.
• What comes back? Live price, currency, availability, and the link or action that completes the booking.

A small example. Before:

{
  "name": "search",
  "description": "Search hotels."
}

After:

{
  "name": "search_hotel_availability",
  "description": "Search live room availability and nightly prices across our hotels. Use when the guest gives a destination or hotel name plus check-in and check-out dates. Returns up to 10 rooms with total price in the guest's currency and a link to book. Does not handle group bookings of more than 8 rooms.",
  "inputSchema": {
    "destination": "City or hotel name, e.g. 'Lisbon' or 'Hotel Avenida'",
    "check_in": "Date, YYYY-MM-DD",
    "check_out": "Date, YYYY-MM-DD",
    "adults": "Number of adults, default 2"
  }
}

Fewer tools also help. OpenAI suggests keeping fewer than 20 tools available at the start of a turn, and Anthropic warns that "more tools don't always lead to better outcomes." A common mistake is wrapping every endpoint of an existing API as its own tool. Expose the few actions your customers actually take, and merge the ones that only differ in name.

Measure it like a channel

Search teams watch rankings and click-through. ATO needs the same discipline, with different signals:

• Selection: in the conversations where your tool could have helped, how often was it called?
• First-call success: how often did the first call have valid inputs?
• Outcome: how many calls ended in a quote, a hold, or a booking?

At Bazak we run the MCP servers behind our customers' agents in ChatGPT and Claude, so we see both sides: the tool calls, and the conversation that led to each one. The conversation is what tells you why a tool was skipped. A traveler who asked for "somewhere warm in March" and got no call from your tool is a description problem, not a demand problem.

Where ATO fits

We think about AI commerce as four steps: your brand gets mentioned, then listed as a tool, then booked, then it serves the customer after the purchase.

GEO earns the mention. ATO earns the selection. Real-time integration, with live inventory, live prices and checkout, turns the selection into a booking. And the brands that keep the customer are the ones whose agent is still there for the date change two weeks later.

None of these replaces the others. But ATO is the cheapest of them to start on: it begins with a page of tool descriptions you can rewrite this week.

A checklist to start

1. List the tools your MCP server exposes today. If there are none, that is the first gap.
2. Rename any tool whose name does not say what it acts on.
3. For each tool, write when to use it and what it cannot do.
4. Describe every parameter with its format and a default.
5. Remove or merge tools that overlap.
6. Log which tool each conversation called, and read the conversations where none was.