Scrappa

Search flights on Google Flights

google_flights_search

Read-onlyIdempotent

Search public one-way flight offers on Google Flights between two airports on one date. For a round trip, search each direction separately. Returns per flight: price, airlines, flight numbers, departure and arrival times, duration and stops. It does not book or buy anything. Reads public data only.

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": {
      "origin": "<origin>",
      "destination": "<destination>",
      "departure_date": "<departure_date>"
    },
    "name": "google_flights_search"
  }
}

Input Schema

Name	Required	Description
`adults`	No	Number of adult passengers, 1 to 9. Default: 1.
`origin`	Yes	Departure airport IATA code, e.g. "BER".
`sort_by`	No	Sort order. Default: top_flights.
`currency`	No	Currency code for prices, e.g. "EUR" or "USD". Default: USD.
`max_stops`	No	Maximum number of stops. Default: any.
`cabin_class`	No	Cabin class. Default: economy.
`destination`	Yes	Arrival airport IATA code, e.g. "LIS".
`departure_date`	Yes	Departure date as YYYY-MM-DD.

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 22, 2026

TDQS

A4.2/5.0

Behavior4/5

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

The annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds useful context by stating it only reads public data, does not book or buy, and lists the per-flight return fields. It does not discuss rate limits, availability variability, or pagination, but it goes beyond the annotations in a meaningful way.

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

Conciseness4/5

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

The description is front-loaded with the core action and scope, followed by the round-trip workaround and return fields. It is efficiently structured, though the phrase 'public' appears twice and the final sentence is partially redundant with the annotations.

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?

For a flight search tool with complete schema descriptions and rich annotations, the description covers the key operational constraints: one-way only, round-trip workaround, return fields, and no booking behavior. No output schema exists, so listing the per-flight return values is especially valuable and sufficient for an agent to understand what it will receive.

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 the parameters are already well documented with formats, defaults, and enums. The description only restates that the search is between two airports on one date, without adding syntax or format guidance beyond the schema. Baseline 3 is appropriate when the schema carries the parameter semantics.

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: search public one-way flight offers on Google Flights between two airports on one date. It clearly scopes the operation to one-way searches and distinguishes it from unrelated sibling tools such as maps, reviews, and transcripts.

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?

It gives explicit usage guidance for round trips: search each direction separately. It also clarifies that the tool does not book or buy anything, which helps an agent avoid using it for purchasing. However, there are no sibling alternatives to route between, so full when/when-not guidance is only partially applicable.

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

All Scrappa 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?