Trvlrr

Name: Trvlrr
Author: sanjaybhagia

by app.trvlrr

Overview Discussions Admin

Server Details

Your travel history and upcoming trips: flights, stays, activities, places, photos and stats.

Ownership verified

Status: Healthy
Uptime: 97.5% over 23 days
OAuth: Works in Glama
Last Tested: 2026-10-23 09:33
Transport: Streamable HTTP · MCP 2025-11-25
URL
Repository: sanjaybhagia/trvlrr-mcp
GitHub Stars: 0
Server Listing: Trvlrr MCP Server

TDQS

A4/5.0

Scored 2026-10-17 08:20 across 10 tools

Disambiguation4/5

Most tools have clearly distinct purposes: read (get_trip, list_trips, get_stats, get_file), write (save_items, update_trip, update_profile), delete, import, and search. There is mild overlap between save_items (adds/updates transport, stay, activity, etc.) and update_trip (trip-level edits plus specialized merge/cancellations/refresh_places operations), but descriptions largely disambiguate. No two tools appear to do the same thing.

Naming Consistency5/5

All ten tools follow a consistent snake_case verb_noun pattern (get_trip, list_trips, save_items, delete_items, search_photos, update_profile, import_trip, etc.). Verbs are used consistently for their operation type (get/list for reads, save/update for writes, delete for removal). No mixing of conventions.

Tool Count5/5

Ten tools is well within the ideal 3-15 range and each maps to a meaningful travel-domain action (trip lifecycle, items, photos, documents, stats, profile). No bloat or redundancy, and no critical operation appears crammed into an overloaded tool beyond update_trip's minor bundling.

Completeness4/5

Coverage is strong: create (import_trip), read (get_trip/list_trips/get_stats/get_file), update (save_items/update_trip/update_profile), delete (delete_items), and search (search_photos). Minor gaps exist, notably no tool for adding/uploading photos and no standalone trip-creation beyond the bulk import path, but agents can work around these.

Available Tools

10 tools

delete_itemsDeleteA

Destructive

Inspect

Permanently delete trips, transport, stays, activities, expenses, packing items, photos or homes. Deleting a trip removes everything in it, including photos and documents. Deletion can't be undone.

ParametersJSON Schema

Name	Required	Description	Default
`items`	Yes	What to delete.

Output Schema

ParametersJSON Schema

Name	Required	Description
`results`	Yes	One result per item: type, id, deleted, error.

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true and readOnlyHint=false, but the description adds genuinely new behavioral context: deletion is permanent and irreversible, and deleting a trip cascades to everything inside it including photos and documents. It stops short of describing permissions or partial-failure behavior, so not a 5.

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?

Three short sentences, front-loaded with the action and its scope, followed by cascade behavior and irreversibility. Nothing is redundant and each sentence adds distinct information.

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?

An output schema exists so return values need no explanation, and annotations carry the safety profile. For a destructive tool, the description supplies the two facts an agent most needs before calling: that deletion is permanent and that trip deletion cascades to nested content.

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% with a single 'items' array parameter whose nested type/id fields are documented and constrained by an enum. The description's list of deletable types mirrors that enum, adding no format, ID syntax, or batch-limit detail beyond the schema, so the baseline 3 applies.

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?

States a specific verb ('permanently delete') and enumerates the exact resource types it operates on (trips, transport, stays, activities, expenses, packing items, photos, homes), which matches the enum in the schema and clearly distinguishes it from siblings like update_trip, save_items, and import_trip.

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

Usage Guidelines3/5

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

The enumerated entity types imply the scope of use, but the description never states when to choose this tool over siblings such as update_trip or save_items, nor does it cover batching or prerequisites. Usage is implied by scope rather than explicitly guided.

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

get_fileOpen a photo or documentA

Read-only

Inspect

Returns a photo (small by default) or a trip document such as an e-ticket or booking PDF. Give photo_id or document_id.

ParametersJSON Schema

Name	Required	Description
`size`	No	For photos: thumb (default) or original.
`photo_id`	No	A photo id.
`document_id`	No	A document id, from a trip's documents.

Output Schema

ParametersJSON Schema

Name	Required	Description
`id`	Yes	The photo or document id.
`kind`	Yes	photo or document.
`mime_type`	Yes	The file's type, e.g. image/jpeg or application/pdf.
`size_bytes`	Yes	The file's size in bytes.

TDQS

A3.5/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds the 'small by default' sizing behavior, but the schema's size field already documents 'thumb (default)', so this adds little beyond structured data.

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?

Two short sentences, front-loaded with what is returned, followed by the identifier hint. Slight redundancy with the schema, but no wasted prose.

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

Completeness4/5

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

For a simple read-only fetch with a full output schema and complete parameter documentation, the description covers the essentials. It could add routing guidance versus search_photos, but nothing critical is missing.

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% and all three parameters are documented in the schema, so the baseline is 3. The description's mention of photo_id/document_id and the default size merely restates what the schema already provides.

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

Purpose4/5

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

The description names a specific verb ('Returns') and the two resource types (photo, trip document) with concrete examples (e-ticket, booking PDF). It is clear what the tool does, but it never distinguishes itself from the sibling search_photos, leaving the agent to infer when to open vs. search.

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

Usage Guidelines3/5

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

Usage is only implied: 'Give photo_id or document_id' tells the agent what to supply but not when to reach for this tool over search_photos, nor any prerequisites. No when-not conditions or alternatives are stated.

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

get_statsTravel statisticsB

Read-only

Inspect

Lifetime numbers over trips that have happened: trips, countries, cities, flights, distance flown and travelled, days away, trips home vs away.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`homes`	No	Homes over the years.
`since`	No	First trip's date.
`trips`	Yes	Trips that have happened.
`cities`	No	Cities visited.
`flights`	No	count, km, hours, airports, airlines.
`distance`	No	Distance in total, by mode and by year.
`countries`	Yes	Countries visited.
`days_away`	No	Days away from home.
`trips_away`	No	Trips elsewhere.
`trips_home`	No	Trips to where home was at the time.

TDQS

B3.4/5.0

Behavior3/5

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

The annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so safety is covered. The description adds one genuinely useful behavioral fact: the numbers cover only trips that have already occurred, excluding planned/upcoming ones. Beyond that it discloses nothing about aggregation window or scope, so a 3 is appropriate.

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?

One sentence, front-loaded with the metric-scope claim and then the enumerated fields. No filler. Slightly dense colon-list style, but every element earns its place.

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

Completeness4/5

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

With an output schema present, the description needn't explain return values, and annotations carry the safety profile. What remains is a zero-parameter read tool whose purpose and data scope are both stated, so an agent has enough to call it correctly.

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

Parameters4/5

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

The tool takes zero parameters and the schema is empty, so there is nothing for the description to clarify; baseline 4 applies. The description correctly signals that no filtering input is expected.

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

Purpose4/5

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

States a specific resource (aggregate travel statistics) and enumerates the exact metrics returned: trips, countries, cities, flights, distance, days away, home vs away. An agent can immediately tell this is the aggregate-summary tool rather than any of the per-trip siblings, though it never names an alternative explicitly.

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

Usage Guidelines2/5

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

The phrase 'trips that have happened' hints at the scope of the data but the description never says when to reach for this tool over list_trips, get_trip, or search_photos. No exclusions or preconditions are stated; the agent must infer that this is the dashboard-summary call.

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

get_tripGet a tripA

Read-only

Inspect

