Skip to main content
Glama
KatouMegumii

vac-product-recommend-mcp

by KatouMegumii

recommend_tours

Find top Ctrip group tour recommendations by entering a keyword, then filter by travel dates, budget, rating, and more. Get ranked results with links in Markdown tables for quick comparison.

Instructions

在携程跟团游「精选/综合」列表里搜索并按需求推荐产品。当用户要『找/推荐/搜索/比较』携程的跟团游、拼小团、私家团、邮轮、自由行、定制游等旅游产品时,直接调用本工具(无需用户指定工具名)。根据点评分、销量、点评量、供应商等维度排序,返回 TopN 产品信息、链接和推荐理由。返回的是 Markdown 表格;最终回复用户时请直接使用该表格,不要改写格式。

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
daysNo游玩天数,支持单值/区间/多选:7、7天、6-8、6,7,8。若用户同时给了出发日和返程日,必须精确计算:天数 = 返程日 - 出发日 + 1,并传该单值,例如 9月25日出发、10月5日返程 → days=11,不要传 10-12
brandNo品牌,可多选(逗号分隔),支持:携程自营/自营
levelNo产品钻级,可多选(逗号分隔),支持:5钻/5、4钻/4、3钻/3、2钻及以下
promoNo优惠活动,可多选(逗号分隔),支持:机票用户价、拼满返现、717嗨玩节
top_nNo返回前几名推荐,默认3,可改成5/10等
vendorNo供应商名称或ID,可多选(逗号分隔),名称支持模糊匹配,例如:随程国旅假期,2256920
keywordYes目的地/主题关键词,例如:土耳其、日本、云南
rank_byNo排序规则:composite=综合分(默认) sales=销量 rating=好评 comment_count=点评量 price_asc=价格升序 price_desc=价格降序composite
vehicleNo交通方式,可多选(逗号分隔),支持:不含往返交通 / 不含大交通 / 当地参团
min_soldNo最低销量,默认0(不过滤)
max_pagesNo最多抓取页数,默认2页(约30个候选)
min_scoreNo最低点评分,仅当用户要求『评分/好评优先』时才设置;默认0表示不过滤。人数请用 team_size,不要用本参数
must_tagsNo硬性标签过滤,逗号分隔,产品标题/标签必须全部包含,例如:0购物,含领队
page_sizeNo每页抓取数量,默认15
team_sizeNo团队规模,可多选(逗号分隔)。用户提到人数时必须设置本参数:1-9人→最多9人,10-20人→10-20人,21人及以上→21人及以上。例如:4人→最多9人
budget_maxNo单人预算上限(人民币),用于过滤
travel_wayNo产品类型/旅行方式筛选,支持多选,传数组,例如:['拼小团','跟团游']。仅当用户明确说『私家团/独立成团/私人团』时才传私家团;用户只说『X人』不代表私家团,不要据此设置本参数
requirementNo用户额外要求,例如:0购物、含领队、直飞、预算2万以内。命中的标签会加分,预算请用 budget_max 传数字。
suit_personNo适用人群,可多选(逗号分隔),支持:亲子友好、老友会严选
service_tagsNo服务保障,逗号分隔,支持:0购物、一价全包、0购物0自费、成团保障、含接送机/站
depart_city_idNo出发城市ID,2=上海,1=北京,默认22
departure_dateNo出发日期(仅出发日,不是返程日)。格式 YYYY-MM-DD。只有用户明确说『出发日期在某段时间内』才用 YYYY-MM-DD~YYYY-MM-DD。若用户同时给了出发日和返程日,只用出发日,例如:9月25日出发、10月5日返程 → departure_date=2026-09-25
candidate_limitNo候选池上限,会自动分页(例:50 会拆成 25×2)。不传则用 page_size × max_pages。
include_trafficNo是否含往返大交通。仅当用户明确要『含往返交通』时传 是;用户说『不含往返交通/不含大交通/当地参团』时请改用 vehicle 参数,不要传本参数
Behavior5/5

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

No annotations are provided, so the description bears full responsibility. It thoroughly discloses behavior: it returns a Markdown table, sorts by multiple dimensions, and respects numerous parameter constraints (e.g., '仅当用户明确说' clauses). This high level of detail ensures the agent understands side effects and conditional logic, exceeding typical transparency.

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

Conciseness5/5

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

The description is a single, well-organized paragraph that front-loads the purpose and usage, then details the output. Despite the large parameter count, the description is concise and avoids redundancy—every sentence adds necessary context. The format is clean and easy to parse.

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

Completeness5/5

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

Given the complexity of 24 parameters and many conditional rules, the description is remarkably complete. It covers the core behavior, output format, sorting logic, and provides explicit guidance on how to interpret user intents for each parameter. No major aspects are missing, and the lack of an output schema is mitigated by the clear statement that the result is a Markdown table.

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

Parameters5/5

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

All 24 parameters have rich, descriptive explanations that go beyond type information. Examples include team_size mapping from user counts, departure_date format and conditionality, and explicit instructions like 'min_socre' only when the user requests rating priority. This exceeds the 100% schema coverage baseline by providing actionable context for each parameter.

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 clearly states the tool's purpose: to search and recommend tour products on Ctrip based on user requirements, with sorting and TopN output. It explicitly lists the action verbs (找/推荐/搜索/比较) and specifies the product types covered, making its function unambiguous and distinct from sibling tools like search_tours.

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

Usage Guidelines5/5

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

The description provides explicit when-to-use guidance: it says to call this tool directly whenever the user asks to find, recommend, search, or compare these tour products, without needing the user to name the tool. It also explains sorting dimensions and output format, covering the primary usage scenarios.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/KatouMegumii/vac-product-recommend-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server