SlickTrip

List bucket lists

list_bucket_lists

Read-onlyIdempotent

Use to see the flight and hotel bucket lists on the signed-in account, each with its settings, the best deals found so far, and the bucket_id that update_bucket_list, remove_bucket_list and share_link take.

Input Schema

Name	Required	Description	Default
`name`	No	Only the bucket lists the traveler asked about: words from a list's name or its places, e.g. 'Firefall' or 'Lisbon'. Leave out to list them all.
`limit`	No	How many to return, newest first, 1-200.

Output Schema

Name	Required	Description
`code`	No	On an error: a machine-readable kind, e.g. unknown_place
`note`	No	How to remove; price semantics
`count`	No	Number of bucket lists returned
`field`	No	On unknown_place: which argument (origin, destination, ...)
`status`	No	error \| sign_in_required (absent on success)
`message`	No	Error or sign-in message from the server wrapper
`manage_url`	No	slicktrip.com saved-buckets page link
`suggestions`	No	On unknown_place: places to offer the traveler, each with code, name, kind (airport, all airports in the city, nearby airport), city, country
`bucket_lists`	No	Flight items (bucket_id, kind, route fields, months, window, nights, price, best_deals...) and hotel items (location, nights, adults, months, best_deals...)
`places_assumed`	No	Place names this call resolved on its own, e.g. 'Portland = Portland, OR (PDX)'; tell the traveler

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 22, 2026

addedInput schema / properties / name

Added value: +{
+  "anyOf": [
+    {
+      "maxLength": 120,
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Only the bucket lists the traveler asked about: words from a list's name or its places, e.g. 'Firefall' or 'Lisbon'. Leave out to list them all.",
+  "title": "Name"
+}

First observedOct 5, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and openWorldHint=false, so the safety profile is covered. The description still adds real value by disclosing the payload contents (settings, best deals found so far, bucket_id) rather than just repeating 'list'. It doesn't mention pagination beyond what the schema's limit field implies, which is the only gap.

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?

A single well-formed sentence that front-loads the purpose and then appends the return-value details and the sibling linkage. Dense but every clause carries information; no filler or repetition of 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?

With annotations covering the safety profile and an output schema covering the return shape, the description only needs to state scope and purpose, which it does. The downstream bucket_id pointer is a genuinely useful addition for a tool in a large, mutation-heavy sibling set.

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 both the name filter and the limit ordering ('newest first') are already documented in the schema. The description adds no syntax, format, or filtering hints beyond that, which is fine but earns only the 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 and resource ('see the flight and hotel bucket lists on the signed-in account') and enumerates what each entry contains, which cleanly distinguishes it from the add_*, update_*, and remove_* siblings. An agent can tell this is the read-side of the bucket-list family 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.

Usage Guidelines4/5

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

The opening 'Use to see...' plus the mention that entries carry the bucket_id consumed by update_bucket_list, remove_bucket_list, and share_link makes the read-before-mutate usage pattern clear. It stops short of explicit when-not-to-use guidance, but the alternatives are implied by naming the downstream tools.

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

All SlickTrip tools Inspect

Try in Browser

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

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?