One trip in full — places (with ids), travellers, every transport leg, stay and activity with their ids, documents and a few photos. include adds more: costs (total and every priced item, in currency), packing (the packing list), plan (the planner conversation and open proposals), photos (every photo's id, time and place).

ParametersJSON Schema

Name	Required	Description
`include`	No	What else to include.
`trip_id`	Yes	The trip id.
`currency`	No	ISO currency for costs, e.g. AUD (default USD).

Output Schema

ParametersJSON Schema

Name	Required	Description
`id`	Yes	Trip id.
`plan`	No	With include plan: the planner conversation and open proposals.
`costs`	No	With include costs: the total and every priced item.
`stays`	No	Accommodation.
`title`	No	Title.
`places`	No	Places visited, with ids.
`status`	No	Trip status.
`packing`	No	With include packing: the packing list.
`end_date`	No	Date, YYYY-MM-DD.
`segments`	No	Transport legs: flights, trains, buses, ferries, rentals, drives.
`documents`	No	E-tickets and booking PDFs.
`travelers`	No	Who went.
`all_photos`	No	With include photos: every photo's id, time and place.
`start_date`	No	Date, YYYY-MM-DD.
`experiences`	No	Activities, restaurants, places and notes.

TDQS

A3.6/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds the useful default-vs-optional split (core trip data by default, extras only via include), but says nothing about auth needs, rate limits, or behavior on a missing trip id. With annotations doing the heavy lifting, this is adequate but not rich.

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?

Two sentences, front-loaded with the core payload and then the optional additions. The inventory is dense but every item maps to a real include value or return group, so it earns its space; slight redundancy with the output schema.

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

Completeness4/5

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

An output schema exists, so the description need not document return values, yet it does so helpfully to clarify the default/include split. With full parameter coverage and annotation coverage, an agent has what it needs to call this correctly; only tool-selection routing and failure behavior are absent.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, but the description earns above that by explaining what each include value actually returns ('costs (total and every priced item, in currency)', 'packing', 'plan (the planner conversation and open proposals)', 'photos'). The schema only says 'Extra detail.' and 'What else to include.', so the description adds real meaning.

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

Purpose4/5

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

The description states a specific resource and scope: 'One trip in full' with an enumerated inventory of what that includes. It implicitly distinguishes itself from the plural sibling list_trips, though it never names it. The retrieval verb is implied rather than stated, keeping it just short of a 5.

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

Usage Guidelines3/5

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

There is no explicit when-to-use statement and no alternatives are named, even though siblings like list_trips and search_photos exist. Usage is only implied by the shape of the tool (fetch one trip by id). No exclusions, prerequisites, or routing guidance are given.

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

import_tripImport a tripAInspect

Bring in a trip with all its transport, stays, activities and expenses in one call — from another travel app, a spreadsheet, a calendar or booking emails, given as fields. Creates the trip, or adds to trip_id; then works out the places visited and the drives between them. Returns the new ids and any item that couldn't be added.

ParametersJSON Schema

Name	Required	Description
`trip`	No	The trip to create. Leave out when adding to trip_id.
`stays`	No	Hotels and other accommodation.
`trip_id`	No	Add to this existing trip instead of creating one.
`expenses`	No	Other spending.
`transport`	No	Flights, trains, buses, ferries, rentals, drives.
`activities`	No	Restaurants, places, activities, notes.

Output Schema

ParametersJSON Schema

Name	Required	Description
`added`	No	Each item added: type and id.
`failed`	No	Each item that couldn't be added, and why.
`trip_id`	Yes	The trip the items went to.
`drives_added`	No	Drives inferred between them.
`places_added`	No	Places worked out.
`trip_created`	No	Whether a new trip was made.

TDQS

A4.6/5.0

Behavior5/5

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

Annotations cover the safety profile (readOnly=false, destructive=false, openWorld=false), and the description adds genuinely new behavior: it discloses the derived post-processing ('works out the places visited and the drives between them') and, importantly, partial-failure semantics ('any item that couldn't be added'). These are non-obvious side effects an agent needs before calling it.

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?

Two tight sentences, front-loaded with the core action and scope, then the mode logic and return contract. No filler, no redundancy with the title.

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

Completeness4/5

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

For a six-parameter, deeply nested import tool with an output schema, the description covers purpose, modes, side effects and return summary well. Minor gap: it doesn't say what happens if imported items duplicate existing ones, but the output schema already carries the return detail.

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

Parameters4/5

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 slightly exceeds that by clarifying the mutually-exclusive create-vs-append relationship between the 'trip' payload and 'trip_id', which is the one structural choice an agent must reason about when assembling the call.

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 uses a specific verb ('Bring in a trip') plus the exact resource and enumerates everything it ingests (transport, stays, activities, expenses) in one call. It also names the outcomes ('Creates the trip, or adds to trip_id'), which cleanly separates it from get_trip, update_trip and list_trips.

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 frames the intended sources (another travel app, spreadsheet, calendar, booking emails) and states the two operating modes, so an agent can judge when it applies. It does not, however, explicitly name an alternative tool or give a when-not-to-use condition, so it stops short of a 5.

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

list_tripsList tripsA

Read-only

Inspect

Every trip the person can see, newest first: id, title, dates, status (past, planning, booked, active), places, travellers and photo count.

ParametersJSON Schema

Name	Required	Description	Default
`status`	No	Only trips with this status.

Output Schema

ParametersJSON Schema

Name	Required	Description
`trips`	Yes	Newest first.

TDQS

A3.8/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so safety is covered without description help. The description adds genuinely new behavioral context beyond the annotations: the visibility scope ('the person can see') and the sort order ('newest first').

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?

A single front-loaded sentence listing scope, ordering, and returned fields with zero filler words. Nothing could be cut without losing information.

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

Completeness4/5

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

With an output schema present, the description need not explain return values, yet it summarizes them harmlessly. For a zero-required-parameter list tool the definition is sufficient; only explicit routing against get_trip would make it fully complete.

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% with a single enum-typed status parameter, so the schema already documents it fully. The description restates the status values inline, which is mildly reinforcing but adds no syntax or semantics beyond the enum.

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

Purpose4/5

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

States a clear verb+resource (list every trip) plus a scope qualifier ('the person can see') and enumerates the returned fields, so the agent knows exactly what this produces. It does not explicitly distinguish itself from the similarly-named sibling get_trip, which is the only gap.

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

Usage Guidelines3/5

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

Usage is implied by 'every trip the person can see' plus the optional status filter, so an agent can infer this is the collection-level read. However, it never names get_trip as the single-trip alternative or states when to prefer one over the other.

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

save_itemsAdd or change trip itemsA

Destructive

Inspect

Add or update any number of items in one call. Each item has a type — transport, stay, activity, expense, packing_item or place — and the fields for that type. Include id to update an existing item (only the fields given change); leave id out to add one to trip_id. Places can only be updated (to pin coordinates or fix the city). Returns a result per item.

ParametersJSON Schema

Name	Required	Description	Default
`items`	Yes	The items to add or update.
`trip_id`	No	The trip new items are added to. Not needed when only updating.

Output Schema

ParametersJSON Schema

Name	Required	Description
`saved`	Yes	Items saved.
`failed`	Yes	Items that failed.
`results`	Yes	One result per item, in order: index, type, id, ok, error.

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already declare write/destructive semantics, so the description is not carrying the safety burden alone. It still adds real behavior beyond them: partial-merge semantics ("only the fields given change"), the update-only restriction on places, and per-item result return, which tells the agent to expect partial success rather than an all-or-nothing write.

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?

Four sentences, front-loaded with the core operation, then the type list, then the add-vs-update rule, then the place exception and return shape. No filler and nothing repeated from the title.

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

Completeness4/5

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

Return shape is covered by the output schema and safety by annotations, and the description fills the remaining gaps: item typing, upsert rule, and the place exception. It stops short of stating permission prerequisites or failure semantics for invalid items, but it is sufficient for correct invocation.

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 descriptions on id, type and per-type fields already do the work; the baseline of 3 applies. The description's account of id/trip_id mirrors the schema rather than adding format or constraint detail beyond it.

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?

Specific verb pair (add/update) plus resource (trip items) in the first sentence, then an explicit enumeration of the six supported item types. An agent can immediately tell this apart from delete_items (removal) and update_trip (trip-level edits) without opening any schema.

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?

Clear operating rules: include id to update vs. omit id to add, trip_id needed only for new items, and places are update-only. It does not, however, explicitly compare itself to sibling tools such as delete_items or update_trip, so the agent must infer the boundary rather than being routed.

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

search_photosSearch photosA

Read-only

Inspect

Find photos by describing them — "lighthouse", "ramen", "beach sunset", a person's name. Returns up to 80 matches with id, caption, landmark, date, place and trip — not the images themselves. Trvlrr Plus.

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes	What's in the photo.

Output Schema

ParametersJSON Schema

Name	Required	Description
`photos`	Yes	Up to 80 matches, best first.

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds real value beyond that: a cap of 80 results, the exact metadata fields returned, and the fact that images themselves are not returned. The trailing 'Trvlrr Plus' hints at a plan/premium gate but is too cryptic to count as clear auth disclosure.

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?

Two tight sentences, front-loaded with the verb and examples, followed by the return contract. No filler.

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

Completeness4/5

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

An output schema exists, yet the description still summarizes return fields and the 80-item cap, leaving little ambiguity for a one-parameter search. The only unclarified element is the ambiguous 'Trvlrr Plus' tag.

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

Parameters4/5

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

The schema covers the single 'query' parameter at 100%, and the description goes further by showing the natural-language style expected ('describe them' plus sample phrases), which helps the agent construct good queries beyond the bare 'What's in the photo.'

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?

Specific verb+resource ('Find photos') with concrete query examples and an explicit statement of what is returned. Nothing among the siblings (trips, items, stats, file) overlaps, so the agent can route to it unambiguously.

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 example queries ('lighthouse', 'ramen', a person's name) give clear context for when this tool applies, and the metadata-only return is spelled out. There is no explicit when-not or alternative tool named, but no sibling competes for this job.

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

update_profileProfile, homes and peopleA

DestructiveIdempotent

Inspect

The person's travel profile (how they like to travel), the homes they've lived in over the years (which decide trips home vs away and where planning starts), and the people they travel with. Change any of it; the reply is the current profile, homes, people and plan. With no changes it only returns them.

ParametersJSON Schema

Name	Required	Description
`homes`	No	Homes to add or change.
`people`	No	People to add or rename.
`profile`	No	Travel profile fields to change: pace, budget, interests, dietary needs, what to avoid and more.

Output Schema

ParametersJSON Schema

Name	Required	Description
`you`	No	The person's name.
`plan`	No	free or plus.
`homes`	No	Homes over the years.
`people`	No	People they travel with: id, name, trips.
`profile`	Yes	The travel profile.

TDQS

A3.5/5.0

Behavior3/5

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

Annotations already declare destructiveHint=true, idempotentHint=true and readOnlyHint=false, so the safety profile is covered. The description adds useful behavioral context ('the reply is the current profile, homes, people and plan') and the no-op read behavior, but does not explain what the destructive hint means here (e.g., whether removals are possible) or permission requirements.

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?

Front-loaded with the resource and the mutation action, and the no-op behavior is stated cleanly. The parenthetical domain color ('how they like to travel', 'which decide trips home vs away') is somewhat verbose but not wasteful enough to derail readability.

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

Completeness4/5

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

Given an existing output schema and full annotation coverage, the description needn't explain return values, yet it helpfully summarizes them. For a nested, optional-only mutation tool it is largely complete, with the only gap being explicit guidance on destructive/removal semantics.

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% and every nested field is documented, so the schema carries the parameter burden. The description only generically summarizes profile fields ('pace, budget, interests, dietary needs, what to avoid') without adding format or constraint detail beyond the schema, so baseline 3 applies.

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

Purpose4/5

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

The description names the resource (travel profile, homes, people) and the verb ('Change any of it'), giving a clear picture of what the tool manages. It does not explicitly distinguish itself from siblings like update_trip or save_items, but the resource scope is distinctive enough to be identifiable.

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

Usage Guidelines3/5

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

It implies usage via 'Change any of it' and notes that calling with no changes returns current data, but gives no explicit when-to-use/when-not guidance or reference to alternatives such as update_trip. Usage is inferable but not spelled out.

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

update_tripUpdate a tripA

Destructive

Inspect

Change a trip: title, dates, status, notes, cover photo, travellers (replaces the list). Also: merge_from_trip_id folds another trip into this one and deletes it (irreversible); cancellations settles items flagged as possibly cancelled from a forwarded email (remove deletes them, keep clears the flag); refresh_places re-works out the places visited and the drives between them.

ParametersJSON Schema

Name	Required	Description
`notes`	No	Notes.
`title`	No	Title.
`status`	No	past, planning, booked or active.
`trip_id`	Yes	The trip id.
`end_date`	No	Date, YYYY-MM-DD.
`budget_raw`	No	A budget with currency, e.g. "AUD 8000"; null clears it.
`start_date`	No	Date, YYYY-MM-DD.
`travellers`	No	Who travelled, by name. New names are added to the account's people.
`cancellations`	No	Settle items a forwarded email flagged as possibly cancelled.
`cover_photo_id`	No	A photo id to use as the cover, or "" to clear it.
`refresh_places`	No	Re-derive places and infer drives.
`merge_from_trip_id`	No	A trip to merge into this one; it is deleted afterwards.

Output Schema

ParametersJSON Schema

Name	Required	Description
`merged`	No	The merge, when one was asked for.
`trip_id`	Yes	The trip.
`updated`	No	Fields changed.
`drives_added`	No	Drives inferred.
`places_added`	No	Places worked out.
`cancellations_kept`	No	Flagged items kept.
`cancellations_removed`	No	Flagged items deleted.

TDQS

A4.6/5.0

Behavior5/5

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

Goes well beyond the destructiveHint=true annotation by naming which operations are destructive and how: merge is flagged 'irreversible' and deletes the source trip, travellers 'replaces the list', cancellations 'remove deletes them', and cover_photo/notes clearing are implied. This is exactly the kind of consequence disclosure an agent needs before a write.

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?

Front-loads the core field-update purpose in the first clause, then groups the complex modes after a 'Also:' marker. Dense and semicolon-heavy, but every clause carries distinct operational meaning; no filler sentences.

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 12-parameter mutation tool with nested objects and three destructive sub-modes, the description covers the risky paths and their consequences, and the presence of an output schema means return values need not be explained here. Nothing critical to correct invocation is missing.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning beyond the schema field docs: it explains merge semantics (folds in + deletes), that travellers replaces rather than appends, and the keep/remove distinction for cancellations. Not exhaustive on all 12 params, but materially above baseline.

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?

States a specific verb (change/update) and resource (a trip), then enumerates exactly which fields it mutates and the three special modes it also supports. An agent can distinguish this from get_trip (read) and delete_items (delete) without opening a schema.

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?

Gives clear conditions for the non-obvious modes: merge_from_trip_id folds a trip in and deletes it, cancellations settles email-flagged items, refresh_places re-derives places/drives. It does not explicitly name alternatives (e.g. 'use get_trip to read first' or 'use delete_items for items'), so it stops short of full when/when-not routing.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

3 tool updatesOct 9, 2026

Changedimport_trip11 fields changed

addedInput schema / properties / activities / items / properties / payment_method

Added value: +{
+  "description": "card or cash.",
+  "enum": [
+    "card",
+    "cash"
+  ],
+  "type": [
+    "string",
+    "null"
+  ]
+}

addedInput schema / properties / activities / items / properties / payment_status

Added value: +{
+  "description": "paid, due (to pay before the trip) or on_arrival (pay there or on the day).",
+  "enum": [
+    "paid",
+    "due",
+    "on_arrival"
+  ],
+  "type": [
+    "string",
+    "null"
+  ]
+}

addedInput schema / properties / activities / items / properties / remind_on

Added value: +{
+  "description": "A day to be reminded about it. Date, YYYY-MM-DD. null clears it.",
+  "pattern": "^\\d{4}-\\d{2}-\\d{2}$",
+  "type": [
+    "string",
+    "null"
+  ]
+}

addedInput schema / properties / activities / items / properties / remind_time

Added value: +{
+  "description": "Time of day for the reminder, \"HH:MM\" local; empty means 09:00.",
+  "pattern": "^\\d{2}:\\d{2}$",
+  "type": [
+    "string",
+    "null"
+  ]
+}

addedInput schema / properties / stays / items / properties / check_in_time

Added value: +{
+  "description": "Check-in time, HH:MM local; empty means mid-afternoon.",
+  "type": [
+    "string",
+    "null"
+  ]
+}

addedInput schema / properties / stays / items / properties / check_out_time

Added value: +{
+  "description": "Check-out time, HH:MM local; empty means late morning.",
+  "type": [
+    "string",
+    "null"
+  ]
+}

addedInput schema / properties / stays / items / properties / payment_method

Added value: +{
+  "description": "card or cash.",
+  "enum": [
+    "card",
+    "cash"
+  ],
+  "type": [
+    "string",
+    "null"
+  ]
+}

addedInput schema / properties / stays / items / properties / payment_status

Added value: +{
+  "description": "paid, due (to pay before the trip) or on_arrival (pay there or on the day).",
+  "enum": [
+    "paid",
+    "due",
+    "on_arrival"
+  ],
+  "type": [
+    "string",
+    "null"
+  ]
+}

addedInput schema / properties / transport / items / properties / payment_method

Added value: +{
+  "description": "card or cash.",
+  "enum": [
+    "card",
+    "cash"
+  ],
+  "type": [
+    "string",
+    "null"
+  ]
+}

addedInput schema / properties / transport / items / properties / payment_status

Added value: +{
+  "description": "paid, due (to pay before the trip) or on_arrival (pay there or on the day).",
+  "enum": [
+    "paid",
+    "due",
+    "on_arrival"
+  ],
+  "type": [
+    "string",
+    "null"
+  ]
+}

addedInput schema / properties / trip / properties / budget_raw

Added value: +{
+  "description": "A budget with currency, e.g. \"AUD 8000\"; null clears it.",
+  "type": [
+    "string",
+    "null"
+  ]
+}

Changedsave_items1 field changed

changedInput schema / properties / items / items / anyOf

Previous value: -[
-  {
-    "description": "A flight, train, bus, ferry, car rental or drive. mode is required when adding.",
-    "properties": {
-      "agency": {
-        "description": "Booked through (travel agency or site).",
-        "type": [
-          "string",
-          "null"
-        ]
-      },
-      "aircraft": {
-        "description": "Aircraft type.",
-        "type": [
-          "string",
-          "null"
-        ]
-      },
-      "arrive_terminal": {
-        "description": "Arrival terminal.",
-        "type": [
-          "string",
-          "null"
-        ]
-      },
-      "arrive_time": {
-        "description": "Local arrival time \"HH:MM\", with \" +N\" if it lands N days after departure, e.g. \"05:20 +1\".",
-        "type": [
-          "string",
-          "null"
-        ]
-      },
-      "arrive_tz": {
-        "description": "IANA time zone at arrival.",
-        "type": [
-          "string",
-          "null"
-        ]
-      },
-      "booking_ref": {
-        "description": "Booking or confirmation reference.",
-        "type": [
-          "string",
-          "null"
-        ]
-      },
-      "cabin": {
-        "description": "Cabin or class.",
-        "type": [
-          "string",
-          "null"
-        ]
-      },
-      "depart_date": {
-        "description": "Departure date. Date, YYYY-MM-DD.",
-        "type": [
-          "string",
-          "null"
-        ]
-      },
-      "depart_terminal": {
-        "description": "Departure terminal.",
-        "type": [
-          "string",
-          "null"
-        ]
-      },
-      "depart_time": {
-        "description": "Local departure time \"HH:MM\".",
-        "type": [
-          "string",
-          "null"
-        ]
-      },
-      "depart_tz": {
-        "description": "IANA time zone at departure, e.g. Australia/Sydney.",
-        "type": [
-          "string",
-          "null"
-        ]
-      },
-      "distance_km": {
-        "description": "Distance in km, if known.",
-        "type": [
-          "number",
-          "null"
-        ]
-      },
-      "from_code": {
-        "description": "Departure airport or station code, e.g. SYD.",
-        "type": [
-          "string",
-          "null"
-        ]
-      },
-      "from_country": {
-        "description": "Country it leaves from (name or ISO code).",
-        "type": [
-          "string",
-          "null"
-        ]
-      },
-      "from_place": {
-        "description": "Where it leaves from, e.g. Sydney or Sydney Airport.",
-        "type": [
-          "string",
-          "null"
-        ]
-      },
-      "id": {
-        "description": "Give the transport's id to update it; leave out to add one.",
-        "type": "string"
-      },
-      "mode": {
-        "description": "How: flight, train, bus, ferry, car_rental, drive or other.",
-        "enum": [
-          "flight",
-          "train",
-          "bus",
-          "ferry",
-          "car_rental",
-          "drive",
-          "other"
-        ],
-        "type": "string"
-      },
-      "notes": {
-        "description": "Anything else worth keeping.",
-        "type": [
-          "string",
-          "null"
-        ]
-      },
-      "operating_carrier": {
-        "description": "Operating carrier if different from the provider.",
-        "type": [
-          "string",
-          "null"
-        ]
-      },
-      "price_raw": {
-        "description": "Price with currency, e.g. \"AUD 420.00\".",
-        "type": [
-          "string",
-          "null"
-        ]
-      },
-      "provider": {
-        "description": "Airline, rail operator, bus or rental company, e.g. Qantas.",
-        "type": [
-          "string",
-          "null"
-        ]
-      },
-      "seats": {
-        "description": "Seat numbers.",
-        "type": [
-          "string",
-          "null"
-        ]
-      },
-      "service": {
-        "description": "Flight or service number, e.g. QF1.",
-        "type": [
-          "string",
-          "null"
-        ]
-      },
-      "status": {
-        "description": "Free text, e.g. \"Confirmed\".",
-        "type": [
-          "string",
-          "null"
-        ]
-      },
-      "ticket_numbers": {
-        "description": "Ticket numbers.",
-        "type": [
-          "string",
-          "null"
-        ]
-      },
-      "to_code": {
-        "description": "Arrival airport or station code, e.g. LHR.",
-        "type": [
-          "string",
-          "null"
-        ]
-      },
-      "to_country": {
-        "description": "Country it arrives in.",
-        "type": [
-          "string",
-          "null"
-        ]
-      },
-      "to_place": {
-        "description": "Where it arrives.",
-        "type": [
-          "string",
-          "null"
-        ]
-      },
-      "travellers": {
-        "description": "Who travelled, by name. New names are added to the account's people.",
-        "items": {
-          "description": "A person's name, or \"me\".",
-          "type": "string"
-        },
-        "type": "array"
-      },
-      "type": {
-        "const": "transport",
-        "description": "Always \"transport\".",
-        "type": "string"
-      }
-    },
-    "required": [
-      "type"
-    ],
-    "type": "object"
-  },
-  {
-    "description": "Accommodation. property is required when adding.",
-    "properties": {
-      "address": {
-        "description": "Street address.",
-        "type": [
-          "string",
-          "null"
-        ]
-      },
-      "agency": {
-        "description": "Booked through.",
-        "type": [
-          "string",
-          "null"
-        ]
-      },
-      "booking_ref": {
-        "description": "Confirmation number.",
-        "type": [
-          "string",
-          "null"
-        ]
-      },
-      "check_in": {
-        "description": "Check-in date. Date, YYYY-MM-DD.",
-        "type": [
-          "string",
-          "null"
-        ]
-      },
-      "check_out": {
-        "description": "Check-out date. Date, YYYY-MM-DD.",
-        "type": [
-          "string",
-          "null"
-        ]
-      },
-      "city": {
-        "description": "City the stay is in.",
-        "type": [
-          "string",
-          "null"
-        ]
-      },
-      "country": {
-        "description": "Country (name or ISO code).",
-        "type": [
-          "string",
-          "null"
-        ]
-      },
-      "guests": {
-        "description": "Number of guests.",
-        "maximum": 9007199254740991,
-        "minimum": -9007199254740991,
-        "type": [
-          "integer",
-          "null"
-        ]
-      },
-      "id": {
-        "description": "Give the stay's id to update it; leave out to add one.",
-        "type": "string"
-      },
-      "lat": {
-        "description": "Latitude.",
-        "type": [
-          "number",
-          "null"
-        ]
-      },
-      "locality": {
-        "description": "The city it belongs to, when the label is a suburb or area.",
-        "type": [
-          "string",
-          "null"
-        ]
-      },
-      "locality_country": {
-        "description": "ISO alpha-2 of that city.",
-        "type": [
-          "string",
-          "null"
-        ]
-      },
-      "lon": {
-        "description": "Longitude.",
-        "type": [
-          "number",
-          "null"
-        ]
-      },
-      "notes": {
-        "description": "Anything else worth keeping.",
-        "type": [
-          "string",
-          "null"
-        ]
-      },
-      "price_raw": {
-        "description": "Price with currency, e.g. \"EUR 540\".",
-        "type": [
-          "string",
-          "null"
-        ]
-      },
-      "property": {
-        "description": "Hotel or place name.",
-        "minLength": 1,
-        "type": "string"
-      },
-      "provider": {
-        "description": "Booked with, e.g. Booking.com or the hotel chain.",
-        "type": [
-          "string",
-          "null"
-        ]
-      },
-      "room_type": {
-        "description": "Room type.",
-        "type": [
-          "string",
-          "null"
-        ]
-      },
-      "status": {
-        "description": "Free text, e.g. \"Confirmed\".",
-        "type": [
-          "string",
-          "null"
-        ]
-      },
-      "travellers": {
-        "description": "Who travelled, by name. New names are added to the account's people.",
-        "items": {
-          "description": "A person's name, or \"me\".",
-          "type": "string"
-        },
-        "type": "array"
-      },
-      "type": {
-        "const": "stay",
-        "description": "Always \"stay\".",
-        "type": "string"
-      },
-      "tz": {
-        "description": "IANA time zone.",
-        "type": [
-          "string",
-          "null"
-        ]
-      }
-    },
-    "required": [
-      "type"
-    ],
-    "type": "object"
-  },
-  {
-    "description": "A restaurant, place, activity or note. kind and name are required when adding; name, kind and city can't be changed later. Updates can also set done and journal.",
-    "properties": {
-      "category": {
-        "description": "restaurant, cafe, bar, attraction, museum, tour, concert, theatre, sport, nature, beach, spa, shopping, meeting, parking or place.",
-        "type": [
-          "string",
-          "null"
-        ]
-      },
-      "city": {
-        "description": "City.",
-        "type": [
-          "string",
-          "null"
-        ]
-      },
-      "country": {
-        "description": "Country (name or ISO code).",
-        "type": [
-          "string",
-          "null"
-        ]
-      },
-      "date": {
-        "description": "Date, YYYY-MM-DD. Optional.",
-        "type": [
-          "string",
-          "null"
-        ]
-      },
-      "done": {
-        "description": "Done (updates only).",
-        "type": "boolean"
-      },
-      "id": {
-        "description": "Give the activity's id to update it; leave out to add one.",
-        "type": "string"
-      },
-      "journal": {
-        "description": "A journal entry about it (updates only).",
-        "type": [
-          "string",
-          "null"
-        ]
-      },
-      "kind": {
-        "description": "restaurant, place, activity or note.",
-        "enum": [
-          "restaurant",
-          "place",
-          "activity",
-          "note"
-        ],
-        "type": "string"
-      },
-      "lat": {
-        "description": "Latitude.",
-        "type": [
-          "number",
-          "null"
-        ]
-      },
-      "lon": {
-        "description": "Longitude.",
-        "type": [
-          "number",
-          "null"
-        ]
-      },
-      "name": {
-        "description": "What it is, e.g. teamLab Planets or Sukiyabashi Jiro.",
-        "minLength": 1,
-        "type": "string"
-      },
-      "note": {
-        "description": "A note about it.",
-        "type": [
-          "string",
-          "null"
-        ]
-      },
-      "price_raw": {
-        "description": "Price with currency.",
-        "type": [
-          "string",
-          "null"
-        ]
-      },
-      "rating": {
-        "description": "1–5, for places already visited.",
-        "maximum": 5,
-        "minimum": 1,
-        "type": [
-          "integer",
-          "null"
-        ]
-      },
-      "time": {
-        "description": "Local time \"HH:MM\". Optional.",
-        "type": [
-          "string",
-          "null"
-        ]
-      },
-      "type": {
-        "const": "activity",
-        "description": "Always \"activity\".",
-        "type": "string"
-      },
-      "tz": {
-        "description": "IANA time zone.",
-        "type": [
-          "string",
-          "null"
-        ]
-      }
-    },
-    "required": [
-      "type"
-    ],
-    "type": "object"
-  },
-  {
-    "description": "Spending that isn't a booking. Can only be added.",
-    "properties": {
-      "category": {
-        "description": "food, transport, stay, activity, shopping or other.",
-        "enum": [
-          "food",
-          "transport",
-          "stay",
-          "activity",
-          "shopping",
-          "other"
-        ],
-        "type": "string"
-      },
-      "date": {
-        "description": "Date, YYYY-MM-DD. Optional.",
-        "type": [
-          "string",
-          "null"
-        ]
-      },
-      "description": {
-        "description": "What the money went on.",
-        "minLength": 1,
-        "type": "string"
-      },
-      "id": {
-        "description": "Give the expense's id to update it; leave out to add one.",
-        "type": "string"
-      },
-      "price_raw": {
-        "description": "Amount with currency, e.g. \"JPY 3400\" or \"$25\".",
-        "minLength": 1,
-        "type": "string"
-      },
-      "type": {
-        "const": "expense",
-        "description": "Always \"expense\".",
-        "type": "string"
-      }
-    },
-    "required": [
-      "type"
-    ],
-    "type": "object"
-  },
-  {
-    "description": "A packing-list entry (Trvlrr Plus). text is required when adding.",
-    "properties": {
-      "done": {
-        "description": "Packed.",
-        "type": "boolean"
-      },
-      "id": {
-        "description": "Give the packing_item's id to update it; leave out to add one.",
-        "type": "string"
-      },
-      "section": {
-        "description": "documents, clothing, tech, health or other.",
-        "enum": [
-          "documents",
-          "clothing",
-          "tech",
-          "health",
-          "other"
-        ],
-        "type": "string"
-      },
-      "text": {
-        "description": "The item.",
-        "minLength": 1,
-        "type": "string"
-      },
-      "type": {
-        "const": "packing_item",
-        "description": "Always \"packing_item\".",
-        "type": "string"
-      }
-    },
-    "required": [
-      "type"
-    ],
-    "type": "object"
-  },
-  {
-    "description": "A place a trip visited, by its id from the trip's places. Update only.",
-    "properties": {
-      "country": {
-        "description": "Country.",
-        "minLength": 1,
-        "type": "string"
-      },
-      "id": {
-        "description": "Give the place's id to update it; leave out to add one.",
-        "type": "string"
-      },
-      "lat": {
-        "description": "Latitude.",
-        "maximum": 90,
-        "minimum": -90,
-        "type": "number"
-      },
-      "locality": {
-        "description": "The city it belongs to.",
-        "minLength": 1,
-        "type": "string"
-      },
-      "locality_country": {
-        "description": "ISO alpha-2 of that city.",
-        "pattern": "^[A-Za-z]{2}$",
-        "type": "string"
-      },
-      "lon": {
-        "description": "Longitude.",
-        "maximum": 180,
-        "minimum": -180,
-        "type": "number"
-      },
-      "type": {
-        "const": "place",
-        "description": "Always \"place\".",
-        "type": "string"
-      }
-    },
-    "required": [
-      "type"
-    ],
-    "type": "object"
-  }
-]New value: +[
+  {
+    "description": "A flight, train, bus, ferry, car rental or drive. mode is required when adding.",
+    "properties": {
+      "agency": {
+        "description": "Booked through (travel agency or site).",
+        "type": [
+          "string",
+          "null"
+        ]
+      },
+      "aircraft": {
+        "description": "Aircraft type.",
+        "type": [
+          "string",
+          "null"
+        ]
+      },
+      "arrive_terminal": {
+        "description": "Arrival terminal.",
+        "type": [
+          "string",
+          "null"
+        ]
+      },
+      "arrive_time": {
+        "description": "Local arrival time \"HH:MM\", with \" +N\" if it lands N days after departure, e.g. \"05:20 +1\".",
+        "type": [
+          "string",
+          "null"
+        ]
+      },
+      "arrive_tz": {
+        "description": "IANA time zone at arrival.",
+        "type": [
+          "string",
+          "null"
+        ]
+      },
+      "booking_ref": {
+        "description": "Booking or confirmation reference.",
+        "type": [
+          "string",
+          "null"
+        ]
+      },
+      "cabin": {
+        "description": "Cabin or class.",
+        "type": [
+          "string",
+          "null"
+        ]
+      },
+      "depart_date": {
+        "description": "Departure date. Date, YYYY-MM-DD.",
+        "type": [
+          "string",
+          "null"
+        ]
+      },
+      "depart_terminal": {
+        "description": "Departure terminal.",
+        "type": [
+          "string",
+          "null"
+        ]
+      },
+      "depart_time": {
+        "description": "Local departure time \"HH:MM\".",
+        "type": [
+          "string",
+          "null"
+        ]
+      },
+      "depart_tz": {
+        "description": "IANA time zone at departure, e.g. Australia/Sydney.",
+        "type": [
+          "string",
+          "null"
+        ]
+      },
+      "distance_km": {
+        "description": "Distance in km, if known.",
+        "type": [
+          "number",
+          "null"
+        ]
+      },
+      "from_code": {
+        "description": "Departure airport or station code, e.g. SYD.",
+        "type": [
+          "string",
+          "null"
+        ]
+      },
+      "from_country": {
+        "description": "Country it leaves from (name or ISO code).",
+        "type": [
+          "string",
+          "null"
+        ]
+      },
+      "from_place": {
+        "description": "Where it leaves from, e.g. Sydney or Sydney Airport.",
+        "type": [
+          "string",
+          "null"
+        ]
+      },
+      "id": {
+        "description": "Give the transport's id to update it; leave out to add one.",
+        "type": "string"
+      },
+      "mode": {
+        "description": "How: flight, train, bus, ferry, car_rental, drive or other.",
+        "enum": [
+          "flight",
+          "train",
+          "bus",
+          "ferry",
+          "car_rental",
+          "drive",
+          "other"
+        ],
+        "type": "string"
+      },
+      "notes": {
+        "description": "Anything else worth keeping.",
+        "type": [
+          "string",
+          "null"
+        ]
+      },
+      "operating_carrier": {
+        "description": "Operating carrier if different from the provider.",
+        "type": [
+          "string",
+          "null"
+        ]
+      },
+      "payment_method": {
+        "description": "card or cash.",
+        "enum": [
+          "card",
+          "cash"
+        ],
+        "type": [
+          "string",
+          "null"
+        ]
+      },
+      "payment_status": {
+        "description": "paid, due (to pay before the trip) or on_arrival (pay there or on the day).",
+        "enum": [
+          "paid",
+          "due",
+          "on_arrival"
+        ],
+        "type": [
+          "string",
+          "null"
+        ]
+      },
+      "price_raw": {
+        "description": "Price with currency, e.g. \"AUD 420.00\".",
+        "type": [
+          "string",
+          "null"
+        ]
+      },
+      "provider": {
+        "description": "Airline, rail operator, bus or rental company, e.g. Qantas.",
+        "type": [
+          "string",
+          "null"
+        ]
+      },
+      "seats": {
+        "description": "Seat numbers.",
+        "type": [
+          "string",
+          "null"
+        ]
+      },
+      "service": {
+        "description": "Flight or service number, e.g. QF1.",
+        "type": [
+          "string",
+          "null"
+        ]
+      },
+      "status": {
+        "description": "Free text, e.g. \"Confirmed\".",
+        "type": [
+          "string",
+          "null"
+        ]
+      },
+      "ticket_numbers": {
+        "description": "Ticket numbers.",
+        "type": [
+          "string",
+          "null"
+        ]
+      },
+      "to_code": {
+        "description": "Arrival airport or station code, e.g. LHR.",
+        "type": [
+          "string",
+          "null"
+        ]
+      },
+      "to_country": {
+        "description": "Country it arrives in.",
+        "type": [
+          "string",
+          "null"
+        ]
+      },
+      "to_place": {
+        "description": "Where it arrives.",
+        "type": [
+          "string",
+          "null"
+        ]
+      },
+      "travellers": {
+        "description": "Who travelled, by name. New names are added to the account's people.",
+        "items": {
+          "description": "A person's name, or \"me\".",
+          "type": "string"
+        },
+        "type": "array"
+      },
+      "type": {
+        "const": "transport",
+        "description": "Always \"transport\".",
+        "type": "string"
+      }
+    },
+    "required": [
+      "type"
+    ],
+    "type": "object"
+  },
+  {
+    "description": "Accommodation. property is required when adding.",
+    "properties": {
+      "address": {
+        "description": "Street address.",
+        "type": [
+          "string",
+          "null"
+        ]
+      },
+      "agency": {
+        "description": "Booked through.",
+        "type": [
+          "string",
+          "null"
+        ]
+      },
+      "booking_ref": {
+        "description": "Confirmation number.",
+        "type": [
+          "string",
+          "null"
+        ]
+      },
+      "check_in": {
+        "description": "Check-in date. Date, YYYY-MM-DD.",
+        "type": [
+          "string",
+          "null"
+        ]
+      },
+      "check_in_time": {
+        "description": "Check-in time, HH:MM local; empty means mid-afternoon.",
+        "type": [
+          "string",
+          "null"
+        ]
+      },
+      "check_out": {
+        "description": "Check-out date. Date, YYYY-MM-DD.",
+        "type": [
+          "string",
+          "null"
+        ]
+      },
+      "check_out_time": {
+        "description": "Check-out time, HH:MM local; empty means late morning.",
+        "type": [
+          "string",
+          "null"
+        ]
+      },
+      "city": {
+        "description": "City the stay is in.",
+        "type": [
+          "string",
+          "null"
+        ]
+      },
+      "country": {
+        "description": "Country (name or ISO code).",
+        "type": [
+          "string",
+          "null"
+        ]
+      },
+      "guests": {
+        "description": "Number of guests.",
+        "maximum": 9007199254740991,
+        "minimum": -9007199254740991,
+        "type": [
+          "integer",
+          "null"
+        ]
+      },
+      "id": {
+        "description": "Give the stay's id to update it; leave out to add one.",
+        "type": "string"
+      },
+      "lat": {
+        "description": "Latitude.",
+        "type": [
+          "number",
+          "null"
+        ]
+      },
+      "locality": {
+        "description": "The city it belongs to, when the label is a suburb or area.",
+        "type": [
+          "string",
+          "null"
+        ]
+      },
+      "locality_country": {
+        "description": "ISO alpha-2 of that city.",
+        "type": [
+          "string",
+          "null"
+        ]
+      },
+      "lon": {
+        "description": "Longitude.",
+        "type": [
+          "number",
+          "null"
+        ]
+      },
+      "notes": {
+        "description": "Anything else worth keeping.",
+        "type": [
+          "string",
+          "null"
+        ]
+      },
+      "payment_method": {
+        "description": "card or cash.",
+        "enum": [
+          "card",
+          "cash"
+        ],
+        "type": [
+          "string",
+          "null"
+        ]
+      },
+      "payment_status": {
+        "description": "paid, due (to pay before the trip) or on_arrival (pay there or on the day).",
+        "enum": [
+          "paid",
+          "due",
+          "on_arrival"
+        ],
+        "type": [
+          "string",
+          "null"
+        ]
+      },
+      "price_raw": {
+        "description": "Price with currency, e.g. \"EUR 540\".",
+        "type": [
+          "string",
+          "null"
+        ]
+      },
+      "property": {
+        "description": "Hotel or place name.",
+        "minLength": 1,
+        "type": "string"
+      },
+      "provider": {
+        "description": "Booked with, e.g. Booking.com or the hotel chain.",
+        "type": [
+          "string",
+          "null"
+        ]
+      },
+      "room_type": {
+        "description": "Room type.",
+        "type": [
+          "string",
+          "null"
+        ]
+      },
+      "status": {
+        "description": "Free text, e.g. \"Confirmed\".",
+        "type": [
+          "string",
+          "null"
+        ]
+      },
+      "travellers": {
+        "description": "Who travelled, by name. New names are added to the account's people.",
+        "items": {
+          "description": "A person's name, or \"me\".",
+          "type": "string"
+        },
+        "type": "array"
+      },
+      "type": {
+        "const": "stay",
+        "description": "Always \"stay\".",
+        "type": "string"
+      },
+      "tz": {
+        "description": "IANA time zone.",
+        "type": [
+          "string",
+          "null"
+        ]
+      }
+    },
+    "required": [
+      "type"
+    ],
+    "type": "object"
+  },
+  {
+    "description": "A restaurant, place, activity or note. kind and name are required when adding; name, kind and city can't be changed later. Updates can also set done and journal.",
+    "properties": {
+      "category": {
+        "description": "restaurant, cafe, bar, attraction, museum, tour, concert, theatre, sport, nature, beach, spa, shopping, meeting, parking or place.",
+        "type": [
+          "string",
+          "null"
+        ]
+      },
+      "city": {
+        "description": "City.",
+        "type": [
+          "string",
+          "null"
+        ]
+      },
+      "country": {
+        "description": "Country (name or ISO code).",
+        "type": [
+          "string",
+          "null"
+        ]
+      },
+      "date": {
+        "description": "Date, YYYY-MM-DD. Optional.",
+        "type": [
+          "string",
+          "null"
+        ]
+      },
+      "done": {
+        "description": "Done (updates only).",
+        "type": "boolean"
+      },
+      "id": {
+        "description": "Give the activity's id to update it; leave out to add one.",
+        "type": "string"
+      },
+      "journal": {
+        "description": "A journal entry about it (updates only).",
+        "type": [
+          "string",
+          "null"
+        ]
+      },
+      "kind": {
+        "description": "restaurant, place, activity or note.",
+        "enum": [
+          "restaurant",
+          "place",
+          "activity",
+          "note"
+        ],
+        "type": "string"
+      },
+      "lat": {
+        "description": "Latitude.",
+        "type": [
+          "number",
+          "null"
+        ]
+      },
+      "lon": {
+        "description": "Longitude.",
+        "type": [
+          "number",
+          "null"
+        ]
+      },
+      "name": {
+        "description": "What it is, e.g. teamLab Planets or Sukiyabashi Jiro.",
+        "minLength": 1,
+        "type": "string"
+      },
+      "note": {
+        "description": "A note about it.",
+        "type": [
+          "string",
+          "null"
+        ]
+      },
+      "payment_method": {
+        "description": "card or cash.",
+        "enum": [
+          "card",
+          "cash"
+        ],
+        "type": [
+          "string",
+          "null"
+        ]
+      },
+      "payment_status": {
+        "description": "paid, due (to pay before the trip) or on_arrival (pay there or on the day).",
+        "enum": [
+          "paid",
+          "due",
+          "on_arrival"
+        ],
+        "type": [
+          "string",
+          "null"
+        ]
+      },
+      "price_raw": {
+        "description": "Price with currency.",
+        "type": [
+          "string",
+          "null"
+        ]
+      },
+      "rating": {
+        "description": "1–5, for places already visited.",
+        "maximum": 5,
+        "minimum": 1,
+        "type": [
+          "integer",
+          "null"
+        ]
+      },
+      "remind_on": {
+        "description": "A day to be reminded about it. Date, YYYY-MM-DD. null clears it.",
+        "pattern": "^\\d{4}-\\d{2}-\\d{2}$",
+        "type": [
+          "string",
+          "null"
+        ]
+      },
+      "remind_time": {
+        "description": "Time of day for the reminder, \"HH:MM\" local; empty means 09:00.",
+        "pattern": "^\\d{2}:\\d{2}$",
+        "type": [
+          "string",
+          "null"
+        ]
+      },
+      "time": {
+        "description": "Local time \"HH:MM\". Optional.",
+        "type": [
+          "string",
+          "null"
+        ]
+      },
+      "type": {
+        "const": "activity",
+        "description": "Always \"activity\".",
+        "type": "string"
+      },
+      "tz": {
+        "description": "IANA time zone.",
+        "type": [
+          "string",
+          "null"
+        ]
+      }
+    },
+    "required": [
+      "type"
+    ],
+    "type": "object"
+  },
+  {
+    "description": "Spending that isn't a booking. Can only be added.",
+    "properties": {
+      "category": {
+        "description": "food, transport, stay, activity, shopping or other.",
+        "enum": [
+          "food",
+          "transport",
+          "stay",
+          "activity",
+          "shopping",
+          "other"
+        ],
+        "type": "string"
+      },
+      "date": {
+        "description": "Date, YYYY-MM-DD. Optional.",
+        "type": [
+          "string",
+          "null"
+        ]
+      },
+      "description": {
+        "description": "What the money went on.",
+        "minLength": 1,
+        "type": "string"
+      },
+      "id": {
+        "description": "Give the expense's id to update it; leave out to add one.",
+        "type": "string"
+      },
+      "price_raw": {
+        "description": "Amount with currency, e.g. \"JPY 3400\" or \"$25\".",
+        "minLength": 1,
+        "type": "string"
+      },
+      "type": {
+        "const": "expense",
+        "description": "Always \"expense\".",
+        "type": "string"
+      }
+    },
+    "required": [
+      "type"
+    ],
+    "type": "object"
+  },
+  {
+    "description": "A packing-list entry (Trvlrr Plus). text is required when adding.",
+    "properties": {
+      "done": {
+        "description": "Packed.",
+        "type": "boolean"
+      },
+      "id": {
+        "description": "Give the packing_item's id to update it; leave out to add one.",
+        "type": "string"
+      },
+      "remind_on": {
+        "description": "A day to be reminded about it. Date, YYYY-MM-DD. null clears it.",
+        "pattern": "^\\d{4}-\\d{2}-\\d{2}$",
+        "type": [
+          "string",
+          "null"
+        ]
+      },
+      "remind_time": {
+        "description": "Time of day for the reminder, \"HH:MM\" local; empty means 09:00.",
+        "pattern": "^\\d{2}:\\d{2}$",
+        "type": [
+          "string",
+          "null"
+        ]
+      },
+      "section": {
+        "description": "documents, clothing, tech, health or other.",
+        "enum": [
+          "documents",
+          "clothing",
+          "tech",
+          "health",
+          "other"
+        ],
+        "type": "string"
+      },
+      "text": {
+        "description": "The item.",
+        "minLength": 1,
+        "type": "string"
+      },
+      "type": {
+        "const": "packing_item",
+        "description": "Always \"packing_item\".",
+        "type": "string"
+      }
+    },
+    "required": [
+      "type"
+    ],
+    "type": "object"
+  },
+  {
+    "description": "A place a trip visited, by its id from the trip's places. Update only.",
+    "properties": {
+      "country": {
+        "description": "Country.",
+        "minLength": 1,
+        "type": "string"
+      },
+      "id": {
+        "description": "Give the place's id to update it; leave out to add one.",
+        "type": "string"
+      },
+      "lat": {
+        "description": "Latitude.",
+        "maximum": 90,
+        "minimum": -90,
+        "type": "number"
+      },
+      "locality": {
+        "description": "The city it belongs to.",
+        "minLength": 1,
+        "type": "string"
+      },
+      "locality_country": {
+        "description": "ISO alpha-2 of that city.",
+        "pattern": "^[A-Za-z]{2}$",
+        "type": "string"
+      },
+      "lon": {
+        "description": "Longitude.",
+        "maximum": 180,
+        "minimum": -180,
+        "type": "number"
+      },
+      "type": {
+        "const": "place",
+        "description": "Always \"place\".",
+        "type": "string"
+      }
+    },
+    "required": [
+      "type"
+    ],
+    "type": "object"
+  }
+]

Changedupdate_trip1 field changed

addedInput schema / properties / budget_raw

Added value: +{
+  "description": "A budget with currency, e.g. \"AUD 8000\"; null clears it.",
+  "type": [
+    "string",
+    "null"
+  ]
+}

10 tool updatesOct 2, 2026
- First observeddelete_items
- First observedget_file
- First observedget_stats
- First observedget_trip
- First observedimport_trip
- First observedlist_trips
- First observedsave_items
- First observedsearch_photos
- First observedupdate_profile
- First observedupdate_trip

Related MCP Connectors

Finding HorizonsOAuth
ca.findinghorizons
Your saved places, trips and travel plans — see them, plan days, and add to them from your AI.
Travel & Transportation Location Services
1
Traveler.mdOAuth
md.traveler
A traveler's portable travel profile and trip plans. It remembers, it does not search or book.
Knowledge & Memory Note Taking
1
TripLedgerOAuth
app.tripledger
Travel ledger for AI: journeys, stays, expenses, tax-residency day counts and Schengen 90/180.
Travel & Transportation Finance Legal & Compliance
1
AdóndeOAuth
com.getadonde
Plan trips and find hotels, tours and flights; build day-by-day itineraries. Account required.
1

Related MCP Servers

trips-flights
Travel & Transportation
leedeadalus
A
license
Not graded
quality
D
maintenance
Enables tracking flights and grouping them into trips, with tools to create, list, and manage trips and flight bookings.
Updated 3 months ago (2026-08-02 00:09 UTC)
ISC
Departi MCP Serverofficial
Travel & Transportation Legal & Compliance
Departi
A
license
A
quality
B
maintenance
Travel compliance and trip planning for digital nomads — visa requirements, tax residency analysis, Schengen 90/180-day tracking, and curated accommodation, transport, and experience search across 189 European destinations.
Updated a month ago (2026-09-10 11:02 UTC)
7
MIT
wanderlog-mcp
Travel & Transportation Finance Note Taking
Owens558
A
license
Not graded
quality
A
maintenance
Lets Claude or any MCP-compatible agent view and build trip itineraries through conversation, adding places, notes, hotels, transit legs, car rentals, checklists, and budget expenses, plus searching destinations, hotels, and user-written travel guides. It can also restructure existing trips by renaming days, moving blocks, editing or removing entries, changing dates, and producing shareable links.
Updated 7 days ago (2026-10-16 18:30 UTC)
103 npm
MIT
tripkit
Travel & Transportation Calendar Management
kovartravis
A
license
Not graded
quality
B
maintenance
Enables agents to maintain a persistent, local-first trip ledger with typed tools for managing trips, flights, stays, day plans, people, packing lists, and transit sketches, plus markdown and ICS exports.
Updated a month ago (2026-09-23 17:22 UTC)
MIT

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.

Server Details

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Related MCP Connectors

Related MCP Servers

Departi MCP Serverofficial

Glama MCP Gateway

Resources