Skip to main content
Glama

booking_recommend

Recommends available continuous time slots for room and venue booking on specified dates, time ranges, and minimum durations, reducing repeated availability checks.

Instructions

场景级复合求解:智能推荐空闲连续时段(避免多次轮询)。

Input Schema

NameRequiredDescriptionDefault
dateNo目标日期,默认 today。
timeNo期望时段范围,如 14:00-18:00。
typeNo场地类型关键词,如 研讨室/自习。
limitNo最大返回条数,默认 8。
keywordNo房间名称关键词,如 云谷/301。
min_hoursNo最小连续可用小时数,如 1.5。

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

C2.5/5.0
Behavior2/5

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

With no annotations, the description carries the full burden of disclosure. It does not say whether the operation is read-only, whether results are ranked by fit, how continuity is computed across rooms, or what happens when no qualifying slot exists. '避免多次轮询' hints at the tool's value proposition of a single batched query, but it does not describe how the tool actually behaves.

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

Conciseness3/5

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

It is a single short sentence, so it is concise, but it is under-specified rather than efficient. The opening phrase '场景级复合求解' occupies a lot of space without adding meaning, and the actual purpose appears after it.

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

Completeness2/5

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

For a 6-parameter tool with no annotations and no output schema, the description is too thin. It does not describe the shape of returned slots, how a slot qualifies as contiguous, or how min_hours interacts with time and limit. An agent must infer the return contract entirely.

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%: date, time, type, limit, keyword, and min_hours each carry their own descriptions, including examples and defaults. The description adds no parameter-level meaning beyond the schema. That is expected when coverage is this high, so the baseline score of 3 applies.

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

Purpose3/5

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

The description contains a specific verb phrase, '智能推荐空闲连续时段' (intelligently recommend free contiguous time slots), but it buries it after the vague jargon '场景级复合求解', which tells an agent nothing. It does distinguish the tool somewhat from sibling tools such as sport_scenes and sport_reservations by implying a recommendation rather than a raw listing, but that distinction is only implicit.

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 only usage hint is '避免多次轮询' (avoid repeated polling), which implies the tool should replace manual iteration but never states when to choose it over sport_days, sport_sites, or sport_reservations. There are no exclusions, prerequisites, or alternative-routing guidance.

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