AlgoTrips

Search flights

search_flights

Read-only

Searches one-way flights on AlgoTrips for one day between two cities or airports, with current prices. Returns up to 5 options (airline, flight numbers, times, duration, stops, baggage, refund, fare and price for all passengers), each with a link to book it on AlgoTrips, and a link to see every flight. Nothing is booked or paid here. The prices are the signed-in AlgoTrips account's own; needs the person to be signed in to AlgoTrips. A city that is not found or is shared by several cities returns close matches instead (status needs_changes).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "from": "<from>",
      "to": "<to>",
      "date": "<date>"
    },
    "name": "search_flights"
  }
}

Input Schema

Name	Required	Description
`to`	Yes	Where the flight goes: a city or a 3-letter airport code, as for from.
`date`	Yes	The day of the flight, YYYY-MM-DD, from today up to 330 days ahead.
`from`	Yes	Where the flight leaves from: a city ("Mumbai", or "Hyderabad, India" when the name is shared) or a 3-letter airport code ("BOM").
`cabin`	No	Cabin: economy, premium_economy, business or first. Left out: every cabin.
`adults`	No	Adults (12 and over) travelling, 1 to 9. Left out: 1.
`infants`	No	Infants under 2 (on a lap), 0 to 4, no more than the adults.
`directOnly`	No	true: nonstop flights only.
`departAfter`	No	The earliest departure time, HH:MM (24-hour clock, local time at the departure airport).
`childrenAges`	No	Each child's age, 2 to 11. Adults and children together are at most 9.
`departBefore`	No	The latest departure time, HH:MM (24-hour clock, local time at the departure airport).
`preferredTime`	No	A preferred departure time, HH:MM. Without departAfter or departBefore, only flights leaving within 2 hours of it are returned. The flight nearest to it is always among the options.

Output Schema

Name	Required	Description
`to`	No
`date`	No
`from`	No
`party`	No	The travellers the search was for (adults left out = 1).
`status`	Yes
`message`	Yes
`options`	No
`priceNote`	No
`suggestions`	No
`allFlightsLink`	No

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 4, 2026

TDQS

A4.5/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the annotations, it discloses that results are capped at 5 options, that each option includes booking links, that prices are tied to the signed-in AlgoTrips account, that sign-in is required, and that ambiguous city names return close matches with status needs_changes. These are substantive behavioral details an agent needs for correct use and interpretation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core purpose, followed by return behavior, authentication and booking caveats, and error fallback. Every sentence carries useful information, with no filler or repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the 11-parameter schema, read-only/open-world annotations, and existing output schema, the description supplies the remaining context an agent needs: one-way/one-day scope, result cap and content, account-linked pricing, sign-in requirement, no booking side effect, and ambiguous-city handling.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so all 11 parameters are already well documented. The description adds some useful meaning for from/to by explaining the close-match fallback for unknown or shared city names, but it does not otherwise deepen parameter semantics beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: it searches one-way flights on AlgoTrips for one day between two cities or airports, with current prices. The scope is precise enough to distinguish it from sibling tools like plan_trip, trip_status, and my_trips without ambiguity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear usage context: one-way flights, one day, two cities or airports, and current prices, and it explicitly says nothing is booked or paid here. It does not name alternatives or explicitly route the agent away from siblings, so it falls short of the highest tier.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All AlgoTrips tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?