Find carpool rides in California and Nevada: live seats, times and all-in seat prices. Read-only.
Scored across 7 tools
Each tool has a distinct resource and action: search rides, search cabpools, get ride details, check service areas, and build links for three different posting flows. The three link-building tools are clearly separated by driver ride, rider request, and shared-rideshare cabpool use cases.
Most tools follow a clear verb_noun pattern in snake_case: get_ride, list_service_areas, post_ride_link, request_ride_link, search_cabpools, search_rides. cabpool_link is the one deviation, using a noun_link form without a verb, but the overall convention remains readable.
Seven tools is well-scoped for a carpool marketplace: two search tools, one detail tool, one coverage-check tool, and three link-generation tools for the main posting flows. Each tool has a clear role without obvious redundancy.
The surface covers the core lifecycle: checking service areas, searching both rides and cabpools, reading ride details, and generating links to post rides, request rides, or create cabpools. Minor gaps exist around individual cabpool detail retrieval and post-management, but the main discovery and posting workflows are covered.
Cabpool: a free Seat Sherpa feature for sharing an Uber, Lyft or Waymo with people going the same way and splitting the fare, most often to or from an airport (SFO, OAK, SJC, LAX, BUR, SAN, SMF and others) or across town in California or Nevada. Use it when the person wants to split a rideshare rather than ride in someone's car, including short trips inside one area (for example "split an Uber from Nob Hill to SFO"), which search_rides does not cover. Returns a link that opens the cabpool form with the pickup, drop-off and day filled in; the person signs in, sees a fare estimate and each person's share, and posts it so others going that way can join. Seat Sherpa does not book, run or charge for the ride and is not affiliated with Uber, Lyft or Waymo: one member books it in their own app and the others pay their share directly. This tool only builds the link and posts nothing.
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | Drop-off, e.g. "SFO", "Downtown Oakland". | |
| date | No | Optional travel date, YYYY-MM-DD (Pacific). Today is 2026-11-03 (Pacific): use today or a later date, and when the person names a day without a year, the next one on or after today. Omit and the person picks the day on the page. | |
| from | Yes | Pickup: a place, neighborhood, campus or airport, e.g. "Nob Hill, San Francisco", "UC Davis", "LAX". | |
| time | No | Optional pickup time, 24-hour HH:MM Pacific (e.g. "06:30"); used only together with date. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent and non-destructive, and the description reinforces this by saying it only builds a link and posts nothing. It also adds context the annotations cannot convey: the recipient signs in and sees a fare estimate, the user's own app books the ride, and Seat Sherpa is unaffiliated and does not charge. No rate limits or edge cases such as invalid places are mentioned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The routing sentence is front-loaded and every claim is accurate, but the description runs long. Airport city lists ("SFO, OAK, SJC, LAX, BUR, SAN, SMF and others"), the California/Nevada coverage note, and some of the legal disclaimer are padding that the agent does not need in order to choose or call the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description correctly explains what is returned: a link that opens the prefilled cabpool form, then the human fills in and posts it. Combined with the schema, an agent has enough to call it correctly; only the relationship to the other cabpool-linking siblings is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so from, to, date and time are already documented including the date-relative-to-today rule and the fact that time is used only with date. The description adds confirmation that the link prefills pickup, drop-off and day, but omits the optional time field and adds no syntax or format guidance beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: builds a Seat Sherpa cabpool link with pickup, drop-off and day prefilled so a person can split an Uber/Lyft/Waymo fare. It explicitly contrasts with search_rides, so an agent can distinguish it from the closest sibling without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
"Use it when the person wants to split a rideshare rather than ride in someone's car" plus the note that search_rides does not cover short in-area trips gives a clear positive trigger and one exclusion. It does not say how it relates to search_cabpools, post_ride_link or request_ride_link, which cover adjacent parts of the same workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Public details of one Seat Sherpa ride by its id (from search_rides or a seatsherpa.app/ride link): route and stops with estimated times, departure (Pacific), seats left, all-in price per seat in USD, the driver's first name, rating and trips, the driver's note to riders, flexibility, the cancellation policy, and the booking link. Read-only.
| Name | Required | Description | Default |
|---|---|---|---|
| ride_id | Yes | The ride id. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, and 'Read-only' merely echoes them. The description does add genuine context beyond the structured fields: departure times are in Pacific time, prices are all-in USD per seat, and the returned set includes driver rating, trips, note, flexibility and cancellation policy.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Purpose and id provenance are front-loaded, then the returned fields are enumerated in one dense sentence. The enumeration is long but justified because there is no output schema; nothing reads as filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description carries the return-value burden and does so thoroughly (route/stops, times, seats, price, driver info, note, flexibility, cancellation policy, booking link). Parameter origin, read-only nature, and timezone/currency units are all covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single parameter is documented there as 'The ride id.', so the schema does the heavy lifting. The description adds meaningful provenance beyond the schema by specifying the two places the id can be obtained, which prevents the agent from guessing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Public details of one Seat Sherpa ride by its id') and distinguishes itself from search_rides by naming it as the id source. An agent can tell it apart from list_service_areas, post_ride_link, and request_ride_link immediately.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It tells the agent where the ride_id comes from ('from search_rides or a seatsherpa.app/ride link'), which is clear routing from the sibling tool. It does not state when not to use it or what to do if the id is unknown, so it stops short of explicit when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The California and Nevada areas Seat Sherpa carpools run between. Use it to check whether a trip is covered before searching.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description adds real domain scope (CA/NV coverage) but says nothing about the freshness or form of the data returned, which is the main behavioral question for a reference-data lookup.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, no redundancy, with the scope statement front-loaded before the usage instruction. Every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, no-output-schema lookup, the description supplies what matters: what the data covers and when to consult it. The only gap is that it never hints at the shape of the result (e.g. list of area names or IDs), which an agent would have to discover empirically.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so per the baseline there are no parameter semantics to explain. There is no risk of misusing an argument and no schema detail the description needs to compensate for.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Names the concrete resource (the California and Nevada areas Seat Sherpa carpools run between) and makes its scope explicit. It is distinguishable from siblings like search_rides or get_ride, though the verb is implicit rather than stated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives a clear usage rule: 'use it to check whether a trip is covered before searching,' establishing the precondition for search_rides. It does not name that sibling explicitly or describe what to do if the trip is not covered, so it stops short of full alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
For a driver: a link where the person posts a drive they are already taking on Seat Sherpa, the carpool marketplace. Drivers set their own seat price, riders share costs like gas and tolls, and riders searching that route get notified. Use it when the person is the one driving (for example "I'm driving to LA on Friday, can I take people?"), not to find a ride. Takes the starting place, the destination and an optional date. The driver signs in and posts on the page; this tool only builds the link and posts nothing.
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | Where the driver is going, e.g. "Los Angeles", "Las Vegas". | |
| date | No | Optional travel date, YYYY-MM-DD (Pacific). Today is 2026-11-03 (Pacific): use today or a later date, and when the person names a day without a year, the next one on or after today. Omit and the driver picks the date on the page. | |
| from | Yes | Where the driver starts: a city or place in California or Nevada, e.g. "San Francisco", "Irvine". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint and idempotent, but the description adds the fact that matters most for an agent: 'this tool only builds the link and posts nothing,' with the driver signing in to complete the post on the page. It also describes the downstream effect on the platform (riders searching that route get notified), so the agent understands the real-world consequence of handing over the link.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core purpose and followed by the usage trigger, so an agent gets the essentials in the first two sentences. The middle marketing sentence about seat prices, gas and tolls, and route notifications is context rather than instruction and could be trimmed, but it is not misleading.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a three-parameter link-builder with no output schema, the description covers what is produced (a link, not an action), who completes the action, when to use it, and what inputs are needed. Nothing an agent requires to call it correctly is absent, and the 'posts nothing' clarification prevents a plausible failure mode.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 fully documented, including the YYYY-MM-DD format and the Pacific-timezone/next-occurrence rules for dates. The description's restatement of 'the starting place, the destination and an optional date' adds no meaning beyond the schema, which is the expected baseline here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a concrete verb and resource: it builds a link where a driver posts a drive they are already taking on Seat Sherpa, and adds the scoping condition 'for a driver.' It separates itself from ride-finding with 'not to find a ride,' but never names the mirror sibling request_ride_link, leaving the driver-link vs rider-link distinction to inference from the word 'driving.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Use it when the person is the one driving' plus a quoted example utterance gives an agent a clear trigger condition, and 'not to find a ride' gives an explicit exclusion. What's missing is a direct pointer to the alternative (request_ride_link for riders, search_rides for finding), so the routing decision is confident in one direction only.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
For a rider when no ride fits: a link where the person posts a ride request on Seat Sherpa, the carpool marketplace, so drivers on that route see it and get notified, and the person hears back when a matching ride is posted. Use it after search_rides finds nothing that works (that answer already includes this link), or when the person asks to be told about a trip nobody has posted. Takes the same places and optional date as search_rides. The person signs in and posts the request on the page; this tool only builds the link, posts nothing, and never needs names, phone numbers or emails.
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | Where the rider is going, e.g. "Los Angeles", "Las Vegas". | |
| date | No | Optional travel date, YYYY-MM-DD (Pacific). Today is 2026-11-03 (Pacific): use today or a later date, and when the person names a day without a year, the next one on or after today. Omit and the person picks the date on the page. | |
| from | Yes | Where the rider starts: a city or place in California or Nevada, e.g. "San Francisco", "UC Davis", "Irvine". | |
| seats | No | Optional: seats the rider needs, 1 to 4. Only mentioned in the answer; the person picks it on the page. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only say read-only/open-world/idempotent; the description adds substantive behavior: the tool builds a link and posts nothing, the person signs in and submits on the page, and no names/phone/emails are needed. That clarifies where the side effect actually occurs, which annotations cannot convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the purpose and the when-to-use rule before the marketplace explanation. It is one long, somewhat run-on paragraph, and the drivers-get-notified clause is explanatory rather than operational, but virtually every sentence still earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers trigger conditions, mutation-free behavior, privacy constraints, and parameter mapping for a 4-parameter tool with full schema coverage and no output schema. The only soft gap is that the returned value (the link itself) is implied by the title rather than stated explicitly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all four parameters. The description adds cross-tool meaning — 'takes the same places and optional date as search_rides' — grounding argument shape in a sibling the agent already knows, and notes seats is informational only.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource: a link the rider uses to post a ride request on Seat Sherpa, and describes the downstream effect (drivers on the route get notified, rider hears back). It is clearly distinct from search_rides (which finds rides) and post_ride_link (the driver-side link) without needing either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit trigger conditions: after search_rides returns nothing usable, or when the person asks to be notified about a trip nobody has posted. It also warns that search_rides already embeds this link, which prevents redundant calls — a real routing rule rather than vague context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find open cabpools on Seat Sherpa: people sharing an Uber, Lyft or Waymo going the same way and splitting the fare, often to or from an airport. Takes a pickup and a drop-off (a city, area, neighborhood or airport such as "San Francisco", "UC Davis", "SFO"; both may be in one area) and an optional date. Returns each cabpool's pickup and drop-off place, departure time (Pacific), service, spots left, an estimate of each person's share in USD and a link to join. Seat Sherpa does not book, run or charge for the ride; when nothing fits, the answer includes a link to post a cabpool.
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | Drop-off area or place, e.g. "SFO", "Los Angeles". | |
| date | No | Optional travel date, YYYY-MM-DD (Pacific). Today is 2026-11-03 (Pacific): use today or a later date, and when the person names a day without a year, the next one on or after today. Omit to list the soonest cabpools. | |
| from | Yes | Pickup area or place, e.g. "San Francisco", "Davis", "LAX". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, open-world, non-destructive, so the safety bar is low; the description nonetheless adds real value by disclosing the return fields (places, Pacific departure time, service, spots left, per-person USD share, join link) and the important non-booking/no-charge guarantee.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the action and tightly packed with useful facts; every clause carries information. It is a single dense paragraph rather than broken into use/returns/fallback blocks, which slightly hurts scanability but no sentence is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, and the description fully covers return contents, time zone, currency, availability signal and the empty-result fallback, plus the read-only nature of the service. Nothing needed to call this three-parameter tool correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3; the description goes beyond it by giving concrete place-format examples and the non-obvious constraint that "both may be in one area" (i.e., a from/to in the same locality is valid), which the schema does not state.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Opens with a specific verb+resource ("Find open cabpools") and immediately scopes it to people sharing an Uber/Lyft/Waymo and splitting the fare, typically airport-related. This distinguishes it cleanly from siblings like search_rides, get_ride and the link-posting tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
States the required inputs (pickup + drop-off, optional date) and gives a clear fallback: when nothing fits, the result links to posting a cabpool. It stops short of explicitly contrasting itself with search_rides or cabpool_link, so an agent must infer the choice between siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find upcoming long-distance carpool rides on Seat Sherpa (California and Nevada) where everyday drivers sell the empty seats on a trip they are already taking, and riders split the cost of gas. Give a starting place and a destination as city or place names (for example "San Francisco" and "Los Angeles"), and optionally a travel date. Returns rides with open seats: route, departure date and time (Pacific), seats left, the all-in price per seat in USD (what the rider pays, fees included), the driver's first name, and a link where the person books. Rides that stop in a city count for that city, so a San Jose to San Diego ride with a Los Angeles stop is found for Los Angeles to San Diego. Booking happens on the link; this tool cannot book. Rides on a nearby route (for example a San Francisco ride for a San Jose search) are listed separately as nearby_rides; say they are nearby, not exact. When no ride fits exactly, the answer includes a link to post a ride request for that route (the same link request_ride_link gives).
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | Where the rider is going, e.g. "Los Angeles", "Las Vegas". | |
| date | No | Optional travel date, YYYY-MM-DD (Pacific). Today is 2026-11-03 (Pacific): use today or a later date, and when the person names a day without a year, the next one on or after today. Omit to list the soonest rides. | |
| from | Yes | Where the rider starts: a city or place in California or Nevada, e.g. "San Francisco", "UC Davis", "Irvine". | |
| limit | No | Most rides to return. Default 10. | |
| days_flexible | No | With a date: also include rides this many days before and after it. Default 1. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare a safe, idempotent read, and the description still adds substantive behavior: nearby_rides is returned as a separate bucket with an instruction to label it as nearby, rides that stop in a city count for that city, and a ride-request link is included when nothing matches. It also discloses what the returned prices mean (all-in, fees included) and that booking happens off-tool via the link.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
It is front-loaded with identity and scope, then moves to inputs, then outputs, then edge cases — a sensible order. It is a single dense block, and the gas-splitting/empty-seats framing, while flavorful, partially restates what carpooling implies, keeping it just short of maximally tight.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description carries the return-value burden and does so fully: route, departure date/time in Pacific, seats left, all-in USD price per seat, driver first name, and booking link. Combined with the nearby-rides and no-match behavior, an agent has everything needed to call it and interpret results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description earns a point by adding meaning the schema doesn't: from/to accept city or place names (with "San Francisco"/"Los Angeles" examples) and the stop-in-city matching rule that changes what results the parameters actually produce. Date and limit/days_flexible semantics are already fully documented in the schema and aren't repeated at length.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The opening names a specific verb and resource ("Find upcoming long-distance carpool rides on Seat Sherpa"), states the geographic scope (California and Nevada), and defines the marketplace model that makes the results interpretable (drivers selling empty seats, riders splitting gas). It also explicitly denies a capability ("this tool cannot book"), which separates it from a booking-style tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is clear: supply from/to and optionally a date, omit the date for soonest rides, and expect a request_ride_link fallback when nothing fits. It even routes agents to request_ride_link for the no-match case. It stops short of naming alternatives like get_ride (retrieve a specific ride) or list_service_areas, so an agent must infer when to search vs. look up a known ride.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
cabpool_linksearch_cabpoolspost_ride_link1 field changedInput schema / properties / date / descriptionPrevious value: -"Optional travel date, YYYY-MM-DD (Pacific). Today is 2026-11-02 (Pacific): use today or a later date, and when the person names a day without a year, the next one on or after today. Omit and the driver picks the date on the page."New value: +"Optional travel date, YYYY-MM-DD (Pacific). Today is 2026-11-03 (Pacific): use today or a later date, and when the person names a day without a year, the next one on or after today. Omit and the driver picks the date on the page."request_ride_link1 field changedInput schema / properties / date / descriptionPrevious value: -"Optional travel date, YYYY-MM-DD (Pacific). Today is 2026-11-02 (Pacific): use today or a later date, and when the person names a day without a year, the next one on or after today. Omit and the person picks the date on the page."New value: +"Optional travel date, YYYY-MM-DD (Pacific). Today is 2026-11-03 (Pacific): use today or a later date, and when the person names a day without a year, the next one on or after today. Omit and the person picks the date on the page."search_rides1 field changedInput schema / properties / date / descriptionPrevious value: -"Optional travel date, YYYY-MM-DD (Pacific). Today is 2026-11-02 (Pacific): use today or a later date, and when the person names a day without a year, the next one on or after today. Omit to list the soonest rides."New value: +"Optional travel date, YYYY-MM-DD (Pacific). Today is 2026-11-03 (Pacific): use today or a later date, and when the person names a day without a year, the next one on or after today. Omit to list the soonest rides."post_ride_link1 field changedInput schema / properties / date / descriptionPrevious value: -"Optional travel date, YYYY-MM-DD (Pacific). Today is 2026-11-01 (Pacific): use today or a later date, and when the person names a day without a year, the next one on or after today. Omit and the driver picks the date on the page."New value: +"Optional travel date, YYYY-MM-DD (Pacific). Today is 2026-11-02 (Pacific): use today or a later date, and when the person names a day without a year, the next one on or after today. Omit and the driver picks the date on the page."request_ride_link1 field changedInput schema / properties / date / descriptionPrevious value: -"Optional travel date, YYYY-MM-DD (Pacific). Today is 2026-11-01 (Pacific): use today or a later date, and when the person names a day without a year, the next one on or after today. Omit and the person picks the date on the page."New value: +"Optional travel date, YYYY-MM-DD (Pacific). Today is 2026-11-02 (Pacific): use today or a later date, and when the person names a day without a year, the next one on or after today. Omit and the person picks the date on the page."search_rides1 field changedInput schema / properties / date / descriptionPrevious value: -"Optional travel date, YYYY-MM-DD (Pacific). Today is 2026-11-01 (Pacific): use today or a later date, and when the person names a day without a year, the next one on or after today. Omit to list the soonest rides."New value: +"Optional travel date, YYYY-MM-DD (Pacific). Today is 2026-11-02 (Pacific): use today or a later date, and when the person names a day without a year, the next one on or after today. Omit to list the soonest rides."post_ride_link1 field changedInput schema / properties / date / descriptionPrevious value: -"Optional travel date, YYYY-MM-DD (Pacific). Today is 2026-10-31 (Pacific): use today or a later date, and when the person names a day without a year, the next one on or after today. Omit and the driver picks the date on the page."New value: +"Optional travel date, YYYY-MM-DD (Pacific). Today is 2026-11-01 (Pacific): use today or a later date, and when the person names a day without a year, the next one on or after today. Omit and the driver picks the date on the page."request_ride_link1 field changedInput schema / properties / date / descriptionPrevious value: -"Optional travel date, YYYY-MM-DD (Pacific). Today is 2026-10-31 (Pacific): use today or a later date, and when the person names a day without a year, the next one on or after today. Omit and the person picks the date on the page."New value: +"Optional travel date, YYYY-MM-DD (Pacific). Today is 2026-11-01 (Pacific): use today or a later date, and when the person names a day without a year, the next one on or after today. Omit and the person picks the date on the page."search_rides1 field changedInput schema / properties / date / descriptionPrevious value: -"Optional travel date, YYYY-MM-DD (Pacific). Today is 2026-10-31 (Pacific): use today or a later date, and when the person names a day without a year, the next one on or after today. Omit to list the soonest rides."New value: +"Optional travel date, YYYY-MM-DD (Pacific). Today is 2026-11-01 (Pacific): use today or a later date, and when the person names a day without a year, the next one on or after today. Omit to list the soonest rides."post_ride_link1 field changedInput schema / properties / date / descriptionPrevious value: -"Optional travel date, YYYY-MM-DD (Pacific). Today is 2026-10-30 (Pacific): use today or a later date, and when the person names a day without a year, the next one on or after today. Omit and the driver picks the date on the page."New value: +"Optional travel date, YYYY-MM-DD (Pacific). Today is 2026-10-31 (Pacific): use today or a later date, and when the person names a day without a year, the next one on or after today. Omit and the driver picks the date on the page."request_ride_link1 field changedInput schema / properties / date / descriptionPrevious value: -"Optional travel date, YYYY-MM-DD (Pacific). Today is 2026-10-30 (Pacific): use today or a later date, and when the person names a day without a year, the next one on or after today. Omit and the person picks the date on the page."New value: +"Optional travel date, YYYY-MM-DD (Pacific). Today is 2026-10-31 (Pacific): use today or a later date, and when the person names a day without a year, the next one on or after today. Omit and the person picks the date on the page."search_rides1 field changedInput schema / properties / date / descriptionPrevious value: -"Optional travel date, YYYY-MM-DD (Pacific). Today is 2026-10-30 (Pacific): use today or a later date, and when the person names a day without a year, the next one on or after today. Omit to list the soonest rides."New value: +"Optional travel date, YYYY-MM-DD (Pacific). Today is 2026-10-31 (Pacific): use today or a later date, and when the person names a day without a year, the next one on or after today. Omit to list the soonest rides."post_ride_link1 field changedInput schema / properties / date / descriptionPrevious value: -"Optional travel date, YYYY-MM-DD (Pacific). Today is 2026-10-29 (Pacific): use today or a later date, and when the person names a day without a year, the next one on or after today. Omit and the driver picks the date on the page."New value: +"Optional travel date, YYYY-MM-DD (Pacific). Today is 2026-10-30 (Pacific): use today or a later date, and when the person names a day without a year, the next one on or after today. Omit and the driver picks the date on the page."request_ride_link1 field changedInput schema / properties / date / descriptionPrevious value: -"Optional travel date, YYYY-MM-DD (Pacific). Today is 2026-10-29 (Pacific): use today or a later date, and when the person names a day without a year, the next one on or after today. Omit and the person picks the date on the page."New value: +"Optional travel date, YYYY-MM-DD (Pacific). Today is 2026-10-30 (Pacific): use today or a later date, and when the person names a day without a year, the next one on or after today. Omit and the person picks the date on the page."search_rides1 field changedInput schema / properties / date / descriptionPrevious value: -"Optional travel date, YYYY-MM-DD (Pacific). Today is 2026-10-29 (Pacific): use today or a later date, and when the person names a day without a year, the next one on or after today. Omit to list the soonest rides."New value: +"Optional travel date, YYYY-MM-DD (Pacific). Today is 2026-10-30 (Pacific): use today or a later date, and when the person names a day without a year, the next one on or after today. Omit to list the soonest rides."post_ride_link1 field changedInput schema / properties / date / descriptionPrevious value: -"Optional travel date, YYYY-MM-DD (Pacific). Today is 2026-10-28 (Pacific): use today or a later date, and when the person names a day without a year, the next one on or after today. Omit and the driver picks the date on the page."New value: +"Optional travel date, YYYY-MM-DD (Pacific). Today is 2026-10-29 (Pacific): use today or a later date, and when the person names a day without a year, the next one on or after today. Omit and the driver picks the date on the page."request_ride_link1 field changedInput schema / properties / date / descriptionPrevious value: -"Optional travel date, YYYY-MM-DD (Pacific). Today is 2026-10-28 (Pacific): use today or a later date, and when the person names a day without a year, the next one on or after today. Omit and the person picks the date on the page."New value: +"Optional travel date, YYYY-MM-DD (Pacific). Today is 2026-10-29 (Pacific): use today or a later date, and when the person names a day without a year, the next one on or after today. Omit and the person picks the date on the page."search_rides1 field changedInput schema / properties / date / descriptionPrevious value: -"Optional travel date, YYYY-MM-DD (Pacific). Today is 2026-10-28 (Pacific): use today or a later date, and when the person names a day without a year, the next one on or after today. Omit to list the soonest rides."New value: +"Optional travel date, YYYY-MM-DD (Pacific). Today is 2026-10-29 (Pacific): use today or a later date, and when the person names a day without a year, the next one on or after today. Omit to list the soonest rides."post_ride_link1 field changedInput schema / properties / date / descriptionPrevious value: -"Optional travel date, YYYY-MM-DD (Pacific). Today is 2026-10-27 (Pacific): use today or a later date, and when the person names a day without a year, the next one on or after today. Omit and the driver picks the date on the page."New value: +"Optional travel date, YYYY-MM-DD (Pacific). Today is 2026-10-28 (Pacific): use today or a later date, and when the person names a day without a year, the next one on or after today. Omit and the driver picks the date on the page."request_ride_link1 field changedInput schema / properties / date / descriptionPrevious value: -"Optional travel date, YYYY-MM-DD (Pacific). Today is 2026-10-27 (Pacific): use today or a later date, and when the person names a day without a year, the next one on or after today. Omit and the person picks the date on the page."New value: +"Optional travel date, YYYY-MM-DD (Pacific). Today is 2026-10-28 (Pacific): use today or a later date, and when the person names a day without a year, the next one on or after today. Omit and the person picks the date on the page."search_rides1 field changedInput schema / properties / date / descriptionPrevious value: -"Optional travel date, YYYY-MM-DD (Pacific). Today is 2026-10-27 (Pacific): use today or a later date, and when the person names a day without a year, the next one on or after today. Omit to list the soonest rides."New value: +"Optional travel date, YYYY-MM-DD (Pacific). Today is 2026-10-28 (Pacific): use today or a later date, and when the person names a day without a year, the next one on or after today. Omit to list the soonest rides."post_ride_link1 field changedInput schema / properties / date / descriptionPrevious value: -"Optional travel date, YYYY-MM-DD (Pacific). Today is 2026-10-26 (Pacific): use today or a later date, and when the person names a day without a year, the next one on or after today. Omit and the driver picks the date on the page."New value: +"Optional travel date, YYYY-MM-DD (Pacific). Today is 2026-10-27 (Pacific): use today or a later date, and when the person names a day without a year, the next one on or after today. Omit and the driver picks the date on the page."request_ride_link1 field changedInput schema / properties / date / descriptionPrevious value: -"Optional travel date, YYYY-MM-DD (Pacific). Today is 2026-10-26 (Pacific): use today or a later date, and when the person names a day without a year, the next one on or after today. Omit and the person picks the date on the page."New value: +"Optional travel date, YYYY-MM-DD (Pacific). Today is 2026-10-27 (Pacific): use today or a later date, and when the person names a day without a year, the next one on or after today. Omit and the person picks the date on the page."search_rides1 field changedInput schema / properties / date / descriptionPrevious value: -"Optional travel date, YYYY-MM-DD (Pacific). Today is 2026-10-26 (Pacific): use today or a later date, and when the person names a day without a year, the next one on or after today. Omit to list the soonest rides."New value: +"Optional travel date, YYYY-MM-DD (Pacific). Today is 2026-10-27 (Pacific): use today or a later date, and when the person names a day without a year, the next one on or after today. Omit to list the soonest rides."post_ride_link1 field changedInput schema / properties / date / descriptionPrevious value: -"Optional travel date, YYYY-MM-DD (Pacific). Today is 2026-10-25 (Pacific): use today or a later date, and when the person names a day without a year, the next one on or after today. Omit and the driver picks the date on the page."New value: +"Optional travel date, YYYY-MM-DD (Pacific). Today is 2026-10-26 (Pacific): use today or a later date, and when the person names a day without a year, the next one on or after today. Omit and the driver picks the date on the page."request_ride_link1 field changedInput schema / properties / date / descriptionPrevious value: -"Optional travel date, YYYY-MM-DD (Pacific). Today is 2026-10-25 (Pacific): use today or a later date, and when the person names a day without a year, the next one on or after today. Omit and the person picks the date on the page."New value: +"Optional travel date, YYYY-MM-DD (Pacific). Today is 2026-10-26 (Pacific): use today or a later date, and when the person names a day without a year, the next one on or after today. Omit and the person picks the date on the page."search_rides1 field changedInput schema / properties / date / descriptionPrevious value: -"Optional travel date, YYYY-MM-DD (Pacific). Today is 2026-10-25 (Pacific): use today or a later date, and when the person names a day without a year, the next one on or after today. Omit to list the soonest rides."New value: +"Optional travel date, YYYY-MM-DD (Pacific). Today is 2026-10-26 (Pacific): use today or a later date, and when the person names a day without a year, the next one on or after today. Omit to list the soonest rides."post_ride_link1 field changedInput schema / properties / date / descriptionPrevious value: -"Optional travel date, YYYY-MM-DD (Pacific). Today is 2026-10-24 (Pacific): use today or a later date, and when the person names a day without a year, the next one on or after today. Omit and the driver picks the date on the page."New value: +"Optional travel date, YYYY-MM-DD (Pacific). Today is 2026-10-25 (Pacific): use today or a later date, and when the person names a day without a year, the next one on or after today. Omit and the driver picks the date on the page."request_ride_link1 field changedInput schema / properties / date / descriptionPrevious value: -"Optional travel date, YYYY-MM-DD (Pacific). Today is 2026-10-24 (Pacific): use today or a later date, and when the person names a day without a year, the next one on or after today. Omit and the person picks the date on the page."New value: +"Optional travel date, YYYY-MM-DD (Pacific). Today is 2026-10-25 (Pacific): use today or a later date, and when the person names a day without a year, the next one on or after today. Omit and the person picks the date on the page."search_rides1 field changedInput schema / properties / date / descriptionPrevious value: -"Optional travel date, YYYY-MM-DD (Pacific). Today is 2026-10-24 (Pacific): use today or a later date, and when the person names a day without a year, the next one on or after today. Omit to list the soonest rides."New value: +"Optional travel date, YYYY-MM-DD (Pacific). Today is 2026-10-25 (Pacific): use today or a later date, and when the person names a day without a year, the next one on or after today. Omit to list the soonest rides."post_ride_link1 field changedInput schema / properties / date / descriptionPrevious value: -"Optional travel date, YYYY-MM-DD (Pacific). Today is 2026-10-23 (Pacific): use today or a later date, and when the person names a day without a year, the next one on or after today. Omit and the driver picks the date on the page."New value: +"Optional travel date, YYYY-MM-DD (Pacific). Today is 2026-10-24 (Pacific): use today or a later date, and when the person names a day without a year, the next one on or after today. Omit and the driver picks the date on the page."request_ride_link1 field changedInput schema / properties / date / descriptionPrevious value: -"Optional travel date, YYYY-MM-DD (Pacific). Today is 2026-10-23 (Pacific): use today or a later date, and when the person names a day without a year, the next one on or after today. Omit and the person picks the date on the page."New value: +"Optional travel date, YYYY-MM-DD (Pacific). Today is 2026-10-24 (Pacific): use today or a later date, and when the person names a day without a year, the next one on or after today. Omit and the person picks the date on the page."search_rides1 field changedInput schema / properties / date / descriptionPrevious value: -"Optional travel date, YYYY-MM-DD (Pacific). Today is 2026-10-23 (Pacific): use today or a later date, and when the person names a day without a year, the next one on or after today. Omit to list the soonest rides."New value: +"Optional travel date, YYYY-MM-DD (Pacific). Today is 2026-10-24 (Pacific): use today or a later date, and when the person names a day without a year, the next one on or after today. Omit to list the soonest rides."post_ride_link1 field changedInput schema / properties / date / descriptionPrevious value: -"Optional travel date, YYYY-MM-DD (Pacific). Today is 2026-10-22 (Pacific): use today or a later date, and when the person names a day without a year, the next one on or after today. Omit and the driver picks the date on the page."New value: +"Optional travel date, YYYY-MM-DD (Pacific). Today is 2026-10-23 (Pacific): use today or a later date, and when the person names a day without a year, the next one on or after today. Omit and the driver picks the date on the page."request_ride_link1 field changedInput schema / properties / date / descriptionPrevious value: -"Optional travel date, YYYY-MM-DD (Pacific). Today is 2026-10-22 (Pacific): use today or a later date, and when the person names a day without a year, the next one on or after today. Omit and the person picks the date on the page."New value: +"Optional travel date, YYYY-MM-DD (Pacific). Today is 2026-10-23 (Pacific): use today or a later date, and when the person names a day without a year, the next one on or after today. Omit and the person picks the date on the page."search_rides1 field changedInput schema / properties / date / descriptionPrevious value: -"Optional travel date, YYYY-MM-DD (Pacific). Today is 2026-10-22 (Pacific): use today or a later date, and when the person names a day without a year, the next one on or after today. Omit to list the soonest rides."New value: +"Optional travel date, YYYY-MM-DD (Pacific). Today is 2026-10-23 (Pacific): use today or a later date, and when the person names a day without a year, the next one on or after today. Omit to list the soonest rides."post_ride_link1 field changedInput schema / properties / date / descriptionPrevious value: -"Optional travel date, YYYY-MM-DD (Pacific). Today is 2026-10-21 (Pacific): use today or a later date, and when the person names a day without a year, the next one on or after today. Omit and the driver picks the date on the page."New value: +"Optional travel date, YYYY-MM-DD (Pacific). Today is 2026-10-22 (Pacific): use today or a later date, and when the person names a day without a year, the next one on or after today. Omit and the driver picks the date on the page."request_ride_link1 field changedInput schema / properties / date / descriptionPrevious value: -"Optional travel date, YYYY-MM-DD (Pacific). Today is 2026-10-21 (Pacific): use today or a later date, and when the person names a day without a year, the next one on or after today. Omit and the person picks the date on the page."New value: +"Optional travel date, YYYY-MM-DD (Pacific). Today is 2026-10-22 (Pacific): use today or a later date, and when the person names a day without a year, the next one on or after today. Omit and the person picks the date on the page."search_rides1 field changedInput schema / properties / date / descriptionPrevious value: -"Optional travel date, YYYY-MM-DD (Pacific). Today is 2026-10-21 (Pacific): use today or a later date, and when the person names a day without a year, the next one on or after today. Omit to list the soonest rides."New value: +"Optional travel date, YYYY-MM-DD (Pacific). Today is 2026-10-22 (Pacific): use today or a later date, and when the person names a day without a year, the next one on or after today. Omit to list the soonest rides."post_ride_link1 field changedInput schema / properties / date / descriptionPrevious value: -"Optional travel date, YYYY-MM-DD (Pacific). Today is 2026-10-20 (Pacific): use today or a later date, and when the person names a day without a year, the next one on or after today. Omit and the driver picks the date on the page."New value: +"Optional travel date, YYYY-MM-DD (Pacific). Today is 2026-10-21 (Pacific): use today or a later date, and when the person names a day without a year, the next one on or after today. Omit and the driver picks the date on the page."request_ride_link1 field changedInput schema / properties / date / descriptionPrevious value: -"Optional travel date, YYYY-MM-DD (Pacific). Today is 2026-10-20 (Pacific): use today or a later date, and when the person names a day without a year, the next one on or after today. Omit and the person picks the date on the page."New value: +"Optional travel date, YYYY-MM-DD (Pacific). Today is 2026-10-21 (Pacific): use today or a later date, and when the person names a day without a year, the next one on or after today. Omit and the person picks the date on the page."search_rides1 field changedInput schema / properties / date / descriptionPrevious value: -"Optional travel date, YYYY-MM-DD (Pacific). Today is 2026-10-20 (Pacific): use today or a later date, and when the person names a day without a year, the next one on or after today. Omit to list the soonest rides."New value: +"Optional travel date, YYYY-MM-DD (Pacific). Today is 2026-10-21 (Pacific): use today or a later date, and when the person names a day without a year, the next one on or after today. Omit to list the soonest rides."post_ride_link1 field changedInput schema / properties / date / descriptionPrevious value: -"Optional travel date, YYYY-MM-DD (Pacific). Today is 2026-10-19 (Pacific): use today or a later date, and when the person names a day without a year, the next one on or after today. Omit and the driver picks the date on the page."New value: +"Optional travel date, YYYY-MM-DD (Pacific). Today is 2026-10-20 (Pacific): use today or a later date, and when the person names a day without a year, the next one on or after today. Omit and the driver picks the date on the page."request_ride_link1 field changedInput schema / properties / date / descriptionPrevious value: -"Optional travel date, YYYY-MM-DD (Pacific). Today is 2026-10-19 (Pacific): use today or a later date, and when the person names a day without a year, the next one on or after today. Omit and the person picks the date on the page."New value: +"Optional travel date, YYYY-MM-DD (Pacific). Today is 2026-10-20 (Pacific): use today or a later date, and when the person names a day without a year, the next one on or after today. Omit and the person picks the date on the page."search_rides1 field changedInput schema / properties / date / descriptionPrevious value: -"Optional travel date, YYYY-MM-DD (Pacific). Today is 2026-10-19 (Pacific): use today or a later date, and when the person names a day without a year, the next one on or after today. Omit to list the soonest rides."New value: +"Optional travel date, YYYY-MM-DD (Pacific). Today is 2026-10-20 (Pacific): use today or a later date, and when the person names a day without a year, the next one on or after today. Omit to list the soonest rides."post_ride_link1 field changedInput schema / properties / date / descriptionPrevious value: -"Optional travel date, YYYY-MM-DD (Pacific). Today is 2026-10-18 (Pacific): use today or a later date, and when the person names a day without a year, the next one on or after today. Omit and the driver picks the date on the page."New value: +"Optional travel date, YYYY-MM-DD (Pacific). Today is 2026-10-19 (Pacific): use today or a later date, and when the person names a day without a year, the next one on or after today. Omit and the driver picks the date on the page."request_ride_link1 field changedInput schema / properties / date / descriptionPrevious value: -"Optional travel date, YYYY-MM-DD (Pacific). Today is 2026-10-18 (Pacific): use today or a later date, and when the person names a day without a year, the next one on or after today. Omit and the person picks the date on the page."New value: +"Optional travel date, YYYY-MM-DD (Pacific). Today is 2026-10-19 (Pacific): use today or a later date, and when the person names a day without a year, the next one on or after today. Omit and the person picks the date on the page."search_rides1 field changedInput schema / properties / date / descriptionPrevious value: -"Optional travel date, YYYY-MM-DD (Pacific). Today is 2026-10-18 (Pacific): use today or a later date, and when the person names a day without a year, the next one on or after today. Omit to list the soonest rides."New value: +"Optional travel date, YYYY-MM-DD (Pacific). Today is 2026-10-19 (Pacific): use today or a later date, and when the person names a day without a year, the next one on or after today. Omit to list the soonest rides."post_ride_link1 field changedInput schema / properties / date / descriptionPrevious value: -"Optional travel date, YYYY-MM-DD (Pacific). Today is 2026-10-17 (Pacific): use today or a later date, and when the person names a day without a year, the next one on or after today. Omit and the driver picks the date on the page."New value: +"Optional travel date, YYYY-MM-DD (Pacific). Today is 2026-10-18 (Pacific): use today or a later date, and when the person names a day without a year, the next one on or after today. Omit and the driver picks the date on the page."request_ride_link1 field changedInput schema / properties / date / descriptionPrevious value: -"Optional travel date, YYYY-MM-DD (Pacific). Today is 2026-10-17 (Pacific): use today or a later date, and when the person names a day without a year, the next one on or after today. Omit and the person picks the date on the page."New value: +"Optional travel date, YYYY-MM-DD (Pacific). Today is 2026-10-18 (Pacific): use today or a later date, and when the person names a day without a year, the next one on or after today. Omit and the person picks the date on the page."search_rides1 field changedInput schema / properties / date / descriptionPrevious value: -"Optional travel date, YYYY-MM-DD (Pacific). Today is 2026-10-17 (Pacific): use today or a later date, and when the person names a day without a year, the next one on or after today. Omit to list the soonest rides."New value: +"Optional travel date, YYYY-MM-DD (Pacific). Today is 2026-10-18 (Pacific): use today or a later date, and when the person names a day without a year, the next one on or after today. Omit to list the soonest rides."post_ride_link1 field changedInput schema / properties / date / descriptionPrevious value: -"Optional travel date, YYYY-MM-DD (Pacific). Today is 2026-10-16 (Pacific): use today or a later date, and when the person names a day without a year, the next one on or after today. Omit and the driver picks the date on the page."New value: +"Optional travel date, YYYY-MM-DD (Pacific). Today is 2026-10-17 (Pacific): use today or a later date, and when the person names a day without a year, the next one on or after today. Omit and the driver picks the date on the page."request_ride_link1 field changedInput schema / properties / date / descriptionPrevious value: -"Optional travel date, YYYY-MM-DD (Pacific). Today is 2026-10-16 (Pacific): use today or a later date, and when the person names a day without a year, the next one on or after today. Omit and the person picks the date on the page."New value: +"Optional travel date, YYYY-MM-DD (Pacific). Today is 2026-10-17 (Pacific): use today or a later date, and when the person names a day without a year, the next one on or after today. Omit and the person picks the date on the page."search_rides1 field changedInput schema / properties / date / descriptionPrevious value: -"Optional travel date, YYYY-MM-DD (Pacific). Today is 2026-10-16 (Pacific): use today or a later date, and when the person names a day without a year, the next one on or after today. Omit to list the soonest rides."New value: +"Optional travel date, YYYY-MM-DD (Pacific). Today is 2026-10-17 (Pacific): use today or a later date, and when the person names a day without a year, the next one on or after today. Omit to list the soonest rides."Search minibus trips between Ukraine, Germany and Switzerland. Read-only.
Read-only public transit departures, stop search, and city coverage for bus and train users.
Live Las Vegas shows, restaurants, attractions and resorts. Read-only, no API key needed.
Read-only public itinerary previews, observed round-trip fares, and flight savings verified today.
Add one secure layer between your agents and this server.
