When teams start building AI travel agents, the first instinct is usually to add more tools.
More hotel suppliers. More search endpoints. More filters. More booking actions. More data.
I understand why. A long tool list makes a system look capable.
But after working with travel infrastructure, I’ve started to think the harder problem is not giving the agent more things to call. It’s helping the agent decide which action actually matters next.
That sounds like a model problem, but a lot of it is really a product and infrastructure problem.
Tool Count Is a Bad Measure of Capability
Imagine an agent with twenty hotel-related tools.
It can search by destination, search by map, search by budget, search by amenities, compare rates, inspect cancellation policies, get hotel details, check availability, create a booking, cancel a booking, and so on.
Technically, that sounds powerful.
In practice, it may just create more chances for the agent to choose the wrong path.
Should it search by destination first, or by neighborhood? Should it call hotel details before comparing rates? Should it check policies for every result, or only the top three? Should it verify availability again before showing options?
If the system doesn’t make those decisions easier, the model has to improvise.
And improvisation is exactly what you don’t want in a transaction-heavy workflow.
Good Infrastructure Reduces Decision Noise
A lot of backend systems are designed around what the supplier API can do.
That’s natural. Supplier capabilities become endpoints, endpoints become tools, and tools get exposed to the model.
But an agent doesn’t think in supplier endpoints. It thinks in user goals.
The user wants a quiet hotel near Shibuya with flexible cancellation. They don’t care whether that requires three internal calls, two supplier lookups, or a fallback to a second inventory source.
This means the infrastructure layer should absorb as much decision noise as possible.
Instead of exposing five slightly different search tools, it may be better to expose one strong search interface with clear inputs, predictable defaults, and useful result metadata.
Instead of forcing the model to interpret raw supplier errors, the platform should turn them into a smaller set of meaningful states.
The agent should spend its reasoning budget on the user’s problem, not on figuring out which internal endpoint behaves least badly.
The Best Tool Is Often the One You Don’t Expose
One thing I’ve become more convinced of is that not every backend capability should become an agent-facing tool.
Internal services can be useful without being directly callable by the model.
A routing service can decide which suppliers to query.
A ranking layer can remove duplicates.
A policy parser can normalize cancellation rules.
A freshness check can decide whether a rate needs to be verified again.
None of these services need to appear as separate tools in the agent interface.
This is similar to good API design. A clean public interface usually depends on a much messier internal system.
The goal isn’t to expose the whole stack.
The goal is to expose the smallest useful surface.
Latency Changes the Agent’s Behavior
Decision quality is also affected by time.
If one supplier responds in 300 milliseconds and another takes five seconds, the agent may start reasoning over an incomplete result set. That can quietly distort the recommendation.
The system might return the fastest options first, even if the slower supplier has better inventory.
Or it might wait too long, making the experience feel broken.
This is why multi-supplier travel systems need more than parallel requests. They need a strategy for incomplete information.
What is the minimum result set that is good enough to continue?
When should the system wait for another supplier?
When should it stop and return what it has?
These are not just performance questions. They directly shape what the agent believes is available.
A Better Pattern: Progressively Stronger Answers
I think a better architecture is to let the system produce answers in stages.
First, return a fast shortlist based on the strongest currently available signals.
Then enrich the top options with more detailed policy, pricing, or availability checks.
Finally, before a booking, run a strict verification step against the live source of truth.
That gives the agent something useful early without pretending that every field is equally fresh.
It also creates a clearer boundary between “good enough for discovery” and “safe enough for transaction.”
The agent doesn’t need perfect information at every step.
It needs the right level of confidence for the decision it is making.
Where MCP Fits
This is where MCP becomes more interesting than a simple connector standard.
If MCP is going to support real travel workflows, the important question is not just whether a tool is callable.
It’s whether the tool gives the agent enough structure to make the next decision safely.
That includes clear input expectations, meaningful result metadata, explicit state transitions, and errors that explain what can happen next.
A useful tool doesn’t just answer a request.
It helps the agent understand the shape of the problem.
That may become one of the biggest differences between an MCP integration that works in a demo and one that survives in production.
The future of agent infrastructure probably won’t be defined by who exposes the most capabilities.
It will be defined by who makes complex systems feel easy to reason about.
And in travel, that usually means hiding more complexity than you show.
